<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>JeeLabs</title>
    <link>https://jeelabs.org/</link>
    <description>Recent content on JeeLabs</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-gb</language>
    <copyright>© 2019 Jean-Claude Wippler</copyright>
    <lastBuildDate>Tue, 09 Jul 2019 00:00:01 +0200</lastBuildDate><atom:link href="https://jeelabs.org/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Measuring with Disco-L053, part 2</title>
      <link>https://jeelabs.org/2019/disco-l053-2/</link>
      <pubDate>Tue, 09 Jul 2019 00:00:01 +0200</pubDate>
      
      <guid>https://jeelabs.org/2019/disco-l053-2/</guid>
      <description>The previous article mentioned that the &amp;ldquo;Disco-L053&amp;rdquo; board includes a complete current measuring circuit, which can handle a range of nearly six decades. So here is a brief description of how to actually use it that way.
First off, on the hardware side, two minor adjustments need to be made to the board:
 Connecting the L053&amp;rsquo;s TX pin to the on-board ST-Link. Connecting the Device Under Test to the board.</description>
    </item>
    
    <item>
      <title>Measuring current with Disco-L053</title>
      <link>https://jeelabs.org/2019/disco-l053/</link>
      <pubDate>Mon, 08 Jul 2019 00:00:00 +0200</pubDate>
      
      <guid>https://jeelabs.org/2019/disco-l053/</guid>
      <description>It turns out that there&amp;rsquo;s a nice way to measure current consumption with a commercial board by ST Microelectronics. It&amp;rsquo;s called the 32L0538-DISCOVERY, but for brevity and consistency I&amp;rsquo;m going to call it the &amp;ldquo;Disco-L053&amp;rdquo; from now on:
This is one of a long range of &amp;ldquo;Discovery&amp;rdquo; evaluation boards by STM, and as you can see it even has a touch slider and 172x72 pixel ePaper display. But the main feature for our purposes is that it includes a very nice current measuring circuit, which is used by some demo software to demonstrate that the main L053 µC on the board draws 42 µA in low-power run mode at 131 KHz and that it has a &amp;ldquo;stop&amp;rdquo; mode which draws a mere 400 nA.</description>
    </item>
    
    <item>
      <title>The PlatformIO command line</title>
      <link>https://jeelabs.org/2019/pio-cli/</link>
      <pubDate>Thu, 04 Jul 2019 00:00:19 +0200</pubDate>
      
      <guid>https://jeelabs.org/2019/pio-cli/</guid>
      <description>Software development for embedded microcontrollers requires &amp;ndash; as a minimum &amp;ndash;
 a text editor to enter and tweak source code, 2) a &amp;ldquo;toolchain&amp;rdquo; to compile and link the code into a firware image suitable for the selected µC, and 3) an upload mechanism. The best-known example of this is no doubt the &amp;ldquo;Arduino IDE&amp;rdquo;, an Integrated Development Environment which, ehm &amp;hellip; integrates all of the above into a single (open-source and free) product.</description>
    </item>
    
    <item>
      <title>The Mac is going downhill</title>
      <link>https://jeelabs.org/2019/downhill/</link>
      <pubDate>Wed, 06 Mar 2019 00:00:19 +0200</pubDate>
      
      <guid>https://jeelabs.org/2019/downhill/</guid>
      <description>Many years ago, I had an 11&amp;quot; MacBook Air. The tapered one. Bought it literally on a whim, accepting whatever model the store had available right then and there (4 GB RAM and 128 GB SSD), and took it home, happy as a kid with a shiny new toy.
I loved it, and ended up using it for many years. It went places, because it was so small and light. My best Mac-buddy ever, and that with 30+ years of owning Macs.</description>
    </item>
    
    <item>
      <title>The DAC and its DMA buddy</title>
      <link>https://jeelabs.org/2018/dac-with-dma/</link>
      <pubDate>Sun, 30 Dec 2018 00:00:01 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/dac-with-dma/</guid>
      <description>After yesterday&amp;rsquo;s article about ADC, it seems fitting to describe the other side of the coin: the digital-to-analog converter (DAC) and how to generate an analog waveform with it.
