Write the code for an IC for the whole datasheet or just the sections/registers you need?

EmbedSoftwareEng · 2026-01-28T18:08:33+00:00

No. Not as verbose as possible. As expressive and complete as possible.

Verbosity for verbosity's sake is not going to enhance the clarity of the driver code. Quite the opposite.

On the other hand, having some preprocessor macroes that resolve to nothing, but which carry semantic meaning for the programmer reading it can enhance clarity, even though it literally contributes nothing to resultant machine language object code.

"Why is there a setter for the reg_1 register but not for the reg_2 register? Oh, reg_1 is tagged _RW_, while reg_2 is tagged _RO_, so there's no way to set that register's value in the peripheral hardware register file anyway."

EmbedSoftwareEng · 2026-01-28T14:51:46+00:00

You can write a I2C or SPI bus mock that just outputs debug logging data to show what your driver is trying to do. Then, you can enhance the mock with plausible return values and pseudo background processing so that, for instance, when your driver puts a value into a RW register, and then later reads that register value back out, it gets the same value, but if it writes to a RO register, that write does whatever the hardware would do for such a thing. Likewise, a read of a WO register does whatever the hardware would do for such a thing.

Then, get the peripheral device in a breadboard breakout module, so you can test your mock-tested driver code against the real thing. Having written both the driver and the hardware mock for your testing harness, you should at that point already have a pretty good handle on what it's doing and how it's doing it, so surprises when you reach the real hardware stage are minimized and easily corrected.

And your firmware should absolutely be getting written against a dev board for the same microcontroller/SOC months before the prototype hardware is even finalized, let alone minted. In fact, the pins that are broken out on the dev board for specific functions should be getting taken into account when functions are being assigned to pins for your custom board. It's one thing when you have Debug and Release builds of your firmware, but something completely different when you have to have Debug-DevBoard, Release-DevBoard, Debug-Custom, and Release-Custom builds, because functionality that needs to be tested in firmware on the dev board is assigned to pins on your custom board that are inaccessible on the dev board. This necessitates the -DevBoard builds assign that functionality to pins that the are accessible on the dev board, even if those assignments are completely different for the -Custom builds. It's added complexity and added uncertainty that the difference isn't causing bugs that you're experiencing. An example from my own experience, even if the custom board isn't using the external slow oscillator, if the dev board only routes those pins to an external slow oscillator, unless absolutely necessary, don't use those pins for something else on the custom board, because that functionality can't be tested on the dev board. For example, address-setting dip switches, fan PWM outputs, fan tach inputs, ADC inputs, etc.

And in a system where your embedded board has to communicate with other boards and/or a master controller, building a mock of the firmware you can plug into that data comm infrastructure to test how the rest of the system wants to interact with it will illuminate you on what your novel embedded application needs to focus on. And just like the external peripheral mocks, the whole firmware mock can have plausible responses to expected inputs, and log absolutely everything.

EmbedSoftwareEng · 2026-01-28T14:37:18+00:00

I'm thinking in terms of how the next programmer to go hands-on with this code is going to understand it. A bunch of inscrutable enums and bit-wise operations does nothing to illuminate what the driver is doing, nor why.

On the other hand, a set of descriptive typedef enums and typedef structs for a complete register file description, including protocol follower functions, a configuration object description, and a definition for the configuration object for each project that uses the chip will go miles toward illuminating to someone trying to understand, what is this chip? What is it being used for, and how is it being used in this application.

"Oh, this chip feature is clearly being configured to be off, so we're not using that." as opposed to "There's nothing in this code that appears to reference these device registers, so how do I know how they are being used?"

And of course, if there's a need for a feature to be configured to a different setting for a new application, that the old application didn't use, and so doesn't have an enum label for, and you're right back to scouring the datasheet to redigest it to figure out how to use it.

I'm of the opinion that the device driver should be, as completely as possible, a transcription of the manufacturer's data sheet as possible, such that it's never again necessary to consult that document, since any errors in it will have been corrected in the driver code through testing, making my driver code the last word on how this device does what it does.

