About architecture

[CS.3]

Hello to the whole community. I want to replicate a project I have already developed on AVR microcontrollers, on the STM32 platform by introducing a graphical GUI using TouchGFX. Substantially the project is a control system to measure the rpm of some fans and I would like to add a graphical part that unfortunately the MCU ( 8-bit) I'm using now doesn't allow me to do or anyway is very basic and not smartphone-like. I am not familiar with the architecture of the STM32 family, but it is obviously much more complex than the C register programming of a small MCU. However, I was wondering if someone could answer some of my questions:

How are the ISRs from the outside handled? Or rather if I exploit the graphics rendering part of the MCU a lot, can I run into errors, in the measurement? Is it better to put a dedicated microprocessor alongside to handle interrupts, computation,etc. and delegate only the graphics part to the STM32?

Which board can I purchase to be able to work on the development of the whole thing?? A basic requirement is to have a 2.4/2.8inch touchscreen LCD on board.

Thanks to all

[Peter BENSCH]

Welcome, @CS.3​, to the community!

Even the STM32 with Cortex-M0 or Cortex-M0+ are orders of magnitude more powerful than the small 8-bit AVRs. The STM32 with Cortex-M4 or -M33 or even more so those based on Cortex-M7 are like Formula 1 racing cars compared to AVR walking aids.

Nevertheless, depending on the structure of your system and the interrupt load, jerking can occur, but this is more likely to happen only under very heavy load due to the sheer computing power. Typically, for the mentioned fans, if there are 4...8 pieces of them, one MCU should therefore be sufficient, e.g. an STM32F7.

For evaluation, one of the many DISCOVERY boards can be useful, because very often an LCD is already included (2.4" - only one with resistive touch, the rest LCD round (3.2"), square (1.54") or rectangular (4"...4.3"). However, very few have more than a few GPIOs left, because a lot of GPIOs on the boards are occupied by sensors and other functions. However, they are very suitable for trying out and for the first steps with TouchGFX.

With a NUCLEO board, you can then tailor the project most flexibly to your target platform, although you also have to do all the driving and control of the display in question yourself.

Does that answer your question for the time being?

Regards

/Peter

[CS.3]

@Peter BENSCH​ 

Hi Peter thank you for your answers.

My project is quite basic, it is based on counting the rising fronts of 8 fans to determine the rpm. This I would do via the internal timers I have available in the time unit of one second. A PWM pin where I manage the duty-cycle of them and the GUI part. You mentioned STM32F7, from the ARM-Cortex M7 series, isn't that oversized for my use? Also as a matter of production costs

Regarding the amount of GPIO available on Discovery boards, I would like to understand one thing. If I start by using a NUCLEO board (Which one for example?) can I realize driver - MCU management independently with any driver or only limited to specific components? Let me explain further:

If I want to interface an LCD display via SPI/I2C interface to the NUCLEO board, can I still use the TouchGFX Designer software to realize the GUI? I ask this because my intention is to , after development, integrate everything on my own circuit board with the appropriate MCU, but in the application interface I only have predefined development boards.

Best Regards

Charles

[Tesla DeLorean]

There are a lot of third-part boards out there, some more focused on break-out, and some more on integrating functionality. Perhaps look at AliExpress and Taobao type markets, or WaveShare boards

Interrupts via EXTI and TIM to monitor frequency and pulse widths should be relatively responsive, you just want them really to record / log accurate data, and process that in worker threads/tasks. DMA can be used for capturing tight timing or higher frequency data.

The DISCO boards frequently just have what pins are exported via Arduino shield headers, but as you observe you could probably use a AVR or similar to gather/capture signal info, and use a serial or reduced interface to off load that to an STM32 MCU.

If you partition your design you can likely balance how the design evolves as you migrate it and get comfortable with which chips, screens, and GFX/RTOS are best suited to your application and development style.

[CS.3]

@Community member​ 

I had also thought about splitting the two activities, management and data collection by entrusting it to a smaller MCU and passing the data to STM32 to have it handle the graphic rendering. It's a more expensive solution, and I don't know if I would really benefit from it in terms of reliability....

[Pavel A.]

@CS.3​ Indeed it looks like the limiting factor for you is the display interface and pin count.

You want a high quality graphics, but these consume many pins. I2C or SPI displays use few pins but less bandwidth. Cheaper CM0 based STM32's do not have LCD interfaces.

So your choice is a F4 (as Peter advised) that has enough pins for I/O.

If a segment LCD can work for you, look also at STM32L0x3.

In the worst case you'll need another chip as I/O extender on a low pin count interface, maybe even a STM232C0 or a 8-bit MCU.