Programming and Testing the UCMOD-0 with Arduino and UPDI
Today I finally got a chance to do some initial software testing with the UCMOD-0 and the Isolated RS485 Carrier Board.
Things went surprisingly well, all things considered, other than a ten-minute diversion trying to figure out why the obligatory “Hello World” LED blink sketch was failing to blink the LED on the carrier board.
Thankfully, the problem existed between the chair and keyboard โ me โ rather than with the hardware.
Programming the UCMOD-0#
I had two main options for programming the UCMOD-0: use my UPDI Friend with the Arduino environment, which is generally my go-to option for quick testing, or use MPLAB.
Unfortunately, I appear to have misplaced my PICkit programmer during the last workshop move, and the UPDI Friend isn’t directly supported by MPLAB. That made the decision fairly straightforward.
For these initial tests I didn’t need any advanced debugging capabilities anyway, so Arduino was more than sufficient. If I need to step through code in the future, I’ll either have to locate the PICkit or finally give in and order a newer one.
Serial debugging isn’t particularly convenient in this setup either. The ATtiny1614’s UART is being used as the primary communications interface for RS485, so I can’t simply dedicate it to debug output.
If I really need serial debugging, I could potentially bit-bang a simple serial interface using a couple of spare GPIO pins. Otherwise, I’ll need proper debugging hardware.
I’ll cross that bridge when I come to it.
Programming an ATtiny1614 with Arduino#
Using the Arduino environment to program the ATtiny1614 directly is actually fairly straightforward.
The main component required on the software side is megaTinyCore, which adds support for the modern tinyAVR devices to the Arduino environment.
For programming, I’m using an Adafruit UPDI Friend, although other compatible UPDI programmers can also be used.
First, connect the UPDI Friend to the PC over USB and then connect it to the programming header on the UCMOD-0.
In my case I’m currently using the three-pin header on the board while I wait for the Tag-Connect cable to arrive.
The three connections are simply:
- UPDI โ UPDI
- VCC โ 3.3 V
- GND โ GND
Once connected, the UPDI Friend appears as a COM port on the PC.
Installing megaTinyCore#
megaTinyCore can be installed through the Arduino IDE using the following steps:
Open File โ Preferences.
Add the following URL under Additional Boards Manager URLs:
http://drazzy.com/package_drazzy.com_index.jsonClick OK.
Open Tools โ Board โ Boards Manager.
Search for megaTinyCore and install it.
Under Tools โ Board โ megaTinyCore, select the group containing the ATtiny1614.
Select the COM port used by the UPDI Friend under Tools โ Port.
Under Tools โ Programmer, select SerialUPDI - SLOW: 57600 baud.
I started with the slower 57600 baud option simply because reliability is considerably more useful than programming speed while bringing up a new board.
The Traditional First Test: Blinky#
Naturally, the first program I uploaded was Blink.
It’s about as basic a hardware test as you can get, but it’s also a useful way of confirming that the microcontroller can be programmed successfully and that at least one GPIO pin is behaving as expected.
Arduino includes the standard example under:
File โ Examples โ 01.Basics โ Blink
I modified it slightly for the UCMOD-0 and carrier board:
// the setup function runs once when you press reset or power the board
void setup() {
// initialize PIN_PA5 as an output
pinMode(PIN_PA5, OUTPUT);
}
// the loop function runs over and over again forever
void loop() {
digitalWrite(PIN_PA5, HIGH);
delay(1000);
digitalWrite(PIN_PA5, LOW);
delay(1000);
}
There is only one real change from the standard Arduino example: instead of using LED_BUILTIN, I’m explicitly using PIN_PA5, which is the ATtiny1614 GPIO connected to the LED on the carrier board.
With the sketch uploaded, the LED should happily turn on and off every second.
Or at least it should if you actually remember to put solder across the normally-open solder jumper that connects the LED to the GPIO pin.
I did not.
Instead, I spent about ten minutes wondering why my newly assembled hardware wasn’t working before eventually noticing the open jumper.
Once that minor operator error was corrected, the LED blinked away quite happily.
Next Steps#
With basic programming and GPIO operation now confirmed, the next test is considerably more interesting.
I’ll connect another RS485 board and try sending a simple string between the two devices using the isolated RS485 interface.
That will start testing the UCMOD-0 and carrier board as an actual system rather than simply proving that I can make an LED blink.
- 2026-10-17 Refining the Protoworks service offerings Lab
- 2026-09-27 Belfast Tech Week Lab
- 2026-09-19 Refining the UCMOD Architecture R&D
- 2026-09-06 Giving AI Agents a Way to Talk to Protoworks Software
- 2026-09-03 A Morning at a Manufacturing Trade Show Lab
- 2026-09-01 Debugging 921600 Baud on the ATtiny1614 R&D