Scope GUI Made Easier

Last time, I assembled a Python object representing a Rigol oscilloscope. Manipulating the object communicates with the scope over the network. But my original goal was to build a little GUI window to sit next to the scope’s web interface. Had I stuck with C++ or even C, I would probably have just defaulted to Qt or maybe FLTK. I’ve used WxWidgets, too, and other than how many “extra” things you want, these are all easy enough to use. However, I had written the code in Python, so I had to make a choice.

Granted, many of these toolkits have Python bindings — PyQt, PySide, and wxPython come to mind. However, the defacto GUI framework for Python is Tkinter, a wrapper around Tk that is relatively simple to use. So, I elected to go with that. I did consider PySimpleGUI, which is, as the name implies, simple. It is attractive because it wraps tkinter, Qt, WxPython, or Remi (another toolkit), so you don’t have to pick one immediately. However, I decided to stay conservative and stuck with Tkinter. PySimpleGUI does have a very sophisticated GUI designer, though.

About Tkinter

The Tkinter toolkit lets you create widgets (like buttons, for example) and give them a parent, such as a window or a frame. There is a top-level window that you’ll probably start with. Once you create a widget, you make it appear in the parent widget using one of three layout methods:

  1. Absolute or relative coordinates in the container
  2. “Pack” to the top, bottom, left, or right of the container
  3. Row and column coordinates, treating the container like a grid

The main window is available from the Tk() method:

import tkinter as tk
root=tk.Tk()
root.title('Example Program')
button=tk.Button(root, text="Goodbye!", command=root.destroy)
button.pack(side='left')
root.mainloop()

That’s about the simplest example. Make a button and close the program when you push it. The mainloop call handles the event loop common in GUI programs.

Continue reading “Scope GUI Made Easier”

Game Graphics: Racing The Beam

Have you ever wondered how the graphics in your favorite video games worked? This is the start of a series on game graphics, and what better place to start than how exactly the original Mario Bros. got those glorious pixely pixels onto the screen. Buckle in, because we’re “racing the beam” with systems like the NES, Commodore 64, and many other classics from the 1980s.

And to understand the 1980’s, it’s important to understand how the televisions of the time worked. Cathode Ray Tube (CRT) televisions work by precisely bombarding a phosphor layer with electrons, which excites the phosphor, which then releases visible light. The beam scans from left to right then top to bottom, giving each pixel a small fraction of a second of time. All of this effectively means that pixel data needs be sent at the same time as when the pixels are being lit up, which is why this type of graphics is often dubbed “racing the beam”.

Continue reading “Game Graphics: Racing The Beam”

Hackaday Links Column Banner

Hackaday Links: October 22, 2023

The second of three major solar eclipses in a mere six-year period swept across the United States last week. We managed to catch the first one back in 2017, and still have plans for the next one in April of 2024. But we gave this one a miss, mainly because it was “just” an annular eclipse, promising a less spectacular presentation than a total eclipse.

Looks like we were wrong about that, at least judging by photographs of last week’s “Ring of Fire” eclipse. NASA managed to catch a shot of the Moon’s shadow over the middle of the US from the Deep Space Climate Observer at Lagrange Point 1. The image, which shows both the compact central umbra of the shadow and the much larger penumbra, which covers almost the entire continent, is equal parts fascinating and terrifying. Ground-based photographers were very much in the action too, turning in some lovely shots of the eclipse. We particularly like this “one-in-a-million” shot of a jet airliner photobombing the developing eclipse. Shots like these make us feel like it was a mistake to skip the 10-hour drive to the path of annularity.

Continue reading “Hackaday Links: October 22, 2023”

Close To The Metal

Firmware is caught between hardware and software. What do I mean? Microcontroller designers compete on how many interesting and useful hardware peripherals they can add to the chips, and they are all different on purpose. Meanwhile, software designers want to abstract away from the intricacies and idiosyncrasies of the hardware peripherals, because code wants to be generic and portable. Software and hardware designers are Montagues and Capulets, and we’re caught in the crossfire.

I’m in the middle of a design that takes advantage of perhaps one of the most idiosyncratic microcontroller peripherals out there – the RP2040’s PIOs. Combining these with the chip’s direct memory access (DMA) controllers allows some fairly high-bandwidth processing, without bogging down the CPUs. But because I want this code to be usable and extensible by a wide audience, I’m also trying to write it in MicroPython. And configuring DMA controllers is just too idiosyncratic for MicroPython.

