If you have ever wanted to implement a RISC-V CPU core in about 600 lines of C, you’re in luck! [mnurzia]’s rv project does exactly that, providing a simple two-function API.
Technically, it’s a user-level RV32IMC implementation in ANSI C. There are many different possible flavors of RISC-V, and in this case is a 32-bit base integer instruction set (RV32I), with multiplication and division extension (M), and compressed instruction set extension (C).
There’s a full instruction list and examples of use on the GitHub repository. As for readers wondering what something like RISC-V emulation might be good for, it happens to be the not-so-secret sauce to running Linux on an RP2040.
What’s better than a pretty nice legged robot? One with an alternate SDK version that opens up expensive features, of course. The author didn’t like that the original SDK only came as pre-compiled binaries restricted to the most expensive models, so rolled up their sleeves and started writing a new one.
The manufacturer’s SDK limits access to programmatic functions, but that needn’t stop you.
There are a number of commercially-available robotic quadrupeds that can trace their heritage back to the MIT Mini Cheetah design, and one of them is the Unitree Go1 series which sports a distinctive X-shaped sensor cluster on its “face”. The basic models are affordable (as far as robots go, anyway) but Unitree claims only the high-priced EDU model can be controlled via the SDK. Happily, the Free Dog SDK provides a way to do exactly that.
The SDK is a work in progress, but fully usable and allows the user to send various high level and low level commands to the Go1 robots. High level examples include things like telling the robot to perform pushups, turn 90 degrees, or walk. Low level commands are things like specifying exact positions or torque levels for individual limbs. With the new SDK, doing those things programmatically is only a Python script away.
Know any other robots that might be based on the same system? This SDK might work on them, too.
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.