<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>JeeH on JeeLabs</title>
    <link>https://jeelabs.org/projects/jeeh/</link>
    <description>Recent content in JeeH on JeeLabs</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-gb</language>
    <copyright>© 2019 Jean-Claude Wippler</copyright>
    <lastBuildDate>Sun, 30 Dec 2018 00:00:01 +0100</lastBuildDate><atom:link href="https://jeelabs.org/projects/jeeh/index.xml" rel="self" type="application/rss+xml" />
    <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>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>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>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>
    
  </channel>
</rss>
