With Luos Rapid Embedded Deployment Is Simplified

Interconnected CPU nodes forming a system-wide network

Those of us tasked with developing firmware for embedded systems have a quite a few hurdles to jump through compared to those writing for the desktop or mobile platforms. Solved problems such as code reuse or portability are simply harder. It was with considerable interest that we learnt of another approach to hardware abstraction, called Luos, which describes itself as micro-services for embedded systems.

This open source project enables deployment of distributed architectures composed of collaborating micro-services. By containerizing applications and hardware drivers, interfaces to the various components are hidden behind a consistent API. It doesn’t even matter where a resource is located, multiple services may be running on the same microcontroller, or separate ones, yet they can communicate in the same way.

By following hardware and software design rules, it’s possible to create an architecture of cooperating computing units, that’s completely agnostic of the actual hardware. Microcontrollers talk at the hardware level with a pair of bidirectional signals, so the hardware cost is very low. It even integrates with ROS, so making robots is even easier.

Luos architecture

By integrating a special block referred to as a Gate, it is possible to connect to the architecture in real-time from a host computer via USB, WiFi, or serial port, and stream data out,  feed data in, or deploy new software. The host software stack is based around Python, running under Jupyter Notebook, which we absolutely love.

Current compatibility is with many STM32 and ATSAM21 micros, so chances are good you can use it with whatever you have lying around, but more platforms are promised for the future.

Now yes, we’re aware of CMSIS, and the idea of Hardware Abstraction Layers (HALs) used as part of the platform-specific software kits, this is nothing new. But, different platforms work quite differently, and porting code from one to another, just because you can no longer get your preferred microcontroller any more, is a real drag we could all do without, so why not go clone the GitHub and have a look for yourselves?

18 thoughts on “With Luos Rapid Embedded Deployment Is Simplified

      1. I understand your point but the purpose isn’t to implement a low-level HAL for every system, it’s to provide a uniform HAL interface. This means that reusing another HAL may be OK if it can fit to work as their HAL interface.

    1. Do you know that all processors doesn’t know anything except pointers, goto and registers? And every layer of abstraction in all that new fancy low entry level languages made to guard extremly low skilled programmers from pointers and gotos to fix their inability to write a good code just means more energy, time and memory consumption that in any case finally ends in just executing highly ineffective native code with same pointers and goto’s on a target MCU.

      Do you have a widespread processor with, f.e. hardware GC, objects and other fancy shugar or may be you find a source of energy way better than that rechargeable batteries to have any excuse for using low entry level languages on MCUs? No? So, why do you feel yorself entitled to solve your own problems with writing effective, small, fast and high-quality code usng pointers and goto’s by putting the expenses on those who will have to use your “code without pointers written in fancy inclusive language”?

      1. You are talking nonsense. There is a lot abstractions which now have, thanks to optimizing compilers, negligible or no runtime cost. As they help a lot with code maintainability, there is no excuse not to use them. You seem to be an elitist prick with bad attitude.

      2. Absolutely agree with the other person. As for the widespread processor with hardware GC – sure, that exists. Rust will give you memory safety on any processor, for free! Zero-cost abstractions are very much a thing and modern languages have tons and tons of them. “If” is an example – it probably compiles to one conditional jump instruction anyway, but the programmer’s intent is much more understandable when reading the code (compared to endless gotos). OOP, for that matter, is another example – it’s just a method of organizing code by grouping data structures with methods that you will only ever use on that particular data structure anyway.

        Besides, what do you do with your void pointers anyway? Probably comment the hell out of your code to ensure that you interpret the value properly, right? Features like type systems are just shorthand for the same stuff.

    2. Historically we were developing this lib in Rust. But at this time rust was not stable for embedded and we spend a lot of time just maintaining Rust compiling. Also most of the embedded developers never eard about Rust, and they wanted C. So we come back to C :(

      We are using RAW pointer because it’s allowing us to take some shortcuts and optimize a lot RAM and CPU consumption.
      You right this is close to code obfuscation and could lead to safety issues, we are putting a lot of effort to test everything and to comment a lot allowing people to understand what the code is doing.

  1. One thing that this project overlooks, is that each and every microcontroller “node” would need to be separately programmed, at least initially. Once a boot-loader is in, it should be theoretically possible to feed firmware in for all MCUs via the gateway node, but out-of-the-box, those MCUs are going to need to be pre-loaded with something minimal at least.

    My workplace makes a Thread-based data collection and control device which right now, is built around a single Cortex M3 MCU. Firmware is built atop OpenThread, and that one MCU is responsible for running the whole show, from issuing Modbus requests over the RS-485 ports, counting pulses from the water meter inputs, and pushing the sampled data to a “cloud”-based server via CoAP.

    The MCU has 32kB of RAM, and it’s tight, as OpenThread chews about 23kB of it, and 5kB is reserved for stack and serial buffers. I had suggested that we move the data collection duties to a smaller, plain “I/O processor” that communicated with the “communications processor” which then just took care of OpenThread duties.

    The reason that approach was not used was because there were concerns about the manufacturing complexity of having to program two MCUs.

    1. That’s strange because you can literally buy chips that are preprogrammed from component distributors like Digikey. If that was really the sole reason then I would say your higher-ups made an oversight.

      1. Yup, we have our boards preprogrammed with our bootloader by the assembly house. Actually, we let them program the chips with a bootloader *and* test code (which gets automatically replaced with the application code)

      2. You can, and we do…but adding a second processor can sometimes square the complexity. You not only have to validate a single firmware, but a second one, in addition to their interoperability. Sure, if you are making a flashlight, this might be moot, but in any application with importance, these are necessary steps.

  2. No interest in being a beta tester for it.

    Otherwise it looks interesting but if you’re not running a STM32 or Atmel variant you are out of luck It sure doesn’t look like it will work with 8 or 16bit micros either.

Leave a Reply to GravisCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.