Embedded Rules of Thumb (2018)
embeddedartistry.com
embeddedartistry.com
Some components can become sensors under the right conditions. Example: Components becoming microphonic.
At high enough frequencies digital design becomes analogue design.
I've heard this stated as "the difference between digital engineers and analog engineers is that the analog engineers KNOW when they're designing an antenna".
Hahaha this is a beautiful quote! I didn't believe this was a real concern until I ran into it in the real world.
Professor: "How fast is your computer at home?" - Me:"2.8GHz.", Professor: "OK, and what is considered the start of the microwave band?" - Me: "1 GHz" Professor: "So, I will see you next semester?"
It turned out to be a great course, we built antennas, resonators, did simulations and compared to physical results, talked about a lot of different situations. In my career as a software engineer I have made great use of that knowledge by being able to better understand the issues that my EE counterparts are working on.
It's a great time to be a digital engineer. Projects like the PocketVNA and the NanoVNA-V2 make it feasible for you to do professional grade S parameter measurements of digital traces at home.
Pair them with QucsStudio, and you have a near professional grade high speed simulation package available for less than $500. So cool.
And, speaking of Rules of Thumb - Embedded Artistry's page calls out Eric Bogatin's Signal Integrity Rules of Thumb as well, which is a fantastic series of blog posts on high speed digital design and signal integrity. Worth a read if high speed digital design is your thing.
Literally the main point of 'Embedded'.
Every truly successful device will be used for purposes you didn't dream of when you first created it.
Yes for many embedded microcontrollers.
Not so sure for larger devices with possibly several ECUs and in the field upgrades. All of the sudden the whole thing becomes a tiny data center with several nodes, and the architect needs to value some flexibility over clear cut single purpose.
In automotive, embedded is transformed in this way.
I disagree. If you have interrupt priorities then you can treat your interrupt service routines as the highest priority tasks. As an example lets imagine a drone controller which has two functions it needs to perform in real time: it needs to vary the PWM signal to the motor controller and it needs to acknowledge radio packets. An interrupt is raised when the accelerometer has new data and another is raised when the radio has received a packet. You could write ISRs which just queues the accelerometer data and radio packets so they can be dealt with by a flight control task and a radio task respectively. Alternatively, you could run the whole of the flight controller inside the accelerometer ISR. This reduces copying of data and context switches. Because the accelerometer ISR now takes longer you need to use the radio ISR to acknowledge the radio packets itself. You split the radio task into two tasks: a low priority task for processing commands and the ISR task which does the acknowledgements.
> Avoid blocking function calls
This can be rewritten as never call functions that block on an action of a lower priority task. It leads to priority inversion in normal tasks and deadlocks in ISRs.
I think "Keep ISRs small" is still a good guideline for most cases. Big interrupt handlers require more system-wide knowledge to verify (e.g., stack space, maximal latency, priority problems, ...). They introduce more coupling into the system, in other words.
Of course, this should not be some hard rule, rather just a rule of thumb. I wouldn't like it if some policy like this prevented you from choosing the optimal solution in a case like you suggested.
I think the point I'm trying to make is that sometimes following the rule of "make your ISR small" actually makes this worse because your bigger high priority task can be interrupted or you turn interrupts off or mask interrupts and you end up with even more complexity.
Another example: if you are shipping over a million units, then adding hardware to simplify software starts to look like a bad trade-off since BOM starts to dominate NRE.
I disagree.
I think the idea of "keep ISRs small" is that it is easier to spend time polishing your ISRs to be as small as possible than deal with long ISRs. As soon as you have long running (long is a relative thing) it is extremely difficult to guarantee any behavior of the system.
I understand your sentiment but simply pushing the work into a task doesn't make guaranteeing the behavior of the system any easier. And I argue that in some cases, it makes it more difficult, if you can eliminate an entire task by putting its processing in an ISR then that reduces the complexity. Handling priority inversion correctly is the example that springs to mind.
For those who are unaware, the NVIC effectively turns the interrupt handling system into a hardware-based FIFO strict realtime task scheduler. The only hard limit is that since all of the tasks are executed on the same stack frame that you need an interrupt stack large enough for the maximum nesting depth. You can safely do much more work in an interrupt handler with such a system than you can in a classical non-nested interrupt-handling system.
You contradicted yourself here. You moved the code out of radio ISR to application code, thus keeping the radio ISR small.
Which means ISRs can grow too big. And that’s the reason keeping ISRs as small as possible should be your goal.
ISR's are random events that preempt your scheduler.
Deferred Service Routines run in the same thread as your scheduler.
It's excruciatingly hard to write (correct) code that can be interrupted and have it's internals monkeyed with at any clock cycle.
Thus the ISR/DSR handoff is a way of sequencing events into a manner the scheduler can handle sanely.
Most ISR's are written to be preemptible, it ack the interrupt and enable interrupts. Thus the chance of losing an event is very small.
The larger your isr the more you're into the realm of "excruciatingly hard to write (correct) code".
Your scheduler may be very simple... eg. only one thread as you described above, but my point applies.
Controlling the motor is a real-time digital control system task, and it needs to be executed at exact time intervals, otherwise you introduce noise and instability into the control loop. "Accelerometer has new data" is a terrible trigger for the control loop. You always want to execute the controller at fixed intervals, triggered by a timer interrupt.
Once you enter that timer ISR though, you are correct. You need to run the whole thing, starting with adjusting the PWM according to the result of the previous control loop, then sampling the sensors and finally running the control algorithm, all before exiting the ISR. This is the epitome of a "hard real-time" requirement.
This is correct but also the accelerometer data needs to be sampled at the same interval. For this reason, running the control algorithm in lock step with the sensor may be sensible.
I think it is important as engineers to always try and keep an eye on the big picture. Many times it is easy to get bogged down in an interesting technical problem in embedded engineering, and we can forget how that problem fits in with the overall state of the project. One example was I found that I could not send more than 1 USB bulk packet per millisecond using Texas Instruments' USB library, even though in theory you could send 19 per millisecond. I wasted a few days to try and fix that, but it was a waste of time because speeding up USB only sped up firmware updates which were not a big deal! There are many examples like this unfortunately.
I think the biggest thing missing from this list is how important it is to thoughtfully design the hardware to make the firmware easier to design. This requires a less agile approach, or more flexible prototype hardware until requirements are better understood. Just one example is using separate SPI/I2C busses for separate peripherals, even though technically they can be shared. This helps you not have to worry at all about collisions or managing Direct Memory Interfaces (DMA).
I think it is also important to have a big enough test point to actually use too! There have been many times I have been trying to hold a probe to a tiny little exposed circle pad, just wishing it was something big enough to clip a lead to.
The "My USB throughput is not what it should be... Oh, well. Must be the USB cable..." attitude is something that can bite you later, because it can be the symptom of a bug (e.g. packets lost because of a buggy ISR) that's just waiting the worst moment to show its ugly face.
Jack Ganssle is quoted repeatedly - his blog has a lot of good war stories that illustrate many of these points in much greater detail.
Thanks for the link to Ganssle’s blog. I’ll be sure to have a read today.
> Algorithmic optimizations have a greater impact than micro optimizations
This is kind of tautological, as micro optimizations can be an important part of algo optimization. We don't execute algorithms on formal automata, but on real machines with real architectures, limitations and opportunities.
> * “Real efficiency gains come from changing the order of complexity of the algorithm, such as changing from O(N^2) to O(N*logN) complexity”
Only if the constant factor that multiplies the lower-complexity expression is small enough and N is large enough.
As an electronics enthusiast, this really sheds a lot of light on different aspects of hardware/software development that I hadn't been exposed to before. I feel like there is a lot of tribal knowledge that people in the business or going to school for EE stuff are privy to that isn't always out there for the rest of us, so kudos for aggregating some of that.
along the same line, does anyone have further articles on hardware topics, like sourcing parts for commercial products? It's another part of electrical engineering and bringing products to market that I haven't seen much of online but would love to learn more about.
That's a topic onto itself. Is there something specific you're thinking about?
I've seen a lot of really cool hobby projects turned small run commercial products in the music/synthesizer world and I guess I'm curious how you would go about sourcing parts for something like that in way that's close to how it's done professionally.
Also, more specifically what sort of tools do people typically use for managing inventory? How about comparing prices/vendors? I imagine something more sophisticated than a simple spreadsheet would be in order and I have to figure it's different from company to company, but are their any widely accepted industry standard tool?
What throws this off is that a lot of shops these days use Contract Manufacturers (CM's). Since CMs are building boards for many different shops, they can purchase parts in larger volumes and get better pricing. They make it easier to outsource some of your manufacturing since you can just give them a BOM (Bill of Materials) and your PCB files and get complete, tested boards back. So you don't even need to deal with parts shopping, etc.
As far as inventory management, if you're not big enough to be using an ERP (Enterprise Resource Planning) system, it's likely a Quickbooks plug-in, a spreadsheet or something custom built.
IME, as long as they people can meet their BOM price target, they just buy from whoever they're used to dealing with.
I have a couple products in low-volume production manufactured in my basement. 90% of my components are purchased from Digi-Key because we're both in Minnesota (and Digi-Key is the best vendor I've ever dealt with) so most things I order arrive the next day without having to pay extra. They also have BOM tools on their site: I can create a bill of materials for a board to make it easier to order parts: just bring up the BOM and enter a number of units and it will create a shopping cart for me.
I'll occasionally look around for better prices on some high-cost parts, but it's hardly worth it at my low volumes: there really isn't enough price variation on most things.
Counterpoint.
Your users won't read the documentation. Get used to it.
Odds on your developers won't either.
Take care when you do read the documentation, it's probably out of date and / or wrong.
Which points exactly?
Also, neither the Rust standard library, nor the C++ std::shared_ptr were designed with embedded in mind. Also, Rust is kind of experimental, not really a good choice for a system that is difficult to update. Not to mention only Intel and AMD64 platforms have Rust Tier 1 support.
Depending on the platform Rust or C++ may not be the first one I reached for.
C is pretty compact if you strip the libs out. But usually at that point you may have to goto ASM just to make it fit.
Had one project which had to be in python (platform dictated by customer). Did all the right style guide things. Classes, the works. Had to toss all of that out. As just by making classes subjected it to a 300 byte overhead per object. I had hundreds of the things. Half my memory was being used by object management. I needed that space for data. Out goes all the cool by the book things that seem right to do. Borderline a total re-write. I took those lessons to the C version. Right up until the new guy decided everything needed to be C++ and use std:lib and would not listen to me. Suddenly it did not even fit in flash and RAM even if you use both by about 5x much less any data needed. He had to spend weeks backing the changes out again. Even after re-stripping it even then the code size dictated we just could not use some platforms.
Another thing to keep in mind is compiler maturity. C++ in the past 10 years has come a long way. But in these embedded platforms you may be working with a C++ tool-chain from the late 1990s (if you are lucky). Some of the toolchains shipped with these chips are in poor shape. They will never change unless you spend a lot of time bringing it up to something semi current. Getting a Rust tool chain on it? Maybe if you spent months messing around with it. Months where you could spend shipping product.
It is becoming less and less of an issue as the more powerful SoC items have come down in price and have more memory/flash. The newer ones also usually come with a somewhat modern compiler stack. Also if you follow some of the MISRA standards in some projects it can even more radically change what you can and can not do.
Panic handling and message formatting are something that however is a known drawback in debug builds. In release builds this gets optimized away in most cases.
Btw one of the main reasons for this is missing CI support. https://github.com/rust-lang/rfcs/issues/1795#issuecomment-3...
But of course there's always a way if you want it enough.
I think Rust has a lot of potential in the embedded space. I'm especially interested in if the async stuff will have power in making small and safe state machine writing easier: I think this could be extremely good at combining the power of stackfull tasks (which are wasteful on memory and less predictable) and state machines (which can be a pain to write, especially long sequential ones). If it lets you ship a product sooner with less bugs on a cheaper micro, I think it may be a strong proposition. Unfortunately given the industry is often unwilling to even consider C++ (and not for good reason: the reasons given for not using it or not even considering it are often based of off misconceptions or just outright falsehoods).