RFC: WiFi Buddy Interface Design #196
Conversation
This commit starts a new RFC for designing the hardware and software interfaces between MnemOS on the CPU and MnemOS on the WiFi Buddy. I've started by adding a summary of the background and a list of design questions that need to be answered as we determine how the WiFi Buddy and the CPU will communicate. This is intended as a jumping-off point for future conversations, and (eventually) to document the design. @jamesmunns, I'd love your input on this --- feel free to add to the RFC doc directly, or leave comments on the PR, whatever you prefer!
rfcs/0000-wifi-buddy-interface.md
Outdated
| The following pins are broken out by the WiFi Buddy hardware and can be used for | ||
| communication between the CPU and WiFi Buddy: | ||
|
|
||
| - One SPI interface (`MOSI`, `MISO`, and `SCK`) |
There was a problem hiding this comment.
There's also a chip select pin CSn.
There was a problem hiding this comment.
I didn't include chip select here because any of the 4 GPIOs could be the chip select pin, right?
There was a problem hiding this comment.
sort of. Short answer, yes it could be for now, but might be worth explicitly addressing as such.
There was a problem hiding this comment.
Overall looks great to me, and I appreciate you writing this up @hawkw!
rfcs/0000-wifi-buddy-interface.md
Outdated
| Based on the background information discussed above, we can begin to enumerate | ||
| design questions for the WiFi Buddy interface: | ||
|
|
||
| - **Is control path communication in-band or out of band?** If data path frames |
There was a problem hiding this comment.
Mentioned in chat, but I'd probably recommend just using SPI unless we come up with a good reason not to.
There was a problem hiding this comment.
Yeah, we're aligned on this --- I wanted to enumerate both options but the proposed design will be SPI only (and IRQs)
rfcs/0000-wifi-buddy-interface.md
Outdated
| between data and control messages. It also means that we don't necessarily | ||
| need to implement drivers for all the interfaces available on the ESP32-C3. | ||
|
|
||
| Downsides of in-band control messages include that we must introduce some |
There was a problem hiding this comment.
Mention in chat: I think using postcard as the wire format means that decoding/encoding is likely to be low overhead (CPU and bandwidth use wise), and allow for flexibility in the future if we add more message types.
rfcs/0000-wifi-buddy-interface.md
Outdated
| the ability to indicate what data is an Ethernet frame and what is BLE, | ||
| anyway, so we'll already be introducing some overhead for tagging data. | ||
|
|
||
| - **Do we want the CPU to be able to receive `trace-proto` from WiFi Buddy?** |
There was a problem hiding this comment.
I think we will want this, but it can also be deferred during early development since we'll have the additional USB link
rfcs/0000-wifi-buddy-interface.md
Outdated
| what control messages will need to be exchanged in order to implement the | ||
| required functionality. | ||
|
|
||
| - **How does the WiFi Buddy signal that data is ready?** Since the CPU is the |
There was a problem hiding this comment.
Definitely +1 that we need at least ONE GPIO signal line, even if it is optional. Possible useful lines are:
- "Modem ready to receive data" (can also indicate "I am busy processing" or "buffers are full")
- "Modem has data for host"
rfcs/0000-wifi-buddy-interface.md
Outdated
|
|
||
| ## Background | ||
|
|
||
| ### Hardware |
There was a problem hiding this comment.
Might be worth mentioning/discussing https://github.com/tosc-rs/mnemos/tree/main/hardware/esp32c3-wifi-dev, and particularly note that we'll be able to use:
- 4-pin SPI
- 2-pin UART
- 2 signal GPIOs (could be 4, if we don't use UART)
For initial development.
rfcs/0000-wifi-buddy-interface.md
Outdated
There was a problem hiding this comment.
Don't forget to change the number of the file from 0000 to 0196 before merging
This commit starts a new RFC for designing the hardware and software interfaces between MnemOS on the CPU and MnemOS on the WiFi Buddy. I've started by adding a summary of the background and a list of design questions that need to be answered as we determine how the WiFi Buddy and the CPU will communicate. This is intended as a jumping-off point for future conversations, and (eventually) to document the design.
@jamesmunns, I'd love your input on this --- feel free to add to the RFC doc directly, or leave comments on the PR, whatever you prefer!