But that’s underselling it.

Because under the hood, this thing is a fully capable STM32 development board that just happens to have industrial-grade differential transceivers attached.

And that changes everything.

The Core: A Real MCU, Not a Bridge Chip

TouCAN Probe is built around the STM32F042C6Tx — not a USB bridge, not a fixed-function CAN controller.

That means:

• Native USB FS device
• Flexible firmware architecture
• Direct control over peripherals
• Access to GPIOs
• SWD programming header
• Real-time performance under your control

This isn’t a “dongle.”
It’s an embedded system that ships as a tool.

It’s a Development Board in Disguise

Because the MCU is fully exposed and programmable, TouCAN Probe can double as:

• A general STM32 development board
• A USB device prototyping platform
• A CAN firmware sandbox
• A serial protocol analyzer
• A bus traffic generator
• A custom USB instrument

You have access to:

• USART (PB6/PB7 exposed)
• GPIOs via headers
• Boot configuration pins
• SWD for full debugging access

Need a quick USB-controlled relay?
Need a CAN bootloader test platform?
Need a custom USB descriptor experiment?

You already have the hardware in your hand.

Could It Be an ST-Link?

The fun thought experiment:
With the right firmware, could TouCAN Probe act as an ST-Link compatible programmer?

The STM32F042C6Tx absolutely has the capability to implement:

• SWD signaling
• USB composite devices
• Debug transport protocols

An official ST-Link uses a more powerful STM32 variant, but architecturally there’s nothing preventing a firmware implementation of a CMSIS-DAP or similar debugger stack on this hardware.

Meaning:

• It could program other STM32 targets
• It could become a debug bridge
• It could act as a USB-to-SWD tool
• It could be a lab emergency programmer

The hardware already exposes the right primitives.

That’s the beauty of building your own tools.

Mode Switching: Intentional and Clean

At reset:

• JP4 closed → USB enumerates as CDC (USART1 → RS-422/485)
• JP4 open → USB enumerates as GS_USB CAN

After reset, jumpers can be reconfigured freely.

Default RS-422 full duplex:

Short JP3 & JP4

And when in CAN mode, USART1 (PB6/PB7) is still accessible externally.

So even in “CAN adapter” mode, you still effectively have a development board with serial IO available.

Hardware That Supports the Ambition

This isn’t a breadboard hack.

CAN transceiver: SN65HVD230
RS-485/422 transceivers: SP3485EN (x2)
LDO: MIC5504-3.3
Board: 4-layer FR4 (~1.6 mm)
EDA: KiCad 9

You get:

• Controlled impedance routing
• Solid ground planes
• Clean USB layout
• Industrial-grade differential signaling
• Production-ready manufacturing files

It’s engineered like a deployable product — not just a lab experiment.

Endless Possibilities

When you combine:

• Native USB device
• CAN + RS-485 + RS-422 hardware
• Exposed GPIO
• SWD header
• Bootloader access
• Open hardware design

You get a platform that can evolve.

Today:

• USB-to-CAN
• USB-to-RS-485
• USB-to-RS-422

Tomorrow:

• Custom CAN protocol analyzer
• Firmware-based CAN bridge
• USB composite device (CDC + CAN)
• Field firmware updater
• Bus intrusion test tool
• Portable automation interface
• Emergency ST-Link-style programmer

Or something no one has thought of yet.

Why This Is Actually Cool

Most adapters are fixed-purpose appliances.

TouCAN Probe is a tool platform.

It reduces lab clutter.
It collapses multiple dongles into one device.
It exposes its internals instead of hiding them.
It invites firmware experimentation.

And if you’re the kind of engineer who likes understanding — and controlling — your tools, that’s the real win.

Because the best hardware tools aren’t just interfaces.

They’re multipliers.

Some projects exist purely to answer the question “what if?” — and this one certainly qualifies. Over the past year, I’ve been slowly pushing a modular SDR design further and further, and this time I decided to do something that probably shouldn’t work at all: connect a modern 20 MHz, dual 10-bit ADC directly to a 50-year-old 6502 CPU.