DAC is easy This is one of the simplest hardware peripherals there are, as far as the software side is concerned. I&amp;rsquo;m again using a Nucleo-L053, since not all L0-series µCs have a DAC.
Here is the basic driver, as now added to the JeeH code repository:</description>
    </item>
    
    <item>
      <title>The ADC and its watchdog</title>
      <link>https://jeelabs.org/2018/adc-watchdog/</link>
      <pubDate>Sat, 29 Dec 2018 00:00:35 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/adc-watchdog/</guid>
      <description>The STM32 L0-series and newer µCs have an interesting feature: the ADC &amp;ldquo;watchdog&amp;rdquo;. Some variants have more than one, in fact.
This mechanism can keep track of analog voltages in the digital world, unlike the analog way of using one or more comparators with reference voltage levels. The effect is similar, though: when an ADC reading falls outside a given range, an interrupt can be generated.
For some upcoming explorations, I need to dive a lot more into the analog side of µCs, and so I definitely want to try this out.</description>
    </item>
    
    <item>
      <title>Low-power L031 [solved]</title>
      <link>https://jeelabs.org/2018/low-power-l031/</link>
      <pubDate>Fri, 28 Dec 2018 00:00:19 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/low-power-l031/</guid>
      <description>The exploration into low-power sleep modes continues. An STM32F103 draws just 3 µA in standby mode, but that&amp;rsquo;s not the end of the story. The STM32L0xx µCs are more modern and even lower-power. So I just had to try the same thing again with an STM32L031:
This is a small, but still hand-solderable, TSSOP-20 package. There&amp;rsquo;s even a TSSOP-14, if you&amp;rsquo;re willing to switch to L011 (2K ram instead of 8K).</description>
    </item>
    
    <item>
      <title>CP/M on F407, part 6 - Finish</title>
      <link>https://jeelabs.org/2018/cpm-on-f407-part6/</link>
      <pubDate>Thu, 27 Dec 2018 00:00:24 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/cpm-on-f407-part6/</guid>
      <description>So now we have a running CP/M system, great. Except that it has no content, and no means to get any new content onto the virtual disk. That makes it pretty much useless.
Intel HEX We need one more step in the emulator to resolve this final bootstrapping issue. And the simplest approach I have found is as follows:
 create a little CP/M tool, called &amp;ldquo;hexsave&amp;rdquo;, which takes a filename as argument when run, it waits for Intel HEX data sent to it over the serial console all the incoming data is checked and saved in memory when the closing Intel HEX command arrives, save all data to a new file  If we somehow had this utility on the disk, we could use it to bring in other files, including more advanced file-transfer tools (such as the popular XMODEM utility from those days).</description>
    </item>
    
    <item>
      <title>CP/M on F407, part 5 - Power up</title>
      <link>https://jeelabs.org/2018/cpm-on-f407-part5/</link>
      <pubDate>Wed, 26 Dec 2018 00:00:24 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/cpm-on-f407-part5/</guid>
      <description>It&amp;rsquo;s time to stop talkin&#39; and start walkin&#39; &amp;hellip;
Disk initialisation As mentioned in the previous article, the last step is about getting the virtual disk in flash formatted and set up correctly.
But instead of uploading all the disk blocks manually (and figuring out where exactly), I&amp;rsquo;m going to let the emulator itself do the work. So the plan is to embed the contents of the system track as data inside the emulator app, and then if flash memory does not yet have a valid disk image, to initialise flash and copy the data.</description>
    </item>
    
    <item>
      <title>CP/M on F407, part 4 - Booting</title>
      <link>https://jeelabs.org/2018/cpm-on-f407-part4/</link>
      <pubDate>Tue, 25 Dec 2018 00:00:24 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/cpm-on-f407-part4/</guid>
      <description>The last piece of the puzzle is to make all the parts line up and work together. This turns out to be quite involved. A large part is due to the &amp;ldquo;virtualness&amp;rdquo; of this whole CP/M setup:
 we need a way to make the Z80 do something meaningful on (virtual) power-up we need to get a system boot loader onto the (virtual) floppy disk, i.e. flash the CP/M code (including our freshly-minted BIOS) needs to be on the floppy disk the floppy disk needs to have the proper structure for a CP/M startup disk ideally, some basic CP/M utilites should also be present on this (virtual) disk  Fortunately, this problem is not new.</description>
    </item>
    
    <item>
      <title>CP/M on F407, part 3 - The BIOS</title>
      <link>https://jeelabs.org/2018/cpm-on-f407-part3/</link>
      <pubDate>Mon, 24 Dec 2018 00:00:24 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/cpm-on-f407-part3/</guid>
      <description>As mentioned in the intro of this little CP/M series, the CP/M hardware abstraction layer is provided in a &amp;ldquo;BIOS&amp;rdquo;. This is a system-specific section of code which interfaces the main part of CP/M with the actual hardware. It&amp;rsquo;s written in 8080 or Z80 assembly language.
