Hex Boot Loader

This is a serial Intel Hex format bootloader for ATMEGA4809, though it is pretty simple to port to other hardware. It occupies less than 512 bytes (I do not think it is possible to fit it under 256).

To use, burn into the processor. Compile your application and link it to start @0x200 by setting .text = 0x100 (its in words). Set the linker to creat a hex file.

Using a terminal emulator such as teraterm set to 115200 baud, no parity, 8 bit, 1 stop, XON/XOFF flow control, send the hex file.

This loader supports extended addressing (record type 2) so it will accpet files up to 1MB for things like SAMD21, SAMD51, etc.. Note further that you will have to change the WriteFlash() function as well as the write to memory method in general for different processors.

link to project https://gitlab.com/bjpiccioni/hex-boot-loader


This is my minimal ili9486 driver.

This is meant to replace the customary AdafruitGFX + MCUFriend_kbv package. Unfortunately those suffer from the customary Arduino code bloat and typically use so much program memory there is little left for an application. Ever after serious editing the Arduino drivers take up a huge amount of space and are very slow.

Roughly speaking this driver requires about 1200 bytes to print a message on the display including about 400 bytes for the font. It is also fast so you can fill the display in about 0.5 seconds with a 20Mhz Atmega4809.

It is meant to drive a typical Arduino 3.5″ display with an ili9486 controller. I also have ili9325 support but I haven’t tested it yet as I can’t remember where I put my 9325 diplay. Note that most display controllers are quite similar so adapting to a new controller should be straightforeward.

There are 6 externally callable routines

  1. Initialize display aOrientation = 0, landscape bool TFTInit( uint8_t aOrientation );
  2. Set foreground/background colour void TFTSetTextColor( uint16_t aForeground, uint16_t aBackground );
  3. Display a text message @ row, column. Character set 20 to 0x7f Note that fonts tend to be on their side to save memory but this makes them slow to draw a pixel at a time. The controllers tend to have a “fast write” function which allows you to blast pixels to the display very quickly. In order to exploit this feature without remapping the font I switch the display on its side, draw the text then switch the display back. Keep that in mind if you want to port to a different controller. void TFTShowMsgRowCol(uint8_t aRow, uint8_t aColumn, char *msg );
  4. Draw a straight horizontal or vertical line of length, width of colour. This is also used to clear the display void TFTDrawLine(uint16_t aStartX, uint16_t aStartY, uint16_t aLength, uint16_t aHeight, uint16_t aColor);
  5. Draw a Pixel @x, y of colour. This can be used to do pretty much anything but is as slow as the Arduino driver (probably) void TFTDrawPixel(uint16_t x, uint16_t y, uint16_t color);
  6. Set the display brightness LED (if supported) void TFTSetBrightness( uint8_t aBrightness );

Any quesitons or bugs contact me brian(at)documenteddesigns.com

link to project https://gitlab.com/bjpiccioni/ili9486driver


ASF4 is a powerful tool for configuring Atmel devices. It is far from perfect (you can configure clocks so your device won’t work) and very poorly documented. To make matters worse (see below) important structures are declared in c files instead of h files meaning important functions are not callable.

USBSerial examples are in ASF3 but ASF3 doesn’t support modern Atmel devices like SAMD51. ASF4 has a “USB Echo” example for SAMD21 but it is essentially undocumented, particularly opaque,(like most ASF4 code) and utterly useless because, eriously, why would you want an ISR which does nothing but echo back USB input?

There are stacks like TinyUSB which work with SAMD51 but then you have to fit in ASF4 and the ASF4 .astart files are obsolete so if you try and use them ASF4 produces garbage.I have managed to get TinyUSB to work with ASF4 but I decided to try getting USBSerial to work with only ASF4 and not using any other stack. This was not easy since ASF4 output is opaque and poorly documented but I think I got it going.

There are 10 core routines:

bool    CheckUSBOutAvailable( void );       //Check if output can be written

void    USBFlush( void );                   //Flush the output buffer (send to terminal)

int     CheckUSBSerialRXAvailable( void );  //Any data in (like UART RX Ready)

