-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MAX78000]: Adding EEEPROM_Emulator example. #330
[MAX78000]: Adding EEEPROM_Emulator example. #330
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! A couple minor questions/comments below
|
||
To write to the EEPROM, transmit a master write command followed by two write address bytes, and finally the data bytes. The write address is a 16-bit address, with the first address byte as the MSB and the second as the LSB. You may transmit as many data bytes as you wish, however only the last 64 data bytes will be stored. If you write past the end of the EEPROM address space, the write will continue at the beginning of the EEPROM address space. | ||
|
||
To read from the EEPROM, simply issue a master read command and the device will begin transmitting its stored data from where the previous read operation left off. It is also possible to specify where the read operation will start by issuing a master write command followed by the two byte read address (same format as the write address), then a repeated start and master read command. Once you have received all the bytes you need, issue a NACK+STOP. If you read past the end of the EEPROM address space, the write will continue at the beginning of the EEPROM address space. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this section could use some refinement. Consider specifying the read location as the "read pointer", then tell how to set the read pointer, then highlight that bytes will be transmitted continuously until the master issues a NACK+STOP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I re-wrote it. Let me know what you think.
|
||
This example utilizes the MAX78000 to emulate a 32KiB EEPROM chip. | ||
|
||
This "EEEPROM" can only perform read and write operations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider linking to the I2C spec. Unfortunately the official spec is behind an NXP account wall, but this link has some public info: https://i2c.info/i2c-bus-specification
|
||
To help with syncronization, a "Ready Signal" is output from a GPIO pin. When the signal is high, the EEPROM is not currently processing a transaction and is ready for the next transaction to begin. When the signal is low, the EEPROM has either not been initialized or is currently still processing the previous transaction, and thus is not ready to process the next transaction. | ||
|
||
**** NOTE ****: Due to the limitations of the flash controller, this example was implemented with a pseudo-cache. The cache copies the current page being operated on into volatile memory, where all reads and writes are performed. The cache is only written back to flash when there is a cache miss. So, if you wish to ensure the data you have written gets stored in flash, you will need to perform a read or write operation on another flash page. For reference, the flash memory used as EEPROM memory in this example is made up of four 8KiB flash pages. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the flash controller's limitations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's talk about this next time we're both in the office.
|
||
while (1) { | ||
// Start next slave transaction | ||
eeprom_prep_for_txn(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we change this to an interrupt-driven model? I think that would be more valuable than the servicer function model and would also open the door for putting the micro in LP mode when idle.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's talk about this next time we're both in the office.
…g a cache write back command, and updating the README.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Optionally add a drawing/timing diagram to the readme to cover the I2C communication scheme
@@ -42,10 +42,6 @@ | |||
#define PAL_SYS_RISCV_LOAD 0 | |||
#endif | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we unintentionally reverted a few things.
This PR adds a new example which uses the MAX78000 to emulate the behavior of an EEPROM chip. It is also meant to be a demonstration of how to use ADI micros as I2C slaves.