configpin for lm3s

[Marcelo Politzer]

Hello, I'm about to start the implementation of the configpin function for lm3s but I have some questions.

The only precious implementation that I've found was for lpc17xx on the docs here: http://www.eluaproject.net/doc/v0.8/en_refman_ps_mbed_pio.html#funcs

with the following syntax:

>> mbed.pio.configpin( pin, function, mode, resistor)

The problem is that the lm3s LIB has a different approach. It configures a pin for a given target peripheral

with functions like:

>> void GPIOPinTypeUART(unsigned long ulPort, unsigned char ucPins)

How should I proceed? The way it looks to me the syntax for mbed doesn't apply very well to the lm.

Something like this seems to make more sense:

>> lm3s.pio.configpin( pin, function)

Is it ok to have a completely diferent API for a diferent board? For the stand point of portability it

doesn't seem to have much of a diference.

Any thoughts about it?

--

Best,

Marcelo

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

[jbsnyder]

--
James Snyder
Biomedical Engineering
Northwestern University
http://fanplastic.org/key.txt
ph: [phone]



On Monday, May 21, 2012 at 1:33 PM, Marcelo Politzer wrote:

> Hello, I'm about to start the implementation of the configpin function for lm3s but I have some questions.
> The only precious implementation that I've found was for lpc17xx on the docs here: http://www.eluaproject.net/doc/v0.8/en_refman_ps_mbed_pio.html#funcs
>
> with the following syntax:>> mbed.pio.configpin( pin, function, mode, resistor)
>
> The problem is that the lm3s LIB has a different approach. It configures a pin for a given target peripheral
> with functions like:
> > > void GPIOPinTypeUART(unsigned long ulPort, unsigned char ucPins)
> >
>
>
> How should I proceed? The way it looks to me the syntax for mbed doesn't apply very well to the lm.
> Something like this seems to make more sense:
> > > lm3s.pio.configpin( pin, function)
> >
>
>
> Is it ok to have a completely diferent API for a diferent board? For the stand point of portability it
> doesn't seem to have much of a diference.

There is also one for str9, which is similarly rather ad-hoc and platform specific, like the lpc17xx one.

For LM3S, it is a bit different.  Note that it's actually a bit more than those functions like GPIOPinTypeXXX, there's also GPIOPinConfigure, which I is actually the one that switches the alternate functions on the pins so that the peripheral is available there.  The GPIOPinTypeXXX basically sets the direction and things like push-pull, input/output and current drive strength.

Additionally, there's some added complexity in that certain pins can be used for certain functions, and things like alternate function 2 could mean PWM on some pins and SPI or CAN on another.

For lpc17xx (I implemented this) and str9 (Bogdan, I think implemented this) we basically just exposed the raw functionality for the various options that could be configured for pins and left the details of what pins could do what in what state to the user.  I think ideally, in the long run, I'd like some sort of function that goes with the peripheral modules that allows one to just say, "I want these pins configured to use with this peripheral" and it would either do that for you (whatever alternate digital function & in/out, pull-up/push-pull, etc..) or tell you that you can't use that peripheral on that pin by having the table of alternate functions internalized, but this is a decent amount of work and is specific to the MCU/package (board renaming of pins like on MBED notwithstanding, since those can be layered on top of getting the lower level right).

In short, if you need the functionality, feel free to do it on a level similar to what we've done before, but if you'd like to do something more sophisticated I certainly don't have a problem with that :-)   At least for LM3S, it might be possible to fairly easily scrape pin_map.h to construct a configuration table for each package automatically since all the parameters for GPIOPinConfigure are defined in there and have consistent naming.

Aside:
The only platform I know of that has much more arbitrary pin configuration is SiLabs' SiM3 line which has a rather neat Crossbar design: http://www.silabs.com/products/mcu/Pages/crossbar-architecture.aspx

There's a port in progress for that platform that will get merged when a bit more functionality is ready.  The main caveat with that platform is that the current parts are 32kB for SRAM (external SRAM is supported, but is of course pin hungry). I'd expect higher spec parts later.  I'm also quite hoping that they give some future parts the sort of 16-bit (SAR) and 24-bit (sigma delta) they've given to their 8051 line.
 
>
> Any thoughts about it?--
> Best,
> Marcelo
>
> _______________________________________________
> eLua-dev mailing list
> [hidden email] (mailto:[hidden email])
> https://lists.berlios.de/mailman/listinfo/elua-dev



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