Buy one here: https://www.imania.dk/samlesaet-hobbyelektronik-og-ic-er-phaselatch-20msps-adc-no-ram.htm

Hardware source: https://github.com/AndersBNielsen/PhaseLatch

Previous parts of the series: https://abnielsen.com/2025/09/06/phaseloom/

The motivation came from earlier iterations. First there was PhaseLoom, which relied on a sound card for digitization. Then PhaseLatch Mini, using a cheap microcontroller with dual ADCs, managed to push a bit over 200 kHz of bandwidth into a PC. But from the start, I knew I wanted something more fundamental — something that interfaced directly with the CPU bus itself.

Enter PhaseLatch: an ADC board designed to be memory-mapped straight onto the 6502 data bus. The ADC I settled on turned out to be oddly perfect for the job: parallel output, straight binary, dual channels muxed onto the same pins — and suspiciously inexpensive. Whether it’s a clone or a second source, it enabled single-instruction ADC reads on a processor running at 1–2 MHz.

Of course, theory and reality rarely align. While the ADC is capable of 20 MSPS, the 6502 most certainly is not. Add in real-world issues like RAM expansion mistakes, rotated footprints, bus timing, and bit-banged clocks, and the project quickly became an exercise in humility.

Still, something remarkable emerged. By adding external RAM and implementing Goertzel’s algorithm, I managed to perform real DSP on the 6502 itself — detecting tones from RF signals mixed down to baseband. It’s about the simplest form of SDR that still earns the name, but it works.

This project isn’t about achieving record-breaking bandwidth. It’s about understanding limits, embracing constraints, and discovering just how much can still be done with hardware that predates most of us. Sometimes, doing things the hard way is the whole point.

Source code and design files: https://github.com/AndersBNielsen/PhaseLatchMini

If you’d told me a few years ago I’d be designing and building my own modular Software Defined Radio platform, I’d have laughed. Radio has always felt like electronics magic to me—no matter how much I learn, the sense of wonder never goes away. In the previous video, we explored the bare-minimum concept of an SDR: mixing a radio signal down to IQ baseband and handing it off for digital processing. And yes, I did that with a 50-year-old CPU, the 6502.

For a quick refresher on what SDR means at the circuit level, check out the first video in this series. Back then, my 65uino didn’t have a usable ADC, so the only real option was the classic 1990s approach—pipe the baseband into a computer sound card. In 2025, that makes it one of the lowest bandwidth SDR setups imaginable: stuck at 44.1 kHz, which is roughly 1/72 of what a cheap RTL-SDR can do. It can’t even decode FM. And since my long-term goal is far beyond a few megasamples per second, I needed something better.

Before jumping into high-end territory, I wanted to explore an affordable middle ground. Enter the STM32 “Blue Pill”—a dirt-cheap board I’d had sitting in a drawer for years. Despite its price, the STM32F103 MCU has a surprisingly ideal feature set for SDR use: USB, DMA, and, crucially, dual ADCs that can sample simultaneously. That last part is essential for properly digitizing I/Q channels, and it’s something many MCUs lack.

My expectations weren’t high, but after experimenting with the dev board, I got enough usable bandwidth to justify designing my own custom board. Huge thanks to this video’s sponsor, JLCPCB, who handled fabrication and assembly. I’ve used them long before ever being sponsored—they’re affordable, fast, and the boards come out great every time.

Since ADC performance depends heavily on layout, I upgraded the board to include a proper ground plane and clean separation between the sensitive analog input and noisy USB lines. The design is simple: capture I and Q through a passive LC low-pass filter for anti-aliasing, then feed them straight into the MCU’s ADCs.

After verifying power rails, programming via SWD, and confirming the 8 MHz clock, I wired the board into my existing PhaseLoom IQ mixer. A single USB cable powers everything. Connected to my 40-meter antenna, the system immediately picked up AM, CW, and FT8—though with some aliasing and imperfect image rejection. Increasing the gain in the mixer helped, but only after carefully matching resistor pairs to avoid I/Q imbalance.

