Some of the users of RenumKicadPCB have asked me about using the program now that Kicad V6 has been released. Kicad 6 is a big improvement over prior releases but it has different file formats to accommodate novel features. Rather than spend the time and effort updating RenumKicadPCB as a standalone program I collaborated with the Kicad devs to add the code to Kicad 6.

Geographical reannotation (ie RenumKicadPCB) is now a standard feature of Kicad 6. It works a little different and there are some quirks but it works fine. Unfortunately, not all RenumKicadPCB users are aware of this and after Alan Miller reached out to me to ask how it is done so I thought I’d make a quick post.

1) PCB Editor Tools → Geographical Reannotate. Note that the default “sort grid” is 1 inch (25.4 mm) so you have to set this to something sensible like 1 mm. Note there are two tabs where the most common options are in the Options tab, while rarely used options are in the Reference Designators tab. Make your selections and click Reannotate PCB.

2) Assuming you want to proceed click Yes to the pop up.

3) Note the “Warning: PCB annotation changes should be synchronized with schematic using the “Update Schematic from PCB” tool.”

4) Note and correct any errors or issues (other than the warning) and click close.

5) PCB Editor Tools → Update Schematic from PCB to push the new references to the schematic.

Important: Make sure Options “Re-link footprints to schematic symbols based on their reference designators” is unchecked, “Update Reference designators” is checked and the other selections (Update Values, Footprint assignments, and Net names) set according to what you want to do. If you don’t do this the schematic will not be updated with new reference designations.

6) Schematic Editor Tools → Update PCB from Schematic or just hit F8. This regenerates the netlist to use the new reference designations. If you don’t do this, and run DRC in the PCB Editor with “Test for parity between the PCB and schematic” checked, you will get errors.

If you have any questions please feel free to contact me.

I have managed to write a BLE client for Windows 10 console example. This might be useful for debugging BLE projects or as a core for working with BLE on Windows. TL:DR https://github.com/BrianAtDocumentedDesigns/BLE-SPP-Client-demo

Bluetooth Low Energy (BLE) is different from Bluetooth Classic (BLC) in a number of ways. Windows support for BLE is such that you can set up a BLC serial port and provided your BLC device is running a serial port acceptor you are golden. BLE is not well supported and, to make things worse, much of the documentation around it appears to be wrong. Microsoft’s own sample project, for example, only works if you “pair” the BLE device, however, you can’t pair a BLE device on Windows 10 so the sample project doesn’t work.

I am working with the ESP32-C3 and while Espressif provides all sort of sample code the ESP32-C3 is not yet well supported. I can’t get the BLC examples to compile for ESP32-C3 and the BLE samples which do compile are ble_spp_server and ble_spp_client, which are meant to talk to each other. My current project requires 2 ESP32-C3s, GPS, and LORA, with one of the ESP32-C3s acting as a gateway to an Android device. For battery reasons it made a lot more sense to connect to Android using BLE instead of WiFi.

When working with embedded devices I find it much easier to get things working on a PC (hardware permitting) and then port things over to my own hardware. I didn’t want to try and learn/program/debug 2 ESP32-C3 boards + Android, especially since my first task will be to debug the hardware. BLE is apparently well supported under Android and Linux using the Bluez stack. Unfortunately, it does not appear there is a Bluez stack for Msys2, or at least I could not find one. I use my PC for other things and did not want to have to install Linux on it at this time.

That meant that I would have to get a BLE Serial Client going under Windows. Since there is no reason why I’d want a GUI application on Windows (remember my first task is hardware debug) I wanted to use a simple console application. I figured that would be easy: surely there would be sample code all over the place and, failing that, how hard could it be. It turns out there is very little BLE sample code available, that which is available either does not work (recall, Microsoft’s own example doesn’t work) and/or is written in C#. After a lot of trying, I found two examples:

1) BLEConsole, which works but is written as a debugger tool and is in C# (see https://github.com/sensboston/BLEConsole) and

2) This Stack Overflow thread https://stackoverflow.com/questions/67934095/trying-to-create-a-gatt-client-application-for-windows-c-that-doesnt-fail-whe post, which doesn’t work, or at least doesn’t work with esp_spp_server even with modification.

Unfortunately, Microsoft’s documentation on its BLE API is of Byzantine complexity and starts with the assumption that you already know how everything works. The few examples it give are of very narrow applicability and, as I noted, their GUI application literally does not work.

I know I am not a particularly competent c++ programmer, and in particular I know next to nothing about Windows API programming. Therefore I am sure this is not an example of how things should be done, but it works and should be useful as a starter.

Known Problems and Limitations:

1) I haven’t figured out how to re-attach a BLE device if connection is lost. You need to re-start the code. Since this is intended for debugging purposes it should not be a problem;

