AVR32 GPIO: Use PX_00 pin names instead of PD_* and PE_*

[Martin Guy]

This patch removes the "PD_nn" and PE_nn" names for port X on AVR32
AT32UC3A0 parts and lets the user say "pio.PX_16" or whatever.
The "PX port" doesn't really exist in the hardware: its 40 pins are
mapped to random inverted ranges of pins on ports 2 and 3.
internally we use the real port and pin pair, which also corresponds
to AVR32's "GPIO number"ing scheme.

Naming these pins as "PC_31" or "PD_00" is disallowed in the name
decoding code instead of when the pin/port is used.

This patch leaves pio.port operations available on ports C and "D"
(ports 2 and 3), though port operations are unlikely to be useful on
AVR32 AT32UC3 parts since the peripherals and RAM use a random
selection of pins from all four ports, leaving just a few actual GPIO
pins here and there.  At most, pio.port.getval() might be useful to
sample several PX GPIO pins simultaneously if they happen to be on the
same hardware port; the user can then figure out which bits to inspect
of which port from the GPIO pin numbers.

As a size effect, this patch also fixes NUM_PIO and PIO_PIN_ARRAY[] on
EVK1101, which only has ports A and B. The PC and PX syntax remains
available on that part, but return nil.

     M

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

Patch updated to apply to svn r884

     M

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

Sorry, Two changes were missing from that.  Use this patch

   M

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

Sorry, I'm having technical problems. Please ignore me.

   M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Sun, Jan 16, 2011 at 7:24 PM, Martin Guy <[hidden email]> wrote:
> Sorry, I'm having technical problems. Please ignore me.

I'll think about this patch a bit more. It fixes things for Lua code
that uses the "pio" module but doesn't do much for the C part of the
code. For example, if your SD/MMC card chip select would be on PX36
you still don't have a good way to specify this in platform_conf.h. I
can see two options here:

- make the C code use a different port/pin mapping than the Lua code.
Very confusing and I'd rather try to avoid it but it might still be an
option (definitely easier to implement).
- rewrite your change at C code level. A bit more work but seems to be
the right thing to do.

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 16 January 2011 18:33, Bogdan Marinescu <[hidden email]> wrote:

> I'll think about this patch a bit more. It fixes things for Lua code
> that uses the "pio" module but doesn't do much for the C part of the
> code. For example, if your SD/MMC card chip select would be on PX36
> you still don't have a good way to specify this in platform_conf.h. I
> can see two options here:
>
> - make the C code use a different port/pin mapping than the Lua code.
> Very confusing and I'd rather try to avoid it but it might still be an
> option (definitely easier to implement).
> - rewrite your change at C code level. A bit more work but seems to be
> the right thing to do.

Thanks.

As I understand it, the GPIO numbers (0-105) are the canonical form to
refer to port/pin settings,
while the PA/PB/PC/PX stuff are names for the electrical signals on
the chip die.

In platform_conf.h (on AVR32) I have only seen pin selection done by
referring to macros in the /usr/avr32/include/avr32/ header files, not
by PA/PB/PC/PX.  If you think that will be useful for C code, I can
probably cook up some macros that turn PA(25) or PX(39) into the
appropriate GPIO numbers.

As it happens, the AVR32 GPIO numbers and the internal word
representing a port/pin pair are the same (pin in the bottom 5 bits,
port in the ones above).  What sort of interface does the C interface
want for specifying port pins?

    M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

> Thanks.
>
> As I understand it, the GPIO numbers (0-105) are the canonical form to
> refer to port/pin settings,
> while the PA/PB/PC/PX stuff are names for the electrical signals on
> the chip die.

That's what I understood too.

> In platform_conf.h (on AVR32) I have only seen pin selection done by
> referring to macros in the /usr/avr32/include/avr32/ header files, not
> by PA/PB/PC/PX.  If you think that will be useful for C code, I can
> probably cook up some macros that turn PA(25) or PX(39) into the
> appropriate GPIO numbers.
>
> As it happens, the AVR32 GPIO numbers and the internal word
> representing a port/pin pair are the same (pin in the bottom 5 bits,
> port in the ones above).  What sort of interface does the C interface
> want for specifying port pins?

