The new firmware boasts an improved UI and multiple measurement units, including Sievert, Rem, and counts per minute or second. You can hold the measurement or compute a dose or average rate. The new firmware also has a host of customizations and can accommodate different tubes.
There are, however, two really key features. First, the new firmware offers about 40% more battery life than the stock version. Second, there is now an onboard nuclear chess game! That way, you can enjoy yourself while you are getting irradiated. There are also a few suggested hardware mods that are optional to improve measurements and increase the buzzer volume, among other things.
We covered [Anders Nielsen]’s 65duino project a short while ago, and now he’s back with an update video showing some more details of bit-banging I2C using plain old 6502 assembly language.
Obviously, with such a simple system, there is no dedicated I2C interface hardware, so the programmer must take care of all the details of the I2C protocol in software, bit-banging it out to the peripheral and reading back the response one bit at a time.
The first detail to concern us will be the I2C addresses of the devices being connected to the bus and how low-level bit manipulation is used to turn the 7-bit I2C address into the byte being bit-banged. As [Anders] shows, setting a bit is simply a logical-OR operation, and resetting a bit is a simple logical-AND operation using the inversion (or one’s complement) bit to reset to form a bitmask. As many will already know, this process is necessary to code for a read or a write I2C operation. A further detail is that I2C uses an open-collector connection scheme, which means that no device on the bus may drive the bus to logical high; instead, they must release the drive by going to the high impedance state, and an external pull-up resistor will pull the bus high. The 6532 RIOT chip (used for I/O on the 65unio) does not have tristate control but instead uses a data direction register (DDR) to allow a pin to be an input. This will do the job just fine, albeit with slightly odd-looking code, until you know what’s going on.
From there, it’s a straightforward matter to write subroutines that generate the I2C start, stop, and NACK conditions that are required to write to the SSD1306-based OLED to get it to do something we can observe. From these basic roots, through higher-level subroutines, a complete OLED library in assembly can be constructed. We shall sit tight and await where [Anders] goes next with this!
Some professional coders are absolutely adamant that learning to program in assembly language in these modern times is simply a waste of time, and this post is not for them. This is for the rest of us, who still think there is value in knowing at a low level what is going on, a deeper appreciation can be developed. [Philippe Gaultier] was certainly in this latter camp and figured the best way to learn was to work on a substantial project.
Now, there are some valid reasons to write directly in assembler; for example hand-crafting unusual code sequences for creating software exploits would be hindered by an optimising compiler. Creating code optimised for speed and size is unlikely to be among those reasons, as doing a better job than a modern compiler would be a considerable challenge. Some folks would follow the tried and trusted route and work towards getting a “hello world!” output to the console or a serial port, but not [Philippe]. This project aimed to get a full-custom GUI application running as a client to the X11 server running atop Linux, but the theory should be good for any *nix OS.
Hello World! In X11!
The first part of the process was to create a valid ELF executable that Linux would work with. Using nasm to assemble and the standard linker, only a few X86_64 instructions are needed to create a tiny executable that just exits cleanly. Next, we learn how to manipulate the stack in order to set up a non-trivial system call that sends some text to the system STDOUT.
To perform any GUI actions, we must remember that X11 is a network-orientated system, where our executable will be a client connected via a socket. In the simple case, we just connect the locally created socket to the server path for the local X server, which is just a matter of populating the sockaddr_un data structure on the stack and calling the connect() system call.
Now the connection is made, we can follow the usual X11 route of creating client ids, then allocating resources using them. Next, fonts are opened, and a graphical context is created to use it to create a window. Finally, after mapping the window, something will be visible to draw into with subsequent commands. X11 is a low-level GUI system, so there are quite a few steps to create even the most simple drawable object, but this also makes it quite simple to understand and thus quite suited to such a project.
We applaud [Phillip] for the fabulous documentation of this learning hack and can’t wait to see what’s next in store!
As much as we might all like it if manufacturers supported their products indefinitely with software updates or replacement parts, this just isn’t feasible. Companies fail or get traded, technologies evolve, and there’s also an economic argument against creating parts for things that are extremely old or weren’t popular in the first place. So, for something like restoring an old car, you might have to resort to fabricating replacement parts for your build on your own. [MangoJelly] shows us how to build our own replacement parts in FreeCAD in this series of videos.
The build does assume that the original drawings or specifications for the part are still available, but with those in hand FreeCAD is capable of importing them and then the model scaling to match the original specs shown. This video goes about recreating a hinge on an old truck, so with the drawings in hand the part is essentially traced out using the software, eventually expanding it into all three dimensions using all of the tools available in FreeCAD. One of the keys to FreeCAD is the various workbenches available that all have their own sets of tools, and being able to navigate between them is key to a build like this.
FreeCAD itself is an excellent tool for anyone repairing old vehicles like this or those making 3D prints, designing floorplans for houses, or really anything you might need to model in a computer before bringing the idea into reality. It does have a steep learning curve (not unlike other CAD software) so it helps to have a video series like this if you’re only just getting started or looking to further hone your design skills, but the fact that it’s free and open-source make it extremely attractive compared to its competitors.
There once was a time when to make a PCB in our community was to use CadSoft EAGLE, a PCB design package which neatly filled the entry level of that category with a free version for non-commercial designs. Upgrading it to the commercial version was fairly inexpensive, and indeed that was a path which quite a few designers making the step from hobby project to small production would take.
If you want a book on network programming, there are a few classic choices. [Comer’s] TCP/IP books are a great reference but sometimes is too low level. “Unix Networking Programming” by [Stevens] is the usual choice, but it is getting a little long in the tooth, as well. Now we have “Beej’s Guide to Network Programming Using Internet Sockets.” While the title doesn’t exactly roll off the tongue, the content is right on and fresh. Best part? You can read it now in your browser or in PDF format.
All the topics you’d expect are there in ten chapters. Of course, there’s the obligatory description of what a socket is and the types of sockets you commonly encounter. Then there’s coverage of addressing and portability. There’s even a section on IPV6.
TLS, byte by byte performs an unusual and interesting function: it fetches itself over HTTPS, and provides a complete annotation of what’s going on in the process, one byte at a time. Visit the site and give the button a click to watch it happen, it’s neat!
Transport Layer Security (TLS) is what’s responsible for encrypting traffic over the internet, and it’s normally implemented on top of TCP to encrypt an application-layer protocol like HTTP (resulting in HTTPS and the little padlock icon in browsers indicating a connection with a web site is encrypted.) Back in the day, traffic over the internet was commonly unencrypted, but nowadays no communication or hardware is too humble for encryption and methods are easily accessible.
So for what purpose would someone actually need or use such an implementation of TLS? Well, probably no one actually needs it. But it is a userspace TLS implementation in javascript that may fit a niche for someone, and it certainly provides beautifully-indented and annotated binary data in the process. Sound up your alley? The GitHub repository for the project has all the details, so give it a look.