It seems like there are two camps, the small group of people who care about UEFI and everyone else who doesn’t really notice or care as long as their computer works. So let’s talk about what UEFI is, how it came to be, what it’s suitable for, and why you should (or shouldn’t) care.
The Si5351 is an extremely useful device, containing multiple clock generators with many versatile programming options that go well beyond its original purpose of providing a clock for digital circuitry. It has in particular found a spot in RF projects, where it provides a cheap and effective stand-in for a variable frequency oscillator in everything from receivers to VNAs. It’s fair to say that programming the Si5351 isn’t the easiest of tasks though, and joining the various attempts to make this simpler is [MR-DOS], who has created an Si5351 library for the STM32 range of ARM Cortex M processors. Fortunately for those afflicted by the semiconductor shortage there’s the advice that porting it to other architectures should only require the relatively manageable task of modifying the i2c function for the new hardware.
Instead of being a full abstraction layer for frequency generation, this library provides functions to give access to the nuts-and-bolts of the chip such as PLL dividers. Thus there’s a need to understand the workings of a PLL and calculate its parameters, while in return much more flexibility over the chip’s operation can be had. We like this approach even though it requires a little more work from the developer.
Over the years this device has attracted a variety of libraries, this isn’t the first we’ve featured.
Header image: Adafruit Industries (CC BY-NC-SA 2.0)
You may (or may not) have heard that Firefox is moving from GLX to EGL for the Linux graphics stack. It’s an indicator of which way the tides are moving in the software world. Let’s look at what it means, why it matters, and why it’s cool.
A graphics stack is a complex system with many layers. But on Linux, there needs to be an interface between something like OpenGL and a windowing system like X11. X11 provides a fundamental framework for drawing and moving windows around a display, capturing user input, and determining focus, but little else. An X11 server is just a program that manages all the windows (clients). Each window in X11 is considered a client. A client connects to the server over a Unix process socket or the internet.
OpenGL focuses on what to draw within the confines of the screen space given by the window system. GLX (which stands for OpenGL Extension to the X window system) was originally developed by Silicon Graphics. It has changed over the years, gaining hardware acceleration support and DRI (Direct Rendering Interface). DRI is a way for OpenGL to talk directly to the graphical hardware if the server and the client are on the same computer. At its core, GLX provides OpenGL functions to X11, adds to the X protocol by allowing 3d rendering commands to be sent, and an extension that reads rendering commands and passes them to OpenGL.
EGL (Embedded-System Graphics Library) is a successor of GLX, but it started with a different environment in mind. Initially, the focus was embedded systems, and devices such as Android, Raspberry Pi, and Blackberry heavily lean on EGL for their graphical needs. Finally, however, Wayland decided to use EGL as GLX brought in X11 dependencies, and EGL offers closer access to hardware.
When Martin Stránský initially added Wayland support to Firefox, he used EGL instead of GLX. Additionally, the Wayland implementation had zero-copy GPU buffer sharing via DMABUF (a Linux kernel subsystem for sharing buffers). Unfortunately, Firefox couldn’t turn on this improved WebGL’s performance for X11 (it existed but was never stable enough). Nevertheless, features kept coming making Wayland (and consequently EGL) a more first-class citizen. Now EGL will be enabled by default in Firefox 94+ with Mesa 21+ drivers (Mesa is an implementation of OpenGL, Vulkan, and other specifications that translate commands into instructions the GPU can understand).
Continue reading “Firefox Brings The Fire: Shifting From GLX To EGL”
One could be excused for thinking sometimes that the concept of connecting devices with other devices for automation purposes is a fairly recent invention. Yet for all the (relatively) recent hype of the Internet of Things and the ‘smart home’, laboratories have been wiring up their gear to run complicated measurement and test sequences for many decades now, along with factories doing much the same for automating production processes.
Much like the chaotic universe of IoT devices, lab equipment from different manufacturers feature a wide number of incompatible protocol and interface standards. Ultimately these would coalesce into IEEE-488.1 (GPIB) as the physical layer and by 1990 the first Standard Commands for Programmable Instruments (SCPI) standard was released that built on top of IEEE-488.
SCPI defines (as the name suggests) standard commands to interact with instruments. It has over the past decades gone on to provide remote interaction capabilities to everything from oscilloscopes and power supplies to exotic scientific equipment. Many off the shelf devices a hobbyist can buy today feature an SCPI interface via its Ethernet, USB or RS-232C port(s) that combined with software can be used to automate one’s home lab.
Even better is that it’s relatively straightforward to add SCPI functionality to one’s own devices as well, so long as it has at least an MCU and some way to communicate with the outside world.
Continue reading “SCPI: On Teaching Your Devices The Lingua Franca Of Laboratories”
People tend to obsess over making computer software faster. You can, of course, just crank up the clock speed and add more processors, but often the most powerful way to make something faster is to find a better way to do it. Sometimes those methods are very different from how a human being would do the same task, but it suits the computer’s capabilities. [Nemean] has a video explaining a better multiplication algorithm known as Karatsuba’s algorithm and it is actually quite clever. You can see the video below.
To help you understand the algorithm, the video shows a simple two-digit by two-digit multiplication. You can see that the first and last digits are essentially the result of one multiplication. It is all the intermediate digits that add together. The only thing that might change the first digit is a carry.
Continue reading “Hacking Multiplication With Karatsuba’s Algorithm”
Have you ever had a program crash before your main function executes? it is rare, but it can happen. When it does, you need to understand what happens behind the scenes between the time the operating system starts your program and your first line of code in main executes. Luckily [Patrick Horgan] has a tutorial about the subject that’s very detailed. It doesn’t cover statically linked libraries but, as he points out, if you understand what he does cover, that’s easy to figure out on your own.
The operating system, it turns out, knows nothing about main. It does, however, know about a symbol called _start. Your runtime library provides this. That code contains some stack manipulation and eventually calls __libc_start_main which is also provided by the library. Continue reading “The Linux X86 Journey To Main()”
The Python world has been fractured a few times before. The infamous transition from version 2 to version 3 still affects people today, and there could be a new schism in the future. [Sam Gross] proposed a solution to drop the Global Interrupt Interpreter Lock (GIL), which would have enormous implications for many projects that leverage the CPython internals, such as Pandas and NumPy.
The fact that Python is interpreted is a double edge sword. It means there can be different runtimes, such as Pyston, Cinder, MicroPython, PyPy, and others, that might support the whole language, a specific version, or a subset. But if you’re using Python, you’re probably running CPython. And it has something known as global interpreter lock that affects threaded code. In a nutshell, only one thread can run in the interpreter at a time. There are some ways around it, such as moving performance-critical sections to C or having multiple interpreters. However, most existing solutions come with considerable downsides. Continue reading “Python Ditches The GILs And Comes Ashore”