Stuff like this:

#define MMCFS_CS_PORT     0
#define MMCFS_CS_PIN      SD_MMC_SPI_NPCS_PIN

This isn't a problem, but in turn this gets used like this:

static
void SELECT (void)
{
    platform_pio_op( MMCFS_CS_PORT , ( ( u32 ) 1 << MMCFS_CS_PIN ),
PLATFORM_IO_PIN_CLEAR );
}

From inc/platform.h:

pio_type platform_pio_op( unsigned port, pio_type pinmask, int op );

The main problem here is the second parameter of platform_pio_op which
is a bit mask for the specified port (the first parameter). It's
currently a 32 bit unsigned int (pio_type in inc/platform.h) but since
PX has more than 32 pins we'd have to change that to a 64 bit unsigned
int. This shouldn't be hard to implement but I still don't feel right
about it. u64 is not a machine native type on our platforms and this
would make PIO operations even slower than they already are. I played
with the idea of having a 'platform_pio_op_pin' function that would
specify directly the pin number instead of a mask but this would mean
that we won't be able to read/write the value of PX as a whole; for
this operation we obviously still need a u64.
This is mostly poetry though at this point, I still have to evaluate
the actual impact of using u64 instead of u32 for PIOs before coming
to a conclusion. This would probably be AVR32 specific, the other
platforms don't need something like this. I don't expect many problems
for this if we document it properly.

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 16 January 2011 20:02, Bogdan Marinescu <[hidden email]> wrote:

> Stuff like this:
>
> #define MMCFS_CS_PORT     0
> #define MMCFS_CS_PIN      SD_MMC_SPI_NPCS_PIN
>
> This isn't a problem, but in turn this gets used like this:
>
> static
> void SELECT (void)
> {
>    platform_pio_op( MMCFS_CS_PORT , ( ( u32 ) 1 << MMCFS_CS_PIN ),
> PLATFORM_IO_PIN_CLEAR );
> }

That's wrong.  SD_MMC_SPI_NPCS_PIN is a GPIO number 0-105.
It only happens to work here because the pin in question is on port 0.

It should be using macros to convert from GPIO pin number to port/pin number.
By coincidence, it's the same conversion as PLATFORM_IO_GET_PORT() and
PLATFORM_IO_GET_PIN(v) - but only by coincidence.  I guess we need two
more (avr32-specific) macros to do this right.

> From inc/platform.h:
>
> pio_type platform_pio_op( unsigned port, pio_type pinmask, int op );
>
> since PX has more than 32 pins we'd have to change that to a 64 bit unsigned

In hardware, PX does not exist; it's just a strange Atmel naming
convention for pins on ports 2 and 3.

> that we won't be able to read/write the value of PX as a whole

You can't read/write PX as a whole, simply because it doesn't exist!
You can read ports 2 and 3 separately and mix the bits up to maintain
the illusion that port X exists.
I wouldn't bother making life so difficult for so little (no) gain.

> I don't expect many problems for this if we document it properly.

Extra complexity is always a problem. In fact, in computing, managing
complexity is *the* problem.

    M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

>> static
>> void SELECT (void)
>> {
>>    platform_pio_op( MMCFS_CS_PORT , ( ( u32 ) 1 << MMCFS_CS_PIN ),
>> PLATFORM_IO_PIN_CLEAR );
>> }
>
> That's wrong.  SD_MMC_SPI_NPCS_PIN is a GPIO number 0-105.
> It only happens to work here because the pin in question is on port 0.

I wouldn't call it 'wrong', it's just the way eLua works :) And the
model is inspired from the real world.This oddity (using GPIO pin
numbers instead of port/pin combination) is specific to AVR32, all the
other platforms have a GPIO subsystem that define both ports and pins.
Which is the same model eLua uses. Some platforms have 8 pins/port,
other have 32 pins/port, none has more than 32. Sure, having a single
port with 106 pins is a particular case of the port/pin model, but it
doesn't quite fit the eLua model for the reasons outlined in the
previous e-mail.

> It should be using macros to convert from GPIO pin number to port/pin number.

