Re: [python-on-a-chip] Digest for python-on-a-chip@googlegroups.com - 11 Messages in 3 Topics

3 views

Skip to first unread message

chipmu...@gmail.com

unread,

Feb 21, 2012, 12:58:44 PM2/21/12

to python-o...@googlegroups.com

Sent from my LG phone

>=============================================================================
>Today's Topic Summary
>=============================================================================
>
>Group: python-o...@googlegroups.com
>Url: http://groups.google.com/group/python-on-a-chip/topics
>
> - improved access to mbed LEDs [5 Updates]
> http://groups.google.com/group/python-on-a-chip/t/2921278e16b9824
> - Problem with printing time [3 Updates]
> http://groups.google.com/group/python-on-a-chip/t/1960c112601d085
> - Adding file system support to PIC32 port [3 Updates]
> http://groups.google.com/group/python-on-a-chip/t/a29d330561ac5712
>
>
>=============================================================================
>Topic: improved access to mbed LEDs
>Url: http://groups.google.com/group/python-on-a-chip/t/2921278e16b9824
>=============================================================================
>
>---------- 1 of 5 ----------
>From: Dean Hall <dwha...@gmail.com>
>Date: Feb 20 11:25AM -0700
>Url: http://groups.google.com/group/python-on-a-chip/msg/f4500ac08b0f2d95
>
>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
>
>
>---------- 2 of 5 ----------
>From: Luciodj <lucio....@googlemail.com>
>Date: Feb 21 04:48AM -0800
>Url: http://groups.google.com/group/python-on-a-chip/msg/73128968b4e64df9
>
>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?
>
>
>
>
>---------- 3 of 5 ----------
>From: "pir...@gmail.com" <pir...@gmail.com>
>Date: Feb 21 01:58PM +0100
>Url: http://groups.google.com/group/python-on-a-chip/msg/e8975d4a8c36f819
>
>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?
>
>
>--
>"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
>
>
>---------- 4 of 5 ----------
>From: Dean Hall <dwha...@gmail.com>
>Date: Feb 21 07:45AM -0700
>Url: http://groups.google.com/group/python-on-a-chip/msg/207080f72953e47c
>
>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
>
>
>
>---------- 5 of 5 ----------
>From: "pir...@gmail.com" <pir...@gmail.com>
>Date: Feb 21 04:27PM +0100
>Url: http://groups.google.com/group/python-on-a-chip/msg/860aedd13a6c98c4
>
>> 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... :-(
>
>--
>"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
>
>
>
>=============================================================================
>Topic: Problem with printing time
>Url: http://groups.google.com/group/python-on-a-chip/t/1960c112601d085
>=============================================================================
>
>---------- 1 of 3 ----------
>From: "pir...@gmail.com" <pir...@gmail.com>
>Date: Feb 21 03:32PM +0100
>Url: http://groups.google.com/group/python-on-a-chip/msg/805913fe44d962ab
>
>It works! I've completed my printf function so "print sys.timer()"
>could be able to show something meaningful for long integers and now i
>have a timer using the system interruptions! :-D
>
>Obviusly, the code is at my Google Code account ;-)
>
>
>
>--
>"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
>
>
>---------- 2 of 3 ----------
>From: Dean Hall <dwha...@gmail.com>
>Date: Feb 21 07:51AM -0700
>Url: http://groups.google.com/group/python-on-a-chip/msg/e1116960ee2674e7
>
>Good news! Way to go.
>
>I forgot to mention that the v10 branch eliminated calling snprintf() for integers (I hadn't back ported that to the default branch)
>
>I just ported the mbed platform to v10, so I think it should be easy for you to port as well.
>
>!!Dean
>
>
>
>
>---------- 3 of 3 ----------
>From: "pir...@gmail.com" <pir...@gmail.com>
>Date: Feb 21 03:55PM +0100
>Url: http://groups.google.com/group/python-on-a-chip/msg/79c1d1ae879d8322
>
>> Good news! Way to go.
>
>Thanks! :-)
>
>> I forgot to mention that the v10 branch eliminated calling snprintf() for integers (I hadn't back ported that to the default branch)
>
>> I just ported the mbed platform to v10, so I think it should be easy for you to port as well.
>
>I wanted to keep on v09 until i have something more complete and
>usable and later do the upgrade, but since v10 is getting stable, do
>you think i should do it now and focus on it?
>
>
>--
>"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
>
>
>
>=============================================================================
>Topic: Adding file system support to PIC32 port
>Url: http://groups.google.com/group/python-on-a-chip/t/a29d330561ac5712
>=============================================================================
>
>---------- 1 of 3 ----------
>From: Luciodj <lucio....@googlemail.com>
>Date: Feb 21 04:40AM -0800
>Url: http://groups.google.com/group/python-on-a-chip/msg/eb11b38b391497ba
>
>I have completed the graphic library wrappers for the PIC32 port and I
>am experimenting with a mini Tkinter-like interface I put together
>this weekend.
>I can now have a three line Hello World gui app with touch screen
>input and all!
>To make it really useful though I would like to add file system
>support, so I am wondering if this has been done already for other
>platforms and/or if there are any templates to add it to the platform
>with minimal disruption of the source yet look and feel like a real
>python native module...
>
>
>---------- 2 of 3 ----------
>From: "pir...@gmail.com" <pir...@gmail.com>
>Date: Feb 21 01:47PM +0100
>Url: http://groups.google.com/group/python-on-a-chip/msg/3f8367f3b05253c8
>
>Look for PyFilesystem (http://code.google.com/p/pyfilesystem). I have
>been working with it for another project (PirannaFS) and is really
>pythonic compared with PyFuse and also allow to access to the
>filesystems using objects without needing to mount them (that it's
>freaking hilarious for testing purposes and the main reason i started
>using it :-P). I was thinking about using it for my x86 port in the
>future, it only would need to develop a new "expose" (it's how they
>call to the backends) for PyMite in the same way they are currently
>for FUSE, Dokan (similar framework like FUSE but for Windows), WSGI or
>standalone web server.
>
>http://code.google.com/p/pyfilesystem/source/browse/#svn%2Ftrunk%2Ffs%2Fexpose
>
>If you want to go for it give a message since i'm also interested ;-)
>
>
>
>--
>"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
>
>
>---------- 3 of 3 ----------
>From: "pir...@gmail.com" <pir...@gmail.com>
>Date: Feb 21 02:26PM +0100
>Url: http://groups.google.com/group/python-on-a-chip/msg/3e236b8204f6d115
>
>In fact, at a first time the expose wouldn't be necesary since we are
>working directly on Python: we can use the fs object natively. The expose
>would be necesary for more advanced uses like faking a mount command to
>allow access to several filesystems at the same time, and also for this
>internally would be so simple as just using a dict... :-)
>
>Sended from my Android cell phone, please sorry the lack of format on the
>text and my fat thumbs :-P
>
>
>
>
>--
>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

Reply all

Reply to author

Forward

0 new messages