improved access to mbed LEDs

[Dean Hall]

I've added LED1-4 to the pin lookup table for the mbed platform. This way, the programmer can do something like this in python code:

p = PwmOut(1) # LED1
p.period_us(1000)
p.pulsewidth_us(500)

Use the integer 1 (one) to access LED1, 2 for LED2 and so on in the constructor of the class as shown in the example above.

!!Dean

[Luciodj]

Dean,
Do you think we should offer a common set of functions (PWM, ADC,
UART...) across all platforms?
Then the next philosophical question is how to support the rest of the
peripherals offered by these embedded processors. There are hundreds
of possible way to configure each peripheral to behave a little
differently... should we address them on a case by case basis (on
demand) or should we try to expose at a higher level (Python) some of
the inner control registers (usng peek() and poke() and a dictionary
{ register:address...}) and spare the user from the low level "native"
function (repetitive) writing?

[pir...@gmail.com]

I prefer the second option, have a very thin low level wrapper and
allow to do it all from Python in a high level way (i did in the past
an I2C chip driver in Python using the PortIO module -
http://portio.inrim.it/).

By the way, it's interesting the idea of offer a common set of
periferical functions to allow an uniform access. I think a good idea
would be something like a 'devices' package with periferical
objects/modules inside of it (in a similar fashion to UNIX /dev
folder) and have a specific one for every platform... What do you
think?

2012/2/21 Luciodj <lucio....@googlemail.com>:

> --
> You are subscribed to the "python-on-a-chip"  (or p14p for short) Google Group.
> Site: http://groups.google.com/group/python-on-a-chip

--
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux

[Dean Hall]

I can't find the exact thread where I spelled out how I thought peripherals should be accessed from p14p. Here is the closest thing I can find: http://groups.google.com/group/python-on-a-chip/browse_thread/thread/d293163b8705488c/462c9ed3ae319abc?lnk=gst&q=serial+api#462c9ed3ae319abc

eLua gives common access to peripherals across micros. But making and maintaining that code is a significant undertaking.
OpenPilot has a peripheral abstraction layer, I describe more here: http://groups.google.com/group/python-on-a-chip/browse_thread/thread/aa221409424e5efd/b7c4da0117f37757?lnk=gst&q=%22openpilot%22#b7c4da0117f37757

I like the idea of a very thin layer because it increases the likelihood of success and maintenance. However, I do intend to give p14p coders a high-level api; not everybody is a professional embedded developer. So the trick will be to find a nice balance between high-level interface and small code size.

!!Dean

[pir...@gmail.com]

> I like the idea of a very thin layer because it increases the likelihood of success and maintenance.  However, I do intend to give p14p coders a high-level api; not everybody is a professional embedded developer.  So the trick will be to find a nice balance between high-level interface and small code size.
>

For this kind of things i used to do a class for basic low-level
access (usually protocol dependent), inherited by a class for
medium-level functionality (usually device dependent) and finally
inherited by a class for high-level functionality (usually my own app
code), and only using code from ancestor classes. It's a nice and
clean and direct design, but the drawback is that maybe it's not the
best design for memory constrained platforms because you need at least
three classes for each device... :-(