bool    CheckUSBAttached( void )            //True if USB attached and initialized

int     USBSerialRead( );                   //Wait for input from USB Serial and return with it

void    USBSerialWrite( int c );            //Write to USB Serial and flush the buffer

bool    USBSerialAttached( void );          //True if USB Serial is attached and ready

void    USBSerialWaitDTR( void );           //If USB_FLOW_CONTROL true wait for DTR

int     _read (int fd, const void buf, size_t count);  stdio used by scanf, etc

int     _write( int fd, const void buf, size_t count ); stdio used by printf, getchr

Note that for getchar to work as expected, stdin is unbuffered via

	setbuf(stdin, NULL);        //No buffering on input (makes getchar work)

This should not be an issue since USB is buffered and I buffer that with a ring buffer.


  • Only 1 endpoint
  • Hardware flow control is not yet fully implemented because for strange reasons ASF4 important structures are defined in c files instead of h files (for example cdcdf_acm_func_data within cdcdf_acm.c and important structures in hal_usb_device.c meaning you can’t use functions inside either without modifying them. Vitally important functions are only accessible from within these c files. For example, to change RTS I need access to the rs232 structure which I can only get with something like this uint8_t FindBuf( void ) { int8_t ep_index = _usb_d_find_ep( ENDPOINT ); struct usb_d_ep ept = &usb_d_inst.ep[ep_index]; uint8_t req = ept->xfer.req; //<======= req is uint8_t to rs232 return( req ); }

I suspect that in order to have > 1 endpoint or working hardware flow control I will have to modify some of the ASF4 files, which sort of misses the point.

Since I can’t figure out how to access the endpoint without modifying cdcdf_acm.c I capure the endpoint and use that to get the status of the USB port through _usb_d_dev_ep_get_status(). The write (print) port endpoint is usually 0x81 single port and the The write (print) port endpoint is usually 0x01 I capture it instead of using a #define because I am hopeful I can extend this to several channels.

I have found that most ASF4 based examples will work if you create the ASF4 files for the desires hardware (i.e. SAMD51, SAMD21) and just copy the example over. I therefore suspect USB_Serial will work on SAMD21 just by doing that (though you might need to adjust timeouts, etc).

I haven’t tried it but the stdio for ASF4 ARM and AVR are different. I believe an AVR implementation would be something like

FILE  USB_SERIAL_STREAM; //Global stdio FILE structure at the top of USB_Serial.c

and this added to the end of USBSerial_Init() and remove _read() and _write() from the source.

USB_SERIAL_STREAM.put = USBSerialWrite;     //Write a character

USB_SERIAL_STREAM.get = USBSerialRead;      //Read a character


stdout = stdin = &USB_SERIAL_STREAM;

Note: Dec 22 Push I recreated an ASF4 packaged and checked for differences. Apparently I had included a number of directories from previous work which were not needed and deleted. I also renamed usb_cdc_echo.c to USB_Serial_example. Besides the files


The only changes from an ASF4 package are in the

atmel_devices_cdc.inf file 

where I shortened the strings from

"Communication Device Class ASF example"



link to project https://gitlab.com/bjpiccioni/samd51-asf4-usbserial

Metro M4 SAMD51 basic serial USB based on TinyUSB

I have been depositing some open source project on Gitlab. Weirdly, these do not show up in google searches, purportedly because Gitlab blocks them.

If so, this is idiotic.

So I am posting my projects here with links to them.

Metro M4 SAMD51 basic serial USB based on TinyUSB

This is my first cut at getting basic serial over USB working on a “bare metal” Adafruit Metro M4 using the tiny USB stack. on Mcrochip/Atmel Studio. You can go to https://github.com/hathach/tinyusb and download the complete source but these do not work in Studio (or maybe they do and I don’t know how).

All this does, for the moment, is implement the echo example. In future I will create library which will implement basic stdio.

Since SAMD51 is pretty poorly supported I thought this might be useful. I have tested the code and it works.

link to project https://gitlab.com/bjpiccioni/metro-m4-samd51-basic-serial-usb-based-on-tinyusb

Geographical Reannotation Within Kicad

I have been working for several months to incorporate RenumKicadPCB functionality inside Kicad. Meanwhile, Alexander Shuklin has done most of the heavy lifting by writing back-annotation into Kicad which does all of the error checking, etc., necessary for reannotation to work. Without his help I don’t think I could have done this.

Geographical re-annotation is under PCBNew/Tools. It should provide the same functionality as RenumKicadPCB but from within Kicad. I am hopeful I can submit a merge request which will be accepted so it will become part of the distribution. Of course, given my modest c++ skills I suspect that will not go smoothly!

I have tested the code with all the projects I used to test RenumKicadPCB and it appears to work. Besides renumbering correctly, it seems to detect project errors such as modules in the PCB which are not in the schematic, etc.

I would be grateful if people who are interested in this functionality would help test it and let me know if they have any problems or suggestions.

The source code is at


Building Kicad on Windows 10 With Eclipse/Msys2 (updated)

After some struggle and with the help of fellow Kicad developers I have managed to get a (mostly) integrated build of Kicad on Windows 10 using Eclipse. Similar instructions should work on any Eclipse platform.

Msys2 Installation

Install Msys2 (Download Msys2 http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20161025.exe )

Open a Mingw64 terminal ( msys64/mingw64.exe ) as this only seems to work if you open a mingw64 window.

pacman -Syuu
Answer yes to remove conflicts. Close the window via task manager when done.
pacman -Syuu
This takes a long time. Close the window via task manager when done.
pacman -Syuu
To make sure all is up to date

copy and paste these lines into Mingw64

pacman -S base-devel \
git \
mingw-w64-x86_64-cmake \
mingw-w64-x86_64-doxygen \
mingw-w64-x86_64-gcc \
mingw-w64-x86_64-python2 \
mingw-w64-x86_64-pkg-config \
mingw-w64-x86_64-swig \
mingw-w64-x86_64-boost \
mingw-w64-x86_64-cairo \
mingw-w64-x86_64-glew \
mingw-w64-x86_64-curl \
mingw-w64-x86_64-wxPython \
mingw-w64-x86_64-wxWidgets \
mingw-w64-x86_64-toolchain \
mingw-w64-x86_64-glm \
mingw-w64-x86_64-oce \
mingw-w64-x86_64-ngspice \
mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain

Install Eclipse

In Windows install Eclipse CDT for Windows 64 bit see https://www.eclipse.org/downloads/packages/release/2019-09/r/eclipse-ide-cc-developers

You need to edit the eclipse.ini file and change the line

This increases the heap for Java so you don’t get out of memory errors.

Save the eclipse.ini and load eclipse to see if it works.

Download and install Kicad Source Files

In the mingw64 terminal and sure you can run mingw32-make.exe. If not, update the dos/windows path until you can.

Note: this assumes you want the development build. If you want a release build, download that, for example kicad-5.1.4.tar.xz and use that name (kicad-5.1.4.tar.xz) insteead of kicad-source-mirror-master.

Download the Kicad source files from https://github.com/KiCad/kicad-source-mirror

Untar or unzip into /home/kicad-source-mirror-master


git clone https://github.com/KiCad/kicad-source-mirror.git

This will create a local repository directory called kicad-source-mirror

At any time you can update the repository by

cd kicad-source-mirror
git pull origin master

Note that this will leave files which are in kicad-source-mirror but not in the kicad source repository unaffected. *** However *** they will over write your versions of those files! So if you edit cmakelists.txt or any other Kicad source file those edits will be lost.

Create a directory such as c:/home/eclipse-kicad. This will be your build directory.

cd /home/eclipse-kicad

Copy and paste these lines into Mingw64

cmake -DCMAKE_BUILD_TYPE=Debug \
-G “Eclipse CDT4 – Unix Makefiles” \
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \

This takes a few minutes but you only do it once.

(note: you may have to copy/paste into a text editor instead of from this web page)

Note that the -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE switch creates a link between the build and source directories for eclipse. This allows for error highlighting, etc..

You can test the build with
make -j install (Note: the -j means use as many cores as you can and reduces compile time on my system by 70%). This process may take hours: on my gaming laptop it takes about 30 minutes if I use the -j option.

In Eclipse

File->Import General->Existing Projects into Workspace Select Root Directory as

Wait for the indexing to complete (this will take some time)

select debug configuration (at the top near the red square)

Right click on project root select Build Targets go to the bottom and select Install.
First time, edit and set make to C:\msys64\usr\bin\make.exe -j then click build.

To rebuild select the project root and hit F9. Note that it you don’t select F9 or Build Targets Install it will not copy the project in the appropriate bin directory.

Note that you can access the source files in Eclipse by clicking [Source Directory] in the Eclipse project and you can rebuild by clicking the (*) Build Targets group.

I have not yet figured out how to integrate the source, build, and debug functions, however I can use the Eclise standalone debugger (see https://wiki.eclipse.org/CDT/StandaloneDebugger ) to debug pretty much any
executable which has been compile with debug info as long as I also have the source files.

I will update this with any corrections or if, as, and when, I figure out integrated debugging.

Build Instructions for RenumKicadPCB on Linux Mint

Recently Alan Miller pointed out that my Windows MSI installer had the debug version bundled which requires different DLLs. I fixed that but I had migrated to a new laptop and so ran into some issues I will have to revisit. See the link to a fixed MSI below, which I will add to the github page. I will have to revisit this problem but I want to make headway on the Kicad/Renum integration (I can’t do too many things at the same time).

In our interchange I discovered Alan was in fact doing most of his work in Linux and yet was using RenumKicadPCB under Windows. I suggested he build a Linux version to save having to move files, etc., to a Windows PC.

Although I had built and tested under Ubuntu, Alan ran into a few problems. One is that I used a linux reserved keyword default in the source on line 86 of RenumGUI0v0_410.cpp. He changed that to def so the proper code should be:

wxSize StringtoSize(std::string &SizeString, wxSize def )
wxSize retval;
retval.x = atoi(SizeString.c_str());
retval.y = atoi(SizeString.substr(( SizeString.find(‘,’) + 1 )).c_str());
if ((0 == retval.x) || (0 == retval.y))
retval = def;

I’ll probably use something else when I update the source.

In addition he had to tweak the make instructions:

g++ -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -I/usr/local/lib/wx/include/gtk3-unicode-3.1 -I/usr/local/include/wx-3.1 -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF”src/RenumGUI0v0_410.d” -MT”src/RenumGUI0v0_410.o” -o “src/RenumGUI0v0_410.o” “src/RenumGUI0v0_410.cpp”

g++ -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -I/usr/local/lib/wx/include/gtk3-unicode-3.1 -I/usr/local/include/wx-3.1 -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF”src/RenumKicadPCB_Base.d” -MT”src/RenumKicadPCB_Base.o” -o “src/RenumKicadPCB_Base.o” “src/RenumKicadPCB_Base.cpp”

g++ -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -I/usr/local/lib/wx/include/gtk3-unicode-3.1 -I/usr/local/include/wx-3.1 -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF”src/RenumKicadPCBClasses.d” -MT”src/RenumKicadPCBClasses.o” -o “src/RenumKicadPCBClasses.o” “src/RenumKicadPCBClasses.cpp”

g++ -pthread -L/usr/local/lib -L/home/alan/wxWidgets-3.1.3/lib -o “RenumKiCadPCB0410” ./src/RenumGUI0v0_410.o ./src/RenumKicadPCB_Base.o ./src/RenumKicadPCBClasses.o -lwx_gtk3u_xrc-3.1 -lwx_gtk3u_html-3.1 -lwx_gtk3u_qa-3.1 -lwx_gtk3u_core-3.1 -lwx_baseu_xml-3.1 -lwx_baseu_net-3.1 -lwx_baseu-3.1 -lgtk-3


I will, of course, get around to updating all this on github but I am dealing with several issues concurrently so I thought it best to document it now in case I forgot or lost the instructions.


Building Kicad with QT Creator on Windows/Msys2

Building Kicad with QT Creator on Windows/Msys2

I have been working towards integrating RenumKicadPCB functionality (i.e. geographic back-annotation) into Kicad for some time. Actually, to be accurate I have been hoping to do that. A major roadblock has been an IDE which allows me to edit, build, and debug the code. I had experimented with Eclipse and Microsoft Visual Studio Community Edition but I couldn’t import the official cmake files as there was always something missing. I am, after all, a former hardware guy not a modern programmer.

Recently back-annotation came up in a Kicad developer’s thread and I made contact with Alexander Shuklin, who is not only a more advanced software guy but he has already contributed to Kicad. We agreed to collaborate on the project – a development which I am very happy with. Alexander uses QT-Creator and, while I was initially hoping he could help me get Kicad working on MSVC I realized it would probably be easier for me to get QT-Creator working since at least I know you can build Kicad on that IDE.

After several days of failure interspersed with a near success (I was so tired I forgot to document what I had done) I managed to get things going. Here is the procedure to build Kicad on Windows with QT-Creator. Note that this only seems to work with the Msys2 version of QT-Creator, not the Windows version of QT-Creator even if Msys2 is installed. Unfortunately this took a day and a half to figure out. I almost succeed with the QT-Creator on Windows (I actually got about 33% through the compile) but, as I mentioned I forgot to document what I done.

First install Msys2 (see http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20161025.exe )

Everything below is from a mingw64 terminal window. It does not seem to work if you pick from the Msys2 pop-up. I show 64 bit development because that is what is recommended. Similar steps would apply to a 32 bit development environment.

There may be redundant or unnecessary steps in this recipe. I completely deleted Msys2 a few times and re-ran this procedure but there are only so many hours in a day.

From the Mingw64 terminal (comments marked by //)

pacman -Syuu //Answer yes to remove conflicts close the window via task manager when done

pacman -Syuu //Takes a long time close the window via task manager when done

pacman -Syuu //To make sure all is up to date

Copy and paste the following lines into your Mingw64 terminal (all the way from pacman -S to the blank line)

pacman -S base-devel \
git \
mingw-w64-x86_64-cmake \
mingw-w64-x86_64-doxygen \
mingw-w64-x86_64-gcc \
mingw-w64-x86_64-python2 \
mingw-w64-x86_64-pkg-config \
mingw-w64-x86_64-swig \
mingw-w64-x86_64-boost \
mingw-w64-x86_64-cairo \
mingw-w64-x86_64-glew \
mingw-w64-x86_64-curl \
mingw-w64-x86_64-wxPython \
mingw-w64-x86_64-wxWidgets \
mingw-w64-x86_64-toolchain \
mingw-w64-x86_64-glm \
mingw-w64-x86_64-oce \
mercurial \
cvs \
p7zip \
ruby \
mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain

Now copy these lines one at a time (it may be possible to combine these with the above)

pacman -S mingw-w64-i686-qt-creator mingw-w64-x86_64-qt-creator

pacman -S mingw-w64-x86_64-clang

pacman -Syuu

Run qtcreator to make sure it works then exit qtcreator.


Download source files eg kicad-5.1.4.tar.xz into a suitable location such as /home source files can be found at http://kicad-pcb.org/download/source/ then

tar -xaf kicad-5.1.4.tar.xz

Run qtcreator from the ming64 terminal (for some reason, it doesn’t work if you pin it to the taskbar)


Select Open File or Project and open the Kicad source directory. Wait for it to parse

Note that QT will make its own build directory. This doesn’t seem to matter.

Select Build, rebuild project. On my machine it takes about 2 hours to compile Kicad

RenumKiCadPCB0410 Bug Fix

I have fixed a bug found by Paul P. where V0410 would not run properly if there was no existing RenumKiCadPCB directory in /users/appdata/roaming (Thanks Paul!).

Also at his suggestion I now show a warning and do not save the updated netlist file if there are netlist errors. This is usually because the netlist is out of date with the schematic and PCB so it makes it easier to fix (just regenerate the netlist from the schematic).

Here’s the link on Github https://github.com/BrianAtDocumentedDesigns/RenumKiCadPCB0401_July12_2019/tree/master