The System Was a Chain of Responsibilities#

At a high level, the controller had to turn physical input into a radio command.

The path was conceptually:

1
Pushbuttons / switchbank / trimpot
2
        ↓
3
Command selection
4
        ↓
5
Command execution
6
        ↓
7
RCM state update
8
        ↓
9
Packet construction
10
        ↓
11
Hamming encoding
12
        ↓
13
TX queue
14
        ↓
15
nRF24L01+ radio
16
        ↓
17
Remote microscope

At the same time, the controller had local output responsibilities:

1
current command
2
    ↓
3
7-segment display
4
LED bar opcode
5
RGB status
6
diagnostic LEDs

That meant the design was not a single loop anymore. It was a set of cooperating state machines and FreeRTOS tasks.

My top-level flow separated startup, button events, command processing, packet construction, and radio transmission.

Lesson 1 - FreeRTOS Is Most Useful When It Defines Ownership#

It is easy to think that the reason to use an RTOS is simply to “run several things at once.”

That is only part of the benefit.

What I found more useful was that FreeRTOS encouraged me to decide which task owned each resource.

For example, the radio transmitter should be responsible for the radio.

The command-input module should not directly manipulate radio registers just because it knows that a packet needs to be sent.

Instead, the cleaner relationship is:

1
command task
2
    ↓
3
RCM system logic
4
    ↓
5
TX queue
6
    ↓
7
radio task

This creates a boundary.

The command task knows what should happen.

The radio task knows how to transmit it.

That difference became increasingly important as the project grew.

If every task can directly call every peripheral, then adding an RTOS can actually make the architecture harder to understand. Concurrency without ownership just creates more possible interactions.

Lesson 2 - Queues Are More Than Buffers#

The TX queue was one of the most important architectural boundaries in the project.

A packet producer could construct a command without caring whether the radio was currently idle, configuring its channel, waiting for the nRF24L01+ state machine, or loading a transmit FIFO.

The producer only needed to place a valid packet into the queue.

The radio side could then process packets at its own pace.

That turns the queue into a contract:

1
Producer guarantee:
2
"I will give you complete packets."
3

4
Consumer guarantee:
5
"I will transmit them in the correct radio context."

This is much easier to reason about than a design where command code immediately starts an SPI transaction.

It also makes failures easier to isolate.

If no packet appears on air, I can ask:

1
Was the packet created?
2
Did it reach the queue?
3
Did the radio task dequeue it?
4
Did the nRF24L01+ enter TX mode?

Each question belongs to a different layer.

Lesson 3 - The Radio Has Its Own State Machine#

The nRF24L01+ is controlled through SPI and exposes control registers, TX/RX FIFOs, a CE control pin, and several radio states.

The nRF24L01+ provides the wireless link while the MCU controls configuration and data transfer over SPI.

The module operates at 2.4 GHz and supports data rates up to 2 Mbps. SPI is used both for configuration and for moving payload data into or out of the radio FIFOs.

This is important because “send packet” is not a primitive physical action.

The software has to coordinate:

1
radio configuration
2
channel
3
address
4
FIFO state
5
CE control
6
TX state
7
return to idle

My radio-control FSM reflected that separation.

The radio path verifies configuration, handles JOIN ownership, and then processes command packets through dedicated states.

This project reinforced a useful rule for peripheral drivers:

If the hardware itself is stateful, pretending that it is a stateless function call usually makes the software worse.

A finite-state machine makes the legal transitions explicit.

Lesson 4 - JOIN Was Really an Ownership Protocol#

Before normal control packets could be accepted, the controller had to send a JOIN packet.

At first, this looked like just another command.

It is more useful to think of it as a distributed ownership mechanism.

The rule is essentially:

1
JOIN
2
  ↓
3
RCM associates control with this sender
4
  ↓
5
XYZ / ZOOM / BRIGHT commands become valid

Without a valid JOIN, the RCM rejects subsequent control packets.

