This blog shows how to leverage the PIO found on RP2040 to drive a not-so-common type of display. Combined with the large SRAM found on the RP2040, this is quite usable.
I thought this was a really good introduction to using the PIO blocks in the RP2040 to drive a peripheral, rather than bit-banging using the CPU.
Being involved with retro computers, I have a few floppy disks (of the 3.5-inch variety) that I would like to preserve as faithfully as possible. Of course, I know there are dedicated devices for doing that, such as the Kryoflux or the SuperCard Pro. But it occurred to me that I already own the required hardware to capture the low-level data from a floppy disk: my Saleae Logic 8 logic analyzer.
Another semi-automated way to capture raw (magnetic flux) disk images from floppy disks, this one using a drive and a logic analyzer with some post-processing. In addition to the other tools mentioned in the post, AppleSauce is a great option.
I want to talk about first simulating an RTL design that contains of soft CPU, and debugging the firmware that ran on that soft CPU after the simulation has completed.
Novel idea of using GDB to debug software running on a soft-core processor in an FPGA simulation, AFTER the simulation is completed!
Between the years 1987 and 1995, Apple Computers, Inc produced a distribution of Unix for the 680×0-based Macintosh. Based on System V release 2.2, Apple Unix (A/UX) provided a familiar Macintosh Finder environment with the ability to run both Unix and Mac applications. While the two products share no code, A/UX was the “conceptual ancestor” of OS X.
Once I get a BlueSCSI or a larger HD in my Centris 650, I’m definitely going to install A/UX on a partition just for fun.
Pinion is a simple tool that allows you to make a nice-looking pinout diagrams for your PCBs
This looks useful and well done. I can see using this for any hardware I eventually develop.
HDMI is a digital video interface, so is easy to drive from modern FPGAs.
Let’s see how it works.
Great HDMI intro, bookmarked for later reference.
Imagine there’s an embedded system that needs to persist some state when the processor restarts (either intentionally or due to a catastrophic error).
This could be some external hardware information (what’s the position of a motor or actuator?) or a method to communicate the reset to the user (display some information on the device’s display).
A simple way to store information through a reboot is to use what’s called “non-initialized” memory.
Neat! Good quick tutorial.
Renode is an open-source Emulator for embedded platforms. Today, it supports x86 (Intel Quark), Cortex-A (NVIDIA Tegra), Cortex-M, SPARC (Leon), and RISC-V based platforms.
Renode can take the same firmware you are running in production, and run it against emulated cores, peripherals, and even sensors and actuators. Better yet, its extensive networking support and multi-system emulation make it a shoe in for testing systems made up of multiple devices talking together.
With Renode, you can start development before your hardware is ready, test your firmware without deploying racks of hardware, and shorten your iteration cycles by cutting out flash loading delays
This post has a good walkthrough on setting up Renode, including customizing emulated hardware and integrating with the automated testing framework.
A glance at this year’s OSDI program shows that Operating Systems are a small niche topic for this conference, not even meriting their own full session. This is unfortunate because good OS design has always been driven by the underlying hardware, and right now that hardware is almost unrecognizable from ten years ago, let alone from the 1960s when Unix was written. This change is receiving considerable attention in the architecture and security communities, for example, but in contrast, so-called OS researchers are mostly in denial. Even the little publishable OS work that is not based on Linux still assumes the same simplistic hardware model (essentially a multiprocessor VAX) that bears little resemblance to modern reality. In this talk, I’ll speculate on how we came to this unfortunate state of affairs, and what might be done to fix it. In particular, I’ll argue for re-engaging with what computer hardware really is today and give two suggestions (among many) about how the OS research community can usefully do this, and exploit what is actually a tremendous opportunity.
As someone who is interested in embedded systems, computer architecture, and operating systems, I found this talk highly enjoyable.
This post documents some of the tips and tricks I learned while integrating ESP8266 into my own circuit designs. Some of them help reduce the components needed thus minimizing the cost, while others have to do with selecting and using GPIO pins. For breadboard prototyping, you can certainly use one of the popular ESP8266 development boards, like NodeMCU, WeMos etc. But what I want to cover in this post is to integrate a ESP8266 module (such as ESP-12F) into the circuit design, without using the development boards.
I need to remember to consider the ESP8266 and ESP32 for my hobby projects. There are some good tips here.