bunnie

A version of the Baochip BIO core, using the same open source RTL as featured on the 22nm version (https://github.com/baochip/baochip-1x/tree/main/rtl/modules/bio_bdma/rtl) has been taped out and will be on the open-to-the-PDK 180nm @wafer_space@mastodon.social run 2! Thanks to Deepak Sharda (twitter: x.com/deeempak / website: https://lut4.com) for doing the heavy lifting of porting the Baochip BIO core to this process! Design is at https://github.com/dpks2003/bio-core

@chrysn You can do both modes, you can always read an I/O pin and poll its state without relying on the quantum mechanism. At 5 Mbaud I would guess you can do polling OK.

@wren6991 thanks! I also really enjoyed analyzing and understanding the PIO, it's a really interesting point in the design space and there's a lot of clever ideas in there.

@xyhhx yep, it's a play on words!

One of my favorite features of the Baochip-1x is the BIO. It's an I/O coprocessor that is based on the PicoRV32, with custom register extensions to allow direct access to GPIOs from the ISA.

Read more about the BIO at this blog post: https://www.bunniestudios.com/blog/2026/bio-the-bao-i-o-coprocessor/ I go in-depth into the architecture and its trade-offs relative to the PIO, and conclude by working through a couple of coding examples.

I built a microcontroller for high-assurance applications on TSMC 22nm. I call it the "Baochip-1x". Read more about what it is and how it came about at this blog post: https://www.bunniestudios.com/blog/2026/baochip-1x-a-mostly-open-22nm-soc-for-high-assurance-applications/

@lutindiscret @baochip.com great, probably just user error on my side.

@lutindiscret @baochip.com weird, doesn't look like stuff is automatically cross posting...

@lutindiscret I guess in theory this should be live in about 5 minutes: @baochip.com

@lutindiscret can you teach me how to bridge accounts? ie link me to a guide or explain how to do it to me.

@gkrnours The baochip is fairly limited in I/O, so any application like this would require some helper to expand the I/O, creating a bottleneck and thus making performance less than desired. So I would guess it is not strictly impossible, but it's probably also not going to work as well as desired.

@Logical_Error "use case" - I think of it as a general purpose MCU with some bonus security features. I personally am developing systems around it targeted at authentication tokens, but I don't mean that to be a box into which it is defined. The emphasis on open source means that everyone is invited to use it however they see fit. The intention is not for Xous to be a desktop replacement - the transition comparison is more like going from say, Zephyr or ThreadX to Xous. It's an embededd OS so the harder challenge is porting code from one ecosystem to another. Because we are Rust, we already don't have source-language compatibility that C-based OSes would have. So maybe the biggest ecosystem you could copy paste code out of is Tock, another Rust-based OS.

@pjacock Also for software support, we're focusing on pure Rust and we have a custom OS we wrote for it called Xous - https://betrusted.io/xous-book/

@pjacock Re pinout - I'd refer you to the KiCAD for the dabao board, it has the symbol with the pinout embedded in it: https://github.com/baochip/dabao it also lists the pin-muxable I/O in the symbol itself The device also has the BIO in it which allows most of the pins to be configured in software to be a bit-bang UART, I2C, etc. modulo the existence of drivers for that protocol.

Interested in the Dabao evaluation board for the Baochip-1x? Sign up here to be notified when they are going on sale: https://www.crowdsupply.com/baochip/dabao

If you missed my talk with Xobs at #39c3, the recording is now up: https://media.ccc.de/v/39c3-xous-a-pure-rust-rethink-of-the-embedded-operating-system

Learn about Xous, the pure-Rust OS we've been working on, and the Baochip-1x, a full custom silicon chip that will soon be available, purpose-built to run Xous!

@jeroen@secluded.ch @mxk@hachyderm.io that's the hope, at least. Part of the experiment is to see if the market will actually put its money where its mouth is in terms of valuing openness in security.

Unfortunately the hardware "kettles" don't come cheap, so next steps always have to strike a balance between progress on openness, and organic, high quality sources of money (such as actual customer demand) that are free of conflicts of interest.

I suspect it will be a very slow process to grow the market for projects like this, especially given the shakiness of the economy these days and the giant sucking sound that is AI taking all the money out any non-AI centered projects.