Building An Open Source Point Of Sale System

[Mukesh Sankhla] has been tinkering in the world of Point of Sale systems of late. His latest creation is a simple, straightforward kiosk system, and he’s open sourced the design.

The Latte Panda MU single-board computer is at the heart of the build, handling primary duties and communicating with the outside world. It’s hooked up to a touchscreen display which shows the various items available for purchase. As an x86 system, the Latte Panda runs Windows 11, along with a simple kiosk software package written in Python. The software uses Google Firebase as a database backend. There’s also an Xiao ESP32 S3 microcontroller in the mix, serving as an interface between the Latte Panda and the thermal printer which is charged with printing receipts.

It’s worth noting that this is just a point-of-sale system; it executes orders, but doesn’t directly deliver or vend anything. With that said, since it’s all open-source, there’s nothing stopping you from upgrading this project further.

We’ve featured other interesting point-of-sale systems before; particularly interesting was the San Francisco restaurant that was completely automated with no human interaction involved Continue reading “Building An Open Source Point Of Sale System”

Porting A Fortran Flight Simulator To Unity3D

There’s an old saying (paraphrasing a quote attributed to Hoare): “I don’t know what language scientists will use in the future, but I know it will be called Fortran.” The truth is, there is a ton of very sophisticated code in Fortran, and if you want to do something more modern, it is often easier to borrow it than to reinvent the wheel. When [Valgriz] picked up a textbook on aircraft simulation, he noted that it had an F-16 simulation in it. In Fortran. The challenge? Port it to Unity3D.

If you have a gamepad, you can try the result. However, the real payoff is the blog posts describing what he did. They go back to 2021, although the most recent was a few months ago, and they cover the entire process in great detail. You can also find the code on GitHub. If you are interested in flight simulation, flying, Fortran, or Unity3D, you’ll want to settle in and read all four posts. That will take some time.

Continue reading “Porting A Fortran Flight Simulator To Unity3D”

Ask Hackaday: What’s The Top Programming Language Of 2025

We did an informal poll around the Hackaday bunker and decided that, for most of us, our favorite programming language is solder. However, [Stephen Cass] over at IEEE Spectrum released their annual post on The Top Programming Languages. We thought it would be interesting to ask you what you think is the “top” language these days and why.

The IEEE has done this since 2013, but even they admit there are some issues with how you measure such an abstract idea. For one thing, what does “top” mean anyway? They provide three rankings. The first is the “Spectrum” ranking, which draws data from various public sources, including Google search, Stack Exchange, and GitHub.

The post argues that as AI coding “help” becomes more ubiquitous, you will care less and less about what language you use. This is analogous to how most programmers today don’t really care about the machine language instruction set. They write high-level language code, and the rest is a detail beneath their notice. They also argue that this will make it harder to get new languages in the pipeline. In the old days, a single book on a language could set it on fire. Now, there will need to be a substantial amount of training data for the AI to ingest. Even now, there have been observations that AI writes worse code for lesser-used languages.

Continue reading “Ask Hackaday: What’s The Top Programming Language Of 2025”

UNIX For A Legacy TI

Although now mostly known as a company who cornered the market on graphing calculators while only updating them once a decade or so, there was a time when Texas Instruments was a major force in the computing world. In the late 70s and early 80s they released a line of computers called the TI-99 to compete (unsuccessfully) with various offerings from Commodore, and these machines were fairly robust for the time. They did have limited memory but offered a 16-bit CPU and plenty of peripherals, and now there’s even a UNIX-like OS that they can run.

This version of UNIX is called UNIX99 and is the brainchild of AtariAge forum member [mrvan] who originally wasn’t looking to develop a full operating system for this computer but rather a set of standard C libraries to help with other projects. Apparently the step from that to a UNIX-flavored OS wasn’t too big so this project was born. While the operating system doesn’t have a UNIX certification, it has most of the tools any of us would recognize on similar machines. The OS has support for most of the TI-99 hardware, file management, a basic user account system, and a command shell through which scripts can be written and executed.

