3 ms·

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

46 points by coderdude 16y ago

sry_not4sale 16y ago
Finally! Now I'm definitely getting one! Thanks for the link.
angusgr 16y ago
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. :)
- coderdude 16y ago
  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_id=520 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).
  - angusgr 16y ago
    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.
    - coderdude 16y ago
      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.
  - angusgr 16y ago
    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!
    - coderdude 16y ago
      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?
      - angusgr 16y ago
        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_thread/thread/4eb730def11bca72/afb8d2591a893d81 http://groups.google.com/group/python-on-a-chip/browse_threa...?
- ianb 16y ago
  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?
  - angusgr 16y ago
    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
  - follower 16y ago
    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.
angusgr 16y ago
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/ http://netduino.com/
carlosedp 16y ago
I saw that Stackless threads can be run, It means that the actual Stackless Tasklets (http://www.stackless.com http://www.stackless.com) can be created? Any doc about the implementation?
mgunes 16y ago
Lazy question: is the regular Arduino supported?
feral 16y ago
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?

46 points by coderdude 16y ago

Finally! Now I'm definitely getting one! Thanks for the link.

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. :)

coderdude 16y ago
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_id=520 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).
- angusgr 16y ago
  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.
  - coderdude 16y ago
    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.
- angusgr 16y ago
  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!
  - coderdude 16y ago
    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?
    - angusgr 16y ago
      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_thread/thread/4eb730def11bca72/afb8d2591a893d81 http://groups.google.com/group/python-on-a-chip/browse_threa...?
ianb 16y ago
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?
- angusgr 16y ago
  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
- follower 16y ago
  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.

angusgr 16y ago

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/ http://netduino.com/

carlosedp 16y ago

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

mgunes 16y ago

Lazy question: is the regular Arduino supported?

feral 16y ago

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?