UPDATE: This post is a work in progress, it reflects my current thinking on the best way to start and run a micropython project on an ESP32, but I’ve been looking into this for only a few days, so it may change a lot.

Be Organised!

Don’t just dump your code anywhere, make a decision about where to put it! For me, this is C:\Users\Gregw\microcontroller-home

From Windows Terminal

• Set up folder structure. Adjust to taste! Don’t forget the tab key to autocomplete partial folder and file names.

cd \Users\gregw\
mkdir microcontroller-home
cd microcontroller-home

Getting to a REPL prompt is a good start, but you need to be able to write code in a capable editor, with intellisense, or context-aware auto-completion, because you’re 50x more productive when you can type a dot after the name of an object, and your editor suggests all applicable properties and methods on that object. Without this, you’ll be spending over 99% of your time trawling documentation.

I’ve tried out VS Code extensions for ampy, rshell and the MicroPython IDE, with varied degrees of success (tip: don’t bother even trying the MicroPyhton IDE in Windows, it does nothing).

The Best Options I can find are…

• micropy-cli
• Pymakr

Global Setup

• It is assumed you’ve installed all the prereqs listed in the previous post
• Install NodeJs
  • use the LTS version, 64bit msi for Windows I also accepted the recommendation to install additional tools, which includes the windows package manager “chocolatey”

I’ve chosen to install the following globally, as you will likely use these tools in many projects.

|I am also not using virtual environments for each project, since micropython dependencies are managed separately by micropy-cli.

cd c:\users\gregw\microcontroller-home
pip install esptool micropy-cli
micropy stubs search "esp32"
micropy stubs add "esp32-micropython-1.12.0"

New Project Setup

Blinking an LED is the Hello World of the microcontroller world.

These step apply to all new projects. I am using a separate python virtual environment for each project, which is a couple more steps for each projec, but keeps each project nicely self-contained.

After a lot of thought, I’ve decided on the following project naming convention…

projectname-device-platform/language

Once you get hundreds of projects stacking up, you come to realise that good naming matters a lot. More on naming in another post.

micropy init oled-esp32-upy
    select all 5 options using space bar and up/down arrows, with Enter to Ok your selection
    then select the stub: esp32-micropython-1.12.0
cd oled-esp32-upy
code .

When VS Code opens, it will ask if you want to install the recommended Extensions. Go ahead and do it.

I will not be using VS Code’s Workspaces feature, but if you regularly switch between different types of projects e.g. Rust and MicroPython, Workspaces are extremely useful.

• Install the VS Code PyMakr extension

Each Session

Once the above steps have been done once in a project folder, next time you want to work on that same project, you just need to navigate to that folder and start VS Code.

cd c:\users\gregw\microcontroller-home\oled-esp32-upy
code .

Hello World on the Display

Copy code from https://raw.githubusercontent.com/micropython/micropython/master/drivers/display/ssd1306.py to src/ssd1306.py

• “install” it using micropy’s package manager so we get intellisense

micropy install -p ./src/ssd1306.py ssd1306

• main.py

import machine, ssd1306
i2c = machine.I2C(scl=machine.Pin(4), sda=machine.Pin(5))
oled = ssd1306.SSD1306_I2C(128, 64, i2c, 0x3c)
oled.fill(0)
oled.text("Hello World", 0, 0)
oled.show()

• Upload your modified main.py

TODO: screenshot of vscode pymakr integration (animated gif better)

References

Setup microPy and PyMakr in VS Code Pinout of ESP32 with onboard OLED sample code to print Hello World on the OLED Another example using the OLED and a digital barometer

This is a little diversion from Rust on the STM32. My nephew has been doing some Python at school, and also had a project in mind for an ESP8266/ESP32. I had a couple of spares, so it’s time to flash MicroPython onto them and have a play.

It is worth noting that using microPython on a board like the ESP32 is not a well polished experience. It may be worth going for a more expensive board that was built with microPython in mind, or going for the even more polished CircuitPython.