Once the hardware side looked solid, I tackled the firmware. The result is the PhaseLatch Mini: an STM32-based direct-conversion SDR front-end paired with simple Python host scripts. GQRX reads samples through a USB FIFO, and tuning is handled on the hardware side through the si5351 synthesizer. With this setup, I was able to cleanly receive HF, FM broadcast, and even experiment (with mixed success) around 144 MHz.

The PhaseLatch Mini isn’t the final destination—it’s a fun and capable side project on the path to a much more advanced 6502-powered SDR. But it’s already a surprisingly usable 200 kHz-bandwidth receiver, and I’ve made boards, kits, and files available for anyone who wants to experiment.

If you’re curious or want to dive deeper, come hang out on the Hackerspace Clubhouse Discord. More samples and a sneak peek at what’s next are at the end of the video up top.

Discord: https://discord.gg/kmhbxAjQc3
Buy a PhaseLoom and PhaseLatch Mini at my store iMania.dk

Source code and design files: https://github.com/AndersBNielsen/PhaseLatchMini

Part 1: A 6502 Software Defined Radio (video), PhaseLoom Github project, this post, buy one here
Part 2: 6502 + STM32 join forces as cheap SDR! (video), PhaseLatch Mini (Github), Building the “PhaseLatch Mini”: A Detour Into Modular SDR Design (blog post), buy one here

Part 3: 6502 + 20MHz ADC!

I just built what might be the coolest gadget of the year: a Software Defined Radio (SDR) powered by none other than the legendary MOS Technology 6502 CPU. And the timing couldn’t be better – this chip turns 50 years old on September 8th!

If you already know what SDRs and 6502s are, your jaw may have just dropped. But if not, don’t worry. I’ll catch you up.

The source code for everything is on Github: https://github.com/AndersBNielsen/PhaseLoom
You can also jump straight over to my store and buy one: https://www.imania.dk/index.php?currency=EUR&cPath=204&sort=5a&language=en

What’s an SDR Anyway?

Think of an SDR as the Swiss Army knife of radios. Instead of filling a workbench with dedicated devices, like a garage door opener, a satellite receiver, and a shortwave set, you just plug in an SDR and let software do the heavy lifting. Tuning, filtering, demodulating is all handled by code.

With an SDR, you can:

• Pull down data from satellites
• Decode airplane transponders
• Listen to ham radio or shortwave broadcasts
• Experiment with frequencies you didn’t even know existed

They come in all shapes and sizes, from cheap USB dongles to professional-grade equipment worth thousands. Some just receive, others transmit. But they all share the same principle: turn analog radio waves into digital data, then let software handle the magic.

And the 6502?

Ah, the 6502. This little 8-bit CPU powered the Apple I & II, Commodore 64, Atari consoles, and even the NES. For many, it was the chip that introduced the world to affordable personal computing. And now, half a century later, it’s back—this time running the front end of my homemade SDR.

Meet the PhaseLoom

I call my creation the PhaseLoom: a Quadrature Sampling Detector Phase-Locked Loop SDR frontend. Don’t worry about the jargon—what matters is that it’s a custom circuit that converts radio signals into the digital I/Q streams needed for software processing.

In practice, it works like this:

RF Frontend – A simple low-pass filter to clean up incoming signals.

Quadrature Sampling Detector – Uses clever switching to split the signal into in-phase (I) and quadrature (Q) components.

Local Oscillator – Generated by an SI5351 clock chip, controlled by 6502 assembly code.

Output – The I/Q signals can be piped into a sound card, oscilloscope, or eventually a higher-speed ADC for real SDR processing.

When I first powered it up, I wasn’t sure what to expect. But sure enough, with an antenna hooked up, I could tune into the 40-meter ham band. It’s rough, noisy, and very much a prototype—but it works. A 6502-powered SDR is alive.

Why This Matters

Most SDRs today rely on powerful modern processors or FPGAs. Running one from a CPU designed in 1975 is absolutely ridiculous—and that’s exactly why it’s so fun. The 6502 may not be doing the heavy DSP (yet), but it’s orchestrating the whole show. And with more development, I plan to push it further—maybe even squeezing in some real signal processing routines on that ancient silicon.

The Road Ahead

