3 ms·

When I experimented with using an STM32H7 for accessing sensors, it was just nowhere near powerful enough for handling real-time 720p @ 30fps on 2 cameras. Also

When I experimented with using an STM32H7 for accessing sensors, it was just nowhere near powerful enough for handling real-time 720p @ 30fps on 2 cameras. Also, good luck getting USB3 out of that CPU... Here's a similar commercial product that - in my opinion - also failed badly: https://openmv.io/collections/cams/products/openmv-cam-h7-r2 https://openmv.io/collections/cams/products/openmv-cam-h7-r2 $80 uses a STM32H743VI CPU and "Most simple algorithms will run between 25-50 FPS on QVGA (320x240) resolutions and below" I predict that his will be vaporware when the authors switch over to using FPGAs like everyone else who tried (and failed to) use cheaper alternatives. Also, once you ramp up your numbers, producing FPGA-based 4k @ 60fps USB3 cameras for $50 per piece becomes possible. So there is in my opinion no good reason - neither technolgy-wise nor price-wise - to use the STM32 here. But welcome to the club, I made the same mistake ;)

dannyw 5y ago
I speculate OP isn't trying to build a commercial product, but rather tinkering with STM32s for this task because they can. Sometimes it's fun to write on very constrained hardware.
adolph 5y ago
Since you write with an authoritative voice, I ask: * I've most often heard of the STM32 series as microcontrollers instead of microprocessors and never as CPUs. What is your reason for referring to them as a CPU? * What is wrong with "25-50 FPS on QVGA (320x240) resolutions and below" for low cost use cases, like a step up or longer range than an ultrasonic obstacle sensor? * What is the advantage of an FPGA over a microcontroller or microprocessor of similar cost? Are there disadvantages in terms of additional technical debt to programming a FPGA instead of a higher level controller or processor API?
- fxtentacle 5y ago
  Dear Adolph, shouldn't you be the one speaking with an authoritative voice? ;) I'd say "microcontroller" and "CPU" are both designations of their purpose, whereas "microprocessor" is a designation of technology. So yes, usually the STM32 are used as hardware/sensor controllers alongside with other microprocessors and then it makes sense to call them "microcontroller". But in this specific hardware design discussed here, the STM32 acts as the central processor coordinating everything. That's why I called it CPU to highlight this central function. "25-50 FPS on QVGA (320x240)" is just too little performance for most practical applications. Also, $80 is very far from "low cost use case". That's why I pointed out that for the same price, one can have much more performance using FPGA. Who wouldn't want 100x faster at the same price? The big advantage of an FPGA is that you can drive its clock from an external source. If you hook a CPU up to a sensor, it needs to burn CPU cycles (or have dedicated FPGA-like hardware) to read bits from the port when the sensor sends them. With an FPGA, you can take the sensor's clock and use that to drive your circuit. But much simpler than that, CPUs are built to handle a lot of different tasks at an OK price. FPGAs are more like GPUs. They do signal processing very well, but fail badly in other areas. Plus CPUs can be programmed easily in a variety of languages, while using an FPGA well requires obscure tools and knowledge. CPUs are Easy+Generic+Slow. FPGAs are Difficult+Specialized+Fast.
  - adolph 5y ago
    Thanks for the reply. I found the below page as a relatively updated info source. It is interesting to see your note about FPGAs being more akin to GPU and then see many development boards pair a FPGA with an Arm processor. https://www.joelw.id.au/FPGA/CheapFPGADevelopmentBoards https://www.joelw.id.au/FPGA/CheapFPGADevelopmentBoards
mediaman 5y ago
Openmv is actually pretty great. I agree if you need 4k at 60fps, or stereoscopic, it’s not for you, but there are lots of industrial tasks that require nothing like that. I’m using it now and it’s great to program the thing in micropython and do blob tracking, fiduciary marker recognition, etc with it at 20-30fps or so, which is all I need. I can see how you’d think it’s a commercial failure if you approach it with an incompatible use case.

dannyw 5y ago

I speculate OP isn't trying to build a commercial product, but rather tinkering with STM32s for this task because they can. Sometimes it's fun to write on very constrained hardware.

adolph 5y ago

Since you write with an authoritative voice, I ask: * I've most often heard of the STM32 series as microcontrollers instead of microprocessors and never as CPUs. What is your reason for referring to them as a CPU? * What is wrong with "25-50 FPS on QVGA (320x240) resolutions and below" for low cost use cases, like a step up or longer range than an ultrasonic obstacle sensor? * What is the advantage of an FPGA over a microcontroller or microprocessor of similar cost? Are there disadvantages in terms of additional technical debt to programming a FPGA instead of a higher level controller or processor API?

fxtentacle 5y ago
Dear Adolph, shouldn't you be the one speaking with an authoritative voice? ;) I'd say "microcontroller" and "CPU" are both designations of their purpose, whereas "microprocessor" is a designation of technology. So yes, usually the STM32 are used as hardware/sensor controllers alongside with other microprocessors and then it makes sense to call them "microcontroller". But in this specific hardware design discussed here, the STM32 acts as the central processor coordinating everything. That's why I called it CPU to highlight this central function. "25-50 FPS on QVGA (320x240)" is just too little performance for most practical applications. Also, $80 is very far from "low cost use case". That's why I pointed out that for the same price, one can have much more performance using FPGA. Who wouldn't want 100x faster at the same price? The big advantage of an FPGA is that you can drive its clock from an external source. If you hook a CPU up to a sensor, it needs to burn CPU cycles (or have dedicated FPGA-like hardware) to read bits from the port when the sensor sends them. With an FPGA, you can take the sensor's clock and use that to drive your circuit. But much simpler than that, CPUs are built to handle a lot of different tasks at an OK price. FPGAs are more like GPUs. They do signal processing very well, but fail badly in other areas. Plus CPUs can be programmed easily in a variety of languages, while using an FPGA well requires obscure tools and knowledge. CPUs are Easy+Generic+Slow. FPGAs are Difficult+Specialized+Fast.
- adolph 5y ago
  Thanks for the reply. I found the below page as a relatively updated info source. It is interesting to see your note about FPGAs being more akin to GPU and then see many development boards pair a FPGA with an Arm processor. https://www.joelw.id.au/FPGA/CheapFPGADevelopmentBoards https://www.joelw.id.au/FPGA/CheapFPGADevelopmentBoards

mediaman 5y ago

Openmv is actually pretty great. I agree if you need 4k at 60fps, or stereoscopic, it’s not for you, but there are lots of industrial tasks that require nothing like that. I’m using it now and it’s great to program the thing in micropython and do blob tracking, fiduciary marker recognition, etc with it at 20-30fps or so, which is all I need. I can see how you’d think it’s a commercial failure if you approach it with an incompatible use case.