This solves an important physical-system problem: multiple users should not independently move the same microscope at the same time.

That made the protocol feel much more real to me.

The packet is not only carrying data. It is establishing permission to affect a physical machine.

In a networked embedded system, protocol design and safety boundaries can become the same problem.

Lesson 5 - Packet Structure Should Be Stable Before the Tasks Become Complicated#

The project used a fixed radio packet structure with:

1
packet type
2
sender address
3
payload string
4
padding

A raw packet was 16 bytes.

Each half-byte was then Hamming encoded, producing a 32-byte radio packet.

Conceptually:

1
16-byte raw packet
2
       ↓
3
split each byte into two nibbles
4
       ↓
5
Hamming encode each nibble
6
       ↓
7
32-byte encoded packet
8
       ↓
9
TX queue

The major packet types included:

For an XYZ packet, the coordinates are expressed as decimal ASCII fields. That makes the payload relatively easy to inspect during debugging.

I liked the separation between semantic payload and radio representation.

The command layer can think in terms of:

1
X = 100 mm
2
Y = 0 mm
3
Z = 0 mm

while the packet layer is responsible for turning that meaning into the exact byte layout required on air.

That boundary is worth protecting.

Lesson 6 - Error-Correcting Codes Change the Way You Think About Interfaces#

Hamming encoding was another part that initially looked like a small implementation detail.

It became more interesting when I thought about where it belongs.

The command logic should not care that a nibble is being protected by an error-correcting code.

Similarly, the radio driver should not need to understand that the payload represents an X coordinate.

A cleaner stack is:

1
RCM command
2
    ↓
3
raw protocol packet
4
    ↓
5
Hamming encoding
6
    ↓
7
radio transport

Each layer transforms the representation while preserving the meaning.

This same idea appears in much larger communication systems.

Once I started viewing it that way, embedded networking became less about “sending bytes” and more about building a protocol stack, even if the stack is small.

Lesson 7 - Interrupts Should Wake Work, Not Become the Work#

Pushbuttons are asynchronous.

The tempting approach is to detect a button interrupt and immediately perform the entire action inside the interrupt handler.

That becomes dangerous when the action eventually includes:

1
state-machine updates
2
display changes
3
packet creation
4
Hamming encoding
5
queue operations
6
radio transmission

The better design is to let the interrupt communicate an event to a task.

My overall flow used FreeRTOS synchronization to move from a button event into task-level processing.

Button events are translated into synchronization signals that drive the higher-level command state machine.

This is one of the most important habits I took from the project.

An ISR should ideally answer:

“What happened?”

and then wake the code that decides:

“What should the system do about it?”

Those are different responsibilities.

Keeping that boundary clear improves latency, predictability, and maintainability.

Lesson 8 - A Command FSM Makes a Small User Interface Predictable#

The local user interface had only a few physical inputs:

• a command-selection pushbutton;
• an execute pushbutton;
• an 8-bit switchbank value;
• a trimpot for relative settings.

But those inputs could control several behaviours:

1
X
2
Y
3
Z
4
ZOOM
5
BRIGHT
6
ORG

A state machine was a natural way to map repeated CMD presses into a selected operation.

The command task separates selecting an operation from executing it and constructing the corresponding packet.

This is much cleaner than writing a long list of unrelated button checks.

The state machine answers:

1
What command is currently selected?

The execute event answers:

1
When should the selected command take effect?

The switchbank or trimpot answers:

1
What value should that command use?

Separating those three ideas reduced ambiguity.

Lesson 9 - Input Conversion Deserves Its Own Task Boundary#

The switchbank provided an 8-bit input value.

One of my task flows periodically read the GPIO state, converted the raw binary input to a decimal representation, formatted it for the rest of the system, and then returned to a periodic wait.

The switchbank task turns raw GPIO state into a reusable numeric value rather than exposing pin-level details to command logic.

This may look like a small wrapper around GPIO.

But it represents an important software boundary:

1
hardware representation:
2
8 GPIO bits
3

4
application representation:
5
VALUE

The command FSM should care about VALUE, not individual pins.

That same principle scales to sensors, ADCs, network packets, and almost every embedded interface.

Lesson 10 - Local Indicators Are Extremely Valuable in Distributed Debugging#

A wireless physical system can fail in many places.

A command might be selected correctly but never executed.

A packet might be created correctly but never transmitted.

The radio might transmit but the RCM might reject the sender.

Without local observability, all of these failures can look like:

“The microscope did not move.”

The project therefore used several local indicators:

1
MFS D1      -> packet transmission activity
2
MFS D2      -> pushbutton activity
3
LED bar     -> selected command opcode
4
7-segment   -> current command value
5
RGB LED     -> zoom/brightness direction or default state

My output FSM coordinated those displays.

The local-output logic maps command state to the seven-segment display, LED bar, and RGB indicator.

This made me appreciate diagnostic outputs as part of architecture rather than decoration.

A spare LED can sometimes save more debugging time than another hundred lines of logging code.

Lesson 11 - Absolute Motion Commands Simplify the Distributed State#

The RCM uses an absolute coordinate frame for X, Y, and Z.

The work area is approximately:

with an origin at the lower-left of the operating area.

A command such as:

1
XYZ10000000

describes a target state rather than a movement history.

That has a useful property in a remote-control system.

With relative commands:

1
move +10
2
move +10
3
move -5

the sender and receiver must remain synchronized about the current position.

With absolute commands:

1
go to X = 100

the desired final state is explicit.

That does not eliminate every synchronization problem, but it reduces how much history has to be shared between the controller and the machine.

The Architecture Became Easier to Understand as Several FSMs#

By the end of the project, I was not thinking in terms of one giant state machine.

I had several smaller behavioural models:

1
Command FSM
2
    -> what the user is selecting
3

4
Radio FSM
5
    -> how packets reach the air
6

7
Output FSM
8
    -> what local feedback should be shown
9

10
RCM processing flow
11
    -> how received command types affect the machine
12

13
FreeRTOS synchronization
14
    -> how events move between those modules

The receive-side flow also made the protocol layering visible.

JOIN, XYZ, ZOOM, and BRIGHT commands follow different paths but eventually converge on shared output and waiting states.

A single giant FSM would have created too many transitions.

Multiple smaller FSMs allowed each module to describe one domain.

This is a design pattern I still prefer:

Use state machines to describe local behaviour, and use queues/events to connect the machines.

What I Would Improve in a Second Version#

If I rebuilt the controller now, I would keep the overall task separation but make several parts more explicit.

1
command
2
    ↓
3
radio transmission
4
    ↓
5
remote validation
6
    ↓
7
ACK with command sequence number

1
duplicates
2
stale packets
3
out-of-order application messages

1
X
2
Y
3
Z
4
zoom
5
brightness
6
ownership status
7
last command

1
queue depth
2
task execution time
3
radio service latency
4
command-to-transmit latency
5
stack high-water marks

Final Thoughts#

This project was a useful transition from peripheral-level embedded programming to system-level embedded architecture.

The nRF24L01+ driver mattered.

The FreeRTOS APIs mattered.

The Hamming encoder mattered.

But the deeper lessons were about how those pieces should be connected.

I learned to think more carefully about:

• task ownership;
• queues as module boundaries;
• interrupts as event sources;
• protocol layers;
• finite-state machines;
• synchronization primitives;
• diagnostic observability;
• the difference between raw hardware values and application-level state.

The physical microscope made those decisions feel much more consequential.

If a small LED demo has a race condition, an LED flashes incorrectly.

If a distributed controller has a confused state model, a physical machine may move somewhere the operator did not intend.

The biggest lesson I kept from the RCM project is:

A reliable embedded system is built by controlling not only the hardware, but also the flow of responsibility between software components.

That idea has become one of the main ways I evaluate embedded architectures today.