Assembler Assembly language is (almost) as close to the raw silicon of a CPU as you can get.
 It&amp;rsquo;s not complicated, it&amp;rsquo;s just low-level.</description>
    </item>
    
    <item>
      <title>CP/M on F407, part 2 - Storage</title>
      <link>https://jeelabs.org/2018/cpm-on-f407-part2/</link>
      <pubDate>Sun, 23 Dec 2018 00:00:24 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/cpm-on-f407-part2/</guid>
      <description>CP/M is a disk operating system. It relies on one or more &amp;ldquo;disks&amp;rdquo; for permanent storage, which persists while the computer is off. At the time, 8&amp;quot; floppy drives had just started to become available, at &amp;ldquo;affordable&amp;rdquo; prices (under a thousand US dollars).
The actual media, i.e. the floppies inserted into these drives, were very crude and easily damaged. Not only that, but an 8&amp;quot; single-sided single-density (SSSD) disk could hold only a small amount of data: 77 tracks with 26 sectors each, containing 128 bytes of &amp;ldquo;payload&amp;rdquo;.</description>
    </item>
    
    <item>
      <title>CP/M on F407, part 1 - Intro</title>
      <link>https://jeelabs.org/2018/cpm-on-f407-part1/</link>
      <pubDate>Sat, 22 Dec 2018 00:00:41 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/cpm-on-f407-part1/</guid>
      <description>CP/M from the 1970&amp;rsquo;s was an operating system for 8080 and Z80 8-bit micrcomputers. It was very popular among hobbyists, because it came at the right time and offered a way to manage data file storage on the upcoming 8&amp;quot; and 5.25&amp;quot; floppy disks. Later still came the 3.5&amp;quot; floppy, and 8086 16-bit micrcomputers with MS-DOS, Windows 3.11, etc.
In short: it all started with CP/M (the original version is also often called CP/M-80).</description>
    </item>
    
    <item>
      <title>Turning a Black F407 into a Z80</title>
      <link>https://jeelabs.org/2018/z80-zexall-f407/</link>
      <pubDate>Fri, 21 Dec 2018 00:00:14 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/z80-zexall-f407/</guid>
      <description>This is an amalgamation of two recent articles: Turning a Blue Pill into a Z80 and Getting started with the F407. I want to use this as starting point for further retro Z80 explorations.
The first goal is very straightforward: get the same &amp;ldquo;ZEXALL&amp;rdquo; Z80 instruction exerciser working on the F407 µC as in the F103-based Blue Pill. It has more memory (enough to emulate the Z80&amp;rsquo;s entire 64K address space) and as a bonus, it&amp;rsquo;s also quite a bit faster.</description>
    </item>
    
    <item>
      <title>Getting started with the F407</title>
      <link>https://jeelabs.org/2018/getting-started-f407/</link>
      <pubDate>Thu, 20 Dec 2018 00:00:48 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/getting-started-f407/</guid>
      <description>The first thing to try out on every new board is to blink an LED: the embedded equivalent of writing a &amp;ldquo;Hello World&amp;rdquo; program. I&amp;rsquo;m going to do this for both the &amp;ldquo;DIYmore&amp;rdquo; and the &amp;ldquo;Black407&amp;rdquo; boards, as introduced here - using two different upload mechanisms.
