Week 13 - Networking and Communications
- [/] Linked to the group assignment page and reflected what you learned individually of the group assignment.
- Documented your project.
- Documented what you have learned from implementing networking and/or communication protocols.
- Explained the programming process/es you used.
- Outlined problems and how you fixed them.
- Included design files (or linked to where they are located if you are using a board you have designed and fabricated earlier) and original code.
hero shot >
- ponder the meaning of supply-side planning
- rewire one of my urumbu implementations
- modify neil’s urumbot code to send messages to led board
- connect led board to mcu to usb hub
- modify led board code to accept serial commands
- determined that I need to pick a baudrate that works for both nano and esp32
- run modified urumbot code
- watch lights blink as urumbot “works”
flavor text >
This past week was a bit busy. I:
- got keys to my new apartment w/ my girlfriend
- finally got my car’s radiator fixed, thanks to guidance from a coworker (a daunting task for someone who never worked on a car)
- crunch time for a project at work
- volunteering task that took a bit of time
And of course, switched my final project with about a month left to go. Woohoo.
Needless to say, I wasn’t able to spend as much time on this weeks assignment. Fortunately, I think(?) it satisfies requirements.
actual project >
In this project, I used my previous work from the machine week to demonstrate serial networking between devices via USB. I modified Neil’s Urumbot code to send additional single char commands to my previous muxed LED board, which is distinct from a stepper or servo.
I had 3 separate USB devices on a single bus (addressing).
The Urumbu machine architecture uses single char commands to control peripheral devices, specifically the stepper motor. It accepts ‘f’ or ‘r’ for forward or reverse, respectively.
I added ‘y’ and ‘n’ for ramp up and ramp down led behaviors on my muxed led board, and modified my led board code to listen for serial commands, similar to how the stepper motor driver boards do.
In the Urumbot python code, I modified the code such that a motor event on either port0 or port1 would result in a write to the led board. The result isn’t very pretty (motor events occur waaaay faster than the led animations so the board is quickly saturated with commands), but it gets the point across.
baud rate >
The nano and the esp32 appear to have different acceptable baud rates. I haven’t dug into this too much yet (planning on swapping over to samd11c boards, so although interesting hasn’t been a priority), but I wasn’t able to talk to the nano at 921000 baud, while I could for the esp32.
The quick fix was to set all of the boards to 115200, a baudrate which all the boards can communicate at.
I should note that in order to make the nano’s work with the urumbu python program, I had to change from serialusb calls to serial, as is typical for your run of the mill Arduino board (Uno, Nano, etc.). This hackaday article notes the difference between serial vs serialusb. The article is worded a bit confusingly, but it notes that the serial library is used for devices that have a usb-to-uart chip, while serialusb is used for devices that have a built-in USB peripheral.
Not surprisingly, the devices w/ the USB peripheral are capable of much higher speeds.