The Serial Peripheral Interface (SPI) interface was initially standardized by Motorola in 1979 for short-distance communication in embedded systems. In its most common four-wire configuration, full-duplex data transfer is possible on the two data (MOSI, MISO) lines with data rates well exceeding 10 Mb/s. This makes SPI suitable for high-bandwidth, full-duplex applications like SD storage cards and large resolution, high-refresh displays.
STM32 devices come with a variable number of SPI peripherals, two in the F042 at 18 Mb/s and five in the F411. Across the STM32 families, the SPI peripheral is relatively similar, with fairly minor differences in the register layout. In this article we’ll look at configuring an SPI peripheral in master mode.
Dangerous machines, like ones that can quickly reduce you to a fine red mist or a smoking cinder, tend to have a Big Red Button™ to immediately stop whatever the threat is. Well, if a more dangerous machine than social media has ever been invented, we’re not sure what it would be, which is why we’re glad this social media kill switch exists.
The idea behind [Gunter Froman]’s creation is to provide a physical interface to SocialsDetox, a service that blocks or throttles connectivity to certain apps and websites. SocialDetox blocks access using either DNS over HTTPS (DoH) or, for particularly pesky and addictive apps, a service-specific VPN. The service does require a subscription, the cost of which varies by the number of devices you want to protect, but the charges honestly seem pretty reasonable.
While SocialsDetox can be set up to block access on a regular schedule, say if you want to make the family dinner a social-free time, there may be occasions where killing social access needs to happen right now. This is where the Big Red Button comes into it, which is attached to a Wemos D1 Mini. Pressing the kill switch sends an API request to either enable or disable the service, giving you a likely much-needed break from the swirling vortex of hate and envy that we all can’t seem to live without. Except for Hackaday, of course — it’s totally not like that here.
The irony of using an IoT appliance to restrict access to social media is not lost on us, but you work with the tools you’ve got. And besides, we like the physical interface here, which sort of reminds us this fitting enclosure for a PiHole.
Teaching people efficiently isn’t limited to transmitting material from one head to another — it’s also about conveying the principles that got us there. [Mara Bos] shows us a toolkit (Twitter,
nitter link) that you can arm your students with, creating a small playground where, given a set of constraints, they can invent and figure communication protocols out on their own.
This tool is aimed to teach digital communication protocols from a different direction. We all know that UART, I2C, SPI and such have different use cases, but why? Why are baud rates important? When are clock or chip select lines useful? What’s the deal with the start bit? We kinda sorta figure out the answers to these on our own by mental reverse-engineering, but these things can be taught better, and [Mara] shows us how.
Gently guided by your observations and insights, your students will go through defining new and old communication standards from the ground up, rediscovering concepts like acknowledge bits, bus contention, or even DDR. And, as you point out that the tricks they just discovered have real-world counterparts, you will see the light bulb go on in their head — realizing that they, too, could be part of the next generation of engineers that design the technologies of tomorrow.
It used to be that to play a console game, you just had to plug in a cartridge or put a CD/DVD in the optical drive. But these days, with modern titles ballooning up to as much as 100 GB, you’ve got no choice but to store them on the system’s internal hard disk drive. While that can lead to some uncomfortable data management decisions, at least it means you don’t have to get up off the couch to switch games anymore.
Which is precisely why the MC2SIO project for the PlayStation 2 is so exciting. As [Tito] explains in his latest Macho Nacho Productions video, this simple adapter lets you connect an SD card up to the console’s Memory Card slots and use that to hold ISOs of your favorite games. With the appropriate homebrew software loaded up, your PS2 becomes a veritable jukebox of classic games.
Sometimes reverse engineering embedded systems can be a right old faff, with you needing to resort to all kinds of tricks such as power glitching in order to poke a tiny hole in the armour, giving you an way in. And, sometimes the door is just plain wide open. This detailed exploration of an off-the-shelf retro arcade machine, is definitely in that second camp, for an unknown reason. [Matthew Alt] of VoidStar Security, took a detailed look into how this unit works, which reads as a great introduction to how embedded Linux is constructed on these minimal systems.
Could this debug serial port be more obvious?
The hardware is the usual bartop cabinet, with dual controls and an LCD display, with just enough inside a metal enclosure to drive the show. Inside this, the main PCB has the expected minimal ARM-based application processor with its supporting circuit. The processor is the Rockchip RK3128, sporting a quad-core ARM Neon and a Mali400 GPU, but the main selling point is the excellent Linux support. You’ll likely see this chip or its relatives powering cheap Android TV boxes, and it’s the core of this nice looking ‘mini PC’ platform from firefly. Maybe something to consider seeing as though Raspberry Pis are currently so hard to come by?
Anyway, we digress a little, [Matthew] breaks it down for us in a very methodical way, first by identifying the main ICs and downloading the appropriate datasheets. Next he moves on to connectors, locating an internal non-user-facing USB micro port, which is definitely going to be of interest. Finally, the rather obvious un-populated 3-pin header is clearly identified as a serial port. This was captured using a Saleae clone, to verify it indeed was a UART interface and measure the baud rate. After doing that, he hooked it into a Raspberry Pi UART and by attaching the standard screen utility to the serial device, lo-and-behold, a boot log and a root prompt! This thing really is barn-door wide-open.
Is that a root prompt you have for me? Oh why yes it is!
Simply by plugging in a USB stick, the entire flash memory was copied over, partitions and all, giving a full backup in case subsequent hacking messed things up. Being based on U-Boot, it was a trivial matter of just keying in ‘Ctrl-C’ at boot time, and he was dropped straight into the U-Boot command line, and all configuration could be easily read out. By using U-Boot to low-level dump the SPI flash to an external USB device, via a RAM copy, he proved he could do the reverse and write the same image back to flash without breaking something, so it was now possible to reverse engineer the software, make changes and write it back. Automation of the process was done using Depthcharge on the Raspberry Pi, which was also good to read about. We will keep an eye on the blog for what he does with it next!
We’ve gotten used to the GPIO-available functions of Raspberry Pi computers remaining largely the same over the years, which is why it might have flown a little bit under the radar: the Raspberry Pi 4 has six SPI controllers, six I2C controllers, and six UARTs – all on its 40-pin header. You can’t make use of all of these at once, but with up to four different connections wired to a single pin you can carve out a pretty powerful combination of peripherals for your next robotics, automation or cat herding project.
The datasheet for these peripherals is pleasant to go through, with all the register maps nicely laid out – even if you don’t plan to work with the register mappings yourself, the maintainers of your preferred hardware enablement libraries will have an easier time! And, of course, these peripherals are present on the Compute Module 4, too. It might feel like such a deluge of interfaces is excessive, however, it lets you achieve some pretty cool stuff that wouldn’t be possible otherwise.
Having multiple I2C interfaces helps deal with various I2C-specific problems, such as address conflicts, throughput issues, and mixing devices that support different maximum speeds, which means you no longer need fancy mux chips to run five low-resolution Melexis thermal camera sensors at once. (Oh, and the I2C clock stretching bug has been fixed!) SPI interfaces are used for devices with high bandwidth, and with a few separate SPI ports, you could run multiple relatively high-resolution displays at once, No-Nixie Nixie clock style.
As for UARTs, the Raspberry Pi’s one-and-a-half UART interface has long been an issue in robotics and home automation applications. With a slew of devices like radio receivers/transmitters, LIDARs and resilient RS485 multi-drop interfaces available in UART form, it’s nice that you no longer have to sacrifice Bluetooth or a debug console to get some fancy sensors wired up to your robot’s brain. You can enable up to six UARTs. Continue reading “Did You Know That The Raspberry Pi 4 Has More SPI, I2C, UART Ports?”→
You could argue that the project to add a round screen to a Raspberry Pi from [YamS1] isn’t strictly necessary. After all, you could use a square display with a mask around it, giving up some screen real estate for aesthetics. However, you’d still have a square shape around the screen and there’s something eye-catching about a small round screen for a watch, an indicator, or — as in this project — a talking head.
The inspiration for the project was a quote from a Google quote about teaching a monkey to recite Shakespeare. A 3D printed monkey with a video head would be hard to do well with a rectangular screen, you have to admit. Possible with a little artistry, we are sure, but the round head effect is hard to beat. Honestly, it looks more like an ape to us, but we aren’t primate experts and we think most people would get the idea.
