Monochron RATT firmware question

[ekeefe]

Hello,

Thank you for a really cool clock kit, I am a unique electronic clock collector. I never had the opportunity to purchase the original 'Pong' clock, so this was a great find.

I just built my monochron kit. I love the display and the case. Good job!

I thought the kit was going to be shipped with the TV tennis firmware, but mine has the XDaliChron firmware.

I downloaded the archive from github for the RATT version, but the .hex file in the firmware folder was also the XDaliChron. Is there a broken link? Am I doing something wrong? Is the .hex file for the RATT clock available pre-compiled?

I was able to down load the hex file to the clock so I know I have the USB/ARVDUDE stuff working. I followed the instructions.

Any help would be super.

Once again, thank you for such a great clock.

ED

[adafruit]

Hi Ed. we had a bit of a mixup in the GitHub repository. its fixable but will take a day to clean up

however, so you dont have to wait, here is what SHOULD be the right .hex
please try it!

[ekeefe]

Thank you!

I downloaded the file and uploaded it to the clock. No problems.

Thank you so much for the quick response.

ED

[adafruit]

yay! we'll get this fixed properly asap

[dataman]

It's github?
Just backout, no?

[adafruit_support2]

For the time being, you can find the main RATT code on my fork, http://github.com/CaitSith2/monochron

I would have fixed the master branch, except that I no longer have write access to the http://github.com/adafruit/monochron (which I only found out when I tried to revert the master branch just now. )

[caitsith2]

Okay, Master branch has been fixed.

[dataman]

Can we perhaps negotiate promoting developer code fixes back up to the master branch?
I mentioned this code fix last October, and it went nowhere.
This is a bug, in a base library, doesn't really affect anyone but intruderchron,
But it's proliferating through the different versions now.

I'm working on combining 7 Chron, IntruderChron, and Ratt Chron into 1 version.
Change around the menu options, and you can select the display style.
And, if there's enough room, maybe Dali Chron as well.

[caitsith2]

Okay, bug fix applied to all branches and forks under my control.

[caitsith2]

dataman: You may wish to checkout the changes I recently pushed to ALL branches that I have write access to. I fixed a rare lockup bug in regards to setting the date and time.

Code: Select all

uint8_t readi2ctime(void) {
  uint8_t regaddr = 0, r;
  uint8_t clockdata[8];
 
  // check the time from the RTC
  cli();
  r = i2cMasterSendNI(0xD0, 1, &regaddr);

  if (r != 0) {
    DEBUG(putstring("Reading i2c data: ")); DEBUG(uart_putw_dec(r)); DEBUG(putstring_nl(""));
    while(1) {
      beep(4000, 100);
      _delay_ms(100);
      beep(4000, 100);
      _delay_ms(1000);
    }
  }

  r = i2cMasterReceiveNI(0xD0, 7, &clockdata[0]);
  sei();

  if (r != 0) {
    DEBUG(putstring("Reading i2c data: ")); DEBUG(uart_putw_dec(r)); DEBUG(putstring_nl(""));
    while(1) {
      beep(4000, 100);
      _delay_ms(100);
      beep(4000, 100);
      _delay_ms(1000);
    }
  }

  time_s = ((clockdata[0] >> 4) & 0x7)*10 + (clockdata[0] & 0xF);
  time_m = ((clockdata[1] >> 4) & 0x7)*10 + (clockdata[1] & 0xF);
  if (clockdata[2] & _BV(6)) {
    // "12 hr" mode
    time_h = ((clockdata[2] >> 5) & 0x1)*12 +
      ((clockdata[2] >> 4) & 0x1)*10 + (clockdata[2] & 0xF);
  } else {
    time_h = ((clockdata[2] >> 4) & 0x3)*10 + (clockdata[2] & 0xF);
  }
 
  date_d = ((clockdata[4] >> 4) & 0x3)*10 + (clockdata[4] & 0xF);
  date_m = ((clockdata[5] >> 4) & 0x1)*10 + (clockdata[5] & 0xF);
  date_y = ((clockdata[6] >> 4) & 0xF)*10 + (clockdata[6] & 0xF);

  return clockdata[0] & 0x80;
}

void writei2ctime(uint8_t sec, uint8_t min, uint8_t hr, uint8_t day,
        uint8_t date, uint8_t mon, uint8_t yr) {
  uint8_t clockdata[8] = {0,0,0,0,0,0,0,0};

  clockdata[0] = 0; // address
  clockdata[1] = i2bcd(sec);  // s
  clockdata[2] = i2bcd(min);  // m
  clockdata[3] = i2bcd(hr); // h
  clockdata[4] = i2bcd(day);  // day
  clockdata[5] = i2bcd(date);  // date
  clockdata[6] = i2bcd(mon);  // month
  clockdata[7] = i2bcd(yr); // year
 
  cli();
  uint8_t r = i2cMasterSendNI(0xD0, 8, &clockdata[0]);
  sei();

  //DEBUG(putstring("Writing i2c data: ")); DEBUG(uart_putw_dec()); DEBUG(putstring_nl(""));

  if (r != 0) {
    while(1) {
      beep(4000, 100);
      _delay_ms(100);
      beep(4000, 100);
      _delay_ms(1000);
    }
  }

}

Specifically, the problem lies in those two functions. The i2c library does NOT disable all interrupts, just the ones specific to i2c itself, when using the No interrupt version of the i2c calls. Of course, if one of the interrupts you didn't disable happens to call readi2ctime, while the processor happens to still be inside of i2cMasterSendNI in the writei2ctime function, then yeah, bad things happen, that lead to a total lockup.

This affects ALL branches. Since I don't have write access to your fork, I can't fix the bug for you, but you should be able to do that very easily.

[dataman]

Cait,

Thank you for the heads up!

Pretty soon, we won't need no stink'n branches.
Check my next subject, MultiChron!

[surfjunkie]

Help! I have my clock built, I was able to get the FTDI to link up and talk to my clock, but when I add the file to write....it comes up with a "parse error". I am either not copying the right file to managing the the file upload right....can someone guide me through this?
I am nearly there...I am just flubbing up somewhere. Help if you can.
Thanks