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 <andr...@atp-media.de> wrote: > > > > -----Ursprüngliche Nachricht----- > > Von: ecl-devel [mailto:ecl-devel-boun...@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" <andr...@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 :) > > > > -- Dr. Martin Kielhorn martin.kielh...@ezono.com Spitzweidenweg 32 Home: +49 (0)3641 795 5844 Work: +49 (0)3641 876 1735 D – 07743 Jena Germany