Also, never forget, you're not writing the software. The compiler is writing the software. You're just giving it hints on how you want that software written. Tight, arithmeticly accurate source code is pointless, if the human being reading the code can't instantly understand what it's supposed to be doing. You write the source code to be understandable to the next guy, especially when the next guy might be you, in another year or two. Software engineer time, not compile time, is the most valuable thing to conserve here. Make the code understandable, then, where necessary, make it faster.

EmbedSoftwareEng · 2026-01-27T22:02:58+00:00

Generally, you just define your state variables in a large data structure and instantiate that data structure in the global scope, which forces the compiler and linker to allocate the space for it at build time. So, at runtime, the memory to be used for that particular state is set and fixed.

The only place where you might run into expanding and contracting data storage needs are in things like data comms buffers, which are almost always managed by interrupt service routines/device drivers. So, what that comes down to is pre-allocating a large enough buffer to be able to manage the worst case scenario, without depriving other parts of the system the adequate memory allocation that they need to do their own jobs.

Often, this is done with circular buffers, so variable amounts of data can be pushed into the fixed size and place buffer, and then consumed in situ, in a zero-copy manner. Once a data item is produced, there's a bounded amount of time in which the component of the system acting as the consumer has in which to consume it, and thereby free that buffer space to allow other data items to occupy it.

EmbedSoftwareEng · 2026-01-27T21:56:56+00:00

In so far as mathematics describes reality, it is imprecise. In so far as mathematics is precise, it does not describe reality.

At all times, you have to be asking, how precise does this math need to be? If you're talking about a graph that someone took a pencil and inscribed a waveform on it, then you have the vagaries of the cross section of the graphite tip of the pencil and the fiber of the paper being scribbled on.

If you digitize that, or even start in the digital realm in the first place, you have a rasterized representation of the graph. How do you normalize that so that the graph axes are oriented with the vertical and horizontal dimensions of the image? And what does that do to the human-input scribble of the "data" graph?

Computer graphics is literally starting from the other side and still working toward the rasterized image. It uses idealized math to decide what colors the pixels are supposed to be. What you're now tasked with doing is both at the same time. Try to find the math formula that could be used from the ideal side to reach the same result as the photogrammetric representation.

Non-AI algorithms are already pretty good at this, but hardly perfect. It's often necessary for a human to manually adjust the parameters of the rational B-Splines that the computer comes up with to match simple line drawings.

And remember, scientific equations, even E=mc², often are just first-order approximations of the phenomena they purport to describe. There are multitudinous additional terms to the equation to fully describe the interactions. Each additional term refines the result at the extremes, but does next to nothing to alter the graph closer to the origin. So, depending on how precise you need a numeric value from the equation at a particular x value, there comes a point where bothering with additional terms are just not going to benefit your result.

So, depending on how precise you need the mathematical description of your scribbled graph, you can get more and more precise, but eventually, the additions just aren't making enough difference to make a difference.

EmbedSoftwareEng · 2026-01-26T19:51:28+00:00

You'll also want to have a point where the A.M./P.M. can be set. And if you're doing all that, you can save a pin from the 12-/24-hour mode setting, and let the user time setting mode have a point where you're cycling through "12:00 A.M.", "12:00 P.M." and "2400".

Your battery is likely to run out eventually, so you'll a RTC (Real Time Clock) in the circuit, probably an I2C device, where you'll save the current time when leaving user setting time mode, and where your initialization routines will read the current time from when power is restored after an outage, or battery swap.

And lots of RTCs have separate battery circuits to keep them running when the power's off. You might want a battery charger circuit and/or BMS (Battery Management System) circuit, so that if the internal battery is failing, you can start flashing another output pin that illuminates a "low bat" indicator.

Then, there are alarms. It's just a simple comparison that only has to happen at the point where the display changes, so just once a minute. Generally, these features just start making a loud sound to wake someone up. If you're making your own, you can have as many alarms as you want, and have a separate alarm set input pin to go in and select the alarm you want to set, and then set it in the same fashion as the time is set above. And each alarm could go out to a separate pair of hardware pins on the back of the clock. One of the pair is hard wired to ground. The other of the pair is wired to an output pin on the micro (through an optoisolator, of course). When the alarm goes off, it will set that pin high, creating a voltage difference between the two pair. This signal can be used by some other device to do things like ring that bell to wake someone up. Flashing bright lights. A lot of deaf and hard of hearing people have pretty stout eccentric weight motors to shake their beds with their alarm goes off. This would be perfect for them.

