内容简介:This roughly describes an architecture of off the shelf microcontroller components that can be used to create a basic standalone PC, somewhere in the neighborhood of performance of an old 286/386 DOS style PC.If I build this, it will almost certainly be do
TL;DR - These are my notes for a potential computer hobbyist personal computer architecture. Someone called it "Minix for motherboards".
This roughly describes an architecture of off the shelf microcontroller components that can be used to create a basic standalone PC, somewhere in the neighborhood of performance of an old 286/386 DOS style PC.
If I build this, it will almost certainly be done in Rust. I do hope to specify the protocol/operational semantics well enough that you could create a component that was written in Micro/Circuit Python, C/C++, Ada, or maybe even as an embedded linux PC.
I currently am working on other projects, but I feel like this would be a fun project to stream, or maybe even write a book about learning embedded systems, or learning Rust with embedded systems?
If you'd be interested in taking a class building/using a system like this, or would be interested in seeing this happen, send me a message .
Project Goals
The goal of this project is to design a PC-ish architecture that makes it easy for people learning embedded systems to build a single component. This includes:
- Making the system resistant to failure of a single component
- Use only protocols/components that can be easily purchased
- Be adaptive to allow for variety of components used
- Value simplicity over performance
- Make the steps to initial success very short
- Make this fun for me and other collaborators to work on
Project Anti-Goals
- Designing something that is wholly useful in commercial deployments
Interesting Ideas
These are ideas that I think will help make the project successful.
Every Component is a Microcontroller - Any Microcontroller.
The idea is to have every part (or Component ) of the system be its own standalone microcontroller system. Honestly, this is how most computers work today anyway, but the idea is to be able to use almost any microcontroller, from 8051, to Arm Cortex-M, to RISC-V parts, for any piece of the PC. At some point, I can see people even making parts of the PC out of FPGAs as well.
This includes all of the following PC parts:
- The Main CPU/Processor
- An input controller (Keyboard/Mouse/Touch)
- A network interface (Ethernet/Wi-Fi/LPWAN)
- A storage controller (SSD/SD/HDD/RAMFS/USB)
- A Sound Card
- A graphics card (framebuffer, shaders)
The system should use a protocol that almost every device has support for, and is forgiving. For that reason, I plan to use SPI for system communication.
The Bus Protocol - SPI, but weird.
So, SPI is a simple, fast, and reliable protocol, but the trick is that it is WAY easier to write a SPI Controller, rather than a SPI peripheral. Since I want things to be simplest for the people writing the Components, they should be the SPI Controllers. But this leaves us with a problem, how do we make a PC with N SPI Controllers work with a single SPI peripheral? Here is where it gets weird.
- Every Component is a SPI Controller, with SCK, COPI, and CIPO pins wired to a central Arbitrator .
-
Every Component also has two GPIOs:
- An output that is a "Request" line. This signals to the Arbitrator that the Component would like to talk
- An input that is a "Go-Ahead" line. This signals to the Component to begin talking to the Arbitrator
In this system, the Arbitrator will either support being a SPI Peripheral for a lot of lines, or will handle MUXing the SCK/COPI/CIPO pins as necessary. The Arbitrator will decide which component it wants to talk to, and for how long. When a Component pulls its Request line low, the arbitrator will eventually acknowledge this by pulling the Component's Go-Ahead line low. The Component can begin clocking SPI data at whatever speed it feels like, up to the maximum speed supported by the Arbitrator. When the Component is done sending/receiving data, it checks whether the Go-Ahead line is still low. If so, then the message was "accepted" by the arbitrator. If the Go-Ahead line is released high before the Component releases the Request line, this means that the arbitrator has "hung up" on the Component, meaning either an error or timeout has occurred.
The Arbitrator - Basically a Northbridge chip
The Arbitrator has two primary tasks:
- Arbitrating the Bus Protocol as described above, servicing and discovering components that have been connected
- Managing memory allocations used to communicate between devices
I've already described the lowest level of the protocol above - we'll use an awkward SPI communication. However I haven't described how the higher protocol layers work.
All devices will communicate through a mailbox system. The arbitrator will take data from the Components, and place them in an in-memory object store. Each created item will be assigned a UUID, which will be returned to the Component on creation. This UUID can then be placed in a mailbox to another component, sending access to the data to that component. Each item is read-only.
Example (psuedocode):
// A binary RPC messages are sent from Component to the Arbitrator // The format will probably be binary, but maybe with an alternative // command to use the following REPL format? // // Components are also assigned a UUID on boot. This Component has // the own-address of 9ea8b6a7-2967-4db8-98b8-d4577548ed04. // Data can be stored to the Arbitrator memory space. Data can then be // referenced as inter-device storage using UUIDs as a reference. Data // is allocated on a FIFO basis, with oldest memory items becoming // dropped. // // The arbitrator may choose to limit the rate, maximum size or other // parameters of creating memory items based on configuration. CREATE( // number of bytes to write, can be set to zero for dynamic // length using something like COBS or when the Request // line is de-asserted 13, // The payload of the data "Hello, world!", // No UUID provided to send to another component, just return // the newly created UUID. If provided, this would place // the created UUID into the mailbox of another component None, ) // The following UUID is returned to the Component on success -> Result<3b2fd5d1-ae16-46af-afc1-f60241d0a5b6, CreateError> // You can send data by reference to another component you know's // mailbox. Mailboxes are provided as a Component's address. Mailboxes // are a FIFO queue of UUIDs that can be loaded by that Component SEND_MAILBOX( // The data reference to send 3b2fd5d1-ae16-46af-afc1-f60241d0a5b6, // The destination address 56c3dbda-c762-4107-be58-855dc8e5aa92, ) // The other device can receive messages on a FIFO basis, and can view // the item at the top of the stack without removing it PEEK_MAILBOX( // You can provide Some(usize) as a max message size, or None for // anymessage size. Messages larger than the usize value will // instead return an Error Some(32), ) -> Result<(13, "Hello, world!"), GetError> // The other device can receive messages on a FIFO basis, and can view // and remove the item at the top of the stack. If the Controller // ends the message before all bytes are received, the item is still // removed from the FIFO. Thiscan be used to simply drop the item on // the top of the FIFO. POP_MAILBOX( // You can provide Some(usize) as a max message size, or None for // any message size. Messages larger than the usize value will // instead return an Error Some(32), ) -> Result<(13, "Hello, world!"), GetError> // TODO: How to have a "clone and modify" operation that isn't hard // because of re-allocs? Insertions would suck unless I used some kind // of rope structure, which might be too complex to implement
You can also use the SPI interface for certain communications directly to the arbitrator
// Register ourself using an enumerated type ID // // TODO: What to do when calling this more than once? REGISTER_TYPE( IO_CONTROLLER, ) -> Result<9ea8b6a7-2967-4db8-98b8-d4577548ed04, GetError> // Get the ID of ourself. Matches ID given on registration GET_OWN_ID() -> Result<9ea8b6a7-2967-4db8-98b8-d4577548ed04, GetError> // Get limits of the arbitrator interface GET_ARBITRATOR_LIMITS() -> { min_speed_hz: 125_000, // What is the minimum SPI clock rate? max_speed_hz: 8_000_000, // What is the maximum SPI clock rate? exp_polls_per_sec: 100, // What is the expected poll frequency? request_line_shared: false,// Is the request line open drain? total_memory: 524288, // 512KiB max_files: 512, // Max number of records alive at once } // Get limits for message creation GET_CREATE_LIMITS() -> { max_bytes: 512, // Largest message can be 512 bytes max_bytes_per_second: 4096, // Running resource limits messages_per_second: 10, // Running resource limits }
TODO: How to register multiple addresses/logical addressing? e.g. for keyboard that has a mouse and touchpad? Could add a "from" field to every message, but then I'm adding a routing layer?
An easy bootloader
Write a simple bootloader that can enumerate on the bus, take an image, and reboot? PXII boot style? Would need to enumerate type and maybe even serial number or something to load the right firmware to the right place.
The First Implementation
These are ideas for possible first implementation of the PC architecture described above
A Simulator with real-world hooks
I could create a simulated environment for these components, using no_std libraries and using TCP over localhost to emulate the SPI target environment, basically providing an I/O library or a "HAL" for simulating each component inside of a system. Maybe even port RTIC to the simulated environment, or even just use QEMU, using Semihosting for simulated SPI/GPIOs?
With a little work, I could also probably have an arbitrator or even just a simple SPI controller sit outside of the PC, bridging one or more simulated components to a shared network with physical components.
This would allow me to bring up multiple devices quickly, both from a Component software perspective as well as a CPU support for the Anachro-PC architecture.
Using an nrf52840-dk as an arbitrator
Since the nRF52 already has an internal pin mux, I could use an nRF52840, which has like 36-48 GPIOs, to act as a physical arbitrator. Assuming you need the following pins for each component:
- SCK
- COPI
- CIPO
- REQUEST
- GO-AHEAD
That means we could probably support 5-8 devices? Maybe more if the request lines are shared? Maybe less if I want external QSPI memory for storage? Then you could just hand-wire the dev boards together, which would be tedious, but possible without me buying new hardware.
Downside is that the nrf52840 only supports a max speed of 8mbps as a SPI peripheral.
Make an arbitrator board
I could put an nrf52840 or something on a PCB, then break out all the pins to ~8 pin headers. That would allow you to easily wire a harness for each external component, or even do something silly like run the lines over an RJ45 or something.
I could also make simple adapters for common footprints, like PJRC's Teensy, Adafruit's Feather, or the Arduino Uno R3 format. These would be no-component PCBs, with thru-hole solderable headers that you could use dupont headers, or some kind of standard 2x4 ribbon cable.
Mix and match
To start, I'll probably make everything with nRF52s to start, because I have a lot of them at hand. In the future, I'll probably start adding
Make a microATX (or smaller) motherboard?
Once I have a design that works, I could make a jumbo sized PCB with full motherboard-ish components. This would be REALLY cool, but also probably REALLY expensive or time consuming to do in tiny quantities
以上所述就是小编给大家介绍的《Anachro-PC - The Anachronistic Personal Computer》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Head First WordPress
Siarto Jeff / O'Reilly Media / 2010-02-15 / USD 34.99
Whether you're promoting your business or writing about your travel adventures, "Head First WordPress" will teach you not only how to make your blog look unique and attention-grabbing, but also how to......一起来看看 《Head First WordPress》 这本书的介绍吧!