embedded-hal VS ulisp

What is the difference between this and https://github.com/rust-embedded/embedded-hal/tree/master/embedded-hal-async?

Maybe worth mentioning if you (or someone else) hasn't seen it before, the embedded-wg is also working on an async version of the embedded-hal traits, embedded-hal-async.

In that case you want to keep most of the unsafe in the HAL crate, and expose an interface as safe as possible. To give you an idea, is it since 2018 that a "generic" DMA safe implementation is in discussion https://github.com/rust-embedded/embedded-hal/issues/37

Does something like embedded hal exist in the C/C++ world? ( https://github.com/rust-embedded/embedded-hal )

worth mentioning also is embedded-hal but my understanding is this has absolutely nothing to do with arduino, so despite being embedded probably not what I want.

The ecosystem is great and growing, It really benefits from a language-standard embedded HAL which makes writing cross-platform drivers a cinch - e.g., you can write a bit-banged MDIO driver and use it on anything that has a timer and a two IO pins, from a Zynq Ultrascale to an arduino. Sure, this is possible in C - but Rust really benefits from a less fragmented ecosystem here.

Have you thought about writing/contributing to embedded-hal compatible crates (a sensor module driver for example)? It's always good to contribute to an eco system.

📝 At the time of writing this post, it came to my attention that there is an additional HAL that targets STM32 device families (the stm32-hal). From what I figure, right now there seem to be two approaches for developing HALs. The first approach is trait driven so to speak where the embedded-hal is used as a foundation. The second approach is more application-driven and provides a high-level API that targets several families of a device. However, this exists only for the stm32 through the stm32-hal. Right now, the first approach is what I found to be more widespread as it covers different microcontrollers and what this post is based on.

I can write a library for an OLED device that is driven by an platform agnostic I2C device that will run on any microcontroller that implements the necessary abstractions.

The `embedded-hal` (https://github.com/rust-embedded/embedded-hal) are these abstractions that allow this to happen

Yes but there needs to be appropriate libraries available such as HAL. Well it doesn't have to but it makes my life as a beginner in both much easier. But its probably matter of time because i predict that this chip will be very popular in Rust embedded.

I love his projects too. He's also the creator of uLisp.

http://www.ulisp.com/

Not CL, but there is ulisp (http://www.ulisp.com/) for microcontrollers, supposed to be really tiny, and there is Carp (https://github.com/carp-lang/Carp) which is without a GC so seems suitable for real-time stuff.

There's also ulisp (for Arduino projects etc.): http://www.ulisp.com/

This is larger, because there are functions for accessing peripherals, and the core is more standard lispy with 'caadr' et.al., and it has a compacting GC, so images can be saved as a compact blob.

You might consider uLisp, it's very Common Lispy for the memory constraints given (sans macros and splicing quote). And you can still connect to it and save an image. I've tried it and it works well enough. Here is the homepage.

Agreed - the interactivity is good. Lisp is close (have you seen http://www.ulisp.com/ - I can't believe they got into into that small a target!). Python is ok, but for some reason I don't use the REPL in the same way I do in Forth - I think calling functions is just harder somehow. Mostly is exploring valves from the Python REPL.