Sharing advanced use cases

[flplv]

Hello, nice project, I was considering writing the same kind of solution for Nim, but someone in the discord told me about this project, it looks nice.

I would like to share one advanced use case that seemed to be common in my professional experience. Due to the never ending push to shave costs on hardware, I have been "forced" to multiplex pin functions at the runtime, i.e., a UART port would be switched to digital output in the middle of the runtime to perform a short living function, and then become UART again.

I wonder if this framework will support this kind of use case, if not, I would like to put this to the discussion. I understand nim for professional projects in firmware may not be a common thing to happen nowadays, which would be a reason to only support basic arduino style use cases, on the other hand we want to see Nim largely deployed on professional embedded systems.

What is your view?

[flplv]

Another advanced use case:

Throughout the life cycle of a device, in the market, often silicon will change, again chasing costs, if a product is being sold for more than 5 years likely a few silicon changes will happen. Sometimes those changes are peripherals (changing the board description) other times they are the core microcontroller (changing the compiler and all the abstractions), how this project supports the same codebase to be build for different boards and microcontrollers?

[PMunch]

Hi, thank you for the kind words. Feel free to contribute to the project as well if you'd like!

For your usecases Ratel would actually work pretty great. The thing is that since all the abstractions are done during compile-time there really isn't much lock-in to the framework at all. There is no sense of a pin being just one thing or the other, so live-switching between UART and digital output shouldn't be any trouble at all. And since Ratel uses compile-time abstractions it means that if you can't do it in Ratel you can simply just write it manually in Nim (or even emit some C code). When designing the abstractions I try to keep them as useful as possible in order to write clean, simple code, but not at the expense of bloating the code. You mention that hardware costs is one of your major concerns and when I wrote my keyboard firmware in Ratel I managed to get it small enough that it could run on an Attiny85 with i2c port expanders and V-USB. This is something which is typically done on boards that are 10 times the price, if not more.

Building for different boards but using the same code-base is basically the whole reason I started this project. I like to program microcontrollers, but doing this in Nim has been a hassle in the past. First you had to find (or create) a build system and abstraction layer for your board. Then you had to learn those abstractions and their quirks. With Ratel the idea is to get much closer to something like Arduino where you simply choose the board you want to build for and without changing your code (or at least very minimally so) you can run it on that new board. While board support currently is pretty poor this is something I'm working on improving. I'm also in the process of writing a guide on how to add new boards, something which is a rather simple process and basically just involves implementing the low-level abstractions and then the high-level abstractions are written in a board agnostic way. It is also possible to implement a board as a separate nimble package, so there is no need to PR or merge your changes into Ratel.

[flplv]

Thank you for the response. Do you want to have boards added in the project itself or in user code or third party package? I ask that because I wonder how to support custom board without having to actually checkout ratel and change it.

[PMunch]

Well it's a matter of support and feature-complete mappings. If you plan on implementing all the interfaces like I2C, SPI, and UART for your board and to maintain the build scripts and such then it would fit nicely within the main repo. But if you only want to create a board quickly and implement the things you specifically need for whatever project you're working on, then starting it as a separate package would be the best option. If it later gets built further by your or others then it could be included back into the main repo.

There is also the matter of similar boards. An example are the AVR chips which come in multiple variations. Currently I have implemented some generic AVR helpers in the main repo, so adding new boards there can benefit from those. They also share the build scripts so that's another benefit.

The process for either are pretty similar, they just differ in where to put the code.