DIYmore First the minimal board, with an F407VG on it. Just to illustrate that it can be used with a Black Magic Probe, I created a little custom adapter - it turns out that all the required pins are conveniently grouped together in one 2x5 section of its three headers:</description>
    </item>
    
    <item>
      <title>Retrocomputing on STM32F407</title>
      <link>https://jeelabs.org/2018/retrocomputing-on-f407/</link>
      <pubDate>Wed, 19 Dec 2018 00:08:51 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/retrocomputing-on-f407/</guid>
      <description>The Blue Pill is a wonderful little board, and my first choice for many projects requiring a small and very low-cost µC board. Especially with PlatformIO&amp;rsquo;s excellent support for it.
Even for retrocomputing &amp;ndash; the hobby of emulating old computers from decades ago &amp;ndash; a Blue Pill can be used: see my recent [Turning a Blue Pill into a Z80](Turning a Blue Pill into a Z80) article for an example. This could easily be extended further: adding more (external) RAM, flash, an SD card, etc.</description>
    </item>
    
    <item>
      <title>The CAN bus, part 6 - Single-wire</title>
      <link>https://jeelabs.org/2018/canbus-part-6/</link>
      <pubDate>Tue, 18 Dec 2018 00:01:14 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/canbus-part-6/</guid>
      <description>There is a second way to use the CAN bus: in &amp;ldquo;single wire&amp;rdquo; mode (SW-CAN). But before I go into that, let me set up a dual-node bus, using standard MCP2551 transceivers for a &amp;ldquo;normal&amp;rdquo; CAN bus with CAN-HI and CAN-LO signals. Here is my little breadboard setup:
On the left: a HyTiny from Haoyu Electronics. It&amp;rsquo;s a nice alternative to the Blue Pill with a convenient 6-pin programming header on the end (power, SWD, and serial).</description>
    </item>
    
    <item>
      <title>The CAN bus, part 5 - Demo</title>
      <link>https://jeelabs.org/2018/canbus-part-5/</link>
      <pubDate>Mon, 17 Dec 2018 00:15:49 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/canbus-part-5/</guid>
      <description>Demo time! As test setup, I&amp;rsquo;m going to use an F4-based STM32 µC, since it has two CAN bus controllers. It&amp;rsquo;s easier to write a quick test for a single system. And since I have these boards lying around, that&amp;rsquo;s what I&amp;rsquo;ll use: a 32F429-DISCO with an Open429Z-D:
The breakout board adds a USB-to-serial interface and headers to plug in two CAN bus drivers (for level translation, as described in part 1).</description>
    </item>
    
    <item>
      <title>The CAN bus, part 4 - JeeH API</title>
      <link>https://jeelabs.org/2018/canbus-part-4/</link>
      <pubDate>Sun, 16 Dec 2018 01:55:43 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/canbus-part-4/</guid>
      <description>Enough already of all this theory &amp;hellip; it&amp;rsquo;s time to put the CAN bus into practice. Since my goal is not just to get CAN working, but also to fully explain how it can be implemented on an STM32 µC, I will present the following material in two sections: a description of the API, as defined in the JeeH library and a detailed walkthrough of the entire driver.
This driver is written in C++ with templates, and is very compact (under 80 lines of code).</description>
    </item>
    
    <item>
      <title>The CAN bus, part 3 - STM32</title>
      <link>https://jeelabs.org/2018/canbus-part-3/</link>
      <pubDate>Sat, 15 Dec 2018 12:12:35 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/canbus-part-3/</guid>
      <description>With the basics out of the way, it&amp;rsquo;s time to look at the actual hardware peripheral, as used in STM32 microcontrollers. It turns out the CAN hardware is almost identical across all STM32 families. Notable exceptions are that on the F103, the CAN memory buffers are shared with USB (which can&amp;rsquo;t be used at the same time), and that on the more recent µCs, new &amp;ldquo;CAN FD&amp;rdquo; (Flexible Datarate) capabilities have been added for higher speed.</description>
    </item>
    
    <item>
      <title>The CAN bus, part 2 - Access</title>
      <link>https://jeelabs.org/2018/canbus-part-2/</link>
      <pubDate>Fri, 14 Dec 2018 00:10:04 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/canbus-part-2/</guid>
      <description>If you place a dozen people in a room &amp;ndash; let&amp;rsquo;s say a bunch of CAN bus geeks &amp;ndash; then more likely than not, a discussion will start to emerge. Interestingly, it&amp;rsquo;ll not be chaos: people will listen when someone else is speaking, and wait to interject a response. Most of the time.
