heuristicjohn
Posts: 39
Joined: Thu Jan 31, 2013 11:55 pm

Re: I2C Access

Fri Mar 08, 2013 11:38 am

My problem is that each of these commands works on its own, but when I execute them in sequence I get the error message "no acknowledge".
(after deep thought): (1) so it must be a timeout problem, and (2) so the workaround is to put a short time delay (10 ms ?) between successive writes (reads are OK) (3) so now I've caught up with everybody else.

heuristicjohn
Posts: 39
Joined: Thu Jan 31, 2013 11:55 pm

Re: I2C Access

Fri Mar 22, 2013 3:36 pm

My query Mar 07:
I am attempting to write data to an EEPROM on the I2C bus (under RISCOS). The device is at address &50, and in the example I write &56 to internal memory location &1234. I then set the memory pointer using a write without data, and then read back the data. My problem is that each of these commands works on its own, but when I execute them in sequence I get the error message "no acknowledge".
I have now downloaded the latest RISCOS version (2013-03-09), and find this problem still exists (and can still be solved by inserting time delays between messages).

Anyone else have this problem ? I'd like to know if this is an unfixed bug or if I'm just doing something silly (again).

redwood
Posts: 2
Joined: Fri Mar 22, 2013 5:35 pm

Re: I2C Access

Fri Mar 22, 2013 5:42 pm

This from the Microchip 24Cxx data sheet:
Note:
The 24XX00 does not generate any
Acknowledge bits if an internal program-
ming cycle is in progress.
A write cycle takes 4mS, could this be the reason you see the no ack message?

redwood
Posts: 2
Joined: Fri Mar 22, 2013 5:35 pm

Re: I2C Access

Fri Mar 22, 2013 6:09 pm

I'd like to know if this is an unfixed bug or if I'm just doing something silly (again).
The microchip datasheet indicates that write cycles for 24Cxx chips take 4mS to complete and during this time there will be no ack on the bus.

A quote from the datasheet:
Since the device will not acknowledge during a write
cycle, this can be used to determine when the cycle is
complete (this feature can be used to maximize bus
throughput). Once the Stop condition for a Write
command has been issued from the master, the device
initiates the internally timed write cycle. ACK polling
can be initiated immediately. This involves the master
sending a Start condition followed by the control byte
for a Write command (R/W = 0). If the device is still
busy with the write cycle, then no ACK will be returned.
If no ACK is returned, then the Start bit and control byte
must be re-sent. If the cycle is complete, then the
device will return the ACK and the master can then
proceed with the next Read or Write command.
Could this be the cause of your problem?

heuristicjohn
Posts: 39
Joined: Thu Jan 31, 2013 11:55 pm

Re: I2C Access

Fri Mar 22, 2013 8:54 pm

Redwood - many thanks - all now clear !

Return to “RISCOS”