Sandu:

Some things to consider....

1) What is the nature of how you do the interface on the I²C bus? Are you doing this by bit bang? You should gather some information on how fast you are able to communicate to the I²C memory module.

2) You mention the use of a miniOS. You should clarify just what this means. If you are actually using a formalized multi-tasking structure for this simple application you may want to reconsider this decision. It is so easy to build up embedded applications where you schedule most of your real time activities from timer interrupt triggers that the overhead of some formalized OS structure may be just too high of performance price to pay.

3) If you are interfaced to the I²C memory module at an interface rate of 100kHz, the standard full speed of the I²C bus, my rough calculation shows that such 256 byte page writes are going to take about 25 to 28 milliseconds to complete the raw data transfer. You then have the write pulse time of the memory to consider on top of that if you are using non-volatile type memory such as a serial EEPROM. You did not tell us how often you try to do this page write so it is hard to give much specific guidance. You should maybe consider using a memory module that could support a 400kHz or faster serial interface rate on the I²C interface. Take a serious look at an 8052 derivative that has an onboard I²C peripheral and use that to get as fast as possible transfer rate. Also consider looking at some memory technology that may not have the write pulse delay penalty like EEPROM has. Look into serial FLASH or FRAM.

4) You did not tell us how the sensor is interfaced to the MCU. If that is also interfaced via I²C and you are reading the sensor on a periodic basis then maybe that activity is colliding with the time span it takes to write the blocks of data to the I²C memory module. In this case you may need to consider using a sensor that interfaces in a different way. Consider a SPI device or a sensor that uses an on-board A/D converter of the microcontroller.

5) It seems to me that you have to evaluate carefully how much time the sensor activity and the page write activity are actually taking in your specific system. You should deploy two spare port pins and set one high at the beginning of each of these two activities and then back low as the respective activity completes. You can then evaluate the system timing performance on an oscilloscope. Sometimes this can be quite enlightening as to what your code actually is doing.

6) Lastly there is a possibility that the memory buffer pool structure that you are using may not be a safe design from the aspect of two processes accessing control variables, indexes, or pointers at the same time. Look carefully at this and think through what can happen if one task is in the midst of using/updating a multi-byte control variable or pointer whilst the other task comes along and changes it. Sometimes it is necessary to use queues that have separate input and output mechanisms to prevent collisions. Other times it is as simple as disabling interrupts around certain critical code sections.

Michael Karas