This is just the beginning. Better filters, wider bandwidth ADCs, and smarter software are all on the horizon. And yes, the PhaseLoom will be open hardware—schematics, code, and boards are already available.

The 6502 started a revolution 50 years ago. Today, it’s tuning in the airwaves. And I can’t wait to see how far this project goes.

For now you can buy one here: https://www.imania.dk/index.php?currency=EUR&cPath=204&sort=5a&language=en

Source and documentation on Github: https://github.com/AndersBNielsen/Universal-Serial-Adapter

The Origins of the Word “Hacker” and a Universal Serial Adapter for Modern Tinkering

Have you ever wondered where the term “hacker” originated? It’s a fascinating journey that’s far removed from the modern association with cybercrime. While working on my latest project—a Universal Serial Adapter—I found myself reflecting on this word’s history and how it ties back to the essence of ingenuity and hands-on innovation.

The Historical Roots of “Hacker”

The term “hacker” first appeared in the 1950s, linked to the MIT Tech Model Railroad Club. These pioneers weren’t cracking passwords or infiltrating systems; they were enthusiasts modifying electrical circuits and railroad systems. According to records from a 1955 meeting, students were advised to turn off power before “hacking on the electrical system.” This suggests that hacking, at its core, involved physical tinkering—sometimes literally with hacksaws—to modify and improve systems.

This origin reflects a time when printed circuit boards (PCBs) were expensive, and modifications were often done by hand. This hands-on spirit of experimentation resonates deeply with the work I’ve been doing, and it’s a mindset I’ve aimed to embody in my latest project.

Introducing the Universal Serial Adapter

The Universal Serial Adapter is a tool designed for flexibility and ease of use. It features:

• USB-C connectivity on one end,
• UART control signals for interfacing with microcontrollers, and
• An RS-232 (COM) port for compatibility with older systems like the IBM PC AT from 1984.

This adapter bridges the gap between decades of computing technology, making it useful for both vintage computer enthusiasts and modern developers working with microcontrollers.

Why Build It?

There are plenty of USB-to-serial adapters on the market, but I wanted something more hackable and modifiable. Most commercial options are encased in epoxy, making them difficult to tweak. By creating an open-source, modular design, I’ve ensured this tool can adapt to various use cases. For example, it’s perfect for testing connections or experimenting with PCB designs before committing to a final product.

The Hackability Factor

One key feature of the Universal Serial Adapter is its configurability. Traditional RS-232 setups often require null modem adapters or crossover cables, which can complicate signal flow and control signal pass-through. To simplify this, I designed jumper blocks that make configuring the polarity straightforward. Here’s how it works:

• Signal pairs are placed in jumper blocks.
• Horizontal jumpers configure straight connections.
• Vertical jumpers cross over the signals (e.g., RX/TX, CTS/RTS).

This intuitive approach eliminates the need for external adapters and ensures the control signals are handled correctly, improving connection reliability.

Modern-Day Circuit Board Innovations

Unlike the expensive PCBs of the 1950s, modern manufacturing has made prototyping affordable. For this project, I relied on JLCPCB, whose sponsorship allowed me to experiment freely without breaking the bank. If you’re interested, new customers can get coupons for their first order, and I’ve linked the details in the description. With their service, you can get six-layer PCBs for as little as $5—a dream for hobbyists and professionals alike.

Open Source and Community Contributions

This project is 100% open source. All design files and schematics are available on GitHub, so you can customize the adapter or use it as inspiration for your own projects. I’ve also integrated ideas from the community. For instance, the jumper configuration technique was inspired by contributions from CommodoreZ and TechAV, showcasing the collaborative spirit of the maker community.

Beyond the Basics

The adapter is built for flexibility:

• Modular Design: It can be snapped apart into separate components using a clever combination of vias and notches, offering sturdiness and convenience.
• Compatibility: It works with both modern computers and vintage hardware.
• Advanced Features: The RS-232 chip includes a sleep mode for power efficiency and can be manually woken up when needed.

For breadboard enthusiasts, the adapter plugs directly into standard boards, making it easy to prototype new circuits. If you need just the RS-232 functionality, you can separate it from the USB-to-serial chip and use it independently.