Maybe this is indeed what we should consider for AVR32 as a particular case.

> By coincidence, it's the same conversion as PLATFORM_IO_GET_PORT() and
> PLATFORM_IO_GET_PIN(v) - but only by coincidence.  I guess we need two
> more (avr32-specific) macros to do this right.

Yes. BTW, PLATFORM_IO_GET_PIN doesn't work properly in this case since
it only uses 5 bits to encode a pin number. By extension, the other
macros that encode/decode ports/pins don't work either.

>
>> From inc/platform.h:
>>
>> pio_type platform_pio_op( unsigned port, pio_type pinmask, int op );
>>
>> since PX has more than 32 pins we'd have to change that to a 64 bit unsigned
>
> In hardware, PX does not exist; it's just a strange Atmel naming
> convention for pins on ports 2 and 3.

>
>> that we won't be able to read/write the value of PX as a whole
>
> You can't read/write PX as a whole, simply because it doesn't exist!

I understand you very well, I'm just trying to find a way to map the
AVR32 model to the "rest of the world" model (I know this is an
untasteful generalization, but up to this point experience seems to
suggest that it is real :) ). The "rest of the world" model contains
functions for reading/writing ports as a whole (8/32 bits at a time,
depending on the platform) which is much faster than setting
individual pins. Imagine that you have a small graphical LCD (128x64
and alike) with an 8-bit interface connected to your GPIO pins.
Settings pins individually to control this works but can be very slow.
Doing it at port level might increase speed significantly.
However, this gives me an idea of "ranges" that one could use as a
generalization for GPIO functionality. Something like this:

range = gpio.range( 0, 7 ) -- initialize a GPIO range for pins 0 to 7 of a prt
range.add( 9 ) -- add pin 9 to range
range.add( 12, 14 ) -- add pins 12, 13, 14 to range

gpio.set( range, 0 ) - clear all pins in range (ideally in a single operation)
gpio.set( range, 1 ) - set all pins in range (ideally in a single operation)
v = gpio.get( range ) - read all pins in range in variable 'v'

This extended model could cover even the AVR32 case properly and might
eliminate the need for the concept of 'ports' completely.

> You can read ports 2 and 3 separately and mix the bits up to maintain
> the illusion that port X exists.
> I wouldn't bother making life so difficult for so little (no) gain.
>
>> I don't expect many problems for this if we document it properly.
>
> Extra complexity is always a problem. In fact, in computing, managing
> complexity is *the* problem.

I couldn't agree with you more, and this is exactly what I'm trying to
avoid here. I chose the port/pin model initially because it was fit
for most eLua targets (and still is) so it was the easiest to
implement. I'm trying to avoid extra complexity by mapping AVR32 over
the same model (while at the same time trying not to loose
funcionality (like getport/setport)) instead of handling special cases
for specific platforms. True, I'm not doing it very well :) so it
might seem that I'm increasing complexity while I'm trying to do the
exact opposite.

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Dado Sutter]

Do we really need the PX_2^7++ pins to use on AVR32 ?

If eLua on AVR32 uses the regular Port/Pins [2⁵] conventions, will it be too strange for AVR/Atmel users ?

Any code implementation to solve this otherwise seem to be performance-costly.

Best
Dado

On Sun, Jan 16, 2011 at 21:29, Bogdan Marinescu <[hidden email]> wrote:

>> static
>> void SELECT (void)
>> {
>>    platform_pio_op( MMCFS_CS_PORT , ( ( u32 ) 1 << MMCFS_CS_PIN ),
>> PLATFORM_IO_PIN_CLEAR );
>> }
>
> That's wrong.  SD_MMC_SPI_NPCS_PIN is a GPIO number 0-105.
> It only happens to work here because the pin in question is on port 0.

I wouldn't call it 'wrong', it's just the way eLua works :) And the
model is inspired from the real world.This oddity (using GPIO pin
numbers instead of port/pin combination) is specific to AVR32, all the
other platforms have a GPIO subsystem that define both ports and pins.
Which is the same model eLua uses. Some platforms have 8 pins/port,
other have 32 pins/port, none has more than 32. Sure, having a single
port with 106 pins is a particular case of the port/pin model, but it
doesn't quite fit the eLua model for the reasons outlined in the
previous e-mail.

