Electronics > PCB/EDA/CAD

Problems in Modern Embedded Dev

(1/5) > >>

country2304:
I'm thinking about making an open-source project related to some problems I've experienced building commercial IoT products and I'm interested to hear other people's thoughts on the stumbling blocks they have encountered in embedded device development.

- I would like to be able to use higher-level languages with nicer syntactic sugar, (using Micropython in the past has sped up dev time, especially during rapid prototyping). However, most solutions like micropython don't seem viable in most constrained environments.

- When I've built CI pipelines in the past it has been not easy to integrate the device firmware into end-to-end tests of our entire system, backend included. I would like to be able to use as much of the actual code run on the device to be used in the tests and not have to write mock code for different hardware functions. (Of course, this kind of test is more useful in scenarios without critical timing components etc. that would require proper simulation of the hardware).

- More generally, I've found that in the embedded world there are fewer tools for managing projects with systems like package managers, maybe more equivalent to what exists in the js world.

Slh:
I'm not sure if there's a question in all of that but there's no substitute for having real hardware for testing. You need a rig that can input all of the inputs (eg button presses/shaking/audio whatever your IOT thing measures) and take all of the outputs (audio/lights/motors). Unfortunately that costs money and takes time to set up and program. But no one ever said that hardware was cheap :)

You can get fancy HIL rigs that might make some of this easier. Probably not cheaper though :)

nctnico:
If you have a good model of the hardware, you can do automated testing for sure. So the claim that you absolutely need hardware to do software verification is false. But you'll need to invest the time to create  a good model of the hardware in software (including timing). The advantage of having a model instead of real hardware is that you can test things like hardware failures and values going out of bounds without causing damage.


--- Quote from: country2304 on November 18, 2023, 03:52:35 pm ---- I would like to be able to use higher-level languages with nicer syntactic sugar, (using Micropython in the past has sped up dev time, especially during rapid prototyping). However, most solutions like micropython don't seem viable in most constrained environments.

--- End quote ---
I would not really care about constrained environments. Microcontrollers continue to be equiped with larger and larger memories with dropping prices. So by the time you have a solution, it will be outdated (*). You could opt to use Lua instead of Micropython as Lua has a slightly smaller footprint. Just check how incredibly cheap an ESP32-S3 chip is for the amount of processing power, memory and storage space you get.

* Just look at how Nokia failed by clinging on to their rather crappy Symbian OS while Google killed them by creating Android using Java. There couldn't be a bigger contrast in approach but what Google did was enabled by advances & price reductions in technology.

dobsonr741:
If you can allow the luxury of micropython, then you can also think about having more compute intensive features for the product, or lower the hardware requirements to lower cost. I bet you would not find micropython in shipping devices by the millions in qty.

As far as stumbling blocks: not enough test vectors/cases in testing. True for both software and hardware: Not enough variance of data, or not enough variation of environmental disturbance/noise/transients if the DUT is hardware.

Smokey:
There is a reason the device categories of " microcontroller" and "microprocessor" are two separate things.  The problem isn't always resource constraints (it often is), unless you count time as a resource.

More and more stuff will accommodate higher levels of overhead as the clock frequencies and memory levels continue to go up, but there will always be applications that are better suited for real optimization.

Target raspberry pi and that stuff if you want an easy application for high level languages and integration.  Real embedded microcontroller type engineers probably aren't going to care what you are doing and are going to keep working as they always have for quite some time.

Navigation

[0] Message Index

[#] Next page