Feature request: Programmable logic

[LVan .31]

I am a fan of STM32, especially the peripheral sets offered are great. Over the years however, one type of peripheral is missing which would be a great help for many projects, this is a programmable logic cell.

Such a cell would contain elements like Flip-Flops, Look Up Tables and such that can be configured for specific functions. For instance using the LUT's, it would be possible to create all kinds of logic operations like AND, OR, XOR gates.

Using the Flip-Flops, I would be able for instance to create a clock gate, which I needed in my last project. There I needed an external clock signal to propagate to other peripherals and be able to enable/disable this. In the end I manage to create this function with a timer but this unfortunately generates something like 9 clock cycles of latency limiting the maximum frequency of the external clock signal. A basic Flip-Flop solution would probably introduce a much smaller latency.

Competing products offer this kind of functionality more and more, for instance the Microchip SAMD51 offers a Custom Logic cell which is highly programmable.

Such a peripheral would offer inputs and outputs that can be connected to other peripherals (GPIO, Timers and so on). Here I do see an issue since the Peripheral Interconnect of STM32 is not quite generic but very specific for the different types of peripheral. Another consideration would be to add so called hardware event channels to the STM32 which allow connecting almost any peripheral event output to another peripheral event input.

Well forgive me for starting to design, just adding the programmable logic would be really great for many control oriented applications.

[LCE]

One more vote for some extra configurable logic in STM32

[BarryWhit]

Thank you all for your interesting comments. I reiterate my support for the addition of a "CLC/CCL/CCLLCCLC/etc"-like peripheral to future STM32 families, together with the addition of lightweight graphical configuration pane in CubeIDE. Beyond that, I don't think more comments are needed, from me anyway.

[unsigned_char_array]

---

@BarryWhit wrote:

Thank you all for your interesting comments. Beyond that, I don't think more comments are needed, from me anyway.

---

Why are you acting like the OP? Very confusing.

[Nikita91]

Raspberrypi used another solution by introducing PIO with the RP2040.
This makes it possible to generate peripherals not provided for by the manufacturer, using this type of very fast processor (it's almost the 4-bit processor requested by someone, but more flexible).

But overall ST has chosen another direction: to provide in each MCU a large number of peripherals of all kinds, increasingly complex, but not all usable at the same time due to the lack of interconnection between them and with the outside world. The notion of AF is very primitive and rustic (there are a lot of empty boxes in the tables), and the more the number of IPs in the MCU increases, the more crucial the problem becomes, which leads to having to choose a case with more pins than necessary.

Introducing something like PIOs or logic cells would produce another MCU architecture:
- Fewer peripherals such as SPI or UART (can be replaced on demand using programmable logic)
- simpler peripherals (I2C and UARTs are very complex at ST, and must consume a lot of cells)
- Need for fewer timers: no more need for master/slave chaining to generate complex signals (but it is still possible if necessary). Given the limited number of timers, their channels must be able to be directed to any GPIO.
For this to work you need more interconnection between the devices (like the Atmel event buses).

Silicon saved on peripherals can be used for interconnects and programmable cells.

Summarizes the expected MCU for me:
- Fewer core peripherals: 2 UART, 2 SPI, 2 I2C. But complete: FIFO, interrupt, etc.
- Few timers: TIM1 for motors/power supplies, TIM2 and TIM5 in 32 bits, all in 4 differential channels.
- An interconnection bus for peripheral events.
- A generalization of the GPIO assignment (which allows the use of cases with fewer pins)
- And PIO and programmable logic: LUT, FLIP/FLOP,

This would likely lead to a "small" MCU in terms of silicon surface area.
So yes this will require changing programming habits, but what flexibility of use!

But this completely changes ST's vision of MCU architecture, and therefore it is unlikely to see the light of day. Not to mention that CubeMX might need to be thoroughly reviewed. In my opinion, if programmable logic is introduced, it will be in the current architecture: limited and fixed interconnection of peripherals, and assignment of specific GPIOs (even more competition for I/O), which will limit their use.

But I'm still impatiently awaiting this development.