In the first weeks since units shipped to backers, there has been a whirlwind of activity in firmware development. We’re delighted to see such a vibrant community come together — thank you to everyone who has shared their experiences so far with us and the Internet. It really means a lot to us that people are using and enjoying their devices!

True to its name, the Precursor is, well, a precursor to your applications. And we’re already starting to see some applications come together. Already, we’ve seen a lightweight IRC client on the device (thanks gsora!), as well as QR code rendering in modals (thanks nworbnhoj!) as well as on-going efforts to port Signal and TLS to the platform. Because we’re trying to build everything from the ground-up in Precursor, sometimes it feels like we’re boiling the ocean one pot at a time, but we’re also finding that many hands make light work. Thank you to all the developers out there who have already engaged with us and created demos, pull requests, and contributed documentation, and to everyone who has shared warm and fuzzy vibes on social media!

Xous Book

In addition to the wiki, we’re starting to gel documentation into the Xous Book. The book now contains examples of message passing, graphical toolkit elements, as well as some improved introductory material. Documentation is hard but essential work, so thank you to everyone who has contributed material and suggestions on what to cover first. Please keep the feedback coming!

Stocking Forecast

The good news is that units are selling briskly. The bad news is that we’re on trajectory to sell out of the current stock in about a month. The even worse news, as you might expect is supply chain problems. We’re working to try and get a restocking shipment in ASAP, which may give us another couple of months of inventory runway, but demand is high enough that probably sometime in the summer we will be sold out and will continue to be until early next year. This is because orders we placed for key parts last September are currently on track for delivery next Feburary — some parts are 70+ week lead time and the vendors are continuing to push out delivery dates.

In addition to the factory orders we already placed, we’ve been checking the "spot market" (distributors, brokers, gray market) regularly to see if there aren’t opportunities to pull in the lead times. Unfortunately, spot pricing on parts like the FPGA have almost doubled, and we’ve seen 10x increases on some of our power regulators. While the current pricing on Crowd Supply reflects some allowance for price increases, we think most users would rather wait longer than pay multiples on the current pricing, so trying to put together an entire device using gray market parts is out of the question (unless you really want to pay over $1k for a device built out of gray market stock!). Thus, we all have to sit tight until the global electronics supply chain straightens itself out and folks like TI and Xilinx can get around to honoring the standing orders we placed many months ago. This will probably happen sometime after we achieve some combination of peace in Europe, more factories built, tariffs/trade barriers reduced, and/or open borders within most of Asia. So…"not this year."

0.9.8 Release

Here are the release notes for version 0.9.8. We’ve just stabilized it and pushed it to the servers. If you are going to update to it, please remember to do a git pull for xous-core, and make sure you’re on the main branch before running the update scripts. There have been some improvements to the scripts to hopefully increase their reliability for applying the updates.

• std support has been expanded
  • Mutex now suspends the thread on the slow path, rather than spinning
  • Condvar is now available, meaning std::sync::mpsc::channel() now works
  • TcpStream is now part of std. Legacy TcpStream has been removed.
  • TcpListener is now part of std. Legacy TcpListener has been removed.
  • UdpSocket is now part of std. DNS and all test routines switched over to libstd, and all prior scaffolding implementations have been removed.
  • Duration and Instant are now part of std
  • We are now building these changes against Rust 1.60.0
• Improvements to the networking stack
  • net server demo program has been upgraded to use multiple worker threads + mpsc channels for communications. Users can now attempt to access buzz/ to cause the vibration motor to run, and there is now a 404 response for pages not found.
  • NetPump call added after Tx (UDP/TCP) and connect (TCP) events. This should improve the transmit latency.
• Timezone and time setting has been refactored
  • The HW RTC is now simply treated as a seconds counter since arbitrary time in the past; the BCD data that the hardware device tries to return is mapped into seconds since epoch. On first boot or invalid RTC detection, a random time is picked since epoch as the offset, between 1-10 years, to provide some deniability about how long the device has been used.
  • One can now switch the local time by just updating the Timezone offset. The actual timezone offsets are not dynamically updated with DST; one has to explicitly program in the offset from UTC upon daylight savings.
  • NTP option for time setting introduced with fallback to manual option
• Graphical elements improved
  • CPU load meter has been shifting around in the status bar to accommodate worst-case proportional font layouts. Maybe we're there?
  • Focus events refactored for the GAM to only send to apps (and not to menus and dialogs); it is strongly encouraged that all apps take advantage of them.
  • Sleep screen is now blanked of all prior content and just the sentinel message is held
  • QR code rendering option added to modals (thank you nworbnhoj!)
• Preliminary text to speech (TTS) support added; compile with cargo xtask tts or set the LOCALE to en-tts to try it out.
• Core improvements
  • Sleep/suspend lightly refactored to fix some bugs. Ticktimer is now the sole Last event.
  • Introduce deferred-response pattern into modals, pddb, and susres.
• pddb critical bug fixes
  • Page table entries were not having their journal numbers synchronized with the free space table when read off of the disk. This would cause inconsistency glitches in the pddb. This release fixes the problem, but, it may require you to reformat the pddb once the patch is in place. Because this is a genuine bug, if you're unlucky to be hit by this, there is no effective migration path. :(
  • pddb major bug fixed where zero-length file allocations were not being committed to disk.
  • pddb revision bumped to v2.1:
    • A first problem was identified where a key was being re-used between the ECB page table cipher and the AES-GCM-SIV data cipher
    • HKDF is now used to derive two separate keys for each
    • A second problem was identified where the virtual page number was being stored as a fully expanded address in the paget able, and not as a page number. Due to the compressed encoding of the page table entry, this means that the virtual address space would be shrunk by ~4000x. This is now fixed, so we have the full as-designed virtual memory space once again.
    • A migration routine was created to go from v1 -> v2 databases. It automatically detects the older version and attempts to guide the user through a migration. Although we don't have many users and databases today, this is a "best practice" for breaking revisions and this serves as a basis for forward-looking changes that are migrateable.
    • Note: we plan to deprecate the v1->v2 migration in the next release, because it's a good chunk of code bloat. So, if you have any data you don't want to lose by v0.9.9, be sure to update to v0.9.8 (or else when v0.9.9 comes out, you can just do a v0.9.8 update and then a v0.9.9 update).
• Various fixes and improvements to the USB update scripts to improve reliability.
• Graphical panic outputs: when there is a panic, you get a "Guru Meditation" error box plus the panic message.
  • Currently all panics are hard crashes
  • Most of the time the system will reboot itself within a few seconds of displaying the panic
  • There will be occassions where you will need to insert a paperclip into the reset port on the lower right hand corner to recover from the panic.
  • If you get a panic, please snap a photo of it and drop it in a new issue in the xous-core repo, along with a description of what you were doing at the time.