Performance and Testing

During testing, the adapter surpassed expectations, achieving data transfer rates of over 1 megabit per second without errors. This performance is impressive given the datasheet ratings for the components. A Python script I wrote for testing is also available on GitHub, so you can replicate or adapt the setup for your own needs.

Looking Ahead

This project is part of a broader effort to upgrade my 6502-based single-board computer, the 65uino, to include USB-C and built-in UART. The Universal Serial Adapter was born out of a need to test these new features, but it has evolved into a versatile tool in its own right.

Join the Conversation

If you have questions or want to share your own projects, feel free to join the discussion on my Hackerspace Clubhouse Discord server. The Universal Serial Adapter is already available in my store, and I’m always happy to hear feedback or ideas for future improvements.

Let’s keep the spirit of hacking alive—whether it’s with a soldering iron, a hacksaw, or just a curious mind. Thanks for reading, and happy tinkering!

UPDATE: The 65uino is now available as a kit with SMD parts presoldered from my own store, iMania.dk

The 65uino is a 6502 based learning platform in a familiar form factor. It has a 6507 CPU, a 6532 RIOT chip and a 28 pin ROM as the core components and aims to teach assembly programming, computer engineering and embedded design by opening up the black box of modern MCU’s.

By going back to a time where the integrated circuits each mostly did their own thing, the 65uino hopes to give a better and faster understanding of the basic concepts that’ll typically be abstracted away nowadays.

The project is 100% open source and you’ll find all the details over on hackaday.io so check it out and follow along!

Are you looking for the Relatively Universal ROM programmer? Have a look at https://github.com/AndersBNielsen/Relatively-Universal-ROM-Programmer
You’ll also find that kit with SMD parts presoldered from my own store.

65uino-related videos

If you’re new to the 65uino, you might want to check out the videos below as explain how the 65uino came to be, and how it works, step by step.

First, it started out on a breadboard…

Then it shrunk and learned to do I2C…

Then it got a screen…

…and a bootloader…

Learned to control a Raspberry Pi…

Got a graphics upgrade…

Figured out all kinds of serial flow control…

Got given away for free…

Studied to become a ROM programmer…

…graduated with honors!

…and more is coming very soon @ https://www.youtube.com/c/AndersNielsenAA

When even the co-author of the FastLED library, Mark Kriegsmann, says it’s can’t be done, you know it’s not going to be easy. “The CPU would need to be at least 20X faster to support them[WS2811 based LED’s], and it isn’t.  For that you want an Arduino or Teensy[…]”, as he puts it.

The WS2812B protocol is very simple. Basically it’s a binary PWM signal. Said another way: A long high pulse followed by a short low period for a 1 and a short high pulse followed by a long low period for a 0, and just a long period of nothing to latch the data and turn on the LED.

That looks easy right? Just toggle a pin at the right interval and it works, right? Well – it is, if you’ve got a fast enough processor. Looking at the numbers though, there isn’t enough time to do much toggling when running at 1 or 2Mhz – let alone varying the periods.

At the very “slowest” the high+low period must be 1.825 microseconds, or just about 500khz minimum. Maybe it’s possible to toggle a 6502 pin at 500khz, but it certainly isn’t possible to squeeze NOP’s in there to vary the period or do any kind of processing to change colors. So maybe Mark is right and you actually do need a faster processor?

Luckily it turns out, this isn’t the case. The 6502 is perfectly capable of controlling a string of WS2812B’s, a.k.a. Neopixels. Just like everything else you might want to interface the 6502 to though — the RGB LED’s need a little bit of help.

In this case all we need is a 6522 VIA, which is part of most 6502 computers anyway, a 74hc14 inverter, and a 74hc165 parallel-in serial-out shift register, along with an 8 Mhz clock and some passives.

To be fair, this does mean running the 6502 at 2Mhz(Note: Not 8 Mhz), which would be slightly problematic for the Apple II, but perfectly doable for many or most other 6502 based computers.

As luck would have it, my own 6502 single board computer has an 8 Mhz clock output available and is already running happily at 2 Mhz, which takes the hard work out interfacing with the LED’s – only two extra IC’s needed.

