general news & update
Dean Hall
week. I was on vacation and didn't want to advertise that information
ahead of time because I prefer to avoid PyMite groupies hounding me at
the airport <smiley>. Anyway, a bunch of stuff came up while I was
away that I should address further:
- Bryan Jones' native code macros: I'd like to adopt them, add some of
my own ideas and fold them into the code base.
- Emanuele discovered a defect when trying to use generators within
ipm. This is described in Issue #95 (http://code.google.com/p/python-on-a-chip/issues/detail?id=95
)
- Angus provided patches to the Teensy++ and AVR platforms that I
shall merge into the code base.
- There was discussion about a network library. A network library is
on my ToDo list, but it's pretty far down on the priority list. If
anyone wants to tackle this, please speak up and we'll design it
together so I can assist making sure it will work cross-platform and
with all the future changes that are coming.
- Angus brought up ideas to reduce RAM usage that coincided with my
plans for "The Big r10 Rewrite" which I haven't mentioned before
because it's a lot of work that I didn't want to promise until I got
it done. This is a longer-term project, but it will make such an
improvement that I want to push through my current ToDo items quickly
(maybe skipping some) so that I can get on with it. I've put an early
proof-of-concept version of the script that converts .py files to code
object C structs here: http://groups.google.com/group/python-on-a-chip/web/pmCoCreator.py
The future incarnation of this script shall serve the equivalent
purpose that pmImgCreator.py serves now: to convert user .py code into
data that goes in program memory. However, pmImgCreator.py will still
be necessary in the future because ipm will still have to use code
images.
- Emanuele is really pushing the VM and running into a high-priority
GC defect (Issue #39). Resolving this issue is the next item on my
ToDo list as a properly functioning GC is crucial.
With all that said, here's my ToDo list (roughly):
1) Finish Issue #86 to where PyMite works on the Econotag and can call
the important libmc1322x APIs (mesh protocol stack, shall come later)
2) Issue #39: Fix GC bug
3) Fix as many r09 issues as possible and create r09 release.
4) Start work on next-gen VM design
>>> Call for Assistance <<<
Sales of commercial licenses are not providing enough income for me to
work on p14p full-time. If anybody knows of a way that will allow me
to work on p14p full-time, I'd like to hear it. Such a method would
require that I focus on coding, not have to do business development,
marketing and sales of this product. If I can't find assistance by
the end of this summer, I will be returning to the embedded work force
and my free time to devote to p14p shall decrease. I love Python,
p14p and I have a large list of things I can do to improve it. I hope
we can find a way to keep the momentum we've been building since PyCon
2009!
!!Dean
ziglionz
On 3 Lug, 22:08, Dean Hall <dwhall...@gmail.com> wrote:
> Okay, everybody, sorry about the few messages and responses this past
> week. I was on vacation and didn't want to advertise that information
> ahead of time because I prefer to avoid PyMite groupies hounding me at
> the airport <smiley>.
PyMite on their netbook. Wrong side of the world possibly!
> - There was discussion about a network library. A network library is
> on my ToDo list, but it's pretty far down on the priority list. If
> anyone wants to tackle this, please speak up and we'll design it
> together so I can assist making sure it will work cross-platform and
> with all the future changes that are coming.
just to wrap the network library of the reference platform, MBED.
That could be abstracted into plat.h/.c so to allow other platforms to
provide their implementation.
> With all that said, here's my ToDo list (roughly):
There are some minor things that I've found a bit strange while
porting full Python code to Pymite:
- the type() function returns an integer while in official Python I
think an object is returned
- some more string methods would certainly be useful. For
example .join(), .match()
- it's a bit odd having to call static methods to access dict types.
Are they not meant to be objects? I wonder how difficult would be to
make them instances of a dict class...
> >>> Call for Assistance <<<
>
> Sales of commercial licenses are not providing enough income for me to
> work on p14p full-time. If anybody knows of a way that will allow me
> to work on p14p full-time, I'd like to hear it. Such a method would
> require that I focus on coding, not have to do business development,
> marketing and sales of this product. If I can't find assistance by
> the end of this summer, I will be returning to the embedded work force
> and my free time to devote to p14p shall decrease. I love Python,
> p14p and I have a large list of things I can do to improve it. I hope
> we can find a way to keep the momentum we've been building since PyCon
> 2009!
sense.
I've listened recently to a podcast with the creator of Mercurial who
was in a similar situation. He'se now able to live on donations to the
project but can't recall what the details were. The point was that
yes, support contracts were too far apart unfortunately.
I've got the feeling that a lot of people using PyMite are researchers
and am not sure whether the platform has reached a maturity that
allows it to run in a commercial product. It's great for getting
something going very quickly as long as the application is simple
enough.
I don't think it's too far from it, the code is excellent but it still
requires a lot of work to port existing Python code to PyMite. That's
been my experience so far.
The potential though, as you mentioned in the video talk, is
absolutely huge. I personally can't wait the moment when we'll get rid
of C forever, such a fragile, error-prone language. Java VMs have not
made it (unless you're talking hundredths megabytes), PyMite might.
E.
Dean Hall
type() is troublesome. I went for the easiest possible
implementation. In p14p right now, the object header in the C struct
uses a 5-bit field to hold the type. So there are at most 32 types
possible, 27 in use and 5 available. Most of the basic Python types
(None, Int, Float, List, etc.) have their own type value, only the
latest type, Bytearray, is a class. There are no Integer, Float, etc.
class objects in the VM, only instances made from C structs. So the VM
is a little like CPython before type/class unification took place a
few years ago. I would consider type/class unification after r10, but
only if it doesn't introduce too much RAM bloat.
string.join() is already Issue #84. I made a note to add .match() too.
Yes, static methods are a bit odd (unless you learned python in the
very early days), but turning the basic types into class instances is
a *big* change to the VM and would consume much more RAM than the
current way using C structs to define the types. Again, this change
would be a part of type/class unification.
!!Dean
Bryan A. Jones
--
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
--
Bryan A. Jones, Ph.D.
Assistant Professor
Department of Electrical and Computer Engineering
231 Simrall / PO Box 9571
Mississippi State University
Mississippi state, MS 39762
http://www.ece.msstate.edu/~bjones
bjones AT ece DOT msstate DOT edu
voice 662-325-3149
fax 662-325-2298
Our Master, Jesus Christ, is on his way. He'll show up right on
time, his arrival guaranteed by the Blessed and Undisputed Ruler,
High King, High God.
- 1 Tim. 6:14b-15 (The Message)
Angus Gratton
> (maybe skipping some) so that I can get on with it. I've put an early
> proof-of-concept version of the script that converts .py files to code
> object C structs here:
Thanks for posting this, Dean! I'll do my best to take a look at it
soon, see if there are any suggestions or comments I can come up with.
> If anybody knows of a way that will allow me
> to work on p14p full-time, I'd like to hear it.
This is a really admirable goal, good luck with it.
I have a couple of suggestions, although they're pretty lame duck
really:
- Corporate sponsorship(?) I have no idea who would sponsor such a
project, but there must be companies out there that would gain from
having a product like p14p available. Plenty of OSS programmers drawing
salaries from random companies & institutions around the world.
- Donate link on the web site. This is obviously not going to pay your
salary, but I figure it can't hurt. People get generous sometimes. :).
- Reselling hardware. In many parts of the world outside the US I don't
think there is an obvious reseller for 'mbed' hardware. I'd gladly buy a
board from a source where I knew that the purchase was benefiting p14p.
There's obviously a lot of overheard in setting up as a reseller, but it
could work especially if p14p becomes more popular.
Hth, at least as food for thought.
- Angus
Jan Wedel
Two things about your CfA:
1.) This is probably not very helpful, but have you though about using
Flattr (http://flattr.com/) ? Might be not the big deal, but as soon as
it is out of beta phase, it might be worth a try. Personally, I would
rather use Flatter that Paypal donations because I don't feel bad giving
too less or thinking about "how much" because Flattr will do the work
for me...
2.) I don't know if you remember, but I was the one who ported p14p to
JavaME. This was intended make python available across different
wireless modules. Actually, I'm using Java right now because it turned
out that the main wireless Python platform was not even providing basic
language features.
No float(!), not threads, none of the other goodies p14p supports! They
are using python 1.5.2 with only a handful of libraries. This is totally
**** an can only be used for some mini-scripts.
Probably, you could offer porting p14p to their platform (I bet it's
some kind of ARM) as a consultant... The company I'm talking about is
Telit (http://www.telit.com/), they're selling GSM modules + terminals,
some of them programmable with python (e.g. GE863-PY). Unfortunately, I
can't give you any direct contact information. I don't know if this is
interesting for you and if they are interested, but this could be worth
a try ;)
/Jan
> -----Ursprüngliche Nachricht-----
> Von: Dean Hall [mailto:dwha...@gmail.com]
> Gesendet: Samstag, 3. Juli 2010 22:08
> An: python-o...@googlegroups.com
> Betreff: [python-on-a-chip] general news & update
>
> >>> Call for Assistance <<<
>
> Sales of commercial licenses are not providing enough income for me to
> work on p14p full-time. If anybody knows of a way that will allow me
> to work on p14p full-time, I'd like to hear it. Such a method would
> require that I focus on coding, not have to do business development,
> marketing and sales of this product. If I can't find assistance by
> the end of this summer, I will be returning to the embedded work force
> and my free time to devote to p14p shall decrease. I love Python,
> p14p and I have a large list of things I can do to improve it. I hope
> we can find a way to keep the momentum we've been building since PyCon
> 2009!
>
> !!Dean
>
John Griessen
>> the end of this summer, I will be returning to the embedded work force
>> and my free time to devote to p14p shall decrease. I love Python,
>> p14p and I have a large list of things I can do to improve it. I hope
>> we can find a way to keep the momentum we've been building since PyCon
>> 2009!
>>
>> !!Dean
I'm developing a kit selling business, plus full manufactured products
that would benefit from python-on-a-chip modules. I don't see enough
instant selling at the end of summer to feed you though, especially
if you want employment instead of self employment with all the jobs that
entails. The researcher market is something to ask around about...
python-on-a-chip driven lab hardware will be a good seller.
Maybe talking with some cross discipline folks could trigger a grant
writer to write you in. bioengineers, chemists, geneticists, physicists,
even a few EE professors etc. would like
machines that are python programmable.
John
Davide "dada" Carboni
> - There was discussion about a network library. A network library is on my
> ToDo list, but it's pretty far down on the priority list. If anyone wants
> to tackle this, please speak up and we'll design it together so I can assist
> making sure it will work cross-platform and with all the future changes that
> are coming.
Hi, I was thinking to a async message based interface, able to work on
top of different stacks. Something ajax-like
send(message,callback)
receive(callback)
But as pointed by Emanuele in a previous message the question is how
to trigger a callback in the current pymite concurrency
implementation.
>>>> Call for Assistance <<<
>
> Sales of commercial licenses are not providing enough income for me to work
> on p14p full-time. If anybody knows of a way that will allow me to work on
> p14p full-time, I'd like to hear it. Such a method would require that I
> focus on coding, not have to do business development, marketing and sales of
> this product. If I can't find assistance by the end of this summer, I will
> be returning to the embedded work force and my free time to devote to p14p
> shall decrease. I love Python, p14p and I have a large list of things I can
> do to improve it. I hope we can find a way to keep the momentum we've been
> building since PyCon 2009!
Unfortunately I have no suggestion about that. I hope that more
developers use and help improve your code, also releasing you from
assisting any newby joining this list.
D.
--
web: http://people.crs4.it/dcarboni
twitter: @__dadaista__
ipse dixit: Il Vero Programmatore entra in casa dalla porta 8080
Steve Casperson
I would like to discuss your situation. Would you have time for a call on Monday?
Kindest regards,
Steve Casperson
813-728-9537
John Griessen
> Steve,
>
> Yes, I have time. I'm working from home all day.
If you two arrive at a way to pay Dean's rent and some
kind of open hardware kit or board or module with enclosure
and mountings would help it, I'll help design and produce
all of it.
I'll be making custom enclosures from recycled plastic and/or
a silicate concrete soon. They'll have interesting colors and textures.
John
Dean Hall
tasks. But there are many situations where the higher-level language
is acceptable. I don't have a good name for it, but it is the
situations that are one step up from the low-level interrupts. Let me
give an example.
A simple UART usually has an interrupt to indicate when it has
received a character. Sending a signal to interrupt the VM for each
character is a poor design. The overhead of interrupting the VM that
many times and reassembling the serial message from so many pieces is
not the best use of a high-level language. Instead, let's look one
step up.
The newer-generation UARTs have a way to set a serial buffer and an
interrupt for when the buffer is full. If the hardware does not
provide the buffer, it can be done in software. Signaling the VM and
reassembling a serial message from buffer-sized pieces at a time
starts to make sense. There are still questions to be answered with
this design: what to do with a partial buffer? Should it timeout?
Who handles the timeout, C code or the VM?
(Aside: If the microcontroller has DMA, then by all means create a DMA
API and let the hardware do the work.)
This "one step up" or "next larger unit" idea works for peripherals
that stream data. UART, SPI and I2C are definitely candidates. I
haven't thought through CAN because I'm not as familiar with it. USB
and Ethernet probably need a C-level API running and the VM interface
works at the data-packet level. The 802.15.4 interface I'm working on
for the Redbee Econotag does just that. I call a C library function
to send a data packet so the Python source is simply:
econotag.tx_packet("your raw packet here")
To conclude, I believe going one step up does two good things: it
reduces the time-impact of device interrupts and it presents the
Python programmer with a high-level interface. This leaves out doing
some of the very-rapid-response that microcontrollers are known for,
but then, Python wasn't designed for real-time systems.
!!Dean
John Griessen
I haven't
> thought through CAN because I'm not as familiar with it.
It's a synchronous time slot system -- time slots have chores to do first,
then time leftover to do other and sleep.
USB and
> Ethernet probably need a C-level API running and the VM interface works
> at the data-packet level. The 802.15.4 interface I'm working on for the
> Redbee Econotag does just that. I call a C library function to send a
> data packet so the Python source is simply: econotag.tx_packet("your raw
> packet here")
does python-on-a-chip run on a redbee board?
John
Mariano Alvira
> Dean Hall wrote:
>
> does python-on-a-chip run on a redbee board?
>
Yes, it will run on anything with a mc13224v.
-Mar.
Dean Hall
basic RF functions like tx_packet() and am getting ready test &
debug. This work is going on in a branch:
http://code.google.com/p/python-on-a-chip/source/browse/#svn/branches/
issue_0086_dwhall_port_to_econotag
!!Dean
pmoran4gmail
Thanks for all your work. Where can I find a step by step procedure
for running the VM on the mbed from a windows platform?
I've done the compile, done the upload but the step in the README that
says "unmount the mbed" is confusing. Not sure I can do that on my
Windows 7 machine.
I can run "make ipm" for the desktop platform using Cygwin, but I'm at
a loss to run this on the mbed.
Thanks in advance,
Pat
BTW - If you're still looking for work I would like to talk.
>
> - Show quoted text -
Dean Hall
repository (r514 or later) as it has important changes that aren't in
release 08.
I've found that the "Unmount the mbed" step can be safely ignored
(I'll fix that in the docs). (We used to have to unmount before an
mbed reboot). On Windows, the unmount equivalent is called "Remove
USB mass store device." It's found by clicking on that little icon in
the lower-right tray.
If you use the default code from the repository with no changes, the
mbed will be ready, running ipm, waiting for the PC to run the host-
side of ipm. Follow the cookbook page to run ipm:
http://mbed.org/projects/cookbook/wiki/PyMite
!!Dean