You should strive to run the interface to the chip as fast as possible for this interface. Have you carefully checked all your bit-bang timing on a scope to make sure that it all looks OK?

How are you accomodating the 5 millisecond write pulse time of the AT25C1024? Are you doing BHUSY polling to ascertain when the devide is done writing? Or have you just done some type of tiemr delay? Do note that if you attempt to try to write the next block of 256 bytes before the current write is complete then that 2ND block will fail. That failure could go unnoticed if your bit-bang I2C routnes are not comprehending any NACK bits that may come back from the device. (Note that ignoring NACKs is a fault with some "free" I2C code you may have found on the web).



This CPU is a pokey 6 clocks / cycle. At your 12MHz clocking you will have difficulty getting the I2C bus even close to the 1MHz rate of you use bit bang methods. Can you post a real link to the Atmel "mini-OS' code you are using so I can look at it and determine just how "light weight" the thing actually is? I have my doubts about a pokey 1-2MHz instruction rate MCU being able to handle overhead of a task scheduling algorithm when you are doing repeatitive tasks that take 28 + 5 milliseconds to perform.



The TWI on your MCU is not limited in any way with regard to how the AT24C1024 serial EEPROM is addressed. Each byte of the serial memory module is sent out through the SSDAT register byte by byte. The 8-bit SSADR register of the TWI is would not be used at all when sending Master Mode transactions to the AT24C1024. The SSADR is used when the TWI is setup to respond as a Slave Device on the I2C bus. You should be able to get the I2C interface to run at 400kHz using the TWI.



Can you reveal what the proprietary interface is? Are you sure that this sensor device does not have some type of behavior where the software interface to the part gets into some mode that has an occasional long delay that causes some type system behavior that interferes with the long transaftions required of the AT24C1024 memory?





Before you completely convince yourself that there is not an overlap of control to critical variables in the queue control mechanism you should at least do one of two things... a) use the spare port bits scheme to show when each entity supposedly "owns" the memory pool controls and check on the scope if there is any overlap...b) try EA=0 / EA=1 instructions around critical code sections to make sure you do or do not still see the same problems.

Michael Karas