James Munns

Thinking about practical steps for my amodem work.

I think I need to get the SPI interface working first - since that will be used by both the bootloader and the application. This will be the primary "downstream" interface for users of the modem. I need to look at what DMA and interrupts I'll have available, and see what kind of interface is easiest to implement.

Then I'll want a bootloader, so I don't need to have SWD attached for every node/update.

From there, I need to verify the RS-485/UART/status LED stuff is working correctly, before I spend time assembling a bunch more boards.

Main Chips

• SN75176BDR - RS-485 Transciever, 5V, 10mbps
• STM32G030F6P6TR - MCU, 3v3, 64MHz, 32KiB Flash, 8KiB RAM, 8mbps UART
• M24C02-WMN6TP, I2C EEPROM 2Kib/256B, 4M write cycles, 16B page, 400kHz

Semi-Made Design Decisions

Use 8MHz UART1 - this is the fastest the STM32G0 supports

Use 9-bit serial over RS-485. This is supported by the STM32G0 hardware. This allows us to use the 9th bit as the address/data selector. This allows us to use the "address match" interrupt.

UART/RS-485 Speed: 710KB/s total. 32 devices: 22KB/s each.

Downstream will use SPI. Up to 8MHz is possible, I think? One (hardware) chip select pin, Two GPIOs for reporting status (data ready? out data ready?)

Not-really-made design decisions

• How to do scheduling/time slices
• How to do address assignment
• Streams vs Registers - If registers, how to do schema and stuff
• Things that are a pain in my ass - The "router" node needs a pretty constant stream of data to be written out. It REALLY doesn't have a lot of RAM.

How do I actually want to use this?

First use case is to allow for the following over RS-485:

• Set "live" values to end-nodes (lighting, etc.) - Good for registers, okay with serial
• Get sensor values from end-nodes - Good for registers, okay with serial
• Sending defmt/tracing msgs - Bad for registers, good with serial
• fwupd the modem - Bad for registers, good with serial
• fwupd the node - Bad for registers, good with serial

Reality Check

1. I probably would be super happy with like 1/s updates to start with
   • More is better later, but honestly it really doesn't matter right now
2. I do probably want some kind of stream ability pretty early, even basic.
3. I will likely not have more than 4-8 nodes to begin with
4. Programming an address onto the eeprom is going to be totally fine.
5. Probably the hardest part is going to be handling buffer management
   • All buffers need to be interrupt safe
   • I don't have atomics
   • I don't have a lot of extra RAM for double/triple buffering
6. I'm really going to need a bootloader

Still trying to figure out roughly what the scheduler will look like so I can solidify the userspace interfaces. Description of each part, numbered above in sequence:

I've been sick the last couple of days, so I've spent a bunch of time idly thinking about mnemOS, but not actually doing anything about it. The brain isn't back at 100%, but good enough to sit upright on the couch, so I thought I would post about it until I don't feel like posting any more tonight.

This post will probably become part of a rough draft of the updated documentation.

What is mnemOS?

Okay, got a fresh beverage, let's do another bite sized piece.

Parts of mnemOS

mnemOS conceptually is broken up into three main parts:

• the kernel, which provides resources like an allocator, an async executor/scheduler, and a registry of active/running drivers
• the drivers, which are async tasks that are responsible for all other hardware and system related functionality
• the user programs, which use portable interfaces to be able to run on any mnemOS system that provides the drivers it needs.

This post covers the kernel.

the kernel

Another day, another chunk of writing.

Parts of mnemOS - continued

In the last post, I covered the kernel. This post moves on to the drivers, which are async tasks that are responsible for all other hardware and system related functionality.

the drivers