2) If you stop and then restart the client quickly, it appears the server (ESP32-C3) still thinks there is a connection and the client won’t connect. Usually it figures it out after a while but if it doesn’t, restart the ESP32 and the client.

I would be delighted if anybody could help me solve these problems, especially the first one, because I think it is related to the second.

The software currently supports only a single BLE device, one read and one write UUID (see below). It should be easy to expand this to mulitple BLE devices and/or mulitple read or write UUIDs, however that was not my requirement.

BLE Client Outline

The ESP32 ble_spp_server_demo sets up a device name “ESP_SPP_SERVER” as well as

1) BLE Service with a UUID of 0xABF0 and

2) Characteristic UUIDs of
DATA_RECEIVE 0xABF1
DATA_NOTIFY 0xABF2
COMMAND_RECEIVE 0xABF3
COMMAND_NOTIFY 0xABF4

(UUIDs are of the form 0000xxxx-0000-1000-8000-00805f9b34fb where xxxx is the 16 bit UUID)

A scan of the BLE device will report services of

[0] 0x1801 (GenericAttribute)
[1] 0x1800 (GenericAccess)
[2] 0xABF0

The client writes to the DATA_RECEIVE UUID and is notified via the DATA_NOTIFY UUID and the server writes to DATA_NOTIFY and reads from DATA_RECEIVE.

The BLE Client starts up a Windows scanner (ScanForBLE::ScanDevices()) which populates vector<BLEDeviceData> deviceList as it discovers nearby BLE devices. The BLE device (i.e. SPP_SERVER) is identified by a unique name (“ESP_SPP_SERVER”) and MAC (which is 98:3b:8f:dd:f4:d1-7c:df:a1:66:a6:3d in my case). Windows refers to this as deviceList.name and deviceList.id. Only unique deviceList.name and deviceList.id combinations are added to deviceList. If there is more than one device with the same name you will have to come up with a way to select which one(s) you want to access. BLE Client assumes only a single BLE device named ESP_SPP_SERVER.

Once a ESP_SPP_SERVER device is discovered, an effort is made to discover the service with UUID 0xABF0 and if that is found the associated characteristics are collected. The UUIDs of the characteristics and their properties will be listed and once this is complete you should be able to read/write the characteristics.

Properties abbreviations
B Broadcast
R Read
w WriteWithoutResponse (used by ESP32 SPP Server for writing)
W Write
N Notify (used by ESP32 SPP Server for reading)
I Indicate
A AuthenticatedSignedWrites
X ExtendedProperties
E ReliableWrites
Z WritableAuxiliaries

You write to the ESP_WRITE_DATA_UUID and (indirectly) read from ESP_READ_DATA_NOTIFY_UUID. The read function is asynchronous (like an interrupt) so the data essentially just appears in a queue called RXDataBuffers. The size of the received packets is not restricted but the number of packets in RXDataBuffers is limited to 10 at the moment.

C Language Interface

There are five functions involved.

1) int StartBLEDeviceServices(char* BLEDeviceName, uint16_t ServiceUUID,
uint16_t WriteUUID, uint16_t ReadUUID,
uint16_t MaxWait);
returns 0 if successful.

2) bool SendData(uint16_t DestUUID16, uint8_t* data, uint16_t size);
returns true if successful;

3) unsigned GetRXData(uint8_t* RXData, unsigned RXMax);
returns number of bytes received. RX data is copied to a uint8_t array of size
RXMax. Note that binary data is exchanged so if you want to print a string
you have to zero terminate (or ensure the sender sends the zero).

4) bool CheckActiveBLEConnectionStatus(void);
returns true if the BLE connection is still active. It takes about 10 seconds for
the connection to be lost.

5) unsigned ListDevices(bool show);
print a list of currently connected BLE devices, service UUIDs, and
characteristic UUIDs.

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.

Limitations

• 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

USB_SERIAL_STREAM.flags = _FDEV_SETUP_RW;

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

USB_Serial.c
USB_Serial.h
USB_Serial_example.c

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"

to

"CDC ASF"

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

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

Geographic annotation has been merged into Kicad! The function can be accessed in PCBNew under tools -> Reannotate PCB.

Note that the master branch is targeting V6 and that means some file format changes and, as usual with unreleased software, there may be bugs, including in the reannotate tool.

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

https://gitlab.com/BrianAtDocumentedDesigns/kicad/commits/reannotate

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
-Xmx1024m
to
-Xmx2048m
Or
-Xmx4096m

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

Alternatively,

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_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
-DMSYS=TRUE \
../kicad-source-mirror-master

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
/home/kicad-source-mirror-master/eclipse-kicad

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.

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;
return(retval);
}

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.