Using Trigonometric Functions In CSS

August 1, 2023 by Maya Posch 14 Comments

Often neglected as ‘merely a styling language’, CSS contains a wealth of functions built right into the browser’s rendering engine that can perform everything from animations to typography and even mathematical operations, with more added each year.

Screenshot of the output of the basic rotating dots example using CSS.

In a tutorial [Bramus] takes us through using the trigonometric functions in CSS. These are supported in all major browsers since Chrome 111, Firefox 108 and Safari 15.4. In addition to these trigonometric functions, further mathematical functions are also available, many of whom have been available for years now, such as calc(), min() and max().

Unlike the JavaScript version of the CSS trigonometric functions, the CSS functions accept both angles and radians for the argument. Perhaps the nicest thing about having this functionality in CSS is that it removes the need to add JavaScript for many simple things on a webpage, such as animations, translations and the calculating of offsets and positions. Perhaps most impressive is the provided example by [Ana Tudor] who created an animated Möbius strip using cos() and sin() and a handful of other CSS functions.

None of this is likely surprising to anyone who is somewhat familiar with the depths of CSS, especially after it has been more-or-less proven to be a Turing-complete programming language. Using this power for visual elements does however make a lot of sense considering that CSS was always intended to help with styling and formatting the raw HTML.

Do you use these advanced CSS features already, or is it something you might consider using in the future, possibly over JavaScript versions? Feel free to share your thoughts and experiences in the comments.

(Heading: Code to move items on a circular path around a central point in CSS.)

TinyBasicLike: A Target-Independent BASIC Interpreter

July 31, 2023 by Maya Posch 13 Comments

In the long and winding history of BASIC, it’s sometimes hard to keep track of all the different variants and dialects. Some may still remember TinyBASIC, which was published in 1976 as Palo Alto Tiny BASIC by [Gordon Brandly]. Later, TinyBASIC was modified by a number of people including [Scott Lawrence] who created TinyBASIC Plus (TBP). Inspired by this, [Karl] figured he could improve on TBP by making the original C-based project even easier to port by removing whatever platform dependencies he could find, creating what he calls TinyBasicLike.

The main change is that TinyBasicLike consists out of two C files, with one containing the core code, and the second the platform-specific details that can be used by the core. Although [Karl] started off with the Palo Alto Tiny BASIC-like code by [Scott Lawrence], he decided to make it into his own by making a few alterations, such as adding left and right shift operators, adding an ADDR() function, expanding the features of INPUT and adding multiple logical operators.

In the example STM32F4 project linked on the project page it is demonstrated how to target a new platform with TinyBasicLike. Performance on the STM32F4 Discovery board with a simple counting loop yielded about 6 lines of TBL program code per millisecond. For a 168 MHz STM32 MCU that’s definitely not astounding, but considering how straightforward Tiny BASIC (and TBL as a consequence) is, it’s definitely no slouch.

This is probably a good time to remind that BASIC was the original champion of cross-platform programming and the source of countless fond (and frustrating) memories.

Illumos Gets A New C Compiler

July 16, 2023 by Al Williams 15 Comments

Illumos is an OpenSolaris-derived Unix system, and no Unix is complete without a C compiler or two. And with a name like Portable C Compiler (PCC), you would think that would be a great bet to get up and running on Illumos. That’s probably what [Brian Callahan] thought, too, but found out otherwise.

PCC already generates x86 code, so that wasn’t the problem. It was a matter of reconfiguring the compiler for the environment, ironic since PCC probably started on true Unix but now won’t work with 64-bit Solaris-like operating system. According to the post:

It looks like some time ago someone added configuration for 32-bit x86 and SPARC64 support for the Solaris family. But no one ever tried to support 64-bit x86. So first we had to teach the configure script for both pcc and pcc-libs that 64-bit x86 Solaris

Continue reading “Illumos Gets A New C Compiler” →

Ask Hackaday: Learn Assembly First, Last, Or Never?

July 14, 2023 by Al Williams 153 Comments

A few days ago, I ran into an online post where someone pointed out the book “Learn to Program with Assembly” and asked if anyone had ever learned assembly language as a first programming language. I had to smile because, if you are a certain age, your first language may well have been assembly, even if it was assembly for machines that never existed.

Of course, that was a long time ago. It is more likely, these days, if you are over 40, you might have learned BASIC first. Go younger, and you start skewing towards Java, Javascript, or even C. It got me thinking, though: should people learn assembly, and if so, when?

