4 ms·

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/prod

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...?

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...?