Hi everyone,

I’m working in a young biotech company developing a scientific instrument for supporting its technology. I contact you on this forum for having your opinion on some choices that are offered to us at this early stage of the development of the apparatus firmware.

Our system has quite a lot of sensors and actuators to manage. The associated calculation is not really heavy but still quite significant. We will probably use USB interface for exchanging informations with a workstation. We also need to couple an HMI to our microcontroller, we plan to use a 800*480 LCD-TFT touscreen. We have chosen a STM32F746NGH6 microcontroller for our system as it has enough power and I/O for managing all of our peripherals including the touchscreen.

Two questions come to us at this point for the software:

-What do you think of using the TouchGFX engine for driving our HMI ?

-Is the use of an RTOS like FreeRTOS interesting for managing all microcontroller routines ?

Please tell me if I need to give you more details about the hardware.

Thanks,

Choco_melon

I would highly recommend you investigate Miro Samek's FSM (Finite State Machine) approach as an alternative to an RTOS. Your project sounds like a heavily event-driven system, which is what this approach handles.

His website is https://www.state-machine.com/. He also has an excellent book, "Practical UML Statecharts in C/C++, 2nd Edition: Event-Driven Programming for Embedded Systems", which you can buy in printed form, or download as a free PDF (click on Resources on the menu bar at the top of the site main page).

While he has a framework and tools available, you can certainly apply all of the concepts on your own.

The learning curve is not difficult, since it builds on common FSM concepts. There is some material to digest. A lot of it is convincing yourself that this approach is a viable alternative to the typical multithreaded RTOS approach.

Thanks, I do not know about this approach, I'll have a look

I would "second" 'sdbranam's vote for Samek's solutions. I think pairing his QF framework with FreeRTOS will give you a great deal of flexibility.

I've applied Samek's C++ solutions in many projects now. The only time I was frustrated was in a project that also used the associated kernels. When using QV, QK, or QXK, the active objects run in a strict run-to-completion environment (i.e. no blocking). This is great if you control all the source code and enforces my preferred event-driven software design. However, it is a bit frustrating when integrating third party libraries that expect traditional RTOS blocking behavior. This forced the project to use QXK and use "raw threads" and yet more messaging between an associated active object to control the third party library. It all worked great in the end, but I think I would have preferred to use FreeRTOS + QF, where such restrictions are not imposed (I think). Something to be aware of if the project is expecting to use third party libraries for any of those sensors.

I've also used TouchGFX + QF + QK. This worked pretty well, but make sure you study the patterns associated with TouchGFX and consider how to apply it to an active object, if you take that approach. The touch handling can be tricky!

And, if it helps, I have received good feedback on this older blog entry of mine:

https://covemountainsoftware.com/2017/03/09/questions-to-ask-software-architecture-design-and-coding/

Hope that helps,

Matthew

https://covemountainsoftware.com/services/consulting/

Sorry if I didn't reply in time, but I want you to know that you advices are preciouse to me. It may help me avoid some critical mistakes 

I can respond to half of your questions. The last time that I needed to use a touchscreen was 20 years ago and everything was roll-your-own drivers and react to simple touches.

However, I do have experience with sensors and real-time monitoring. Using STM32F7 processor family is a good choice. There are usually plenty of communication ports for your application.

Now, concerning RTOS. I've been a believer in being greedy, selfish, and a whole list of otherwise nasty attributes when it comes to software development. That is, if you want it to work exactly like you want it to work, write it yourself. Don't let somebody who isn't around to tweak the software tell you how it should be done in your project. Avoid the RTOS and develop your own set of IO handlers.

I have been using the method of "setting everything up and then run in an infinite loop" since I wrote a commercial IDE for the IBM PC (the kind with two floppy drives and no hard disk). Must have been a good choice, the STM32IDE code generator sets up the same model. 

The code generator writes good interrupt handlers. Use those for communicating with your sensors. You will need to deal with sensor output quickly in the section of code that you have to write. I suggest that you fetch the data and put it into a circular queue and deal with it during the infinite-loop.

