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