Hello Uwe,
On Wednesday, 15. September 2010 18:26:30 Uwe Bonnes wrote:
> appended tar file contains 78 git patches that bring libftdi EEPROM
> handling to a state that lets me read and write FT2232C/FT232R and
> FT2232H on different boards with different setting with no error found
> yet when decoding later with FTDI tools.
Wow! Congratulations on that one. According to the commit dates,
this only took you like seven days to decode...
> As nearly all EEPROM handling needs to know ftdi->type and usage of
> ftdi->error_str comes handy, I changed the API to work on struct
> ftdi-context. "struct eeprom" and string buffer handling is now done
> inside libftdi, so some APIs formerly needed to (intransparently)
> manipulate these items are removed.
After a quick code review, this would have been my first question.
Back in 2003, I intentionally kept those two apart as I thought
the eeprom stuff is not needed for daily operation.
Though it won't hurt except for wasted memory and as it
simplifies things, I'm ok with this.
> I propose also to move all EEPROM related code to a seperate file, as
> ftdi.c is quite big now
Good idea. I also thought about merging the separate ftdi_eeprom tool
into libftdi as new EEPROM features usually require a new libftdi
version -and- a new ftdi_eeprom version.
ftdi_eeprom was a standalone program as I didn't want to burden
normal libftdi users to install libConfuse back in the days.
Maybe we could just disable the build of ftdi_eeprom
if libConfuse is not installed?
I'll check your decoded EEPROM map with the sparse NDAed documents I have
floating around for the old chip types. Could take me some days
as I'm still catching up from the holidays.
How should we proceeded? If you don't mind I'll put this into a separate
git branch so we can cook it further without serious EEPROM API breakage
for everyone else ;)
Cheers,
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