> It should be using macros to convert from GPIO pin number to port/pin number.

Maybe this is indeed what we should consider for AVR32 as a particular case.

> By coincidence, it's the same conversion as PLATFORM_IO_GET_PORT() and
> PLATFORM_IO_GET_PIN(v) - but only by coincidence.  I guess we need two
> more (avr32-specific) macros to do this right.

Yes. BTW, PLATFORM_IO_GET_PIN doesn't work properly in this case since
it only uses 5 bits to encode a pin number. By extension, the other
macros that encode/decode ports/pins don't work either.

>
>> From inc/platform.h:
>>
>> pio_type platform_pio_op( unsigned port, pio_type pinmask, int op );
>>
>> since PX has more than 32 pins we'd have to change that to a 64 bit unsigned
>
> In hardware, PX does not exist; it's just a strange Atmel naming
> convention for pins on ports 2 and 3.

>
>> that we won't be able to read/write the value of PX as a whole
>
> You can't read/write PX as a whole, simply because it doesn't exist!

I understand you very well, I'm just trying to find a way to map the
AVR32 model to the "rest of the world" model (I know this is an
untasteful generalization, but up to this point experience seems to
suggest that it is real :) ). The "rest of the world" model contains
functions for reading/writing ports as a whole (8/32 bits at a time,
depending on the platform) which is much faster than setting
individual pins. Imagine that you have a small graphical LCD (128x64
and alike) with an 8-bit interface connected to your GPIO pins.
Settings pins individually to control this works but can be very slow.
Doing it at port level might increase speed significantly.
However, this gives me an idea of "ranges" that one could use as a
generalization for GPIO functionality. Something like this:

range = gpio.range( 0, 7 ) -- initialize a GPIO range for pins 0 to 7 of a prt
range.add( 9 ) -- add pin 9 to range
range.add( 12, 14 ) -- add pins 12, 13, 14 to range

gpio.set( range, 0 ) - clear all pins in range (ideally in a single operation)
gpio.set( range, 1 ) - set all pins in range (ideally in a single operation)
v = gpio.get( range ) - read all pins in range in variable 'v'

This extended model could cover even the AVR32 case properly and might
eliminate the need for the concept of 'ports' completely.

> You can read ports 2 and 3 separately and mix the bits up to maintain
> the illusion that port X exists.
> I wouldn't bother making life so difficult for so little (no) gain.
>
>> I don't expect many problems for this if we document it properly.
>
> Extra complexity is always a problem. In fact, in computing, managing
> complexity is *the* problem.

I couldn't agree with you more, and this is exactly what I'm trying to
avoid here. I chose the port/pin model initially because it was fit
for most eLua targets (and still is) so it was the easiest to
implement. I'm trying to avoid extra complexity by mapping AVR32 over
the same model (while at the same time trying not to loose
funcionality (like getport/setport)) instead of handling special cases
for specific platforms. True, I'm not doing it very well :) so it
might seem that I'm increasing complexity while I'm trying to do the
exact opposite.

Best,
Bogdan

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 25 January 2011 22:01, Dado Sutter <[hidden email]> wrote:
> Do we really need the PX_2^7++ pins to use on AVR32 ?
>
> If eLua on AVR32 uses the regular Port/Pins [2⁵] conventions, will it be too
> strange for AVR/Atmel users ?
>
> Any code implementation to solve this otherwise seem to be
> performance-costly.

The PX00-39 names have no correspondance in hardware.  They are only
names used by Atmel to refer to everything except PA PB and PC 0-5
In reality, and in the code implementation, they are a bizzare
sequence of inverted pin ranges on the 32-bit C and D ports, and these
are the codes used internally in eLua so there is no extra
implementaion stuff.  They are just human-readable names.

The PX00-39 names are only the names that human beings use for these
extra pins, for some strange capriccio of Atmel.
So, what I did is make these names work for human beings in eLua
pio.PX_* syntax, mapping them to the actual port/pin values.

Internally, these are stored as port/pin pairs in a single integer: 5
bits for the pin and the rest for the port number.
By coincidence, this exactly coincides with Atmel's second alternative
scheme for referring to the pins, their "GPIO numbers" 0-109.