That being said, the limitations of the hardware do come through in the operating system. There’s no multitasking, for example, and the small amount of memory is a major hurdle as well. But that’s what makes this project all the more impressive, and [mrvan] isn’t stopping here. He’s working on a few other improvements to this platform, and we look forward to seeing future releases. UNIX itself is extremely influential in the computing world, and has been used a the model for other homebrew UNIX-like operating systems on similar platforms of this era such as the Z80.

Thanks to [Stephen] for the tip!

Photo courtesy of Rama & Musée Bolo via Wikimedia Commons

Going Native With Android’s Native Development Kit

Originally Android apps were only developed in Java, targeting the Dalvik Java Virtual Machine (JVM) and its associated environment. Compared to platforms like iOS with Objective-C, which is just C with Smalltalk uncomfortably crammed into it, an obvious problem here is that any JVM will significantly cripple performance, both due to a lack of direct hardware access and the garbage-collector that makes real-time applications such as games effectively impossible. There is also the issue that there is a lot more existing code written in languages like C and C++, with not a lot of enthusiasm among companies for porting existing codebases to Java, or the mostly Android-specific Kotlin.

The solution here was the Native Development Kit (NDK), which was introduced in 2009 and provides a sandboxed environment that native binaries can run in. The limitations here are mostly due to many standard APIs from a GNU/Linux or BSD environment not being present in Android/Linux, along with the use of the minimalistic Bionic C library and APIs that require a detour via the JVM rather than having it available via the NDK.

Despite these issues, using the NDK can still save a lot of time and allows for the sharing of mostly the same codebase between Android, desktop Linux, BSD and Windows.

Continue reading “Going Native With Android’s Native Development Kit”

Debugging Vs Printing

We’ll admit it. We have access to great debugging tools and, yes, sometimes they are invaluable. But most of the time, we’ll just throw a few print statements in whatever program we’re running to better understand what’s going on inside of it. [Loop Invariant] wants to point out to us that there are things a proper debugger can do that you can’t do with print statements.

So what are these magical things? Well, some of them depend on the debugger, of course. But, in general, debuggers will catch exceptions when they occur. That can be a big help, especially if you have a lot of them and don’t want to write print statements on every one. Semi-related is the fact that when a debugger stops for an exception or even a breakpoint, you can walk the call stack to see the flow of code before you got there.

In fact, some debuggers can back step, although not all of them do that. Another advantage is that you can evaluate expressions on the fly. Even better, you should be able to alter program flow, jumping over some code, for example.

So we get it. There is more to debugging than just crude print statements. Then again, there are plenty of Python libraries to make debug printing nicer (including IceCream). Or write your own debugger. If gdb’s user interface puts you off, there are alternatives.

Bare Metal STM32: The Various Real Time Clock Flavors

Keeping track of time is essential, even for microcontrollers, which is why a real-time clock (RTC) peripheral is a common feature in MCUs. In the case of the STM32 family there are three varieties of RTC peripherals, with the newest two creatively called ‘RTC2′ and RTC3’, to contrast them from the very basic and barebones RTC that debuted with the STM32F1 series.

Commonly experienced in the ubiquitous and often cloned STM32F103 MCU, this ‘RTC1’ features little more than a basic 32-bit counter alongside an alarm feature and a collection of battery-backed registers that requires you to do all of the heavy lifting of time and date keeping yourself. This is quite a contrast with the two rather similar successor RTC peripherals, which seem to insist on doing everything possible themselves – except offer you that basic counter – including giving you a full-blown calendar and today’s time with consideration for 12/24 hour format, DST and much more.

With such a wide gulf between RTC1 and its successors, this raises the question of how to best approach these from a low-level perspective.

Continue reading “Bare Metal STM32: The Various Real Time Clock Flavors”