Hacker News Reader

Comment by quchen | Hacker News Reader

This is really cool, I would love to program my fleet of ESP8266s with anything but C. And I’ve been passively interested in using Lisp for many years. Using Lisp for my program as glue for the normal ESP C libraries would be awesome. I’ve read the documentation of uLisp a bit, two main questions remain:

1. What’s the workflow? REPL for development is super cool, but how do I persist my programs? How does »flash this code onto the microcontroller« work?

2. How can I interface with the large amount of C libraries out there? For example, uLisp does not provide an OTA library (for updating the software over Wifi), or one for MQTT. I don’t want to rewrite those myself, so how do I call existing C from uLisp?

View on HN

The scheme distributions I'm familiar with (Chicken, Gambit, and Gerbil) have well-defined FFIs for C.

I think with Gambit you can have C inline with your Scheme:

https://www.iro.umontreal.ca/~gambit/doc/gambit.html#C_002di...

This is no help for programming for embedded targets? Maybe? I'm very close to clueless (I RTFM, but I still don't understand a large portion of functionality of Schemes of FFIs).

Having never heard of Gambit, it looks like Gambit:Scheme::Awka:AWK

https://github.com/noyesno/awka

> I would love to program my fleet of ESP8266s with anything but C.

Have you looked into Embeddable Common-Lisp? (https://gitlab.com/embeddable-common-lisp/ecl)

The "Embeddable" in Embeddable Common Lisp means that you can embed your CL code in C programs, not that it's for embedded programming. Probably a poor naming choice because a lot of people have this perception about it.

All true, but ECL after having been transpiled to C has a fair chance of being x-compiled for and run on a uC.

> but how do I persist my programs?

    (save-image 'your-fun)

I used uLisp in a project. I had no available non-volatile storage so I handled persistence by writing my code on the laptop and sending it serially to the micro.

When some functions proved to be stable and useful I ported them in as uLisp builtins with a C implementation.

I used it as a debug driver in an STM32 for an eZ80 CPU - the STM32 provided USB to TTY and a third serial channel for debug control.

It was a nice addition but I do wish it was designed in a way that made these modifications easier.

Another commenter already mentioned Gambit Scheme. That provides for inline C and therefore very easy interop with external libraries. It still has a runtime and GC though - those might pose a problem depending on your platform and task.

Ferret (https://github.com/nakkaya/ferret) and Carp (https://github.com/carp-lang/Carp) are both Lisp-like low level languages. Both seem to be fairly experimental in nature though.

> anything but C

Taking you literally, Rust and D can both compile for bare metal. D in particular has a "Better C" subset. (https://dlang.org/spec/betterc.html)

In the same vein, Terra is a C like language (manual memory management) that you metaprogram with Lua. (https://github.com/terralang/terra)

Taking you very literally, Forth is also an option.

I went down many of those routes myself, though not the lisp ones. There's also TCL. But I've settled on Nim as my favorite for embedded (at least for a while). For the esp2866 Rust (or D) would be tricky. Nim can compile to C, unlike Rust which doesn't support the Xtensa architecture found on most esp chips. Not sure about D bit it seems unlikely to support Xtensa.

There's a Nim Esp2866 sdk: https://github.com/clj/nim-esp8266-sdk And a youtube talk on Programming esp2866: https://youtu.be/eCCrkZI0rVU

Just be sure to use ARC/ORC. If you're interested in esp32's as well, I wrote a Nim wrapper of the esp-idf: https://github.com/elcritch/nesper

Just to clarify - Gambit, Chicken, and Carp all compile to portable C.

I hadn't realized LLVM mainline doesn't support Xtensa. I'm surprised.

D does support Xtensa via LDC (https://forum.dlang.org/thread/rpdwiusbevvphqyvjhdj@forum.dl...). It looks like GDC also nearly supports it, requiring only a minor patch at present.

A functioning LLVM backend does exist (https://github.com/espressif/llvm-project/issues/4) and appears to be making very slow progress towards being merged. A quick search shows that it works for Rust. I suspect (but don't know) that it might work for Terra as well.

There's also the LLVM C backend (https://github.com/JuliaComputingOSS/llvm-cbe) but I've no idea how efficient such an approach is when applied to real world embedded tasks.

Reply on news.ycombinator.com