The only cause for concern is if these pins need to be turned back
into human-readable form for printing, in which case the "PX" pins
would be printed as "PC" and "PD" according to the real pin location
in the hardware. If you can find somewhere in the eLua code where this
is done, it may be worth the trouble to re-map these pins back to the
"PX" names.
I don't remember seeing anywhere where this is done.

The last thing is that the PORT name PX, used in some primitives to,
e.g. read or set all 32 pins simultaneously, is useless.
If you want to implement that, yes, you would need to change the
internal representation to handle 40-pin ports.  However it is a
useless comcept on AVR32 because the usable GPIO pins are mixed up
with all the peripherals' pins and SDRAM data lines, which occupy most
of the actual port pins, leaving only 9 or 10 GPIO lines free in
random positions.

    M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Dado Sutter]

Hello Martin,

On Tue, Jan 25, 2011 at 20:40, Martin Guy <[hidden email]> wrote:

On 25 January 2011 22:01, Dado Sutter <[hidden email]> wrote:
> Do we really need the PX_2^7++ pins to use on AVR32 ?
>
> If eLua on AVR32 uses the regular Port/Pins [2⁵] conventions, will it be too
> strange for AVR/Atmel users ?
>
> Any code implementation to solve this otherwise seem to be
> performance-costly.

The PX00-39 names have no correspondance in hardware.  They are only
names used by Atmel to refer to everything except PA PB and PC 0-5
In reality, and in the code implementation, they are a bizzare
sequence of inverted pin ranges on the 32-bit C and D ports, and these
are the codes used internally in eLua so there is no extra
implementaion stuff.  They are just human-readable names.

The PX00-39 names are only the names that human beings use for these
extra pins, for some strange capriccio of Atmel.
So, what I did is make these names work for human beings in eLua
pio.PX_* syntax, mapping them to the actual port/pin values.

Internally, these are stored as port/pin pairs in a single integer: 5
bits for the pin and the rest for the port number.
By coincidence, this exactly coincides with Atmel's second alternative
scheme for referring to the pins, their "GPIO numbers" 0-109.

The only cause for concern is if these pins need to be turned back
into human-readable form for printing, in which case the "PX" pins
would be printed as "PC" and "PD" according to the real pin location
in the hardware.

You have explained it very well previously, thanks.
My question was, do we really need to support this (Atmel specific) naming ?
We strive to be as close to each platform ecosystem as we can (and this is why we support different naming schemes like PA_x, P1_x, ...) but if this will result in a major refactor or loss of performance, maybe we could let it out.

If you can find somewhere in the eLua code where this
is done, it may be worth the trouble to re-map these pins back to the
"PX" names.
I don't remember seeing anywhere where this is done.

I think this is done on the Lua bind maps but I couldn't find or remember it quickly neither.

The last thing is that the PORT name PX, used in some primitives to,
e.g. read or set all 32 pins simultaneously, is useless.
If you want to implement that, yes, you would need to change the
internal representation to handle 40-pin ports.  However it is a
useless comcept on AVR32 because the usable GPIO pins are mixed up
with all the peripherals' pins and SDRAM data lines, which occupy most
of the actual port pins, leaving only 9 or 10 GPIO lines free in
random positions.

Yes, this was the feeling I had when I asked "is it really worth supporting the PX_ nomenclature ?

   M

Best
Dado


 

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 26 January 2011 00:30, Dado Sutter <[hidden email]> wrote:
> My question was, do we really need to support this (Atmel specific) naming ?

Yes, otherwise those pins are unusable. At present they are only
accessible by trial and error using names like PD_01 for PX33 with no
correspondence between the PD/PE names and the PX pin names, nor with
the GPIO numbers.  You can only find out which is which by random
probing.

> if this will result in a major refactor or loss of performance, maybe we could let
> it out.

It doesn't. If affects the inside of one function with an extra "case"
statement #if AVR32 only without changing anything else, and only
affects the input syntax for naming these pins when building for
AVR32.  I guess I should have inclouded some explanation at the top of
the patch file that I sent, to explain better the differences that it
makes (it practically nothing). It seems to be scaring several people,
probably because it is unclear what it does.
   I admit it was difficult to get my head round the four naming
