Slots with i2C

matchbox

Senior Member
I was working on a project up to October last year, that contained the use of two slots on a 28X2.
Slot 1 contained a full function clock/alarm. And slot 0 monitored/controlled dozens of I/O's. Which required continuous scanning of those inputs.

The issue I have experienced, is the i2C bus loosing data sync as the programs shift back and forth between slot's, at least 6 x per second... Which is obviously slowed by changing command and flag variable data and the re-diverting of the program to where it left off.
I tried all sorts of methods... running i2C read in both slots, trying to resync the data as it entered each slot.
But can not maintain continous sync for longer than a 1 minute or so.

Both program memory's have used around 3500byte.

Both programs are 95% complete. But I couldn't get this to work... So I moved to other things and forgot most of what I tried.

Just thought I'd ask if anyone else found a fool proof way to accomplish this?

Thanks
 
Last edited:

Technoman

Senior Member
The clock is updated on interrupt from RTC every second?
Can you post a block diagram of your system?
 

matchbox

Senior Member
Unfortunately no.
I had built on this project and the memory usage got greater as I went along. A flag interrupt is already used elsewhere. And the hint pins are already hard wired in this project to other items. To rewire it, is more hassle than its worth.. Easier to just remove Slot 1 clock functionality. Hence why I have left it for the last 6 months.

I never did a layout of the circuit as such.
 

hippy

Technical Support
Staff member
Can you detail what "synchronisation" you are losing, in what way it is lost or how it manifests itself ?

A more detailed overview of what the program overall and each slot does may help identify where the issue is and how to resolve it.
 

matchbox

Senior Member
Can you detail what "synchronisation" you are losing, in what way it is lost or how it manifests itself ?
The RTC stops seconds counting on the clock readout.

I'm trying to throw my memory back that far, to what I tried. I remember getting some ideas from here, of what other people tried as well.
I few of those ideas would prevent a total lockup of the RTC data. But i assume because its continuously changing slots. It eventually stops counting second. And the only way to re-establish is a power cycle.

Slot 0. Has a RF communications, OLED, RTC, Audio file player, photo-transistor, tactile control, all using a multi-menu selection system to control and monitor various peripheral devices.
Slot 1. Has Full function yearly clock display, with time and alarm sett-ability via slot 0's subroutine.
Slot 2. Stores all the function and menu names for the scratch pad. And loads them to the scratch pad on power-up.

Also uses an 18m2 on the display, which uses two way comms and an interrupt from the 28X2.
An 08M2, handles the RF TX/RX side.

I had a quick skim over it today. And after 6 months.. I'm flat out, working out half of what I wrote :rolleyes:

Anyhow... I was just hoping for a few idea's from anyone who may have experienced a similar issue... Otherwise I don't have the motivation or time to get myself up to speed again on the project, if its going to end up with no success.. That's why I thought I'd ask here first.
But no big issues if nothing comes to mind... I know how difficult it can be to assist someone without totally immersing yourself in the project as well...Of which this one ain't simple by any means.
 
Last edited:

hippy

Technical Support
Staff member
I wouldn't have thought jumping between slots would lock-up the I2C bus but if it's locking up it's locking up. The two approaches would be to prevent lock-up, if one can figure out what is causing it and avoid doing that, or resolve it when it does happen.

I would be surprised if anyone else has experienced the issue simply because I doubt anyone has done the same.

If power-cycling does resolve the problem powering the RTC via an output pin would allow that to be power-cycled, a RESET command when things go wrong may be enough to return to correct operation.

Huge projects which simply don't work can be a PITA to debug and fix, and, as you are finding, hard enough to understand and remember how things were meant to work some time later.

One option is to tear it up and start again, implement incrementally checking everything still works as one progresses. That never looks appealing but often isn't as hard as it may first appear. Alternatively you could take that step back, get one half working, then incrementally reimplement the other half.

It might be worth zipping up your entire project and posting that as that might allow someone to spot an issue, suggest the best way forward,.
 
Top