Close

Automatic code generation

A project log for MCU pin setup

Visual pin layout setup tool for development boards with an editor mode for community involvement

norbert-feketeNorbert Fekete 03/28/2017 at 14:450 Comments

I've put the initial code generation commit into my website: https://hubberthus.github.io/

It creates a basic header which can be downloaded as a zip file. Has no functionality in it yet.

But if you turn on/off the "ADC", it will include/exclude code, so preprocessing via JavaScript can be done.


I've been thinking lately a lot about the automatic code generator, which could be a powerful function of this tool.

If I think in FreeRTOS, then there's several MCUs I can use, it is available for:

There is a trend to become Arduino-compatible because of its simplicity and number of libraries it offers. Virtual cores are being developed for it so anyone familiar with Arduino can do a simple jump-start.

Something similar could be achieved for FreeRTOS.

Why FreeRTOS?

It provides a different approach than the standard "main loop+interrupts". And can also be made easy using UML modeling tools supporting FreeRTOS. Imagine your kid just drawing the threads and state-machines, then simply generate the application code from it. Could be a great way of teaching multi-threaded real-time OS approaches to problems.

Adding the MCU pin setup tool the virtual layer code can also be generated automatically, based on a very visual setup.


If this tool could create a generic C header file as a basic interface for all kinds of MCUs and boards, and C sources would be based on the specific MCU with the specific setup done.

A Makefile then could be used to select from targets, like "make arduino2560", "make esp32" or something like that.

Now, this tool can be used to create the pin layout, and turn on/off and setup peripherals. Also, different MCUs can have specific peripherals available.

This difference can be however handled by giving back an error code (or throwing an exception in case it would be in C++) if the code tries to access unavailable peripherals. For basic features like UART, I2C, SPI... it should not be a problem to have cross-compatibility. Other unique features should be handled by the application if it wants to be cross-MCU-compatible.

As test I will try to make something run on an Arduino, an ESP32, and also an STM32. Wish me luck..

Discussions