Continue reading “Ask Hackaday: Learn Assembly First, Last, Or Never?” →

Linux Device Drivers In Only A Few Years

July 11, 2023 by Al Williams 10 Comments

[Johannes 4GNU_Linux] has been filming a video series on how to write Linux device drivers for a couple of years now, but luckily, you won’t need that long to watch them or to create your own driver. He’s added some recent videos to the series, like the one below, but might want to rewind a few years and start at the beginning.

If you build your own hardware for Linux, you’ll probably eventually want to write a driver which runs as a privileged program. While there are many things you can do in user space, for the ultimate control and performance, you can’t beat a driver.

One problem, though, is that drivers can really crash your system in a big way. In the old days, it was common to have a dedicated system for driver development. Today, for many drivers, you can get away with running a virtual machine that you can crash and reload without much trouble.

The videos cover diverse topics like interrupts, completions, polling, and threads. He even uses a Raspberry Pi, which will be very useful for many embedded projects. Of course, the trend these days is to have one driver — like the USB driver — and have it provide user-space access so that everyone doesn’t have to write their own drivers. But, as usual, that only goes so far.

We aren’t sure how many more videos there will be, but if you make it through the first 31, maybe more will be waiting for you. It has been a while since we looked at SPI drivers in Linux. As an example of why you might want to roll your own, consider a custom FPGA driver.

Continue reading “Linux Device Drivers In Only A Few Years” →

MicroLisp: Lisp For Microcontrollers Now Has Lisp-Based ARM Assembler

July 10, 2023 by Maya Posch 12 Comments

In a way it feels somewhat silly to market a version of Lisp as targeting resource-constrained platforms, considering the systems it ran on back in the 1960s, but as time goes on, what would have given 1970s Big Iron a run for its money is now a sub-$5 microcontroller that you can run uLisp (MicroLisp) on. This particular project now even has an ARM assembler that is written in Lisp whose source code (GitHub) fits on a mere two A4-sized pages.

ULisp currently supports five platforms, being AVR-nano (ATmega328 and similar low-cost AVRs), AVR, ARM, ESP (8266 and 32), as well as RISC-V. The purpose of this assembler is to execute native ARM instructions when running on an ARM board, since uLisp itself runs a Lisp interpreter on the platform. When executed natively like this, a considerable speed-up of the task can be expected, as illustrated by a number of ARM assembler examples in the documentation.

Running a Fibonacci sequence that takes 24.6 seconds with the Lisp version on an Adafruit Metro M4 is reduced to a mere 61 ms when ARM assembly is used instead. This shouldn’t be too shocking, since this assembler essentially bypasses the Lisp runtime, coming closer to what would be the performance of firmware written in e.g. C. However, it also demonstrates that with this ARM assembler it is possible to have your Lisp and still get native performance when you want it, all using Lisp code.

Suc Aims To Replace Slack In Five Lines Of Bash

July 10, 2023 by Bryan Cockfield 43 Comments

The design philosophy of Unix is fairly straightforward. Software should do one thing as simply as possible, and do that one thing only. As a design principle this is sound advice even well outside of the realm of Unix, and indeed software in general, but that doesn’t stop modern software packages from being too large for their own good. So, if you’re tired of bloated chat programs like Slack or Mattermost with their millions of lines of code, you might instead favor something like Simple Unix Chat (suc).

The idea is that suc can perform almost all modern chat functions in only five lines of Bash, supporting rich-text chat, file sharing, access control, and encryption. These five lines, though, only perform the core function of suc — which is to write text to a file on the system. Indeed, suc makes liberal use of plenty of other Unix services which do not add to the line counts, such as the use of SSH to handle authentication. It also relies on some other common Unix system features to handle things like ownership and access for the text files that host the text for the chat.

As channels are simply text files, it makes writing bots or other tools exceptionally simple. You can also easily pipe the output of commands directly into suc with one-liners that can do things like dump the output of make into a specific channel if compilation fails.

While it’s not likely that everyone will ditch tools like Slack to switch to something like this, it’s still an impressive demonstration of what can be done when designing around the Unix philosophy and taking advantage of system tools that already exist rather than reinventing the wheel and re-programming all of those tools into the application. Practices like this might decrease development time and increase the ease of developing cross-platform applications but they often also produce a less than desirable user experience.