Displays We Love Hacking: LVDS And EDP

There are times when tiny displays no longer cut it. Whether you want to build a tablet or reuse some laptop displays, you will eventually deal with LVDS and eDP displays. To be more exact, these are displays that want you to use either LVDS or eDP signaling to send a picture.

Of the two, LVDS is the older standard for connecting displays, and eDP is the newer one. In fact, eDP has mostly replaced LVDS for things like laptop and tablet displays. Nevertheless, you will still encounter both of these in the wild, so let’s start with LVDS.

The name “LVDS” actually comes from the LVDS signaling standard (Low-Voltage Differential Signaling), which is a fairly generic data transfer standard over differential pairs, just like RS485. Using LVDS signaling for embedded display purposes is covered by a separate standard called FPD-Link, and when people say “LVDS”, what they’re actually talking about is FPD-Link. In this article, I will also use LVDS while actually talking about FPD-Link. Barely anyone uses FPD-Link except some datasheets, and I’ll use “LVDS” because that’s what people actually use. It’s just that you deserve to know the distinction so that you’re not confused when someone mentions LVDS when talking about, say, industrial machinery.

Both LVDS and eDP run at pretty high frequencies – they’re commonly used for color displays with pretty large resolutions, so speed can no longer be a constraint. eDP, as a successor technology, is a fair bit more capable, but LVDS doesn’t pull punches either – if you want to make a 1024 x 768 color LCD panel work, you will use LVDS, sometimes parallel RGB – at this point, SPI just won’t cut it. There’s a lot of overlap – and that’s because LVDS is basically parallel RGB, but serialized and put onto diffpairs. Let me show you how that happened, and why it’s cool.

Continue reading “Displays We Love Hacking: LVDS And EDP”

Linux Fu: Getting Started With Systemd

I will confess. I started writing this post about some stupid systemd tricks. However, I wanted to explain a little about systemd first, and that wound up being longer than the tricks. So this Linux Fu will be some very fundamental systemd information. The next one will have some examples, including how to automount a Raspberry Pi Pico. Of course, by the end of this post, you’ll have only scratched the surface of systemd, but I did want to give you some context for reading through the rest of it.

Like many long-time Unix users, I’m not a big fan of systemd. Then again, I’m also waiting for the whole “windows, icon, mouse, pointer” fad to die down. Like it or not, systemd is here and probably here to stay for the foreseeable future. I don’t want to get into a flame war over systemd. Love it or hate it, it is a fact of life. I will say that it does have some interesting features. I will also say that the documentation has gotten better over time. But I will also say that it made many changes that perhaps didn’t need to be made and made some simple things more complicated than they needed to be.

In the old days, we used “init scripts,” and you can still do so if you are really motivated. They weren’t well documented either, but it was pretty easy to puzzle out the shell scripts that would run, and we all know how to write shell scripts. The systemd way is to use services that are not defined by shell scripts. However, systemd tries to do lots of other things, too. It can replace cron and run things periodically. It can replace inetd, syslog, and many other traditional services. This is a benefit or a drawback, depending on your point of view.

(Editor’s note: And this logging functionality was exactly what was abused in last week’s insane liblzma / ssh backdoor.)

Configuring systemd requires you to create files in one of several locations. In systemd lingo, they are “units.” For the purpose of this Linux Fu, we’ll look at only a few kinds of units: services, mounts, and timers. Services let you run programs in response to something like system start-up. You can require that certain other services are already running or are not running and many other options. If the service dies, you can ask systemd to automatically restart it, or not. Timers can trigger a service at a particular time, much like cron does. Another unit you’ll run into are sockets that represent — you guessed it — a network socket.

Continue reading “Linux Fu: Getting Started With Systemd”

Bare-Metal STM32: Setting Up And Using SPI

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.

Continue reading “Bare-Metal STM32: Setting Up And Using SPI”

KittyOS: Writing A Toy OS For The ATmega168 From Scratch

Writing an operating system for a computing platform is one of those non-trivial tasks few people actually need to do, regardless of whether it’s for a small microcontroller or a larger general-purpose computer. Many of us spend a large amount of our time working on producing robust code for embedded systems, occasionally diving deeper into the abstraction when we’re stuck on a problem. Quite often this work is sitting on top of an RTOS, which we consider a solved problem. [Jonathan Diamond] had picked up a fair bit of knowledge of some of the low-level AVR black magic, as well as some details of how operating systems work internally, and so decided to have a crack a building a toy operating system called KittyOS, for the learning experience alone.

[Jonathan] hastens to add that this is not a practical OS, but a learning platform that needs a few more bells and whistles added to be useful. Aimed at the 8-bit AVR ATmega168 with its mere 16kB of flash and 1kB of SRAM, the diminutive chip can still perform more than well enough to host the rudimentary OS — up to four application tasks, and some basic system call support.

Already, KittyOS sports preemptive multitasking, with prioritization and support for applications written in C. Hardware support is a bit limited, with just serial I/O and a spot of GPIO, but that’s more than enough for a demonstrator. Applications can be loaded into any of the four available slots, with per-slot run state control, using the Python-based host interface. The post is a long one, with an absolute ton of the gory details we love around these parts, and we’re very glad [Jonathan] took the time to make a proper write-up as well as a demonstration video, which can be found after the break.

