Today I managed to get a little time to test my PICkit 5 programmer with the UCMOD-0 module, mainly by porting the example code I had previously created using Arduino over to plain C using MPLAB in Visual Studio Code.

It isn’t quite working yet.

I can see the TX line flickering on the oscilloscope, and I already know that the receiver code works correctly from my previous test setup using a Raspberry Pi Pico 2 W. That narrows the problem down considerably.

At the moment I suspect either a clock timing issue or an incorrectly configured USART register somewhere.

The good news is that I can compile the application and send the resulting firmware to the ATtiny1614 on the UCMOD-0 using the PICkit 5 without any problems. That’s the part of the exercise I really wanted to prove.

Hopefully another half-hour or so at the bench should uncover the remaining problem and I’ll see the usual test message appear on the receiver.

Getting a Little Closer to the Hardware#

One of the interesting things about moving this example away from Arduino is seeing exactly how much work Arduino normally does on your behalf.

That’s not a criticism of Arduino — abstraction is largely the point of it.

Something like:

pinMode(pin, OUTPUT);
digitalWrite(pin, HIGH);

is considerably more convenient than working directly with the microcontroller’s registers.

When using plain C, however, you start getting much closer to the hardware. GPIO direction registers need configuring, USART control registers need setting correctly, baud-rate registers need calculating, and individual bits are manipulated using the usual AND and OR operations.

The same applies to things such as clock configuration and fuse settings.

There is something quite satisfying about working at this level because there is much less mystery about what the microcontroller is actually doing. If a pin becomes an output, it is because I explicitly changed the appropriate bit in a register. If the USART runs at a particular baud rate, it is because I configured the peripheral to do so.

Of course, the downside is that if I’ve calculated something incorrectly, the TX pin happily flickers away while the receiver gets complete nonsense.

Which appears to be where I currently am.

Once I’ve tracked down the remaining problem, I’ll post the working code here.

GCBASIC#

While browsing around today I also discovered something I’d somehow managed to miss until now: GCBASIC.

GCBASIC is a BASIC compiler aimed primarily at 8-bit microcontrollers, including PIC, AVR and Logic Green devices.

That immediately caught my attention.

Its syntax appears fairly familiar to anyone who has used traditional BASIC dialects such as QBASIC or FreeBASIC, and I still occasionally mess around with FreeBASIC for my own amusement rather than because I have any particular development requirement for it.

Sometimes the limitations of an older or simpler language actually encourage a bit more creativity.

QBASIC was also one of the languages of my youth many years ago, so I still have a soft spot for BASIC in general.

There is probably a direct line from messing around with BASIC back then to subsequently starting my professional software development career as a Visual Basic 6 programmer, writing business software for a small company in Aberdeen, Scotland.

Once I’ve fixed the current USART problem, I may try putting together a small GCBASIC program for the UCMOD-0, assuming the ATtiny1614 is supported cleanly enough.

It serves absolutely no pressing business requirement.

Which is probably a good enough reason to try it.

The LGT8F328P#

The other curiosity I stumbled across was the LGT8F328P from Logic Green.

This is an inexpensive 8-bit microcontroller that is heavily inspired by the ATmega328P and has become particularly well known through low-cost Arduino-compatible boards.

The ATmega328P, of course, is the microcontroller most closely associated with the classic Arduino Uno.

The LGT8F328P is often described as an ATmega328P replacement, although that description needs a little qualification. It has a very similar architecture and can run Arduino code with the appropriate support package, but it isn’t simply an electrically identical clone that can be substituted blindly into every ATmega328P design.

It does have some interesting capabilities of its own, however, including the ability to run at higher clock speeds than the traditional ATmega328P.

For an inexpensive 8-bit processor, it looks like another interesting device to experiment with.

The ATmega328P itself is now marked as not recommended for new designs by Microchip, with newer AVR devices providing considerably more peripheral capability. The ATmega328PB is another member of the family which maintains a great deal of software compatibility while adding additional peripherals, although it too has hardware differences that mean it shouldn’t simply be treated as a drop-in replacement.

Realistically, there are plenty of newer microcontrollers I would select before any of these devices when starting a completely new commercial design.

But that isn’t really the point.

The LGT8F328P is cheap, unusual, supported by Arduino and GCBASIC, and different enough from the devices I’ve been working with recently to make it interesting.

That’s normally enough to get something added to the experiment pile.

An Unfocused Day#

As you can probably tell, today was fairly unfocused.

Most of my time has actually been taken up with business administration — accounts, organising business cards for trade shows, and the other assorted jobs that come with trying to turn engineering projects into an actual business.

I therefore didn’t have a large uninterrupted block of development time.

But sometimes that’s just the way a day goes.

I proved that the PICkit 5 can program the UCMOD-0 using my MPLAB toolchain, got sufficiently far with the USART code to know that something is being transmitted, discovered a BASIC compiler for 8-bit microcontrollers, and found another strange little processor that I now want to experiment with.

Not exactly a wasted day.