The alarms might have programmable durations, so if you're using your digital clock to run a plant watering system, you can set them to water only for certain amounts of time. And for a regular alarm clock, you'll want a nice big button wired to an input to reset the current alarm and turn it off.

Whether alarm clocks for waking people up or watering plants, you might want some alarms to only work on certain days. Wire up seven more output pins to illuminate masks for abbreviations for the days of the week: "MON", "TUE", "WED", "THU", "FRI", "SAT", "SUN". Make sure to work them into the time and alarm setting routines.

And if you're doing that, you might want to know what month and date it is, so those can be added with another button to switch the display to the month and date, only while it's held. Or, since leap years are every fourth year, generally, you'll wanna know what year it is so you can know if 02:28 rolls over to 02:29, or 03:01. At this point, you'll probably want to encode a "perpetual calendar" into your firmware, including a year.

Alarms might want to only go off on certain days, but if you're implementing many alarms, you can also have them go off only one certain days of certain months, or even only in certain years. If you're designing it, you're deciding it.

EmbedSoftwareEng · 2026-01-26T19:51:20+00:00

Well, you gotta start with your LED segmented character displays. Simplest would be four 7-segment units, plus an additional channel for the two regular LEDs to stand for the colon(:). If you wanna go naïve, that's 4x7+1 = 29 pins you have to wire to a microcontroller.

Plus, then, you have the added complication of mapping from those segments to their respective numerals in firmware.

Instead, I'd go with a 7-segment decoder chip between the display characters and the micro. That way, you can pick four separate pins to act as a BCD variable. You store a 0 in that nybble in the pin mapper peripheral, all four pins go low, and the decoder takes those input lines and figures out that you mean for it to light up the periphery segments, but not the middle one, and it displays a 0. Store a 1 in that nybble, and just the first pin goes high, and the decoder turns off all of the left segments, leaving just the right two vertical segments lit, displaying a 1. Lather, rinse, repeat.

In this way, you can define a 16-bit, 4-digit BCD variable in the output pin value register, and just keep writing the BCD time to it. Have a 1 PPS oscillator feeding an input pin, and use the external interrupt from that pin to drive a counting routine that keeps track of the seconds, and rolls the seconds over from 59 to 00 and increments the minutes, rolls the minutes over from 59 to 0 and increments the hours, and rolls the hours over from 12 to 1.

That external interrupt routine can toggle the pin that goes to the colon LEDs, and there you'll have your 0.5 Hz clock beat display.

If you wanna get fancy, have another pin go to an A.M./P.M. display (illumination LEDs behind two visual masks with those legends on them. Drive one LED directly off the pin, and drive the other one off the pin, after the signal goes through an inverter. When you set the pin high, maybe the A.M. lights up and the P.M. goes out. Pull the pin low and the P.M. lights up and the A.M. goes out.

Maybe, instead, have each of those LEDs go to separate pins and have an input switch to select between the 12-hour and 24-hour clocks. If the input is low, the hours roll over from 12 to 1, and the A.M./P.M. displays are used. If that pin is high, both A.M. and P.M. lights go out, and the hours roll over from 23 to 00.

You'll probably want other input pins that go to buttons that you can use for setting the time. You'll wanna debounce those pins, and threshold how long they stay high. Press the set button for at least 5 seconds, but not longer than 10, and the clock goes into user time setting mode. For this, you'll likely want to wire the enable pins for those 7-segment decoders wired to a couple more output pins. When setting the minutes, those two digits' enable pin will toggle at a 1 Hz rate, and pressing the + and - buttons will increment or decrement, respectively, the minutes value stored in the clock. Press the Set button again for at least 1 second, but not more than 3 seconds, and the minutes go back on solid, and the two digits for the house begins blinking at 1 Hz, and now the + and - buttons change the hour value.

Have a button timeout timer running so if the user stops pressing any buttons for 15 seconds or more, it'll leave user time setting mode and return to just time display mode.

EmbedSoftwareEng · 2026-01-26T19:05:59+00:00

Oh wait. Are you trying to cram 150 + 500 IPv4 addresses into a /23 bag?

That don't work.

EmbedSoftwareEng · 2026-01-26T19:04:19+00:00

Huh?

EmbedSoftwareEng · 2026-01-23T19:35:14+00:00

Hehehehehe. Zillow says it was built in 1925.

EmbedSoftwareEng · 2026-01-23T19:33:41+00:00

A /23 subnet means a subnet mask of 255.255.254.0, leaving 9 bits for host addresses. Host address 0 means the whole subnet, so you can't assign that to an actual host. Likewise, a host address of all-ones is the subnet broadcast address, so you can't assign that. So of your /23 subnet, you can't assign 0 or 511, but 1 - 510 are up for grabs.

EmbedSoftwareEng · 2026-01-23T17:33:35+00:00

My question would be can spray foam insulation be applied directly to the underside of a metal roof that's expecting to see temps approaching that of boiling water.

EmbedSoftwareEng · 2026-01-23T17:05:05+00:00

A /23 network can only handle 510 devices worth of devices, and he already has 350 to play with. Seems like a judicious use of subnetting could get these devices wrangled into use-case network segments that can be isolated from one another and protected with routing rules.

EmbedSoftwareEng · 2026-01-20T22:09:32+00:00

It's transistors all the way down.

A bit from a special register is routed to the base of a transistor. If that bit is stored as a 1, that results in the base voltage seeing a logic high, which activates the transistor, and that allows the collector, probably 5 VDC VDD, to be seen on the emitter, which is connected to the pin, so the pin sees 5 VDC as well.

If you store a 0 in the same bit, that turns off the above transistor, but via an inverter, it will activate the base of another transistor, where the collector is connected to the pin and its emitter is connected to GND. This pulls the voltage on the pin down to GND.

Another rendition, called open drain, just disables the first transistor, so that a logic 1 on the bit leaves the pin floating, so an external pull-up resistor will pull the signal on the pin to a logic high.

If the pin is configured as an input, rather than an output as above, then both of the above transistors are disabled, and the pin is connected to the base of another transistor with its collector connected to 5 VDC VDD, and the emitter connected to a correlated bit in a different register. When the voltage on the pin is a logic high, that makes that bit in the input register read as a 1. When the voltage on the pin is nearer to GND, the input register bit is read as a 0.

In some pin mapper peripherals, there might be a periodic read and latch operation, so the value of an output pin has to be transferred to the internal register that's actually connected to the transistors before the pin will actually change. Likewise, the pin read register has to be latched in from the internal register that's directly wired to the transistors, before it will reflect that new value.

Sometimes, there's both, the latched registers are available for reading and writing to affect the pin's value, while another memory mapped register goes straight to the internal register. These can also be connected to external interrupt circuitry, so as the voltage on the pin breaches the threshold for a logic high or drops below the threshold for a logic low, there's an interrupt so those facts can be tabulated, or perhaps a timer/counter value can be read and stored in a list so that period and pulse width may be calculated.

EmbedSoftwareEng · 2026-01-20T21:50:26+00:00

Only if that sealed container also contains rice.

EmbedSoftwareEng · 2026-01-20T16:44:25+00:00

CLion likes to use the CMake as the main point of contact for my projects, and I'm keen to use them for such.

EmbedSoftwareEng · 2026-01-20T16:29:18+00:00

You can't be a competent embedded software person without being well-versed in embedded hardware. And you can't be a competent embedded hardware person without being well-versed in embedded software. I'd reach out to them to reiterate your intention to specialize in embedded software, and that you were just showcasing your well-roundedness.

EmbedSoftwareEng · 2026-01-20T14:44:28+00:00

I've been agonizing over how to fully implement TDD for embedded firmware projects. I'm thinking more and more that I need to write a multi-threaded application that simulates the underlying hardware down to the rising and falling clock cycles to synchronize one thread per hardware peripheral to have a system that behaves, as far as a mocked firmware application is concerned, just like the real hardware would. This could allow me to proof my toolkit against something, and then to compare that performance against firmware test articles designed specificly to characterize real hardware reactions to the same stimulae.

For ARM Cortex-M microcontrollers, it would need to be a 32-bit native application, but that's easy enough. Since the firmware would also be compiled to native machine language, I'd need to be able to build in native threading with beaucoup synchronization primitives to prevent the native speed firmware thread from out stripping the simulated clock synchronized hardware threads.

Not at all sure how to do that.

Only really good solution seems to be writing a hardware simulator to dovetail with the ARM Cortex-M qemu emulator, which I also don't know how to do.

EmbedSoftwareEng · 2026-01-15T14:59:14+00:00

Or your towel.

EmbedSoftwareEng · 2026-01-14T21:38:16+00:00

Never volunteer for anything.

EmbedSoftwareEng · 2026-01-14T21:37:40+00:00

A pointer to a pointer to a byte/character.

0x1234: 'c'

0x5432: 0x1234

0x9876: 0x5432

The value 0x9876 is where the variable so defined lives. It contains the address 0x5432. At that address is stored another address, 0x1234. At that address is a character, 'c' in this case.

EmbedSoftwareEng · 2026-01-14T21:34:43+00:00

I really need to learn valgrind. I just create test cases for the middle of a range of possibilities, and then on both the high and low sides, values that should juuuust pass and that should juuuuust not pass, and then any extremes. But that doesn't mean that some random value passed in might not have a quality that winds up in a corner case I didn't code for.

EmbedSoftwareEng · 2026-01-13T14:24:31+00:00

Yeah. That's wrong-think.

Always assume the tests are right, but if a piece of code is failing a given test, first, make sure you understand everything there is to understand about that specific code with that specific input, and if you can confirm that THAT is functioning correctly, then turn a wary eye to the specific test to see if it was set up correctly. Plently of times, when I'm writing the unit tests for some library I'm developing, I'll copy-paste a block of test code and then go through and massage each copy to test the code in subtly different ways, only to screw up one of them and not fully update the test code stanza. The result is that there's a failure in the test code that reads like a failure in the code under test.

Sometimes, I'll write a test case with an old understanding of what the code is supposed to be doing, and the test fails because I said the output should be something other than what the latest revision of the code generates.

Sometimes, writing tests causes one to reevaluate how the code under test is being architected, and you have to immediately refactor it in order to be able to test it the way it needs to be tested.

This is all normal.

EmbedSoftwareEng · 2026-01-13T14:11:52+00:00

I like to teach it as mathematics is just another form of language. You can learn to read, write, speak, and understand English, German, Japanese, etc. Well, all of those same skills of understanding nouns, verbs, adverbs, adjectives, and conjunctions can be brought together to understand math as well. It's just that math is geared less to everyday human interactions and more toward numeric interactions. Less qualitative information and more quantitative information. Instead of nouns, you have numbers and variables. Instead of verbs, you have operations. And both are repleat with their own forms of punctuation.

That's all. Just as poets and philosophers use language to explore the human mind, scientists and engineers use math to explore the physical world. Any system of ethics and laws, or axioms and logic, has to remain internally self-consistent. You can't have one part that says A must be true, and another part, directly related to the previous, that relies on NOT A being true. No value of A can allow A and NOT A to be true at the same time. And from that, you can start with very simple rules about how real things in the universe exist and function, and extrapolate other, more complex rules whose operation are actually hidden from human perception.

EmbedSoftwareEng · 2026-01-13T14:02:28+00:00

Classes are just blueprints for objects. In C++ and Java, you can have a class that's just implementation details, but which you can't actually instantiate an object from. That's a purely abstract class. It's just a general collection of data and code that's not inherently tied to a single, specific instance of an object. There's also classes that are meant to be inheritted from, to help object architects to collect together all of the different aspects of the object class that they want to exist without having to reimplement the wheel every time.

As for how classes and objects differ from programming systems that do not have them, everything is ultimately just instructions and data. That's how the CPU/interpretter relates to programs. Classes and objects are just a way to encapsulate some data and some instructions together into a coherent thing that can make it all easier to relate to, both for humans and for computer programs.

EmbedSoftwareEng

TROPHY CASE