Continue reading “KittyOS: Writing A Toy OS For The ATmega168 From Scratch”

It’s Linux. On An ESP32

By today’s standards, the necessities for running a Linux-based operating system are surprisingly meagre in terms of RAM and processor power. Back in the day we ran earlier Linux versions on Intel 386 and 486 machines with tiny quantities of memory compared to the multi-gigabyte many-core powerhouses we do today.

So it stands to reason that many of the more powerful microcontrollers should also run Linux, but of course they are often unable because the lack a memory management unit. The original ESP32 is just such a candidate, plenty of power but unable to run Linux. Not so fast, because [Dror Gluska] has managed to boot a Linux kernel on Espressif’s dual-core chip. How on earth? By emulating a RISC-V processor on it and booting a RISC-V version of the kernel.

The emulator in question is [Fabrice Belard]’s TinyEMU, a piece of software that brings both RISC-V and x86 to limited-spec platforms, and the write-up describes the extensive optimization and tracing of ESP32 bottlenecks which was finally able to get a Linux kernel booting in 1 minute and 35 seconds. Of course it’s simply an exercise to prove it can be done and we won’t be seeing Linux-based ESP projects any time soon, but it’s still an impressive piece of work.

This isn’t the lowest-spec microcontroller we’ve seen run Linux, back in 2012 we saw it on emulated ARM running on an 8-bit AVR.

A purple PCB with an OLED display and various chips

A Neat Little Tool To Reset The Fuses On Your ATtiny

If you’re an experienced hacker, you’ve probably run into a problem at some point and thought “let’s make a tool to automate that”. A few hours later you’ve got your tool, but then realize that the amount of work you put into making the tool vastly exceeds what you would have needed to solve the original problem manually. That really doesn’t matter though: developing a fancy tool can be a rewarding experience that teaches you way more about the original problem than you would have learned otherwise. [sjm4306]’s ATtiny High Voltage Fuse Reset-er is a clever device that firmly falls into this category.

The problem it solves is familiar to anyone who’s ever worked with Atmel/Microchip’s ATtiny series of microcontrollers: set one of the configuration fuses incorrectly and you’re no longer able to reprogram your chip. Getting the ATtiny back to its original configuration requires a high-voltage programming step that involves pulling the reset pin to 12 V in what’s otherwise a 5 V system. You could simply grab a spare 12 V supply and hack together a level shifter with a few transistors, but where’s the fun in that?

[sjm4306]’s solution is built on a pretty purple PCB that contains an ATmega328, an OLED display, and sockets to accommodate various versions of the ATtiny series microcontrollers. To generate the required 12 V, one could simply use an off-the-shelf boost converter IC. But instead, he decided it would be interesting to make such a circuit out of discrete components and control it using the ATmega. After all, this chip already contains timers to generate PWM signals and an ADC to measure the converter’s output voltage, so all it took was to write some control logic in the form of a PID controller.

The end result, as you can see in the video embedded below, is a convenient little PCB that runs off a 5 V USB power supply and resets the fuses on your ATtiny at the push of a button. Sometimes, simple tools that do one thing well are all you need; however, if you’re looking for an all-in-one AVR programmer that also supports HV programming, check out this AVR Multi-Tool.

Continue reading “A Neat Little Tool To Reset The Fuses On Your ATtiny”

Strange Computer Languages: A Hacker’s Field Guide

Why do we build radios or clocks when you can buy them? Why do we make LEDs blink for no apparent purpose? Why do we try to squeeze one extra frame out of our video cards? We don’t know why, but we do. That might be the same attitude most people would have when learning about esolangs — esoteric programming languages — we don’t know why people create them or use them, but they do.

We aren’t talking about mainstream languages that annoy people like Lisp, Forth, or VBA. We aren’t talking about older languages that seem cryptic today like APL or Prolog. We are talking about languages that are made to be… well… strange.

INTERCAL

We have to start at the beginning. INTERCAL. This was started as a joke in 1972 and the acronym is purportedly for Compiler Language With No Pronounceable Acronym. There was no actual implementation, though, until around 1990. Now there are two: C-INTERCAL and CLC-INTERCAL.

Since INTERCAL is a parody, it makes some very odd choices. For example, bitwise operators like AND operate with two arguments, but one of the arguments is reversed. That is, the top bit of one operand matches the bottom bit of the second operand. In a nod to social convention, there is a modifier known as PLEASE that you should sometimes use when, for example, reading data as in “PLEASE READ IN.” If you don’t use it often enough, the compile will fail warning you that the program is insufficiently polite. However, if you use it too often, you’ll also get an error that your program is excessively polite.

Originally, the implementation used EBCDIC, so it uses some characters that don’t appear on conventional 7-bit ASCII systems. This forced some character substitutions and now, with Unicode, some versions will allow the old-style characters if you prefer them. The INTERCAL manual renames nearly all the special characters for further confusion. A single quote is a “spark” and the equal sign is a “half-mesh”. Only the ampersand remains unscathed.

Want to know more? Be careful what you wish for.

Continue reading “Strange Computer Languages: A Hacker’s Field Guide”