Python-on-a-Chip now supports Arduino Mega (BlimpDuino, Robotics, Touch Screens) | Hacker News Reader

Python-on-a-Chip now supports Arduino Mega (BlimpDuino, Robotics, Touch Screens)

code.google.com

46 pointscoderdude15 comments

It also supports the Teensy++. (disclaimer: I did the Teensy++ support.)

However, in both cases 8kb of RAM is not really ideal. You can do a few simple things in Python, but you run out of RAM -very- quickly.

I had some discussions with Dean (the main p14p author) about this and he has a plan to move some of the 'code object' metadata, which is currently allocated in RAM, to be allocated in the flash. That should give quite a bit more breathing room.

There are, of course, some gotchas doing this easily on the Harvard architecture AVRs compared to the other platforms (ie need to use PROGMEM directives not simple memory mapping.)

Also, 8kb of RAM may never be enough for non-trivial programs in Python.

If anyone wants a challenge, jump in and hack it together. :)

How quickly do you think 32kb of RAM would get eaten up by PyMite? I recently stumbled upon the Phillips LPC2138 ARM 7 IC (http://www.sparkfun.com/commerce/product_info.php?products_i...).

I think it would make for a good porting experience, since I have little to-date. SparkFun provides a devboard for it as well and you can add GPS, cellular, and Bluetooth. It would make for some interesting modules in the mostly barren lib folder, even if the support would be for a single chipset and component (for now).

How quickly do you think 32kb of RAM would get eaten up by PyMite?

I think 32kb is the p14p recommended amount, and you could do quite a bit with that (although I've only ever used p14p on 8kb avrs, actually!)

IIRC, at the moment >4kb is used just initialising the VM, which is obviously a much larger share of 8kb than it is of 32kb. Dean says his changes should bring that >4kb down to <1kb, though.

Good, it sounds like 32kb should be more than enough to play with! A smaller initialization footprint should make all the difference in the world if you've only got 8kb of RAM to begin with.

It would make for some interesting modules in the mostly barren lib folder

Yes, I think that's where p14p will suddenly become very useful (like the Arduino) - big libraries of (native code) hardware support easily strung together with developer-friendly Python code.

That's what I wanted to do with the Teensy++ (flesh out the 'avr' module) but at the moment each extra function declared in a module takes RAM for code metadata, so you end up using much of your 8kb storing (unused) function metadata!

I saw your comment in avr.py about saving ram by commenting out the port and ddr methods. Since any Python modules you use are "baked-in" upon compiling, perhaps something could be done to auto-comment functionality in modules that isn't used by the resulting program?

I actually suggested something similar on the mailing list[1] (static analysis & removal, similar to -ffunction-sections & -gc-sections in gcc.) That's when Dean pointed out his plans to not have the code objects resident in RAM, which he thinks should make that step redundant.

[1] http://groups.google.com/group/python-on-a-chip/browse_threa...?

Why do these systems have such tiny amounts of RAM? Every dinky little device seems to have a few megabytes of RAM, so it's kind of baffling to me how limited these hacker systems seem to be. Is there some important constraint I'm not understanding?

If you're writing in C then 8kb is really quite a lot for many applications.

The ATMEGA168P in the last-generation Arduino Duemilanove only had 1kb of RAM, and the ATMEGA328 in the current generation has 2kb. The attiny2313 only has 128 -bytes- of RAM!

Even the Arduino environment actually uses more RAM than you'd consume just using plain avr-gcc, but AFAIK for most applications that's not an issue. The amount of flash (for code & static data) seems to be a more common concern in many cases.

When you start managing dynamic runtime data structures, like in a VM or a full-blown operating system, then you really need the extra RAM. If you don't need it, then you're having it at the expense of cost, power consumption & (at the extreme end) size.

That said, if you could buy an 8-bit AVR with 64kb of RAM then I would have bought it by now, just to play with Python. :P

In these cases the RAM is in the same package as the CPU, whereas in "dinky little devices" it's most likely external to the CPU.

(Insert a bunch of hand-wavy explanations about manufacturing volume, cost and power consumption here. :) )

Some of the AVR chips support external memory.

This just seems all wrong...

I love Arduino. I use them to control most of the simple robotics hobby projects I build.

I love Python too, I code in it all the time - but its just the wrong tool for the job on an Arduino. The system resources just aren't there.

The built in C/C++ implementation and libraries are small, elegant, easy; they are a perfect fit for the vast majority of the projects.

I'd rather a good C/C++ than a bad python.

I mean, it's cool that someone did this project, but I don't see it as being useful work. If it ain't broke, don't fix it?

I'd really like to see the Netduino[1] supported. ARM7 power, more RAM, Arduino compatible pinout, reasonable price.

It's on my list of "projects to try", somewhere... :)

[1] http://netduino.com/

I saw that Stackless threads can be run, It means that the actual Stackless Tasklets (http://www.stackless.com) can be created? Any doc about the implementation?

Finally! Now I'm definitely getting one!

Thanks for the link.

Lazy question: is the regular Arduino supported?

Reply on news.ycombinator.com