The schematic

The circuit takes a shift clock and serial data from the 6522 shift register. CB1 is the clock and CB2 is the shifted data. CB1 is normally high until it starts clocking out data, which keeps the ~CE(chip enable, active low) pin high through R2. When CB1 goes low the first time, C2 immediately discharges through D1 (I used a 4148) and ~CE is activated. This arrangement keeps the shift register active while data is shifted.

At the same time the signal from CB1 is also fed through the U1A inverter, a simple RC filter, and another inverter, giving the ~PL(load register pin) the short negative pulse needed to latch the data being clocked out from the 6522 shift register. If the pulse is too long, we miss the first bit.

Now we get to where the magic happens – the serial binary data is converted to WS2812-style PWM data. Since D7 is always high and D0-D4 is always low, this varies the high period of the signal by putting the data on pins D5 and D6.

The latched data is then clocked out to Q7 at the rate of 8 Mhz, fed to the CP pin and this is then fed directly to the WS2812B data pin. This means the 6522 supplies data at a comfortable rate of 1 Mhz and the 74HC165 shifts out the converted data at 8 Mhz, which means the bit rate is right around 1bit per microsecond. As you can see this is well within the 1.25us+-600ns in the datasheet.

We’re actually closer to going too fast than too slow, but halving the clocks to 500KHz and 4 Mhz would make it 2 microseconds pr bit – out of spec that says max 1.825 microseconds.
Maybe – just maybe – this could actually work on an Apple II since it has a slightly higher clock than 1Mhz @ 1.023Mhz, but you would then need to make a 4x frequency multiplier for the shift register CP to match input and output.

But wait… 3/8 is only 375ns, right? That would be a 0 signal, right? And 1/8 is only 125ns? Well – in my case I seem to have either stray capacitance on Q7 or something else messing with the timing – somehow using more than two pins for the data gives me a T1H period way longer than what we’re aiming for here – essentially making every bit a 1. Maybe a pulldown resistor on Q7 would make things more consistent – either way I chose to leave things the way they are simply because they work.

The code

The code below is a simplified modification to the current state of my 6502 firmware – my favorite compiler for the 6502 is cc65. Since I’m not sure I’ll merge the change, I’m leaving it here for now – untested, but contains everything needed to get it working. Assume a CC BY-NC license for now.

Sending a color to an LED on the string is as simple as just sending them in the right order with a delay that’s long enough to make sure the 6522 shift register finished shifting before sending another byte – the WS2812B expects colors in GRB order. 24 bits in total per LED.

When we’re done putting colors on the LED string, all that’s left to do is just to wait 50 microseconds, so the string latches the data (updates).

Essentially this means we have 100 clock cycles (at 2 Mhz) available to manipulate LED data even while we’re sending pixels. As long as we’re sending the next 24 bit LED data before the 50 microseconds have passed, we can keep using time between LED’s for as many LED’s as we need.

100 clock cycles is more than enough to rainbow the LED’s and most other simple processing.

;Variables used besides 6522 registers, ACR & SR affected here
; WS2812B variables
GREEN = $20
RED = $21
BLUE = $22
PIXELS = $27

main:
          LDA #%01011000
          STA ACR             ; 6522 ACR register T1 continuous, PB7 disabled, Shift Out Ø2
          lda #40 ; This is how many pixels I'm using.
          sta PIXELS
          jsr sendpixels ; This should clear LEDs on reset if RAM has been 0'd out - random color otherwise. 

    sendpixels:
      ldx PIXELS
    sending:
      sei ; Getting interrupted breaks the timing
      jsr sendpixel
      cli
      dex
      bne sending
      jmp halt ; Done

    sendpixel:
      lda GREEN
      sta SR1
      jsr eznop
      lda RED
      sta SR1
      jsr eznop
      lda BLUE
      sta SR1
      jsr eznop
       rts

      eznop:
         rts

      halt:
      jmp halt ; Loop forever here

Conclusion

