| Previous journal: | Next journal: |
|---|---|
| 0094-2023-06-12.md | 0096-2023-06-17.md |
So far this is very rough and ready, and I've started implementing it in Wokwi as a clumsy state machine using the RP2040 C SDK. The way I've done it should be very lightweight, and hopefully reliable, but probably hard to read/follow. Also need to work out later how we want to handle out-of-band stuff like reacting to whatever we consider an "interrupt".
- Start up with all GPIOs (except USB) set to input.
- Blink LED 3 times.
- Line-based comms? Even when doing binary payloads.
- Lines starting with
#are ignored; a way to do debug output. - Is ENTER key in minicom always just 0x0A (LF)? What about in PuTTY, etc?
@means "read all GPIOs" and returns state of GPIO[29:0] as a binary string (1s and 0s).emeans "echo" and it repeats back its supplied parameter (though it may be truncated if it's too long).- Good responses start with
>, bad responses start with!, and comments (which could be considered logs or debug info) start with#.
When made as a proper PCB:
- Two-way jumpers, one option going direct, other via current-limiting (safety) resistor.
What's the max sink/source of both DE0 and Pico?
- Cyclone IV data suggests max pin current of 25mA. Suggest we assume 20mA.
- Discussion here on RP2040 suggests max pin current of 12mA. Suggest we assume 10mA. Thus, safety resistor on 3.3V short should be 330Ω
- Header pins and header sockets.
- Markers (silkscreen?) for danger pins.
- T-shape?
- Pico stand-off and swappability. Use 10-way stacking headers for DIP-IC-style pin profiles? DIP socket stripes.
- Cuttable traces
- Break-off strips that can be used to couple a breadboard into the adapter?
- Code to retrieve and print initial state of all GPIO registers, which could be handy also for knowing how to access all these registers anyway: https://forums.raspberrypi.com/viewtopic.php?p=1956337&hilit=gpio+default+pull&sid=0965765be3f049419fbe94df73f738ef#p1956337
- This asserts that RP2040 GPIOs should start up as inputs, but with pull-downs enabled. Thus, they should be read as 0 if floating, though they should be overridden by pulling them high. Note that I suppose it's possible some would have different states, if they have ARM special purposes enabled, but I'm not sure any are in this state by default.
- General info about GPIO from datasheet
- Info on initial state of GPIOs from datasheet ("PADS_BANK0: GPIO0, GPIO1, …, GPIO28, GPIO29 Registers")
- There's some good info about GPIO registers here. Note,
hardware_regs. - Simply read all GPIOs via API:
gpio_get_all - Experimenting with Pi Pico in Wokwi.
- Maybe IRQ stuff in Wokwi?
- Wokwi example with Verilog
- Wokwi Pico Assembly example
- Other useful Pico-DE0 feature ideas:
- Set/Clear/Toggle an individual GPIO.
- ...or a range...
- ...optionally while changing direction of others, e.g. for bi-dir.
- Pulse option.
- One-shot or looping pattern playout.
- Set interrupt handler.
- NOTE: Some of these things might be more like PIO behaviour.
- RP2040 is documented as having 30 GPIOs, or maybe 32 (GPIO0..31?), but BOOTSEL (input only?) is documented to be GPIO33??
- Pico USB serial selection happens inside
CMakeLists.txt:...I assume therefore that any printf or read stuff is ubiquitous and just follows whichever device is selected.# Enable usb output: pico_enable_stdio_usb(${PROJECT_NAME} 1) # Disable uart output: pico_enable_stdio_uart(${PROJECT_NAME} 0)
- CMake tutorial
- RP2040 SDK USB timeout stuff: raspberrypi/pico-sdk#699 (comment) - see the rest of that discussion too.
- Official RP2040 SDK doco inc. APIs: https://www.raspberrypi.com/documentation/pico-sdk/
- This copy of RP2040 SDK doco might also be relevant (v1.5.0): https://cec-code-lab.aps.edu/robotics/resources/pico-c-api/group__pico__stdio.html
- Interesting re USB detection and non-blocking reads: https://forums.raspberrypi.com/viewtopic.php?t=331207
- See
getchar_timeout_usandstdio_set_chars_available_callback(alt. source) - Can we do both USB output and debug output via a 2nd UART or SWD?