Adding methods to handle reading and writing of the EEPROM through li… #87
Conversation
|
I will give it a try with a real device, but I think it would be nice to add this feature to PyFtdi. There are a couple of things to fix (move doc/URL to I'm worrying a bit with the address management: I think it is safer to raise an exception if the client attempts to access an invalid address than silently ignore the error and access an unexpected location - especially if this may corrupt the EEPROM contents and eventually brick the FTDI :-) Thanks. |
|
Sorry about the formatting issues. I am still getting use to the format. Thanks for taking care of them. Yes, you are absolutely correct that an exception should be raised, at least in _write_eeprom_raw() and _write_eeprom_word(). For the “public” method write_eeprom(), since it reads the entire contents of the EEPROM and inserts the new data as bytes, addr and data length can safely be odd. I think that it makes for a more natural interface to keep them as a byte address and byte data. So an exception for odd addr or odd len(data) is not required in write_eeprom(). For example, if addr is odd, addr is decremented by 1 for writing, but it is simply writing back the byte that was read from the EEPROM. |
|
Sorry sgoadhouse, I'm really busy by now - I'll try to review all your changes when I get some spare time; thanks for the fixes. |
|
Understood. Thanks for letting me know.
…--
Stephen Goadhouse
Electronics Engineer
University of Virginia
Physics Department
office: room 265
434-982-5594
sgoadhouse@virginia.edu<mailto:sgoadhouse@virginia.edu>
http://faculty.virginia.edu/phys-electronics<http://faculty.virginia.edu/phys-electronics/>
For any Electronics Shop requests, please email the team at phys-electronics@Virginia.EDU<mailto:physics-electronics-shop@Virginia.EDU>
or feel free to come see Larry St. John in the Electronics Shop in Physics Rm 115
On Feb 22, 2018, at 08:28, Emmanuel Blot <notifications@github.com<mailto:notifications@github.com>> wrote:
Sorry sgoadhouse, I'm really busy by now - I'll try to review all your changes when I get some spare time; thanks for the fixes.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#87 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAfWSqGG2u8Nmi6Yoa3-W2Ajx9KOak2lks5tXWtdgaJpZM4SLEB3>.
|
|
Checking at the pull request changes, I do not really see where a read-modify-write is performed. As there is no "erase" feature, I do not get why extending a non-aligned write with '0xFF' is a better value that any random value (vs. accessing a NOR or NAND flash, where '0xFF' would make sense). Did I miss something? Moreover, if addr & 1 && length & 1, we end up reading out two extra bytes, for example, which get not truncated (if the return buffer is 2 byte longer than requested). Sounds weird, does not it? Nevertheless I've imported your code and started to work on it, see eeprom-access branch (WIP) |
|
The read-modify-write is handled in write_eeprom(). The self.read_eeprom() reads the entire contents of the EEPROM. You need to recompute the checksum over the entire contents of the EEPROM so I read it all out at the beginning. I then put in the new data with “eeprom[addr:addr+len(data)] = data” and then compute the checksum over the new EPROM contents. I then write back the new data using even byte boundaries and then write the new checksum.
I do think that in the accessor methods, _write_eeprom_raw() & _write_eeprom_word(), these should raise an exception if addr or data or both are odd, as you once suggested. This may be a good idea for read_eeprom() and calc_eeprom_checksum() as well.
…--
Stephen Goadhouse
Electronics Engineer
University of Virginia
Physics Department
office: room 265
434-982-5594
sgoadhouse@virginia.edu<mailto:sgoadhouse@virginia.edu>
http://faculty.virginia.edu/phys-electronics<http://faculty.virginia.edu/phys-electronics/>
For any Electronics Shop requests, please email the team at phys-electronics@Virginia.EDU<mailto:physics-electronics-shop@Virginia.EDU>
or feel free to come see Larry St. John in the Electronics Shop in Physics Rm 115
On Feb 26, 2018, at 11:52, Emmanuel Blot <notifications@github.com<mailto:notifications@github.com>> wrote:
Checking at the pull request changes, I do not really see where a read-modify-write is performed. As there is no "erase" feature, I do not get why extending a non-aligned write with '0xFF' is a better value that any random value (vs. accessing a NOR or NAND flash, where '0xFF' would make sense). Did I miss something?
Moreover, if addr & 1 && length & 1, we end up reading out two extra bytes, for example, which get not truncated (if the return buffer is 2 byte longer than requested). Sounds weird, does not it?
Nevertheless I've imported your code and started to work on it, see eeprom-access branch (WIP)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#87 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAfWSsJoPhy9_8sN0XQC4FCCuJufdPa8ks5tYuEwgaJpZM4SLEB3>.
|
|
I've added those sanity checks in the latest dev branch (eeprom-access), and the code should now deal with any kind of access - 16 bit aligned or not. I've added a couple of unit test for this feature. I have not tried the write feature - only simulated it for now. The very useful think now would be to add a new file/class with helper function to encode/decode the EEPROM content, but that's quite a piece of code. |
|
Thanks for the test cases. A very useful thing to include.
If you try a write, I recommend writing higher then byte address 0x80 where the user section of the EEPROM resides in most newer devices (like the ‘H’ series). Also, be sure to keep the high byte in the word as 0x00. Apparently, these are 16-bit unicode characters. If the upper byte in the word is not 0x00, it may be an invalid code and cause some program to crash. I already ran into this when using the eeprom executable within the libftdi package to read back the EEPROM after doing test writes.
encode/decode of the EEPROM like how is done with the eeprom executable within libftdi would be great, but the byte definitions of the EEPROM is considered secret information and you can only receive it from FTDI if you sign a Non-Disclosure Agreement (NDA) with them. If you do sign the NDA, then you likely cannot use the information in open source code. So instead, you could glean the information from the libftdi code, but they really should not make that information public. So it may be best to just stay away from that legal grey area.
…--
Stephen Goadhouse
Electronics Engineer
University of Virginia
Physics Department
office: room 265
434-982-5594
sgoadhouse@virginia.edu<mailto:sgoadhouse@virginia.edu>
http://faculty.virginia.edu/phys-electronics<http://faculty.virginia.edu/phys-electronics/>
For any Electronics Shop requests, please email the team at phys-electronics@Virginia.EDU<mailto:physics-electronics-shop@Virginia.EDU>
or feel free to come see Larry St. John in the Electronics Shop in Physics Rm 115
On Feb 27, 2018, at 12:13, Emmanuel Blot <notifications@github.com<mailto:notifications@github.com>> wrote:
I've added those sanity checks in the latest dev branch (eeprom-access), and the code should now deal with any kind of access - 16 bit aligned or not. I've added a couple of unit test for this feature. I have not tried the write feature - only simulated it for now.
The very useful think now would be to add a new file/class with helper function to encode/decode the EEPROM content, but that's quite a piece of code.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#87 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAfWSjgWiBBbwTSaWVrxo1-PdPZsCsLLks5tZDeZgaJpZM4SLEB3>.
|
|
Yes, I know about the stupid FTDIchip NDA policy. Back in the inception days of PyFTDI, I had to reverse engineer the Windows USB driver communication to support FT4232 devices... :-( They are still many unknown areas with FTDI devices, such as timings for example. I already had a look @ libftdi, and adding a comprehensive EEPROM encode/decode support will require several hours of (boring) work :-) I think at least common EEPROM needs (such as changing the serial number and the product description string) could be easily added. I just do not have spare time for now to write this feature... |
|
Ported and adapted to a193973, thanks |
…busb ctrl_transfer(). I have tested these quite a bit with a FT4232H but have not tested with older FTDI devices. If these are accepted, it may be good to duplicate the write eeprom warning in my code changes to the README.