As you can see, the 6502 is perfectly capable of rainbowing a string of individually addressable RGB LED’s – it even has time to spare. Previously I’ve managed to run one of these LED strips at 4 Mhz(out of spec though), but I’m happy to report it’s possible to go even lower with this approach.
In a pinch you could use the same trick with an Arduino at lower clock speeds – all you would need is a second ‘165 shift register to have the Arduino output a whole port at the same time ( PORTA = RED; NOP x 7 etc.)

What do you think? Cool experiment or waste of time? I’d appreciate a comment here or on Youtube.

Hint: Gallery the bottom of this post!

So.. What can it do? Blink lights? Well yes.. and so much more.

Even though it has it’s limitations, there’s actually a lot you can do just by bitbanging with an 8Mhz microcontroller. As you can see in the screenshot from the IDE below, it’s actually meant to work with a bunch of peripherals – even though there is no hardware support for any of it.

Of course there’s a couple of very smart people over on the EEVBlog forum working hard at making an open toolchain for these chips, but I decided I couldn’t wait to get started and stuck with the manufacturer IDE, ICE and programmer.

To get the most out of the tools at hand, the IDE seems to expect you to use a mix of plain C, macros and assembly instructions, all mushed together in some pretty interestingly looking code. I’m probably not going to be popular for saying this but it actually feels very intuitive when you get used to it. It’s weird, but it’s “fun”.

After my initial mandatory “blinky tests” I decided to try something slightly more useful – controlling a WS2812B LED. Since the protocol itself relies on bitbanging with pretty tight timings, I figured this was a good test.

Before we move on, here’s the spoiler! Success:

But how? Adafruit’s Arduino-library uses 3 bytes of RAM for every LED so how do you run 300 with just 64 bytes of RAM?

Turns out there’s a simple solution to this problem: Don’t put every LED in RAM.
Since the timings of the WS2812B’s aren’t that tight, there’s actually room for a lot of spare cycles between sending the 24bit value for each LED. Basically just do the logic on the fly, instead of storing each LED in RAM. The only downside is you can’t just change a single LED value and leave the rest.

The logic for controlling the LED’s is pretty simple once you wrap your head around it. Send 24 bits for each LED and end with a delay long enough to make the data latch. In this case, keep each bit around 1.25uS, a “0” is a short high, followed by a “long” low and a “1” is a long high followed by a short low. So simply: High->Low 24 times. Long high for 1, short high for 0.
Here’s a snippet from the datasheet:

The +/- 150ns was plenty of headroom in my case, with the PMS150C running at 8mhz. Same is the case with the +/- 600ns for each bit. I expect I could’ve easily run 3000 LED’s instead of 300 – but I didn’t have the power supply for that much heat lying around

Tim “cpldcpu” wrote a detailed post about it back in 2014 but either things changed since or he got the details wrong, because in my tests a RES signal needed to be at least 50uS and when experiencing glitches, the longer the reset signal, the better.
I have a feeling I would’ve never done this project if I hadn’t seen Big Josh’s post about how simple the protocol actually is but sadly his code needed some serious manipulation to port to the Padauk IDE, so I ended up rewriting it completely from scratch with the WorldSemi datasheet in hand and a vague memory of what BigJosh did with it.
A big thank you for the inspiration to both Tim and BigJosh!

So.. What about the code?

Below is the minimum code I use to talk to the string of LED’s. There’s room for optimisation and I’m sure a bunch of it looks funny, if you’re used to seeing a plain C project on an AVR. First of all, the Padauk IDE is a little bit fuzzy when it comes to data types. There’s no such thing as a “long” and it seems to me all types are unsigned by default – though I haven’t researched this thoroughly.
The only data types available in the Padauk IDE are:

• Bit (1 bit)
• Byte (8 bit)
• Int (8 bit(!))
• Word (16 bit)
• EWORD (24 bit)
• DWORD (32 bit)

The handy thing about the types though, is that the individual bits and bytes can be accessed by macros, without any fuzzing about with shifting them around.

For instance:
mybyte.4 = 0; //Clears bit 4 of mybyte
myEWORD$1 = mybyte; //Sets the middle byte of the 24 bit EWORD

Also, the builtin macros come very handy. See the below code. All the code needed to control the WS2812B’s are contained in the macros “send1”, “send0” and the function SendRGB();

