Hi Matthias,
You wrote on Mon, Sep 30, 2019 at 08:45:24AM +0200:
> The way I went with was changing line 570 of ftdi_eeprom/main.c from
> if (command == COMMAND_ERASE)
> to
> if ((command == COMMAND_ERASE) || (command == COMMAND_FLASH))
>
> After all, (re-)flashing the chip requires deleting any existing data, so
> this did the trick for me.
> I am not sure if there are any edge cases where erasing the whole chip is
> undesirable.
some chips support storing user data in a reserved area. It has been ages since
I last tweaked around the eeproms, but it could be that this area gets cleared
by the ERASE command, too.
May be someone else can chime in here.
> As a side note: It would be nice to have chip size refactored in
> src/ftdi.c so the size of the various chips isn't hardcoded in more than
> one spot.
> (I suggest a function that takes chip type id as parameter and returns
> size or values <0 in case of error.)
support for different chips and eeprom sizes was growing over the years. The
problem here is verifying code changes as I just have a few different devices
lying around. The eeprom size also affects the location device strings offsets.
See also the "size guessing" code in ftdi_read_eeprom():
commit 2d543486ed96287e3d0f8f33d82321dfc2f835d0
Author: Uwe Bonnes <bon@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
AuthorDate: Wed Sep 8 15:50:06 2010 +0200
Remove ftdi_read_eeprom_getsize() function. Integrate in into the
ftdi_read_eeprom() function. On ftdi_eeprom_write() another approach is needed
Cheers,
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
