Hi Andreas, I was annoyed by the ~20s programming time of the Arduino Due. I tried to port femtolisp to the Arduino Due: https://github.com/plops/arduino_due_lisp/tree/master/arduino-femtolisp
I added a few functions to access the DAC and the GPIO pins. Using this I was able to do some exploratory programming.
I didn't try to implement a garbage collector but small examples like this work:
(let ((i 0)) (while (< i 10) (digitial-write 8 1) (delay 10) (digital-write 8 0) (delay 1) (set i (+ i 1))))
Development with this is much more fun. I found that even though the code is is interpreted, there is very low jitter.
The next steps would be to get a garbage collector and then a way to load compiled functions from the host computer into RAM. Unfortunately I don't know how to do that.
Regards, Martin
On Sun, Mar 27, 2016 at 2:23 PM, Andreas Thiele andreas@atp-media.de wrote:
-----Ursprüngliche Nachricht----- Von: ecl-devel [mailto:ecl-devel-bounces@common-lisp.net] Im Auftrag von Pascal J. Bourguignon Gesendet: Sonntag, 27. März 2016 00:32 An: ecl-devel@common-lisp.net Betreff: Re: ECL on very small chips?
"Andreas Thiele" andreas@atp-media.de writes:
can I use ECL to write software for a chip without OS?
Yes.
In my case I’d like to write software for NXP1769 which is ARM Cortex M3, 64kB Ram, 512kB Flash.
Anything with more than one bit of memory.
You didn't ask if you could develop software using ECL running on this chip. You can use ECL (or any other CL implementation), at all phases of the creation of software for a chip without an OS.
I would start by writing LAP (Lisp Assembler Program) for that chip. Then I would write in lisp an emulator of that chip. The reason why you don't want to use the chip itself is that it doesn't have an OS, therefore it must be rather hard to debug code you sent there, (even with a logic analyser). By writing the emulator in lisp, that means that you can easily instrumentalize it to help you in debugging.
Once you have a LAP, you can implement a compiler for a subset of Common Lisp targetting this LAP.
Let's remember, you didn't ask to run an interactive lisp with an development environment ON this chip. Therefore you may not need a garbage collector, a compiler or an interpreter, strings, cons cells, pathnames, multidimensional arrays, CLOS objects, bignums, ratios, etc. Probably, for the application you have in mind, you only need (signed-byte 32) and vectors, perhaps structures. You may not need to implement dynamic unwinding, the condition system with restarts and so on. After all, all your other colleagues only run C code on those chips. So a small subset of Common Lisp can be all you really need.
But notice that in the code of your macros, you can use the full Common Lisp language, since macros are evaluated at compilation time. It's in the lisp code generated by your macros that you must restrict yourself to your CL subset. (Cf. eg. parenscript).
You would define this CL subset also as a package that exports only the operators included in that subset. Say the ANDREAS-THIELE-LISP package, nickname ATL.
So you can now develop your software for this chip, as a normal CL program using this subset of Common Lisp, that is, using the ATL package instead of the CL package, on any CL implementation, using all the tools of your Common Lisp implementation and IDE (choose the one with the best debugger).
Once it's good and debugged as a normal CL program, you compile it with your compiler instead of using the CL compiler, and you obtain the bytes to be sent to the chip. You don't send them to the chip!
You send them to your emulator, and you test and debug on your emulator in Common Lisp, using all the tools of your Common Lisp implementation and IDE.
When it's good and debugged as binary program for you chip, then you can send it to the chip, and test the final product with whatever tools you have there.
Ok, it may sound complex explained like this, but it's one of the most fun way to build a program.
This is how they wrote Crash Banditcoot, for example. https://en.wikipedia.org/wiki/Crash_Bandicoot https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp http://all-things-andy-gavin.com/2011/02/02/making-crash-bandicoot- part-1/ http://all-things-andy-gavin.com/2011/10/25/lispings-ala-john-mccarthy/
Finally, remember that the original LISP was written on a machine with 36-bit words and 32 Kwords; that's 144 KB. (each 36-bit word could store a cons cell with two 15-bit pointers and two 3-bit type tags).
There were lisp implementations on 8-bit processors (eg. on the Apple ][ 6502 with 64 KB of addressing space).
In the case of CL, the name of the symbols alone take already 12 KB:
(let ((z 0)) (do-symbols (s "CL" z) (incf z (length (symbol-name s))))) --> 11271
(but that's uncompressed, you can be smart).
So if your purpose was to implement a Common Lisp system on your chip, with 512 KB of flash memory, I'd say that it would be perfectly possible, but easier by starting from scratch to take into account the size limitations.
-- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk
Thank you for the inspiring and enlightening answer.
Yes my question was a bit unspecific. The trigger for my question was an unbelievable turnaround time of about 2 minutes (edit, compile, reload, test again) I came across when an embedded box currently under development came onto my desk. This one is written by a junior c programmer with lengthy, sparsely commented c code containing cryptic function names. My job here is programming common lisp, nearly exclusively. So I thought about having a more dynamic development system on the box, which allows dynamic compilation of functions during runtime to not have to reboot the whole box just because one function gets modified. Meanwhile I thought about ECL, PicoLisp, miniPicoLisp, Lua and even Javascript, but I abandoned them all.
Although your emulator suggestion first made me grin, I think it is a possible way to go. Problem is, the chip is connected to other hardware, which has slow communication protocols. Now I think about connecting these hardware components to my emulator (to be written). This could indeed be an approach. I have to think :)
Andreas
P.S. After browsing the ARM Thumb instruction set I guess writing the emulator will not be trivial :)