systems then in use: PXnn pins, GPIOnn pin numbers, the old phantom PD
and PE ports (which exist even less than PX does; there are four
32-bit ports in reality) and the actual port C/D pins that each of the
"PX" pins is in reality.

PX00-PX10 = GPIO100-GPIO90 = Port 3 pins 04-00; port 2 pins 31-26
PX11-PX14 = GPIO109-GPIO106 = Port 3 pins 13-10
PX15-PX34 = GPIO89-GPIO70 = Port 2 pins 25-06
PX35-PX39 = GPIO105-GPIO101 = Port 3 pins 09-05

I only mapped a few of the old internal PD_ and PE_ eLua names of a
few pins, but they had nothing to do with any of the above 3 naming
schemes, but were yet another seemingly random mapping. I only
discovered some of them by running a program to read all pins of port
D (or E) and print a 32-bit mask, then take the few free GPIOs high
and low with a resistor to see which bit changed.
The old, random PD_ and PE_ names for the ones I mapped are still
noted in the section "Elua view" of
http://code.google.com/p/mizar32/wiki/GPIO

PX16 GPIO88 P7 pin 13 pio.PD_18
PX19 GPIO85 P7 pin 12 pio.PD_15
PX22 GPIO82 P7 pin 11 pio.PD_12
PX33 GPIO71 P6 pin 10 pio.PD_1

This patch removes the craziest of these naming schemes, which existed
only in eLua, and lets users use one of the already existing set of
names.

>> If you can find somewhere in the eLua code where this
>> is done, it may be worth the trouble to re-map these pins back to the
>> "PX" names.
>> I don't remember seeing anywhere where this is done.
>
> I think this is done on the Lua bind maps but I couldn't find or remember it
> quickly neither.

Well, if it starts printing PC_27 and PD_14 some time can we leave
someone to report that as a bug?
It should be harmless.

    M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

> The PX00-39 names have no correspondance in hardware.  They are only
> names used by Atmel to refer to everything except PA PB and PC 0-5
> In reality, and in the code implementation, they are a bizzare
> sequence of inverted pin ranges on the 32-bit C and D ports, and these
> are the codes used internally in eLua so there is no extra
> implementaion stuff.  They are just human-readable names.
> The PX00-39 names are only the names that human beings use for these
> extra pins, for some strange capriccio of Atmel.

I said it before and I'll say it again: I _really_ want to meet
someone from Atmel who worked on the AVR32 and ask him what they're
smoking there ...

> So, what I did is make these names work for human beings in eLua
> pio.PX_* syntax, mapping them to the actual port/pin values.
> Internally, these are stored as port/pin pairs in a single integer: 5
> bits for the pin and the rest for the port number.
> By coincidence, this exactly coincides with Atmel's second alternative
> scheme for referring to the pins, their "GPIO numbers" 0-109.

Which is what makes your patch functional in the first place (in took
me a while to figure this out): it maps directly to eLua's internal
representation by coincidence :)

> The only cause for concern is if these pins need to be turned back
> into human-readable form for printing, in which case the "PX" pins
> would be printed as "PC" and "PD" according to the real pin location
> in the hardware. If you can find somewhere in the eLua code where this
> is done, it may be worth the trouble to re-map these pins back to the
> "PX" names.
> I don't remember seeing anywhere where this is done.

This isn't done in the code.

> The last thing is that the PORT name PX, used in some primitives to,
> e.g. read or set all 32 pins simultaneously, is useless.
> If you want to implement that, yes, you would need to change the
> internal representation to handle 40-pin ports.  However it is a
> useless comcept on AVR32 because the usable GPIO pins are mixed up
> with all the peripherals' pins and SDRAM data lines, which occupy most
> of the actual port pins, leaving only 9 or 10 GPIO lines free in
> random positions.

I see. OK, I agree: port operations on PX will not be allowed since it
is not a port at all.
I'll try to make all this into a patch that touches the
platform/common code rather than the PIO modue (much more elegant).

Best,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev