This article introduces a generic and light-weight debugging aid / event tracing mechanism that is both feasible for targets without proper debugger connection, as well as visual, providing visibility into high-level and low-level events.
“What would an ocean be without a monster lurking in the dark? It would be like sleep without dreams.” ― Werner Herzog
“The harder you work… and visualize something, the luckier you get.” ― Seal
Conversion from linear time (elapsed seconds since some point in time) into calendar representation and back often crops up when doing work in the embedded space. While the commonly accepted truth is that one should always try to use the historical “standard library” facilities, there are several cases where this becomes problematic. This article is a story about util/calendar which is a small collection of functions that are suitable for resource constrained systems and when correct operation and repeatability in different environments becomes important.
Was originally planning to write this a couple of weeks back, but a side-project and Horizon: Zero Dawn took the extra time. Both are now concluded with great success, and I’m back to regular programming (so to speak).
Background One of my longer term projects has been to learn Portuguese. I tried doing this the hard way some years back by enrolling to an evening class. My capacity of memorizing “arbitrary” non-logical things coupled with general tiredness after work days caused this experiment to fail.
In the previous article in the series, we ended up with FRDM-K64F’s SDA MCU (K20) executing our code and blinking LED correctly, but the code on the MAIN MCU (K64) did not start.
The reason why MAIN MCU wouldn’t start was because one or more pins on the SDA MCU were keeping the MAIN MCU in a state that wouldn’t allow it to execute code. In order to change this, we need to manipulate the signal levels and configuration of the pins on the SDA MCU.
(blinky is a common name for a program that only blinks an LED, a “hello world” of the embedded world)
Background A couple of months back, I thought that it would finally be fun to do some experiments using an embedded SoC I’m already familiar with, in order to finally test out various ideas that have been floating around my head, but without pressure of actually getting anything delivered (like in Real Life™).
I should in fact be doing another thing, which is to complete the project that will result in the first technical article to the blog, but today is procrastination day, so let’s. Managed to switch the hard-drive on my PS4 today. I’ve become somewhat apt at it, since I mainly just repeated the process that I did the last time. Which was a couple of weeks back.
So, I’ll just write down what happened so that I can return to this adventure later.
Slightly over a week ago I decided to attempt to organize my somewhat chaotic note taking and planning process. After looking around for a tool that would support my (quite) haphazard note-taking philosophy, I settled on trying WorkFlowy.
Some years ago I developed a habit of keeping a work diary. While I do love the immediacy of paper and pen, having the possibility to easily to search the history is more important, and so all my note taking has been electronic for the past many years.
Restarting a blog, been way too long and going to do it properly this time. We’ll see where we get eventually. Hold on to your hats!
In this blog I’ll try to write a bit about things in the intersection of what interests me, and what might be useful for others. Perhaps it can also act as a kind of technical design diary, but we’ll see how this goes. I’ll try to also occasionally write a short review on a product or service that I think deserves to be written about.
While I do have a lot of interesting stories about real life product development, I won’t be sharing those through this medium (NDAs and such).