Exactly the same happens on the CAN bus: transmissions start only when the bus has been idle for a little while, i.</description>
    </item>
    
    <item>
      <title>The CAN bus, part 1 - Intro</title>
      <link>https://jeelabs.org/2018/canbus-intro/</link>
      <pubDate>Thu, 13 Dec 2018 15:34:41 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/canbus-intro/</guid>
      <description>The CAN bus is a very interesting medium-speed &amp;ldquo;interconnect&amp;rdquo;, for various reasons:
 it&amp;rsquo;s based on just 2 signal wires and the bus is completely passive it&amp;rsquo;s made for noisy environments, e.g. cars, trucks, and boats it&amp;rsquo;s real-time, i.e. there are guarantees w.r.t. delivery time on a busy bus it&amp;rsquo;s robust, with checksums to guard against packet corruption it&amp;rsquo;s like a h/w pub-sub mechanism, supporting point-to-point and multi-cast it&amp;rsquo;s highly standardised, w.</description>
    </item>
    
    <item>
      <title>Z80 and CP/M in a red box</title>
      <link>https://jeelabs.org/2018/z80-in-a-red-box/</link>
      <pubDate>Wed, 12 Dec 2018 21:07:59 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/z80-in-a-red-box/</guid>
      <description>Some people like computers from the previous century, the ones which are long obsolete, unusable, or have been mostly forgotten. Perhaps because they owned one in the past, or because they never could own one, or hey, maybe it&amp;rsquo;s a mom-and-dad thing. Whatever.
Fact is: 1) I&amp;rsquo;m somewhere in that category, 2) &amp;ldquo;retrocomputing&amp;rdquo; exists, and 3) there are numerous projects to fix, reconstruct, or replicate these clunky old systems.
One very nice project is the Z80 Membership Card by Lee Hart.</description>
    </item>
    
    <item>
      <title>Current measurements</title>
      <link>https://jeelabs.org/2018/current-measurement/</link>
      <pubDate>Tue, 11 Dec 2018 11:34:11 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/current-measurement/</guid>
      <description>An F103 sleeping with a current consumption of 3 µA is very impressive. This translates to about 7 years of &amp;ldquo;run&amp;rdquo; time on a CR2032 coin cell (although not doing anything useful). That is three orders of magnitude lower than the ≈ 5 mA of standard run mode at 8 Mhz.
And it&amp;rsquo;s very much in line with the capabilities specified in the STM32F103 datasheet:
Our demo actually exceeds the specs given in the table above, which is down to 3.</description>
    </item>
    
    <item>
      <title>STM32F103 low-power mode</title>
      <link>https://jeelabs.org/2018/standby-current-f103/</link>
      <pubDate>Mon, 10 Dec 2018 03:34:11 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/standby-current-f103/</guid>
      <description>I&amp;rsquo;ve always kept an interest in low-power explorations, most of which I did many years ago. First there was the ATmega328, then the LPC824, and finally on the STM32L052. One reason, is that I find it fascinating to see a µC drop multiple orders of magnitude in power consumption, yet still have enough wits to wake up, periodically or via an I/O pin.
It&amp;rsquo;s hard to overstate the effect this can have on real-world devices: letting a circuit drop to µWatt power levels, i.</description>
    </item>
    
    <item>
      <title>Turning a Blue Pill into a Z80</title>
      <link>https://jeelabs.org/2018/z80-zexall-bp/</link>
      <pubDate>Sun, 09 Dec 2018 01:15:49 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/z80-zexall-bp/</guid>
      <description>The Z80 micrcomputer was a revolutionary chip in the 1970&amp;rsquo;s - a more capable alternative to the Intel 8080. The commercially smart move was that it implemented (almost exactly) the same instruction set as the 8080, while adding many extra registers and instructions.