The trick to using the infinite loop is not to get stuck in any function in the loop for any amount of time. Do a little bit and move on. This is where the finite-state machine mentioned earlier comes in. Divide the steps for talking to the sensor or performing any analysis into small steps. For me, each step in a block of code or method called from a "switch / case" statement (the heart of the state machine) - you can also use a table of pointers to functions and the state is the index of the table.

Each trip around the loop, you enter each of the FSM functions and if there is nothing to do to advance to the next step (waiting for the circular queue to show that data is available, for instance), leave and proceed to the next FSM function.

You might have code that looks something like this:

while (1)

{

Handle_User_Commands();

Handle_User_Responses();

Handle_GPS();

Handle_Gas_Sensor();

Handle_Temperature_Sensor();

Handle_TouchScreen();

Handle_LCD_Display();

HAL_Delay(SOME_DELAY_IF_REQUIRED);

}

Last - The joy and feeling of accomplishment in software development is meeting each challenge (The "I don't think that you can do it" challenges are the best) and solving it. Be inventive and creative.

Thank you very much, it was great to give a so detailed reply on how fsm work. I'm starting reading Samek's fsm now 

I've never used it myself, but it looks like a good tool. In particular, it has a simulator, which IMO is critical for developing graphics applications, as trying to debug graphic UIs on a download/test/repeat cycle on a micro-controller is painfully slow. You want to develop UIs on a workstation. The main things to watch out for on a graphics library are that it is fast enough to drive the display at an acceptable frame rate, and that it doesn't steal too many processor cycles from the actual application while doing so. A touchscreen GUI with just some buttons and static displays is far less intensive than one that is expected to show real-time 60Hz animated graphics. The only way to know for sure is to write some tests screens/widgets similar to your app and profile the CPU usage of the library on the micro-controller.

The development system for TouchGFX also runs on a Linux host which is a huge plus in my NSHO.

<i>Is the use of an RTOS like FreeRTOS interesting for managing all micro-controller routines ?</i>

An event-driven architecture is key in any case. We've used FreeRTOS before on projects and liked it. My 'trip point' when moving from a pure self-written event-driven loop to an RTOS is when I start needing some more sophisticated drivers. Simple serial ports or I2C is easy enough, but when the application starts calling for USB, network stacks, and other more sophisticated protocols an RTOS with those drivers already available and tested comes in handy. Moving to an RTOS does throw in more overhead and requires a step up in micro-controller power. I've never used the STM32F746NGH6 itself, but I've been impressed with the STM32 parts I have used. The only way to really know if it can do what you want is get the dev kit and benchmark a quick prototype screen and do some acquisition/calculation cycles with some of your sensors. You'll usually get a really good or a really bad feeling at that point about your processor choice :-)

TouchGFX or something like CrankSoftware would work for your solution. 

It sounds like your system may be Real-time and has enough time management activities to deal with that an RTOS would make sense.

Thanks for you reply, does freeRTOS seems fine to you or do you suggest another RTOS?

I agree with @beningjw and @sdbranam.

I must confess I didn't know Miro Samek's FSM ( thanks @sdbranam, I'll give it a try ).

Basic use of FSMs written by your own is not so difficult, but the problem with writing your own FSMs is that it's hard to implement process communication tools, like semaphores and mailboxes, that RTOS brings it ready for you and perhaps Miro Samek's FSM too ( I'll check it ).

Of course, either FSM or RTOS can be used in all cases, it's a matter of taste, I think.

My advice here is: Don't write your own tool. Use well known and proven tools. This remains valid both for FSMs and RTOSes, as for GUIs. And stick to a good coding standard, like "Embedded C Coding Standard from the Barr Group". By doing so, you'll be paving the way for quality software.

Cheers!

There is no need to reinvent the wheel (device drivers) time after time. You would be more interested in the bio-logic of your device, rather then in fiddling with the registers of USB or SPI controller. So, an RTOS with a good set of drivers would be highly recommended.

You can have a look at RIOT-OS: https://riot-os.org

The documentation is available here: https://doc.riot-os.org

I've used it before with STM32F4xx, but I see that your MCU is also supported.

  Vadim