Programming languages, like fashion, are very much a matter of personal taste. Professional developers often don’t have much say in which language they’ll use for a given project, either for legacy or team reasons, but if they did have a choice, they’d probably choose the language that works best with the way they think. Some languages just “fit” different brains better than others, and when everything is in sync between language and developer, code just seems to flow effortlessly through the keyboard and onto the screen.
One language that consistently scores at the top of developers’ “most loved” lists is Rust. For a language that started as a personal project and has only existed for a little more than a decade, that’s really saying something. The emphasis Rust puts on safety and performance probably has a lot to do with that. And thanks to its safe concurrency, its memory safety, and its interoperability with C and other languages, Rust has made considerable in-roads with the embedded development community.
To learn more about Rust in embedded systems, James Munns will stop by the Hack Chat. James is an embedded systems engineer, with a history of working on software for a wide range of systems, including safety-critical avionics, and rapidly prototyped IoT systems. He’s a founding member of the Rust Embedded Working Group, as well as a founder of Ferrous Systems, a consultancy focused on systems development in Rust, with a specialty in embedded systems development. James also used to write for Hackaday, so he must be a pretty cool guy. So swing by the Hack Chat and find out where Rust might be able to help you out with your next embedded project.
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about. Continue reading “Embedded Rust Hack Chat”→
Very few people want to invent the universe before they blink their first LED. Sure, with enough interest a lot of folks will drill-down to the atomic level of technology and build their way back up. But there’s something magical about that first time you got your blinky to blink, and knowing how to write makefiles plays no part in that experienc). Now apply that to projects using smartphone as wireless interfaces… how simple can we make it for people?
Jose David Cuartas is working to answer that very question and gives us a guided tour of his progress in this Meta_Processing workshop held during the Hackaday Remoticon. Meta-Processing is an IDE based on — as you’ve probably guessed — Processing, the programming language that unlocked higher-level functionality to anyone who wanted to perform visually-interesting things without becoming software zen masters. The “Meta_” part here is that it can now be done with very limited typing and interchangeably between different spoken languages.
The approach is to take the best of text programming and block programming languages and mash them together. In that way, you don’t type new lines, you add them with a click of the mouse and select the instruction you want to use on that line from a list. It means you don’t need to have the instructions memorized, and avoids typos in your code. The docs for that instruction will be shown on the bottom bar of the IDE to help you with parameters. And the kicker is that since you’re selecting the instructions, choosing any of the IDE’s 14 available spoken languages will update your “code” with translations into the new language.
People learn in many different ways. Having options like this to help people get to blinky very quickly is a great way to break down barriers to understanding and using computers.
The best thing about field-programmable gate arrays (FPGAs), when you have a massively parallel application, is that everything runs in parallel. The worst thing about FPGAs, when you need a lot of stuff to happen in sequence, is that everything runs in parallel. If you have a multi-step computation, for example, you need to break it up into chunks, figure out the timing between them, and make sure that each chunk clears before it is fed new data. This is pipelining, and taking care of all the low-level details yourself is one of the things that can sometimes make FPGA a four-letter word beginning with “F”.
[Julian Kemmerer]’s PipelineC is a C-like language that compiles down into VHDL so that you can use it in an FPGA, and it does the pipelining for you. He has examples of how you’d use it to construct a simple state machine, and after you’ve written a few hundred state machines the long way, you’ll know why this is a good idea.
PipelineC isn’t the only high level synthesis language out there, but it sits in an interesting place. It doesn’t take care of memory or define interfaces. It just takes care of pipelining. We haven’t tried it out yet, but it looks like it would be interesting for moderately complex projects, where the mechanics of pipeline signalling is a hassle, but you don’t require the deluxe treatment. Check it out, and if you like it, let us (and [Julian], natch) know.
If you stay up to date with niche software news, your ears may recently have twitched at the release of a new programming language: V. New hobby-project programming languages are released all the time, you would correctly argue; what makes this one special? The answer is a number of design choices which promote speed and safety: V is tiny and very fast. It’s also in a self-proclaimed alpha state, and though it’s already been used to build some interesting projects, is still at an early stage.
If you have ever worked in software-related industries, the chances are that the word “Rockstar” will elicit a visceral reaction. It’s a word used by a Certain Type Of Manager for an elite software developer who’s so 1337 they don’t play by the rules of ordinary mortals. In reality it’s use is invariably an indication of trouble ahead, either from clueless startups or troublesome rockstar developers making a toxic atmosphere for the mere members of the backing band. Hackaday has a team that brings together a huge breadth of experience, and we’ve been there.
Would you like to be a rockstar developer, but without the heartache? No silly incentives, or even guitars required! [Dylan Beattie] can help, because he’s come up with a specification for the Rockstar programming language, a Turing-complete programming language whose syntax follows the conventions of 1980s rock power ballads. Of course, it’s a joke, and an excuse of some “Certified Rockstar Developer” laptop stickers, but it’s also an entertaining journey into lyrical language and compiler parsing, and the discovery that yes indeed, a singable set of classic rock lyrics can also be a compilable program.
Our particular favourite comes from the scheme used to represent numbers, as sentences in which a decimal is built from the lengths of the sentence words, and poetic licence can be employed to the fullest. The example is
My dreams were ice. A life unfulfilled; wakin' everybody up, taking booze and pills
which line of code places the value 3.1415926535 into a variable called “my dreams”.
There does not appear to be a working Rockstar compiler at the time of writing, but we are sure that the amazing community of Rockstar developers will shortly create one. And we would be hugely disappointed were we not to hear some performative coding from spandex-clad guitar-wielding developers as a result. After all, how else will they get their work noticed!
Shared libraries are our best friends to extend the functionality of C programs without reinventing the wheel. They offer a collection of exported functions, variables, and other symbols that we can use inside our own program as if the content of the shared library was a direct part of our code. The usual way to use such libraries is to simply link against them at compile time, and let the linker resolve all external symbols and make sure everything is in place when creating our executable file. Whenever we then run our executable, the loader, a part of the operating system, will try to resolve again all the symbols, and load every required library into memory, along with our executable itself.
But what if we didn’t want to add libraries at compile time, but instead load them ourselves as needed during runtime? Instead of a predefined dependency on a library, we could make its presence optional and adjust our program’s functionality accordingly. Well, we can do just that with the concept of dynamic loading. In this article, we will look into dynamic loading, how to use it, and what to do with it — including building our own plugin system. But first, we will have a closer look at shared libraries and create one ourselves.