ARM Ethernet-capable Development Board
This is still very much in it's general planning stages. I'm just letting it rattle around in my head for a while, then I'm going to actually implement it in my free time over the summer.
So this board will actually serve a purpose, it will end up controlling some lighting. Right now this is being handled by an Arduino Leonardo ETH. While it is able to work right now, it isn't really fit to the task. It barely has enough RAM to hold a TCP/IP stack and an MQTT client, and flash is running kind of low. Throughput isn't great and the libraries I'm using don't really give me much control over what's going on. I also just want to try implementing my own ethernet board with MII/RMII.
I have a few main criteria for my part selection.
- Everything has to be reasonably hand-solderable. Wide-pitch QFN is the hardest I am willing to go.
- I want to use ARM. I do want to expand my comfort zone, but I know I am able to use open source ARM build tools.
- I want to use MII, so I can scope it more easily.
- Nothing can be insanely expensive.
Again, it has to be ARM, so I have a fair amount of choice. I mostly settled on three processors.
- ST Microelectronics STM32F2x7 series
- Atmel SAME53 series
- Nuvoton M487 series
All of these are somewhat inexpensive, have good documentation, and have free and available build environments. The Atmel and Nuvoton parts were cheaper, and I can get the Atmel part on DigiKey, so I'm leaning towards Atmel. Also, I've been dealing with the STM32 series quite a lot recently, and while I like them a lot, I would like to push my comfort zone and setup a whole new build environment by myself. I feel that doing that on a different series will force it to happen.
The specific one doesn't really matter, but I'm looking at using the KSZ8081 or KSZ8091.
I want to go with a make or cmake build system that I design. Again, mostly just to challenge myself. I also want to get a good gdb setup going with OpenOCD (maybe vim? I don't know, see how it works). If I have to I can always fall back onto eclipse.
For peripheral configuration I want to use the very basic register configuration. So I'll just import the headers Atmel provides and configure the registers directly. Again, I want to challenge myself and really understand how these peripherals work.
For TCP/IP I plan on using LwIP, and integrating that into the ethernet controller. The LwIP project also has an MQTT client built in so I plan on using that for my MQTT functionality, or, if all else fails, just implement it myself. MQTT isn't super complicated.
For my use case, I will need to be able to configure it for multiple environments, or if I want to change a setting I don't want to go reflashing it. I'm thinking of using a YAML config file on an SD card. Keep it simple, stupid.
There's some specific firmware update behaviour I still want to flesh out, but suffice it to say I want to do SD-card firmware updates.
Firmware / IDE setup
I want to use Rust.
No real reason. I would probably get it done way faster in straight C, but:
- I want to learn Rust.
- I want to practice slightly higher level programming concepts than C has.
- I want to learn Rust.
There would be quite a bit of work in doing the board level bring-up. Honestly not much more than C would be since I'm not using the Atmel tools, I'm going straight register level. I would have to generate a crate for the SAME series (or at least the E53), and write the drivers for the peripherals I would need. I would also probably try to expose as many pins/peripherals as I could for my first board revision so I can test out and write drivers for as many peripherals as I can. I would then have to set up an IDE for it so I could do debugging. I could always just do printf debugging, and that is useful a lot of the time, but I really do like step-debugging. Also I don't want to use command line gdb. It's just not as nice as what modern IDEs can do.
I found a nice article about setting up vscode for rust embedded debugging, so that's probably what I'm going to do.
I got rust all setup and working for an STM32F030 on VSCode. I can't seem to get debugging working directly through vscode, but I think that's because of my gdb setup (I installed a pretty-ing extension thing)
I found smoltcp, which seems to be a good, small TCP stack. Unless something comes up and it won't work, I think that's what I'll use