Python-on-a-chip(code.google.com)
code.google.com
Python-on-a-chip
http://code.google.com/p/python-on-a-chip/
10 comments
Tangentially related: Four or five years ago I was an R&D intern working on replacing an ancient EOL'd embedded processor. We were targeting an FPGA with a soft processor (Alterra's Nios II), and found out they were powerful enough to run Linux directly. The device was doing realtime motion control, so we slapped two soft cores onto the FPGA and had them talk over drop-in bus. One did realtime, the other ran Python. It was a nifty way to hack on an HTTP status page, a test runner... not sure if it ever shipped.
The reference platform is mbed:
http://mbed.org/tour/
It's kind of neat that they have an online c++ compiler for it.
http://mbed.org/democompiler/
http://mbed.org/tour/
It's kind of neat that they have an online c++ compiler for it.
http://mbed.org/democompiler/
For you Rubyists out there, there is also RAD - a Ruby version of this for the Arduino platform:
http://rad.rubyforge.org/
http://rad.rubyforge.org/
That converts ruby programs to Arduino compatible C program.
The project linked from the thread's title says that Python runs on the chip itself unlike the RAD for Arduino that compiles down to a C program.
The project linked from the thread's title says that Python runs on the chip itself unlike the RAD for Arduino that compiles down to a C program.
Yea, it's true - not an apple to apples comparison, but still: Ruby for the 'duino!
Makes me miss Lisp machines :-/
I keep trying to convince myself I should learn some HDL. Reconstructing a Lisp machine would be a nice project.
A fully functional Lisp machine with a USB keyboard and mouse to match would be the ultimate übergeek gift.
A small Alto would also be pretty neat. The vertical screen could be tricky.
A fully functional Lisp machine with a USB keyboard and mouse to match would be the ultimate übergeek gift.
A small Alto would also be pretty neat. The vertical screen could be tricky.
Here's a guy implementing a Lisp machine on a FPGA:
http://www.aviduratas.de/lisp/lispmfpga/
http://www.aviduratas.de/lisp/lispmfpga/
there are higher level HDL's , that are c-like.
i know of impulse c.
it gives you more power , and you suffer some loss of speed/efficency(as usuall) .
might make it simple enough to develop a lisp machine.
might make it simple enough to develop a lisp machine.
I just have to ask why? What is so neat about it? Please enlighten ..
The Alto was, IIRC, the first machine with a bit-mapped display, overlapping windows, Smalltalk, a mouse...
Seriously: more than once we have lost a technology because we turned the other way at some point. The Lisa'a stationery idea is one example off the top of my mind of a great idea that was not only ahead of its time but ahead of our time. We install programs and run them to create documents instead of using a desktop to create a document of a new type that the program we installed happens to support. I like to joke Smalltalk 80 made Java 2010 look primitive. I am only half joking on that.
Seriously: more than once we have lost a technology because we turned the other way at some point. The Lisa'a stationery idea is one example off the top of my mind of a great idea that was not only ahead of its time but ahead of our time. We install programs and run them to create documents instead of using a desktop to create a document of a new type that the program we installed happens to support. I like to joke Smalltalk 80 made Java 2010 look primitive. I am only half joking on that.
You can give a try to ARMPIT SCHEME, an interpreter for the Scheme language (lexically-scoped dialect of Lisp) that runs on RISC microcontrollers with ARM core.
http://armpit.sourceforge.net/
http://armpit.sourceforge.net/
"Requires roughly 40 KB program memory and initializes in under 3 KB of RAM"
Maybe I'm just not 'with it', but last microcontroller I used had 64KB of address space. 43KB overhead seems like a lot.
Maybe I'm just not 'with it', but last microcontroller I used had 64KB of address space. 43KB overhead seems like a lot.
Well, there are a ton of Micro's today that can easily support that and there a ton that aren't. We work with high temperature microcontrollers so our devices end up having about 32k flash and about 8k ram.
In the microcontroller family you can put a lot of different devices.
The board they target with this project is based on a NXP Cortex-M3 chip with 512KB of Flash and 64KB of RAM: http://mbed.org//nxp/lpc1768/technical-reference/
The other target, STM32, is a similar Cortex-M3 microcontroller.
Want to use something different than C with a smaller footprint? you can always play with forth ^__^ for example an MSP430 (TI 16bit) port of CamelForth, should be usable with any MSP430 device having at least 512 bytes of RAM, 8K of ROM, and one USART. www.camelforth.com
It's fun and it doesn't hurt too much ;-)
Regards Pietro
The other target, STM32, is a similar Cortex-M3 microcontroller.
Want to use something different than C with a smaller footprint? you can always play with forth ^__^ for example an MSP430 (TI 16bit) port of CamelForth, should be usable with any MSP430 device having at least 512 bytes of RAM, 8K of ROM, and one USART. www.camelforth.com
It's fun and it doesn't hurt too much ;-)
Regards Pietro
Losely related: does anyone know of cheap (and fast) microcontroller with von neuman architecture (ie. able to execute code from RAM) and usable amount of embedded RAM (say 32KB at least)?
Only microcontroller architecture than I know of than can be (ab)used as von neuman machine is MCS-51 (and there are even some mass produced products that do that and have self-modifing firmware). But MCS-51 is not exactly fast and moreover this hack requires considerate amount of external components.
Only microcontroller architecture than I know of than can be (ab)used as von neuman machine is MCS-51 (and there are even some mass produced products that do that and have self-modifing firmware). But MCS-51 is not exactly fast and moreover this hack requires considerate amount of external components.
I don't understand: they all (more or less) execute code from RAM. You can't execute code from ROM, and you can only fit an instruction at a time (or so) in the IR within the CPU. Von Neuman doesn't have an exclusive on that.
The architecture of the CPU refers more to how the data is processed internally, but generally speaking, it's always "load from ROM, stick in RAM, execute in CPU, write results back to RAM." Rinse and repeat.
However, the Von Neuman views both ROM and RAM as a single, vertical unit. You can shift data to and from the ROM & RAM as needed to represent a single high-speed high-volume storage unit, but that's only needed if you want an easy way to page RAM to disk (not run programs from RAM).
The Modified Harvard Architecture is nice, and is popular with many embedded devices. I primarily use Atmel, and their Modified Harvard works great for me.
Have a look: http://en.wikipedia.org/wiki/Modified_Harvard_architecture
When you're dealing with embedded devices, there's (almost always) another way of dealing with the RAM requirements. For instance, I highly recommend the AT90USB1286 CPUs for hobbyists and entry-level enterprise stuff because of their true USB support and super-low cost. These only have 8k of RAM, but they have 128k Flash memory. You should be able to use the flash to do what you need.
The only time you need the kind of stuff you describe is when you're basically running software meant for "normal" CPUs on microcontrollers. When you're trying to run "operating systems" instead of firmware, and "packages" instead of highly-optimized and platform-specific code, that's when you need 32KB+ RAM. For everything else, a larger (32KB+ all the way till 1MB) ROM backend will do.
My only problem with the ATMEL was the limited EEPROM size for the actual firmware, and since it's a Harvard architecture the separation between data and instructions makes it difficult to run code from the flash ROM. But the new generation now has 8k+ EEPROM for the firmware, which is a nice improvement.
The architecture of the CPU refers more to how the data is processed internally, but generally speaking, it's always "load from ROM, stick in RAM, execute in CPU, write results back to RAM." Rinse and repeat.
However, the Von Neuman views both ROM and RAM as a single, vertical unit. You can shift data to and from the ROM & RAM as needed to represent a single high-speed high-volume storage unit, but that's only needed if you want an easy way to page RAM to disk (not run programs from RAM).
The Modified Harvard Architecture is nice, and is popular with many embedded devices. I primarily use Atmel, and their Modified Harvard works great for me.
Have a look: http://en.wikipedia.org/wiki/Modified_Harvard_architecture
When you're dealing with embedded devices, there's (almost always) another way of dealing with the RAM requirements. For instance, I highly recommend the AT90USB1286 CPUs for hobbyists and entry-level enterprise stuff because of their true USB support and super-low cost. These only have 8k of RAM, but they have 128k Flash memory. You should be able to use the flash to do what you need.
The only time you need the kind of stuff you describe is when you're basically running software meant for "normal" CPUs on microcontrollers. When you're trying to run "operating systems" instead of firmware, and "packages" instead of highly-optimized and platform-specific code, that's when you need 32KB+ RAM. For everything else, a larger (32KB+ all the way till 1MB) ROM backend will do.
My only problem with the ATMEL was the limited EEPROM size for the actual firmware, and since it's a Harvard architecture the separation between data and instructions makes it difficult to run code from the flash ROM. But the new generation now has 8k+ EEPROM for the firmware, which is a nice improvement.
And running "operating system" is exactly what I'm trying to achieve. What I want is simple and cheap hardware platform for teaching.
Then you don't want a microcontroller. What you want is a dirt-cheap all-in-one CPU/RAM/ROM package.
Have a look at mini PCs and plug PCs.
http://www.hawkboard.org/distributors http://www.linuxfordevices.com/c/a/News/Mini-Linux-PC-breaks... http://www.wired.com/gadgetlab/2009/02/marvell-offers/
Of course, you don't say what you want to teach, so these could be totally missing the mark.
Have a look at mini PCs and plug PCs.
http://www.hawkboard.org/distributors http://www.linuxfordevices.com/c/a/News/Mini-Linux-PC-breaks... http://www.wired.com/gadgetlab/2009/02/marvell-offers/
Of course, you don't say what you want to teach, so these could be totally missing the mark.
Samsung's SoC's have an MMU and will run Linux. Take a look at the Hammer board (http://www.tincantools.com).
Some of NXP's ARM microcontrollers have an external memory bus (but most don't have an MMU), and will run uClinux given enough RAM.
Some of NXP's ARM microcontrollers have an external memory bus (but most don't have an MMU), and will run uClinux given enough RAM.
I may be wrong here, but I vaguely remember that Infineon chips used in Siemens mobile phones some time ago (sl45i model exactly - C166) had proper memory mapping architecture in place. Especially, someone managed to exploit a stack overflow there by loading a specific jar file -- that would mean the stack at least was executable (and ram itself that way).
The jar did some demo-scene like presentation by injecting the code into a running system and taking the control over from the original firmware. That's another clue that screams "RAM execution".
It was a very long time ago though, so I may have some details wrong here, but the sl45i jar hack should be still available on youtube to prove it. Fast -- it could do 26MHz. Cheap... not sure.
Edit: Now I remember that someone wrote a binary file loader (from the MMC) that were either memory-copied, or memory-mapped. So yes - definitely look at the Siemens-Infineon C16X series - or newer if they exit.
It was a very long time ago though, so I may have some details wrong here, but the sl45i jar hack should be still available on youtube to prove it. Fast -- it could do 26MHz. Cheap... not sure.
Edit: Now I remember that someone wrote a binary file loader (from the MMC) that were either memory-copied, or memory-mapped. So yes - definitely look at the Siemens-Infineon C16X series - or newer if they exit.
Well, I know about C166/167, but while it is probably cheap (used in considerate amount of ECUs, and many Siemens products) it is not exactly readily available. Also this architecture is, to put it simply, weird, I would describe it as 16bit hybrid of MCS-51 and Alpha.
Have you considered the Blackfin?
http://en.wikipedia.org/wiki/Blackfin
http://en.wikipedia.org/wiki/Blackfin
What's the motivation for this?
The ability to use Python (instead of C, C++, or some flavor of assembly) on small chips and microcontrollers.
That doesn't really answer the question. Why would one want to do that, and why's that worth the trouble?
"What's the motivation to make a chip that runs Python?" "To be able to run Python on a chip."
"What's the motivation to make a chip that runs Python?" "To be able to run Python on a chip."
A computer nerd is a person who uses a computer in order to use a computer.
It's easier to do complicated things in a language like python than with C++. And it will never let you dereference a null pointer.
It's easier to do complicated things in a language like python than with C++. And it will never let you dereference a null pointer.
Write once/run anywhere would be a motivation. By the looks of it you wouldn't be able to literally run just any script on the chips that you bring over from a desktop machine, but the amount of tweaking would be minimal I think.
Being able to use Python's standard library on a chip would be useful. It's a dynamic language so you can do things you couldn't do with C. It's type-safe and easy as all hell to use. The usual motivations for using Python apply here. It just uses more resources and is understandably slower to execute.
Being able to use Python's standard library on a chip would be useful. It's a dynamic language so you can do things you couldn't do with C. It's type-safe and easy as all hell to use. The usual motivations for using Python apply here. It just uses more resources and is understandably slower to execute.
Some objections:
Write once/run anywhere would be a motivation. - "Run anywhere" is not true for most desktop programs and definitely not true for embedded stuff. When you're at 64k, you usually don't even reuse stuff like display handling, because your PCB layout is different enough that you'd have to rewrite the i/o layer anyways. Or because you a specific way to get the data. Or...
I can't imagine much reasonable code reuse outside of standardised platforms like Arduino. Much less any "run anywhere" programs.
It's a dynamic language so you can do things you couldn't do with C - There's nothing in language X, that you cannot do in C.
Since it seems to be a google project, I guess they're just trying to create something that can be pushed onto Android, much like their own Java VM.
Write once/run anywhere would be a motivation. - "Run anywhere" is not true for most desktop programs and definitely not true for embedded stuff. When you're at 64k, you usually don't even reuse stuff like display handling, because your PCB layout is different enough that you'd have to rewrite the i/o layer anyways. Or because you a specific way to get the data. Or...
I can't imagine much reasonable code reuse outside of standardised platforms like Arduino. Much less any "run anywhere" programs.
It's a dynamic language so you can do things you couldn't do with C - There's nothing in language X, that you cannot do in C.
Since it seems to be a google project, I guess they're just trying to create something that can be pushed onto Android, much like their own Java VM.
Running python VM on these platforms is certainly better than running there VM for some flavor of BASIC as is often done. Primary motivation for both is probably same as for dynamic languages on normal computers: easier programming.
I'm not trying to pick a fight here, nor am I claiming you're wrong as such, but I think you have to actually justify the claim that programming a microcontroller in Python is "certainly better" than doing so in BASIC. An overwhelming number of microcontroller applications are extremely simple bits of control code; there's certainly an argument to be made that _not_ carrying around the trappings of a high-level language like Python is better.
"Better for x," it would seem, is the only type of argument that will be tenable. So, what's an application for a microcontroller that will actually make use of Python's various advantages over BASIC?
"Better for x," it would seem, is the only type of argument that will be tenable. So, what's an application for a microcontroller that will actually make use of Python's various advantages over BASIC?
Memory protection, ease of development, fantastic libraries and clarity all come to mind.
Yeah! It's really awesome.
[deleted]
Sweet! Hope we can soon have Arduino support! I love the Arduino python libraries and would love to see this embeddable!
AVR is probably too limited to run almost any kind of dynamic VM effectively (with notable exception of forth).
Classic microcontrollers (which AVR essentially is) have relatively large amounts of program memory combined with miniscule RAM, for dynamic VM you need it exactly other way around.
Classic microcontrollers (which AVR essentially is) have relatively large amounts of program memory combined with miniscule RAM, for dynamic VM you need it exactly other way around.
It will run on 8-bit AVRs, however, mainly the the ones with the largest quantities of RAM. I'm not sure if any of the available Arduino platforms meet the requirements.
I think the Arduino MEGA's will eventually be supported but the regular ones are too limited.
You have to wonder who will be the first to put the Dalvik VM on a chip. Yeah, I know it's been tried with Java before.
Ironically, many ARM chips - including the ones Dalvik run on - include Jazelle, which allows them to run Java bytecode directly. But then many argue that a good JIT will give you better performance anyway. There's a reasonable discussion on StackOverflow: http://stackoverflow.com/questions/1153076/does-andriod-cast...
(I wasn't clear from your statement "I know it's been tried with Java before" if you knew it is working on ARM, or if you were referring to niche chips like the JavaChip etc)
(I wasn't clear from your statement "I know it's been tried with Java before" if you knew it is working on ARM, or if you were referring to niche chips like the JavaChip etc)
I was referring to JavaChip specifically.
I'm just wondering as the Android footprint grows if this could be an evolutionary step. It's also been rumoured that Apple could buy out ARM Holdings.
I'm just wondering as the Android footprint grows if this could be an evolutionary step. It's also been rumoured that Apple could buy out ARM Holdings.
Successfully in the opposite direction, up to 864 processor cores all with a flat SMP "mediocre" speed connection to up to 768 of gigabytes of RAM: http://www.azulsystems.com/
Hotspot hotshot Clif Click's blog is worth taking a look at: http://www.azulsystems.com/blogs/cliff/
Hotspot hotshot Clif Click's blog is worth taking a look at: http://www.azulsystems.com/blogs/cliff/
I'm not sure about Dalvik on a chip, but ThumbEE is there in ARM A8s just for accelerating virtual machines.
[deleted]