<div dir="ltr"><div><div>Hi Andreas,<br>I was annoyed by the ~20s programming time of the Arduino Due.<br>I tried to port femtolisp to the Arduino Due:<br><a href="https://github.com/plops/arduino_due_lisp/tree/master/arduino-femtolisp">https://github.com/plops/arduino_due_lisp/tree/master/arduino-femtolisp</a><br><br></div><div>I added a few functions to access the DAC and the GPIO pins.<br></div>Using this I was able to do some exploratory programming. <br><br></div>I didn't try to implement a garbage collector but small examples like this work:<br><div><pre>(<span class="">let</span> ((i <span class="">0</span>)) 
 (while (< i <span class="">10</span>)
  (digitial-write <span class="">8</span> <span class="">1</span>)
  (delay <span class="">10</span>)
  (digital-write <span class="">8</span> <span class="">0</span>)
  (delay <span class="">1</span>)
  (set i (+ i <span class="">1</span>))))</pre><div><div>Development with this is much more fun. I found that even though the code is is interpreted, there is very low jitter.<br><br></div><div>The next steps would be to get a garbage collector and then a way to load compiled functions from the host computer into RAM.<br></div><div>Unfortunately I don't know how to do that. <br></div><div><br><br><br></div><div>Regards, Martin<br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 27, 2016 at 2:23 PM, Andreas Thiele <span dir="ltr"><<a href="mailto:andreas@atp-media.de" target="_blank">andreas@atp-media.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> -----Ursprüngliche Nachricht-----<br>