Setting up your host PC

• Essential: Install Python 3.x 64bit Windows - you’re host PC uses various Python tools to flash microPython to the board, upload your code, and perform other tasks
  • Use the Windows Installer Version
  • Don’t use the Windows Store version
  • I left everything default except…
  • Add Python 3.8 to PATH: Yes
  • Note: I did not use the Customize Installation option, which can be used to install Python in C:\Program Files, as this can cause extra permissions problems when running pip from a non-elevated command prompt.
• Recommended: Install Putty. You need a way to communicate with serial ports. Putty is one way to do it, and is commonly used for a variety of tasks, so it is worth getting used to its quirky UI. Use the 64bit MSI (“Windows Installer”)
• Recommended: Install Visual Studio Code Because you don’t want to be writing code in the REPL, or Notepad!
• Recommended Install Windows Terminal. Because it is a lot more user friendly than the 30 year old Command Prompt.
• Optional: Python Virtual Environments are very useful, as they allow you to create independent environments for different projects, each with their own sets of packages. Read about Virtual Environments here. I’ll be using venv in this tutorial.

Flash MicroPython onto the ESP32

• Download the ESP32 firmware. I used the latest stable one based on ESP-IDF v3.x, and save or copy it to your working folder.
  • Note: by using the stable version of MicroPython, we don’t need the extra step of “disabling debug output”
• Find the COM port of your ESP32
  • Open Device Manager (right click the Windows Logo and choose Device Manager)
  • Expand Ports (COM & LPT)
  • Plug in you ESP32. You should see a new COM port appear, and then disappear when you remove it. Make a note of the COM port, e.g. COM3
• Erase the deviceh, then upload new firmware (change COM port number as appropriate)
  • Hold down the Boot button on the ESP32 board as you hit Enter on the following command, and keep it pressed until you see something useful happening. This may or may not be needed for the next step as well.

esptool.py --port COM3 erase_flash
esptool.py --chip esp32 --port COM3 write_flash -z 0x1000 esp32-idf3-20191220-v1.12.bin

• If the above commands run without error then MicroPython should be installed on your board!

Reference (and additonal info if things go wrong): Getting started with MicroPython on the ESP32

Using Putty to Connect to the REPL Prompt

After initial setup, the only way to get a REPL prompt is over a serial port. This is where Putty comes in. Putty can be used for various types of connection to remote devices and servers, but we are just interested in the simple case of a Serial connection.

1. Select the Serial radio button
2. Change Serial line to that used by your ESP32 board. Mine was COM3
3. Change the Speed (also known as baud rate) to 115200
4. Optional: You can give these setting a name (in Saved Sessions), and Save it for future use

Once connected you should get a REPL prompt in your Putty session.

You can mess around in REPL getting WiFi to work, and this is good for testing stuff out, but you’re going to want those WiFi settings to run when the board starts up, so for this you need to write a boot.py and be able to upload it.

The tutorial at docs.micropython.org are excellent. From this point I would skip straight to tutorial/network_basics to learn how to do stuff with Wifi. They do everything in REPL, but if you want something to happen at every boot of the device, you should add it to boot.py

NEXT: Setting up your dev environment and writing some code

Other References

• Micropython, ESP8266 and VSCode
• Getting a MicroPython REPL prompt - official docs
• Running MicroPython on the ESP8266 - a useful guide

Yes, I know I could just grab the blink example from the stm32f4xx-hal repo. But this much more time-consuming way teaches more about both chips, and increses my familiarity with the all-important reference manuals.

• Clone the F1 repo, give clone a second parameter to change the name of the folder you clone into
• Then disconnect it from the original remote, because you wouldn’t want to push the converted code to the original repo

git clone https://github.com/GregWoods/01-blink-f1-rs.git 01-blink-f4-rs

• Create the new repo in github

gh repo create 01-blink-f4-rs

