avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] Updated patch for Linux sysfs GPIO programmer type


From: Hannes Weisbach
Subject: Re: [avrdude-dev] Updated patch for Linux sysfs GPIO programmer type
Date: Sat, 5 Jan 2013 17:35:25 +0100

> You have the same behaviour for ftdi based prgrammers, where you have to
> write 4 when you actually mean ADBUS3.
> 
> I would prefer a much more general approach to this problem.
> 
> You have to remember that there are not only single pins but also list
> of pins are possible for vcc and buf pin definitions. And these define
> their pins as 1<< pin1 | 1 << pin2 | ... . So setting the default to -1
> would set there all bits if there is no definition in the conf-file.
> 
> I would like to have the pin definition as follows:
> 
> typedef struct programmer_t {
> ...
>  unsigned int pinno[N_PINS];
> ...
> }
> 
> changed to
> 
> typedef struct programmer_t {
> ...
>  pin_def_t pinno[N_PINS];
> ...
> }
> 
> with pin_def_t defined as:
> 
> #define N_MAX_PINS 32 /* or 256 if GPIO is compiled in */
> 
> struct {
>    uint32_t mask   [N_MAX_PINS/32];
>    uint32_t inverse[N_MAX_PINS/32];
> } pin_def_t;
> 
> Then you have a single pin defined as:
> mask = { 0b0001000, .... }
> inverse = { 0b0000000, .... }
> 
> an inverted pin as:
> 
> mask = { 0b0001000, .... }
> inverse = { 0b0001000, .... }
> 
> pin lists as:
> 
> mask = { 0b0010110, .... }
> inverse = { 0b0000000, .... }
> 
> and it would even be possible to define a mixed inverted pin list as
> wished in bug #37727 Add support for LM3S811 dev board as a programmer
> 
> mask = { 0b0010110, .... }
> inverse = { 0b0010010, .... }
> 
> However you had to change the code for the following programmer types
> avrftdi, ftdi_syncbb, par and serbb. (These are the only ones which
> currently use pin definitions in the config file.)
> 
> I would also propose to change then pin numbers of ftdi based
> programmers to 0 based numbers in the config file. But leave them for
> parallel and serial port 1-based as they correspond to real pins at
> their connectors.
I think it's a good idea and would provide the necessary changes to avrftdi, if 
this proposal is generally accepted and you provide the definitions.

Best regards,
Hannes


reply via email to

[Prev in Thread] Current Thread [Next in Thread]