> Von: ecl-devel [mailto:<a href="mailto:ecl-devel-bounces@common-lisp.net">ecl-devel-bounces@common-lisp.net</a>] Im Auftrag<br>
> von Pascal J. Bourguignon<br>
> Gesendet: Sonntag, 27. März 2016 00:32<br>
> An: <a href="mailto:ecl-devel@common-lisp.net">ecl-devel@common-lisp.net</a><br>
<span class="">> Betreff: Re: ECL on very small chips?<br>
><br>
</span><div><div class="h5">> "Andreas Thiele" <<a href="mailto:andreas@atp-media.de">andreas@atp-media.de</a>><br>
> writes:<br>
><br>
> > can I use ECL to write software for a chip without OS?<br>
><br>
> Yes.<br>
><br>
><br>
> > In my case I’d like to write software for NXP1769 which is ARM Cortex<br>
> > M3, 64kB Ram, 512kB Flash.<br>
><br>
> Anything with more than one bit of memory.<br>
><br>
><br>
><br>
> You didn't ask if you could develop software using ECL running on this<br>
> chip.  You can use ECL (or any other CL implementation), at all phases<br>
> of the creation of software for a chip without an OS.<br>
><br>
> I would start by writing LAP (Lisp Assembler Program) for that chip.<br>
> Then I would write in lisp an emulator of that chip.  The reason why<br>
> you<br>
> don't want to use the chip itself is that it doesn't have an OS,<br>
> therefore it must be rather hard to debug code you sent there, (even<br>
> with<br>
> a logic analyser).  By writing the emulator in lisp, that means that<br>
> you<br>
> can easily instrumentalize it to help you in debugging.<br>
><br>
> Once you have a LAP, you can implement a compiler for a subset of<br>
> Common<br>
> Lisp targetting this LAP.<br>
><br>
> Let's remember, you didn't ask to run an interactive lisp with an<br>
> development environment ON this chip.  Therefore you may not need a<br>
> garbage collector, a compiler or an interpreter, strings, cons cells,<br>
> pathnames, multidimensional arrays, CLOS objects, bignums, ratios, etc.<br>
> Probably, for the application you have in mind, you only need<br>
> (signed-byte 32) and vectors, perhaps structures.  You may not need to<br>
> implement dynamic unwinding, the condition system with restarts and so<br>
> on.  After all, all your other colleagues only run C code on those<br>
> chips.  So a small subset of Common Lisp can be all you really need.<br>
><br>
> But notice that in the code of your macros, you can use the full Common<br>
> Lisp language, since macros are evaluated at compilation time.  It's in<br>
> the lisp code generated by your macros that you must restrict yourself<br>
> to your CL subset.  (Cf. eg. parenscript).<br>
><br>
> You would  define this CL subset also as a package that exports only<br>
> the<br>
> operators included in that subset.  Say the ANDREAS-THIELE-LISP<br>
> package, nickname ATL.<br>
><br>
> So you can now develop your software for this chip, as a normal CL<br>
> program using this subset of Common Lisp, that is, using the ATL<br>
> package<br>
> instead of the CL package, on any CL implementation, using all the<br>
> tools<br>
> of your Common Lisp implementation and IDE (choose the one with the<br>
> best<br>
> debugger).<br>
><br>
> Once it's good and debugged as a normal CL program, you compile it with<br>
> your compiler instead of using the CL compiler, and you obtain the<br>
> bytes<br>
> to be sent to the chip.  You don't send them to the chip!<br>
><br>
> You send them to your emulator, and you test and debug on your emulator<br>
> in Common Lisp, using all the tools of your Common Lisp implementation<br>
> and IDE.<br>
><br>
> When it's good and debugged as binary program for you chip, then you<br>
> can<br>
> send it to the chip, and test the final product with whatever tools you<br>
> have there.<br>
><br>
><br>
> Ok, it may sound complex explained like this, but it's one of the most<br>
> fun way to build a program.<br>
><br>
><br>
> This is how they wrote Crash Banditcoot, for example.<br>
> <a href="https://en.wikipedia.org/wiki/Crash_Bandicoot" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Crash_Bandicoot</a><br>
> <a href="https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp</a><br>
> <a href="http://all-things-andy-gavin.com/2011/02/02/making-crash-bandicoot-" rel="noreferrer" target="_blank">http://all-things-andy-gavin.com/2011/02/02/making-crash-bandicoot-</a><br>
> part-1/<br>
> <a href="http://all-things-andy-gavin.com/2011/10/25/lispings-ala-john-mccarthy/" rel="noreferrer" target="_blank">http://all-things-andy-gavin.com/2011/10/25/lispings-ala-john-mccarthy/</a><br>
><br>
><br>
> Finally, remember that the original LISP was written on a machine with<br>
> 36-bit words and 32 Kwords; that's 144 KB. (each 36-bit word could<br>
> store<br>
> a cons cell with two 15-bit pointers and two 3-bit type tags).<br>
><br>
> There were lisp implementations on 8-bit processors (eg. on the Apple<br>
> ][<br>
> 6502 with 64 KB of addressing space).<br>
><br>
> In the case of CL, the name of the symbols alone take already 12 KB:<br>
><br>
> (let ((z 0)) (do-symbols (s "CL" z) (incf z (length (symbol-name s)))))<br>
> --> 11271<br>
><br>
> (but that's uncompressed, you can be smart).<br>
><br>
><br>
> So if your purpose was to implement a Common Lisp system on your chip,<br>
> with 512 KB of flash memory, I'd say that it would be perfectly<br>
> possible, but easier by starting from scratch to take into account the<br>
> size limitations.<br>
><br>
><br>
> --<br>
> __Pascal Bourguignon__                 <a href="http://www.informatimago.com/" rel="noreferrer" target="_blank">http://www.informatimago.com/</a><br>
> “The factory of the future will have only two employees, a man and a<br>
> dog. The man will be there to feed the dog. The dog will be there to<br>
> keep the man from touching the equipment.” -- Carl Bass CEO Autodesk<br>
><br>
<br>
</div></div>Thank you for the inspiring and enlightening answer.<br>
<br>
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.<br>
<br>
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 :)<br>
<span class="HOEnZb"><font color="#888888"><br>
Andreas<br>
</font></span><br>
P.S. After browsing the ARM Thumb instruction set I guess writing the emulator will not be trivial :)<br>
<br>
<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Dr. Martin Kielhorn<div><div><div dir="ltr"><div><div dir="ltr"><div><div><span><font color="#888888"><div><div><div dir="ltr"><div><div dir="ltr"><div><div><b><span style="font-size:14pt"></span></b>martin.kielhorn@eZono.com<br>Spitzweidenweg 32<br></div><div>Home: <a href="tel:%2B49%20%280%293641%20795%205844" value="+4936417955844" target="_blank">+49 (0)3641 795 5844</a><br></div><div>Work:  <a href="tel:%2B49%20%280%293641%20876%201735" value="+4936418761735" target="_blank">+49 (0)3641 876 1735</a><br></div><div>D – 07743 Jena<br>Germany</div></div></div></div></div></div></div></font></span><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>