The SendRGB() function is a prime example of Padauk IDE weirdness, containing both assembly instructions, macros and plain old C. But what can I say: It works. I probably could’ve shifted the rgb EWORD x in a while loop(more efficiently than the 24 macro if’s) but I decided to try out the macro and it was more than efficient enough for this purpose. The rest of the code(which I haven’t included here) is basic manipulation of the r,g & b values followed by a show(); to set the right colors. Leave a comment if you want to see, and I’ll throw the complete project on github.

After popular demand, the complete source is available here:
https://github.com/AndersBNielsen/pms150c-projects

byte red, green, blue; //Could save these three RAM bytes by using the rgb EWORD directly ( rgb$0, rgb$1, rgb$2)

EWORD rgb;

word pixels; //Only has to be a word if number of pixels > 255
define definedPIXELS 300;

send1 MACRO
SET1 LED;
.DELAY 5; //Around 0.85uS
$ LED low; //Same as SET0 LED;
// .DELAY 1; //Going around is enough delay 1.25uS in total
ENDM

send0 MACRO
SET1 LED;
.DELAY 2; //Around 0.40uS
$ LED low;
.DELAY 2; //With the loop around 0.85uS
ENDM

void SendRGB (void) {
DISGINT; //Let’s not get interrupted

.FOR bitno, <23,22,21,20,19,18,17,16,15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0> //Regular for() loop doesn't work, but at least the compiler can do the hard work

if (rgb.bitno == 0) {

send0;

} else {

send1;

}

.ENDM

ENGINT;
}

void show (void) {
rgb$0 = blue; //I lost track of MSB, LSB and endians.. This is what works.
rgb$1 = red;
rgb$2 = green;
SendRGB();
}

void clearLED (void) {
rgb = 0;
pixels = definedPIXELS;
do {
SendRGB();
} while (–pixels);
.delay 2000; //If you want to make sure the LED-reset is caught, use a longer one.
}

So.. Why would I choose this instead of a major brand MCU?

Obviously, the major selling point of this microcontroller is the price. At 3 cents each it’s ten times cheaper than the Pic equivalent(at 3000 MOQ) – the pic10f200(34 cents) or the ATTiny10(28 cents @ 4500 MOQ). //Digikey
Also, the customer service is far from bad – I got an email reply from Padauk within 12 hours.
The downside for the PMS150c is the OTP nature, the limited instruction set, and the sometimes curious and seemingly random IDE documentation – only partially translated into English. (Getting better with every release though from 0.84 to 0.86)
If you’re thinking about making a toy with an ATTiny10 in it and it doesn’t need to do a lot of heavy math – this might be able to do the same job for a tenth of the cost. That doesn’t mean I would be happy to see it in a pacemaker.

What else can it do?

My guess is: More than you’d think. I have a feeling my next project might involve controlling the nrf24L01+ SI24R01 2.4Ghz radio module or maybe a budget Raspberry Pi module.

Either way, please tell me what you think, point out my mistakes and let me know in a comment what you’d like to see me do with this thing in the future.

Of course there’s the minor problem that USBasp is designed for ATMega8/88 and to run at 12mhz but since it can run on an ATTiny85 I figured it couldn’t be that hard to port it to the ATTiny84, since both my business card and USBasp uses vUSB.

Turns out: It wasn’t bad at all. And in case my USBasp dies some day, my bizcard is now self replicating.

So. If you’re missing a programmer for ISP or TPI and you only have an ATTiny84 lying around, the code I just put on github should do the trick.

The downside, compared to my USBasp clone, is that it doesn’t support 3.3V, but the upside is that it’s actually more handy because of the micro usb connector, so I no longer need a USB extender cable or long jumper wires. And of course the BOM is hardly more expensive than the price of a chinese USBasp clone.

Also – I used it to finally upgrade the firmware on my old USBasp clone so that it now supports TPI. Expect to see some projects featuring the ATTiny10 soon

Have anything to say? Please leave a comment.

What I meant to say was: Don’t waste your time. I could’ve had these made for 50 cents each but instead I wasted my time. Lesson learned