• And follow the instructions on the new repo default page, to connect your new remote to your local repo

got remote remove origin
git remote add origin https://github.com/GregWoods/01-blink-f4-rs.git
git push -u origin master

Change the Setup

• .cargo/config
  • change thumbv7m-none-eabi to thumbv7em-none-eabihf (2 instances)
  • change arm-none-eabi-gdb to arm-none-eabihf-gdb (1 instance)
• cargo.toml
  • change your package name from 01-blink-f1-rs to 01-blink-f4-rs
  • change the hal dependency to [dependencies.stm32f1xx-hal]
  • and change the features list: remove stm32f103, use stm32f411 (or ```stm32f401`` for the cheaper verison of the black pill)
  • Add a version number to stm32f4xx-hal. Currently 0.7.0 (we need this the first time, becaue we don’t have a valid value in cargo.lock) Trying to build will report a list of possible versions)
  • remove the ```medium`` feature from the hal crate
• memory.x
  • The FLASH and RAM start addresses are the same
  • But the sizes for the stm32f411 are: FLASH 512K; RAM: 128K (as far as I can tell)
• .vscode/launch.json
  • replace STM32F103VCT6 with STM32F411CEU6
  • Replace target/stm32f1x.cfg with target/stm32f4x.cfg
  • Change the svd from STM32F103.svd to STM32F411.svd
  • Change the executable path, replace thumbv7m-none-eabi with thumbv7em-none-eabihf
• Go and download STM32F411.svd
• main.rs
  • change the use statement from stm32f1xx_hal to stm32f4xxx_hal
  • replace pac from the ‘use’, with stm32 - an odd naming inconsistency between the stm32f1 and stm32f4 hal projects
  • rustup target install thumbv7em-none-eabihf to install the missing bits of the toolchain

Change the Code

Run cargo build and fix the bugs one by one referring to the hal repo: github.com/stm32-rs/stm32f4xx-hal

I’m not entirely sure you’ll get the errors come back in the same order as listed here! It is likely I fixed more than one at once.

Error 1

16 | use stm32f1xx_hal::{
   |     ^^^^^^^^^^^^^ use of undeclared type or module `stm32f1xx_hal`

An easy one. Change stm32f1xx_hal to stm32f4xx_hal

Error 2

18 |     pac,
   |     ^^^ no `pac` in the root

In this hal, the peripheral access crate (pac) is called stm32. Which leads to our next fix…

Error 3

    |     let dp = pac::Peripherals::take().unwrap();
    |              ^^^ use of undeclared type or module `pac`

Change to

    let dp = stm32::Peripherals::take().unwrap();

Error 4

    |     let mut flash = dp.FLASH.constrain();
    |                              ^^^^^^^^^ method not found in `stm32f4::stm32f411::FLASH`

‘constrain’ is not a thing in the Reference Manual. So this is something added by the HAL, probably to keep the rust compiler happy. In the hal code, inside flash.rs is the following comment… /// Constrains the FLASH peripheral to play nicely with the other abstractions

The stm32f4xx-hal doesn’t have a flash.rs. A quick search in the github repo shows it uses stm32.FLASH from the PAC. Before I went down a rabbit hole, I noticed that the probably fix for the next will mean we don’t need to use FLASH at this time. So I remove the line. I will have to revisit this sometime, but not today!

Error 5

    |     let clocks = rcc.cfgr.freeze(&mut flash.acr);
    |                           ^^^^^^ expected 0 parameters

‘freeze’ doesn’t appear to be a feature of RCC_CFGR registers as far as I can tell. This is something “Rusty”. According to ‘freeze’ in the stm32f1xx-hal, an ‘acr’ parameter exists, but is not used! It looks like the stm32f4 hal has simply removed this unused param, so we should be able to remove it here. Easy!

Error 6

    |     let mut gpioc = dp.GPIOC.split(&mut rcc.apb2);
    |                              ^^^^^ expected 0 parameters

The syntax of ‘splitting’ the GPIO port remains a mystery to me for now, and passing rcc.apb2 is even more confusing. The fact that the stm32f4 doesn’t require this parameter is all I need to know for now!

Error 7

     |
     |     let mut led = gpioc.pc13.into_push_pull_output(&mut gpioc.crh);
     |                              ^^^^^^^^^^^^^^^^^^^^^ expected 0 parameters

Examine the Reference Manual and HAL. In the stm32f4 reference manual, there are no search results for CRL or CRH. Things are obviously done a bit differently to the stm32f1, where ```CRH`` is ‘Port Configuration Register High’

stm32f1

For port configuration, the MODE bits(2 bits per gpio line) and CNF bits (also 2 bits per ‘pin’) for each GPIO pin are interleaved, so we can only store 8 pins worth of setting within 32 bits.

The CRL register is the same, but for GPIO pins 0..7

stm32f4

The arragement is simpler for this chip. The settings for all 16 pins on a single GPIO port are stored in one 32 bit register.

Therefore the HAL simply doesn’t need to refer to CRH or CRL, it just uses the MODE register directly.

Error 8

    |     let mut timer = Timer::syst(cp.SYST, &clocks).start_count_down(1.hz());
    |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected 3 parameters

Looking at the stm32f4xx-hal code, in timer.rs, we find:

    impl Timer<SYST> {
        /// Configures the SYST clock as a periodic count down timer
        pub fn syst<T>(mut syst: SYST, timeout: T, clocks: Clocks) -> Self
        where
            T: Into<Hertz>,

well, this is handy - the timeout in Hertz is set in the constructor, instead of in the chained start_count_down.

Fixing that has shown another error

    |
    |     let mut timer = Timer::syst(cp.SYST, 1.hz(), &clocks);
    |                                                  ^^^^^^^
    |                                                  |
    |                                                  expected struct `stm32f4xx_hal::rcc::Clocks`, found `&stm32f4xx_hal::rcc::Clocks`
    |                                                  help: consider removing the borrow: `clocks`

As is often the case, the compiler suggests the fix. I’m unsure of the consequences of giving syst ownership of clocks, but that is for another day.

Our converted line looks like:

    let mut timer = Timer::syst(cp.SYST, 1.hz(), clocks);

We can fix a couple of compiler warnings about variables which don’t need to be mutable, and everything is good.

This should all now build, and the debugger can step into the code.

Or… Computing for tightwads

For my 6 yearly PC upgrade, how do I decide which CPU to buy? My pockets aren’t deep enough to simply buy the best there is, so price/performance is a major consideration.

The last CPU I purchased new was an Intel Core i3-xxxx. Even at the time it was towards the bottom of the pile.

I was playing a lot of Flight Simulator X at the time, and from what I’d read, it was a lot happier on Intel silicon than AMD, which I’d always been a fan of up to that point. Also, FSX only uses a single core, so it was important to get a high clock speed, and not important to get quad cores.

The top end Intel CPUs, with the ‘K’ suffix, meaning clock multiplier unlocked, have always commanded a much higher price. Too high for the extra performance gained, especially for those not interested in overclocking.

The i3-2130 at 3.40GHz was the obvious choice. It was in the price performance sweet spot.

Fast forward to 2019, and I’m playing Dirt Rally now and again. It generally runs great on the old i3, but there are occasional glitches - dramatic drops in framerate, which can be worrying when hurtling down a Hellenic mountainside. I’m also getting itchy for an upgrade, but to get an up to date CPU, I need to replace motherboard and RAM too.

For an interim upgrade I looked at the CPUs my motherboard supports. It supports both 2nd and 3rd gen Intel Core i-series chips, so I sourced an i5-3550 on eBay for £32. When I run the Dirt Rally benchmark again, I see no real difference in average frame rate, but the lowest framerate has dramatically increased. It barely hiccups now. It was likely Windows performing some background task that was causing the slowdowns, and adding 2 more cores made a dramatic difference.

But What Next?

Probably back to AMD. The Ryzen 5 3600 is looking good value, under £200, and is rated at 65W perfect for a tightwad.

*My self imposed 65W limit isn’t about running costs, it is simply a way to avoid getting carried away with buying the latest and greatest CPU in the range, and paying too much for the privilege. I also value a quiet PC, and the lower wattage devices help keep temperatures down even with stock or low cost coolers.

I have spent quite a bit of time recently trying to learn the Rust programming language for use on the $2 ARM Cortex M3 STM32 board, commonly known as the “Blue Pill”. The learning process has often been frustrating, and it has not been quick. But I feel I can share some code, and tips which can make it less painful.

Where have I come from?

I am a full time developer working on the Microsoft stack for a number of years in the high level C# realm. As a hobbyist, I have a strong interest in microcontrollers, and have tinkered with PIC and AVR using assembly language, C, and Arduino. I love the Arduino platform due to it’s accessibility for noobs, but I’ve been itching to move away from it. Why?

Why the Blue Pill?

Cost

For the same price as an 8MHz 8bit Arduino Pro Mini clone, I can buy a 72MHz, 32 bit Arm Cortex M3 board (and for not much more, a Cortex M4F)

Features

For my projects, both Arduino and Arm Cortex M3 boards will have all the features I need, but the stm32 boards have greater horsepower, which allows the running of a simple RTOS, along with more complex code in interrupt handlers.

Debugging

It is possible to do real debuggiong on the stm32 board, when connected to an ST-Link debugger. It should be possible to stop using printing-to-the-console to debug, and instead set breakpoints and step through the code like a real programmer!

Why Rust?

I love the simplicity of Arduino code. This simplicity is all due to the friendly design of the libraries. But, it is still C++, and once your code starts getting even slightly complex, you hit all the problems of C++, including various abuses of pointers which cause hard to find runtime bugs. Rust promises the speed of C/C++ with a more robust system of memory safety, whereby the compiler always knows which code block a variable belongs to, and thus can check for many sources of bugs at compile time (this is a gross oversimplification. Go and read the docs yourself) I don’t have the clout to convince anyone that Rust is worth the effort, but you have to at least check it out. Start with the official docs rust-lang.org/what/embedded

It also helps that Rust has a very helpful compiler. Compiler error messages are not the afterthought that they are in C++. They system has been carefully thought out, and is exceedingly helpful to noobs.

The Trap

It is always dangerous to learn a new tool or lanaguage and then use it for absolutely everything, no matter how inappropriate it may be. For some projects, an 8 bit microcontroller on Arduino may be the best choice. But, to maximise the little time I have for learning the new platform, I will be focusing my efforts on Rust on the STM32 for current hobby projects.

Next - How to Learn

The water’s not that deep - you’ll be fine

You will find tutorials and blog posts telling you how easy it is to get started in Rust on an STM32 platform.

They lie!

Or at least, they are written by experienced embedded developers who are simply transitioning to Rust.

As an Arduino developer, you are familiar with:

• downloading the IDE
• changing the board type
• copy-pasting some demo code
• change the odd pin assignment
• compile and upload
• Done!

This is not Arduino

Instead you are now faced with:

• Manual setup of your toolchain
• Manual configuration of your debugging tool/uploader
• No out of the box integration with your IDE
• Blog posts which are outdated, whose code won’t compile anymore
• Libraries at a much lower level than Arduino ones
• Having to be very familiar with your chip’s data sheets

The Wrong Way to Learn

My initial approach to learning, which has usually served me well, was

• Avoid any dusty official documentation, it takes too long to digest all that detail
• Find a respectable looking blog-with-code
• Relicate the steps in the blog; make some trial and error modifictions; add some interesting looking libraries to tinker with peripherals
• Glue together the various bits of experimentation into your actual project

I wasted a lot of time. Rust and the libraries in the ecosystem have changed in the last 3 years, and most of the blog posts were written by seasoned embedded developers who were early adopters in Rust. Although I learned something from every one of them, it was not the right apporoach to learning a whole new language and ecosystem.

Take Your Time, Structure Your Learning

The right way is to take your time and use the official docs - they are excellent, and shouldn’t be rushed. I am using a multi-faceted approach.

• Learn Rust on its own - with no embedded distractions
  • The book
  • Rust by Example
  • Rust Cookbook - because it’s good to see how other people write Rust
  • Lots more official Rust documentation
  • Various Rust books from my Packt Publishing subscription
• Get started with embedded Rust Start at the beginning. Don’t fast forward until you’ve completed the next step, QEMU
  • Use the emulator QEMU even if you never plan on using the emulator ever again, it helps you grasp the toolchain and ecosystem.
  • Get your first blinky working in a VS Code environment This is my own quickstart code. It is using a HAL, so it is skipping ahead a few steps, but I find it useful to have a ready to go starter project
• Learn the chip
  • Learn about SVDs and Peripheral Access Crates using this excellent tutorial from Vivonomicon
  • Get to know the 1134 page Reference Manual. This is not optional! But you don’t need to read it cover to cover
    • Get to understand the blinky code from the point of view of the Reference Manual. Start at chapter 9 “General-purpose and alternate-function I/Os (GPIOs and AFIOs)”. Comparing the Reference Manual to the code you’ve written using your PAC, will help you grasp how the STM32 registers work for IO.
  • Go and get a HAL, and learn to use it But make sure you get the right one. There are deprecated projects out there to catch the unwary.
    • After using the Peripheral Access Crate directly, the HAL, to me anyway, is more complex and less intuitive due to it’s use of the inversion-of-control principle. But, getting used to the way it works should help you write code which can be ported to other chips
  • Get to know RTFM - Real-Time-For-the-Masses. I’m yet to get into this, but it does feel like the right way to go for most projects.

The above list is not a strict sequence, I am learning a little about each of the 3 top level areas each week. Progress, for me at least, is not particularly fast, which can be frustrating when you have projects in mind. Which is why the next point helps.

Keep a Learning Log

This has helped me to avoid the feeling that I’m not getting anywhere. It helps me see what to study and try out next. I abbreviate book titles.

I use a simple table in OneNote

Excerpt…

I’ve seen lots of more complex Learning logs online, but for me, just a running virtual bookmark is enough. Notes may be a page or chapter reference. Sometimes I’ll note an immportant topic I convered. I’ll note any code I worked on. My log isn’t well written or consistent in its type of content. I don’t go into great detail about what I’ve learnt, it isn’t a summary. It is more to track progress.

I’ve found it a great help.

So that is my Rust learning story so far. I hope it helps!

UPDATE: 5 years after the original post… Microsoft has improved the UI for the command prompt colours… by introducing the new “Windows Terminal”. It is in the Microsoft Store. Go and get it. It has json based config just like VS Code, easy colour schemes, and support for various shells, including command prompt, Powershell, Powershell Core, and Linux through Windows Subsystem for Linux (WSL)

I have happily used the Windows command prompt for years. As a matter of habit, I always change the font to Consolas 14pt and background colour to something a little less harsh than #000000. Usually a muted dark blue or green. When doing so, I’ve simply changed any one of the colour swatches to my desired colour and assign it to the “Screen Background” radio button. This seems to be how the dialog was designed, and it works fine when using standard windows command prompt. However, some recent tinkering with Node.Js made it all go horribly wrong.

As you can see, some of the text from the output of the REPL session has disappearred into the background.

Above: My incorrect idea of how the colours dialog works

The reason is that my mental model of how the Command Prompt Properties ‘Colours’ tab works, was completely wrong.

According to my mental model, I…

• Pick a colour tile, any tile from the ‘palette’ of available colours
• Modify it using the RGB values
• Assign it the “Screen Background” radio button
• Job done! My everything looks great, until I use node
• Through lots of trail and error and looking at how Unix terminals treat colours, I”ve come to realise that not only is my mental model completely wrong, but this dialog box is really really badly designed.

This mental model works fine if you are only every using ‘DOS’ commands. But node was designed for Unix-y environments.

It turns out that windows command prompt has a lot more in common with Linux than I ever thought. It seems that these 16 colour chips correspond with the ANSI colours used by all terminals. They are not simply a colour palette to pick and choose from.

Above: A better mental model of how this dialog works

Therefore the correct way to use this dialog appears to be

• Select the first colour chip
• Change it to your background colour
• Make sure it is still assigned to the “Screen Background” radio button
• Ensure the next 7 colours are clearly visible on your background colour
• Note that I had to deselect the colour value box before switching to another ‘swatch’ or it would transpose the colour value I was editing onto the new swatch, making things really awkward.

Here is my colour scheme after 10 minutes of playing around. They are shown in the image.

I’ve ignored the other 8 colours, I’ve yet to see them used.

If nothing else, this post is a reminder to me how this obscure dialog works. I suspect this dialog has been around since Windows 3! It would be a good exercise in UI Design to re-fashion it to better fit how it works.

Note on driver types (it is relevant!)

On Windows 8.1 64 bit (and true for 64 bit Vista and Win7 as far as I know) you have 3 types of driver…

• Signed driver - This is preferred. It is how you are used to installing and using windows devices, but the developer must pay for it to be signed. Not an option for com0com.
• Unsigned driver - every time you want to use the unsigned virtual COM ports, you must reboot your PC twice to get to the Allow Unsigned Driver option. It is a pain. This is true of the latest com0com 3.0.0.0. If using 64bit Windows, avoid like the plague
• Test Signed Driver - you can run a simple command line instruction to tell Windows to allow Test-Signed drivers. The setting persists between reboot, so it is convenient. For com0com, this is true for the signed version of 2.2.2.0

Installation

Use version 2.2.2.0 because it is signed. When installing, I unchecked the option to add a default pair of COM ports. I preferred a clean start Run the command: bcdedit -set TESTSIGNING ON Once com0com is installed, go and get hub4com, unzip, rename the readme file and copy the whole lot into your com0com folder.

Note

v2.2.2.0 signed doesn't have the graphical setupg program, so need to use setupc for everthing

com0com command prompt: list

My Scenario

I have an Arduino on COM3, and some PC Software which talks to it, called “PC Lap Counter” (PCLC) - it’s a race management solution for slotcar racing. PCLC sends race and lap info to the Arduino over the serial connection, but I want to be able to look in on this info as it is happening.

Step 1: Setup the Virtual COM port Pairs

Set up 2x com0com pairs using the com0com command line setupc.exe

    install 0 PortName=COM5 -</span>
    install 1 PortName=COM6 -</span>

maybe need another COM port for a second putty session for injecting input

• COM5 is to be used by PC Lap Counter, and is paired with CNCB0
• COM6 is used by Putty for monitoring, and is paired with CNCB1
• COM3 is physical COM port which Arduino is attached to
• Note that these COM ports will persist after reboot, whereas the hub4com routes need making every time.

Step 2: Join the COM port pairs together with hub4com’s Routes

From std command prompt…

hub4com -baud=9600 -octs=off -ox=on -route=0,2:All -no-default-fc-route=0,1:All \\.\CNCB0 \\.\CNCB1  \\.\COM3

unsure what the -no-default-fc-route is all about. Try without!

This routes PC Lap Counter to both Putty and Arduino. Plus, routes Arduino serial output to Putty

Step 3: Snoop away

Using Putty, create a new ‘Serial’ connection. In the above example, it is connected to COM6 at 9600baud

Then along came the microcontroller. I can’t remember whether I discovered PIC or AVR first, but whenever a new development board was being given away for free or nearly free, I’d be on it. Writing little test programs wasn’t overly difficult. Setting up the development environment however, was. Often, between long droughts of development, my PC would have been rebuilt, and I’d lost all that setup time and effort. As far as the programming went, I have always enjoyed low level coding (starting with hand written Z80 machine code on a Sinclair ZX81). But enjoyment wasn’t the only goal - a finished project matters. And hour upon hour could be spent at too a low a level to feel like progress was being made.

I heard about Arduino, discovered it was AVR based and had a bootloader - which didn’t seems a compelling reason to go with it, since AVRISP programming worked fine. The boards were also far too big, and too expensive compared to the $1 (£1 to me) chips I was used to buying. I was perhaps also swayed by a slight preference towards PICs over AVRs. The Arduino marketing didn’t help me either. I read it as “Helping whimsical arty types create pointless trinkets with overpriced, overspecified boards so they don’t have to learn the hard way”. I liked the hard way. So I wrote Arduino off as a toy.

How wrong I was.

I recently resurrected my childhood love of slot car racing (Scalextric) by building up a reasonable collection of Scalextric Digital track and cars. I explored the PC based Race management Systems which add a whole new dimension. My ‘maker’ mentality was reawakened at the thought of interfacing with all this digital information flying round the track and doing useful things with it, like a leader board or F1 style start lights (my current project combines these into an ‘onmi gantry’ - more later). Each of the three PC based Race Management applications supported Arduino in one way or the other. So I put aside old prejudices and ordered a couple of cheap, Chinese clones of the Arduino Pro Mini and FTDI programmer. No bigger than a DIL chip, the Pro Mini appealed to my barebones mentality. After a couple of days reading around the subject, waiting for the slow boat from China to arrive, I bought an Uno. The price was more reasonable than I’d remembered - and all the tutorials referred to them, so I decided, for once, to make things as easy as humanly possible so I could concentrate on getting my project finished. The fact that the Uno can be used to burn the bootloader onto bare Atmel chip was another compelling reason to have an Uno.

I’m now a week into Arduino programming, and I can say I’ve done more in a week than I would have done in months with a bare AVR/PIC. Having the bootloader does make a big difference. When you can’t get a line of code to work… change - upload - test - repeat. Valuable seconds saved dozens of times in a programming session add up to a more pleasurable experience. The fact that I can go to a brand new PC, download the IDE, load up my files from Dropbox and carry on coding from where I left off is also useful. But the real appeal of Arduino is the libraries and other support material. The various hardware shields don’t interest me too much, but the libraries developed to support them are amazing. To think, I used to to have to read chip datasheets to write code. Now I download the library and I’m good to go. LCD screens, LED matrices, NeoPixels, Serial communication, I2C sensors - all have superb libraries which mean that getting a project finished is now a real possibility.

Finally, if anyone thinks, as I did, that cheap ARM cored boards spell the death of the 8 bit microcontroller - they are wrong. There are many projects where even an 8MHz processor is technically overkill. My next project is adding realistic looking running lights to an RC Helicopter. It seems ridiculous that such processing power is being used for such a trivial task. But doing it from discreet components would be a huge undertaking without an Electrical Engineering background. The finished project would be so big and heavy that the heli wouldn’t be able to lift off! Being able to adjust the timing of the flashing lights with a line of code is awesome compared to swapping out resistors and capacitors. An Arduino Pro Mini does the job nicely for a couple of bucks, and grams. You wouldn’t want to use the size and expense of a Raspberry Pi or BeagleBone for those kind of tasks!

So, in case you haven’t figured it out, I’m a bit pleased with the Arduino. Rather than feeling like I may have missed the boat, I believe it’s a good time to start out. The platform is mature, the community solid, the glitches ironed out and libraries already written. So if there are any hardware tinkerers out there who, like me, are stubbornly refusing to take a look at Arduino - Jump on the bandwagon, the ride is surprisingly smooth.