Hi Uwe,
On Wednesday, 31. August 2011 19:31:40 Uwe Bonnes wrote:
> appended tar file resends the last 3 pending patches
> - Try to inihibit programming EEPROM with data for a different device
> and zero EEPROM memory image early (unmodified)
Applied, thanks.
> - Rewrite the baudrate calculation, tested for 232R and 232H
> (unmodified, tested with a scope on several devices)
I've verified the code changes manually and
the looked sensible to me.
Still this change affects all chips types,
so I wrote a unit test for the exisiting code.
If I apply your patch, the output changes in some areas a lot.
Could you apply your patch and run the unit test? It's done like this:
- The unit test gets automatically compiled
if the boost unit test framework is found. [cmake only]
- You can enter the "test" directory and run ./test_libftdi.
Also you can focus on single tests only with this:
"./test_libftdi --run_test=Baudrate/Type232HFixedBaudrates"
The output of the unit test is not that pretty as I put the actually testing
in a generic function. Usually that's a no no, but I didn't want to
duplicate the code for every chip type. Maybe a macro can come
to the rescue here.
> - Use default vendor/product strings for EEPROM when user doesn't
> supply some (rewritten for future extensability and correct string
> handling)
>
> and adds 4 patches to let me run Tilmann Hentze's config from the mail
>
> "ftdi_eeprom and max packet size" with the
>
> BM_type_chip=true # Newer chips are all BM type
>
> removed. After programming a FT232R board with the patches applied, I can
> see no artefact in the lsubs -v output for the package size.
I'll look into the other patches later on.
Cheers,
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|