But there’s an escape hatch. In my case, it’s courtesy of the machine.mem32 function, which lets you read and write directly into the chip’s memory, including all of the memory-mapped configuration registers. Sure, it’s absurdly low-level, but it means that anything you read about in the chip’s datasheet, you can do right away, and from within the relative comfort of a Micropython program. Other languages have their PEEK and POKE equivalents as well, or allow inline assembler, or otherwise furnish you the tools to get closer to the metal without having to write all the rest of your code low level.

I’m honestly usually a straight-C or even Forth programmer, but this experience of using a higher-level language and simultaneously being able to dive down to the lowest levels of bit-twiddling at the same time has been a revelation. If you’re just using Micropython, open up your chip’s datasheet and see what it can offer you. Or if you’re programming at the configure-this-register level, check out the extra benefits you can get from a higher-level language. You can have your cake and eat it too!

Tiny Linux On A No-MMU RISC-V Microcontroller

In the vast majority of cases, running a Linux-based operating system involves a pretty powerful processor with a lot of memory on hand, and perhaps most importantly, a memory management unit, or MMU. This is a piece of hardware which manages virtual memory, seamlessly giving each process its own memory sandbox in which it shouldn’t be able to rain on its neighbours’ parade. If there’s no MMU all is not lost though, and [Uros Popovic] gives us a complete guide to building the MMU-less μClinux on a RISC-V microcontroller.

The result is something of a Linux-from-scratch for this platform and kernel flavour, but it’s so much more than that aside from its step-by-step explanation. It’s probable that most of us have heard something of μClinux but have little direct knowledge of it, and he leads us through its workings as well as its limitations. As examples, standard ELF binaries aren’t suitable for these systems, and programmers need to use memory-safe techniques.

Whether or not any of you will run with this guide and build a tiny MMU-less Linux system, anything which expands our knowledge on the subject has to be a good thing. it’s not the first time we’ve seen a RISC-V microcontroller turned to this task, with a nifty trick to get round the limitations of a particular architecture.

Chip Shortage Engineering: Misusing DIP Packages

After years of seeing people showing off and trading their badge Simple Add-Ons (SAOs) at Supercon, this year I finally decided to make one myself. Now for a first attempt, it would have been enough to come up with some cool PCB art and stick a few LEDs on it. But naturally I started with a concept that was far more ambitious than necessary, and before long, had convinced myself that the only way to do the thing justice was to have an onboard microcontroller.

My first thought was to go with the venerable ATtiny85, and since I already had a considerable stock of the classic eight-pin DIP MCUs on hand, that’s what I started prototyping with. After I had something working on the breadboard, the plan was to switch over to the SOIC-8 version of the chip which would be far more appropriate for something as small as an SAO.

Unfortunately, that’s where things got tricky. I quickly found that none of the major players actually had the SMD version of the chip in stock. Both DigiKey and Mouser said they didn’t expect to get more in until early 2024, and while Arrow briefly showed around 3,000 on hand, they were all gone by the time I checked back. But that was only half the problem — even if they had them, $1.50 a piece seems a hell of a lot of money for an 8-bit MCU with 8K of flash in 2023.

The whole thing was made all the more frustrating by the pile of DIP8 ATtiny85s sitting on the bench, mocking me. Under normal circumstances, using them in an SAO wouldn’t really be a problem, but eight hand-soldered leads popping through the front artwork would screw up the look I had in mind.

While brooding over the situation my eyes happened to fall on one of the chips I had been fiddling with, it’s legs badly bent from repeated trips through the programmer. Suddenly it occurred to me that maybe there was a way to use the parts I already had…

Continue reading “Chip Shortage Engineering: Misusing DIP Packages”

At Last! Faster OpenSCAD Rendering Is On The Horizon

Known as “The Programmers Solid 3D CAD Modeller”, OpenSCAD is used by many people for whom writing code comes more naturally than learning a fiddly user interface. It’s a very capable piece of software, but regular users will tell you that it can be rather slow when it comes to rendering your work. We’re very pleased to see that a fix for this has been produced courtesy of [@ochafik], can now be found as an experimental feature in nightly builds, and will in due course no doubt find its way to official releases.

Despite a modern computer invariably having a multi-core architecture, it might surprise you to find that OpenSCAD wasn’t able to take advantage of this previously. The above-linked thread spans over a decade of experimenting and contains some fascinating discussions if you’re prepared to wade through it, and culminates a few weeks ago in the announcement of the new feature giving access to multiple CPUs. We don’t have it yet, but it’s great to know it’s in the works and we’re looking forward to render time involving considerably less of a wait.

So many OpenSCAD projects have passed through these pages over the years, it’s safe to say that it has a significant user base among Hackaday readers. It’s still something an AI hasn’t mastered yet though.

Thanks [pca006132] for the tip.