The Z80 is an 8-bit micrcomputer (i.e. 8 bits of data, D0..D7) with support for up to 64 KB of memory (i.e. addresses of 16 bits, A0..A15). A separate group of instructions deals with I/O, so reads and writes can be either in memory, or in &amp;ldquo;I/O space&amp;rdquo;.</description>
    </item>
    
    <item>
      <title>Getting started with the Blue Pill</title>
      <link>https://jeelabs.org/2018/getting-started-bp/</link>
      <pubDate>Sat, 08 Dec 2018 14:51:49 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/getting-started-bp/</guid>
      <description>The &amp;ldquo;Blue Pill&amp;rdquo; is a small development board with an STM32F103 32-bit ARM µC on it, plus essential supporting logic. It&amp;rsquo;s widely available and very low-cost. See this wiki page on the STM32duino website for a wealth of useful information.
The tricky part is getting over the initial hurdle of uploading firmware to this little board. There are two ways to do it, but both of them require some care and tinkering:</description>
    </item>
    
    <item>
      <title>Toggling I/O pins on STM32</title>
      <link>https://jeelabs.org/2018/toggling-io-pins/</link>
      <pubDate>Fri, 07 Dec 2018 11:03:06 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/toggling-io-pins/</guid>
      <description>All microcontrollers have I/O pins to connect to the outside world. These can be used as inputs or outputs, and tend to have various interesting capabilities. Here, I&amp;rsquo;ll treat these &amp;ldquo;General Purpose I/O&amp;rdquo; pins as outputs and try to toggle them as quickly as possible.
These examples will use the STM32F407. Other families may differ slightly (the GPIOs in the older F1 series are somewhat less configurable and less flexible, for example).</description>
    </item>
    
    <item>
      <title>Random numbers in hardware</title>
      <link>https://jeelabs.org/2018/random-numbers/</link>
      <pubDate>Wed, 05 Dec 2018 21:38:30 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/random-numbers/</guid>
      <description>Random numbers are useful for simulations, to create a sense of arbitrariness in games that might make them more &amp;ldquo;interesting&amp;rdquo;, i.e. generally speaking: to introduce a level of unpredicatability in the oh-so-deterministic world of today&amp;rsquo;s computers.
There is an alternative, if you take randomness with a grain of salt: pseudorandomness. This is a technique which generates numbers that appear random and totally unrelated, but are in fact produced by carefully designed algorithmic computations.</description>
    </item>
    
    <item>
      <title>Hardware CRC calculation</title>
      <link>https://jeelabs.org/2018/hardware-crc/</link>
      <pubDate>Tue, 04 Dec 2018 17:00:19 +0200</pubDate>
      
      <guid>https://jeelabs.org/2018/hardware-crc/</guid>
      <description>Most (all?) STM32 microcontrollers have a built-in hardware checksum calculation unit. From Wikipedia:
 A cyclic redundancy check (CRC) is an error-detecting code commonly used in digital networks and storage devices to detect accidental changes to raw data. Blocks of data entering these systems get a short check value attached, based on the remainder of a polynomial division of their contents. On retrieval, the calculation is repeated and, in the event the check values do not match, corrective action can be taken against data corruption.</description>
    </item>
    
    <item>
      <title>Hello again, world</title>
      <link>https://jeelabs.org/2018/hello-again/</link>
      <pubDate>Sat, 01 Dec 2018 13:11:33 +0100</pubDate>
      
      <guid>https://jeelabs.org/2018/hello-again/</guid>
      <description>After nearly a year of silence, I&amp;rsquo;ve started writing articles again. Much has happened, but I&amp;rsquo;m still delighted by the sight of a tiny blinking LED and the smell of a good solder joint.
New look, same website. All previous content is still there - for an overview, see the map. The previous home page is here. New articles get published when the muse is willing.
Enjoy,
-jcw</description>
    </item>
    
    <item>
      <title>Looking for something?</title>
      <link>https://jeelabs.org/about/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jeelabs.org/about/</guid>
      <description>This is a list of &amp;ldquo;stuff&amp;rdquo; I&amp;rsquo;ve worked on over the years, in reverse chronological order:
  This site has changed shape a few times, beginning with WordPress (2008 to 2015), to a static site (until end 2017), to what you&amp;rsquo;re looking at now (also static). There&amp;rsquo;s an archive page which ties most of this old stuff together.
  The list of latest articles on this site (2018 to 2019) is at https://jeelabs.</description>
    </item>
    
  </channel>
</rss>
