Re: [avrdude-dev] New pin definition data structure, updated ftdi_syncbb to support buff

[Hannes Weisbach]

> Hi,
Hi,
> 
> as I already mentioned I checked in now the new pin definitions data 
> structures.
Thank you.
> 
> All existing bitbang programmer should work as before as the convert the new 
> data into the existing data fields. (See their initpgm functions.)
> 
> I guess avrftdi could be adapted very easy by changing the add_pins and 
> set_pins functions (add_pin and set_pin might be removed). Another place to 
> change is the pin setup in avrftdi_open. (Maybe looking at ft245r.c and its 
> usage of the SET_BITS_0 macro and its check_pins function might help. )
As of r1165, avrftdi uses the new 0-based pindef infrastructure.

> 
> BTW: I don't like the fact that in avrftdi the default pins are set if 
> MOSI,MISO,SCK, or RESET does not fit the expectations. If some one has really 
> connected the pins as he describes in the config file, than we should rather 
> exit because of wrong connections, instead to change it by ourself and 
> possible destroy the connected hardware. (Maybe he could still use 
> synchronous bitbanging using ftdi_syncbb in this configuration.)
Corrected.
> 
> Also the add_pin(s) and set_pin(s) functions seem to use different return 
> code for errors (1 vs. -1).
add_pin[s]() is now gone and substituted by avrftdi_pin_setup(). Both 
avrftdi_pin_setup() and set_pin() now return -1 on error.
> Maybe we should introduce some generic defines in avrdude.h so it is really 
> clear what the value for OK is, what values for error (any negative number? 
> so you can code the reason in it?)
I think in general this is a good idea. Specifically for avrftdi_pin_setup() 
and set_pin() I don't think this makes sense, since there are many error 
reasons (illegal pin, mandatory pin missing, pin inverted although it is 
forbidden) and combinations thereof to encode in a single return value. 
pins_check() already tells the user what is wrong and following code should 
only care whether an error occurred or not.

Best regards,
Hannes