Organize projects in chronological order

03-serialuart/README.md

@@ -34,14 +34,15 @@ writepin 2 low
 ... to turn it off. Simple, but it gave me a chance to poke around at the C compiler in the arduino IDE. To do this, I needed a few C features and functions:
 
 * Structures
+* `memset` for initializing some memory
 * `strtok` for tokenizing a string
 * `strncmp` for comparing N characters of two strings
 * `strncpy` for copying N characters of two strings
 * Pointers
 
-The Arduino IDE *says* that it is using C++. I'll be honest, I'm not sure how true that statement is. I've written a decent amount of C++, and it doesn't look exactly like what I'm seeing in the Arduino IDE. But it looks a lot like C, so I decided to treat it like C, and write my parser using standard libc functions, since that seemed like a simpler ramp in this environment. And, as usual, bare C failed to disappoint me.
+The Arduino IDE *says* that it is using C++. That's true, but there's some complexity they're hiding, and some magic they're enabling. I don't like magic, that's part of the whole reason I'm doing these projects. So I'm writing in C, with standard libc functions, since that seemed like a simpler ramp in this environment. And, as usual, bare C failed to disappoint me.
 
-C and libc just work, basically everywhere you go, and there's very little magic behind it.
+C and libc just work, basically everywhere you go, and there's very little magic behind it. Don't get me  wrong, there are implementation differences, and some libc variants are incomplete. But for the most part, if you know libc, and your platform has a C compiler, you can drop in and start writing code.
 
 Feels good man.
 
@@ -85,7 +86,9 @@ One of the most useful tools in enterprise IT is something called `tcpdump`, whi
 
 When I decided to get into embedded development, I wanted to be able to do the same thing with the digital inputs and outputs on my dev boards. We can use a voltmeter to check electrical connections, and we can use an oscilloscope to check waveforms, but how do we (without great effort) figure out exactly what is going over that wire at any given time? How do we capture information going over that wire, examine it, and maybe even play it back later? How do we put a man in the middle between two pins and put something there that lets us not only capture but also inject signals?
 
-I did a little research, and picked up a [Digilent Digital Discovery logic analyzer](https://digilent.com/reference/test-and-measurement/digital-discovery/start). It's a pretty slick little device that can do all kinds of things
+I did a little research, and picked up a [Digilent Digital Discovery logic analyzer](https://digilent.com/reference/test-and-measurement/digital-discovery/start). It's a pretty slick little device that can do all kinds of things, and I'll probably be discovering new tricks with it for a decade. The most important thing it can do for me right now, however, is giving me that man in the middle for any circuit I choose to put probes on.
+
+[Here's a video of the embedded noob discovering his analyzer](https://x.com/AKLabsDotNet/status/2060156789111316602)
 
 ## ESP32-S3 Serial monitor when using the USB JTAG
 
@@ -135,3 +138,5 @@ The oscilloscope could show the waveforms of the data coming off the serial TX/R
 The Digilent logic analyzer, however, was a whole other beast. Not only could it capture the transmission on the pins as square waves, it would map them up to a millisecond scale timeline, and it would overlay the ASCII on top of it so I could see how the waveform was actually sending the data! That's pretty damn slick.
 
 ![Logic analyzer showing UART traffic at the line level](logicuart.png)
+
+This kind of thing is invaluable for figuring out things like timing errors. UART and other line serial protocols tend to need very precise timing to get any data over the wire, if you're off by milliseconds, your transmission is jacked. Being able to not only inspect what I'm using, but compare it to known good signals from previous captures, is gold.