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: René Liebscher
Subject: Re: [avrdude-dev] Updated patch for Linux sysfs GPIO programmer type
Date: Sat, 05 Jan 2013 17:18:01 +0100
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0

Am 04.01.2013 23:37, schrieb Radoslav Kolev:
> ...
>
> Before sending a final revised version of the patch I have some questions.
>
> First, the patch increases the maximum pin number in config_gram.y to
> 255, since it's normal for modern SoCs to have a large number of
> GPIOs. Just wanted to point it out in case you've missed it and would
> prefer this as a separate patch/change, since it's not directly
> related to the new programmer type.
>
> The second thing also concerns pin numbers. As far as my understanding
> goes, if a pin is not specified in a certain programmer entry in the
> configuration file it will default to 0, which means not
> available/used by this programmer. The problem is that GPIO numbering
> in Linux starts from zero, so it's actually a valid value. To work
> around this now the pin numbers specified in the config file are
> actually off by one. For example if you mean GPIO5 (from the point of
> view of Linux's sysfs interface) in avrdude.conf you have to put 6 as
> the value.
>
> That's kind of annoying and I would like to fix it somehow. Ideally,
> if the default not assigned pin value was -1 and not 0 that would
> solve it, but I have no idea how this will influence the rest of the
> code. Another way would be to just assume that miso, mosi, reset and
> sck pins are set in the config file and use their value, even if it's
> zero. If any of those pins is not assigned there isn't much chance
> programming will work anyway, but I didn't see an easy way to make
> these parameters required just for a single programmer type.
>
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.

> What do you recommend for the above?
>
> Best regards,
> Rado
>
Kind regards,

René Liebscher



reply via email to

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