All You’ve Ever Wanted To Know About Compilers

They say that in order to understand recursion, you must first understand recursion. Once you master that concept, you might decide that it’s time to write your own compiler that can compile itself as a fun side project. According to [Warren] aka [DoctorWkt], who documented every step of writing this C compiler from scratch, a true compiler will be able to do that.

Some of the goals for the project included self-compiling, focusing on a real hardware platform, practicality, and simplicity. [Warren] outlines a lot of the theory of compilers as well, including all the lexical, grammar, and semantic analysis and then the final translation into assembly language, but really focuses on making this compiler one for practical use rather than just a theoretical implementation. He focuses on Intel x86-64 and 32-bit ARM platforms too, which are widely available.

This project is a long read and very thoroughly documented at around 100,000 words, so if you’ve ever been interested in compilers this is a great place to start. There are a lot of other great compiler tools floating around too, like the Compiler Explorer which shows you generated code as you write in a higher level language.

[via Hackaday.io]

36C3: Open Source Is Insufficient To Solve Trust Problems In Hardware

With open source software, we’ve grown accustomed to a certain level of trust that whatever we are running on our computers is what we expect it to actually be. Thanks to hashing and public key signatures in various parts in the development and deployment cycle, it’s hard for a third party to modify source code or executables without us being easily able to spot it, even if it travels through untrustworthy channels.

Unfortunately, when it comes to open source hardware, the number of steps and parties involved that are out of our control until we have a final product — production, logistics, distribution, even the customer — makes it substantially more difficult to achieve the same peace of mind. To make things worse, to actually validate the hardware on chip level, you’d ultimately have to destroy it.

On his talk this year at the 36C3, [bunnie] showed a detailed insight of several attack vectors we could face during manufacturing. Skipping the obvious ones like adding or substituting components, he’s focusing on highly ambitious and hard to detect modifications inside an IC’s package with wirebonded or through-silicon via (TSV) implants, down to modifying the netlist or mask of the integrated circuit itself. And these aren’t any theoretical or “what if” scenarios, but actual possible options — of course, some of them come with a certain price tag, but in the end, with the right motivation, money is only a detail.

Continue reading “36C3: Open Source Is Insufficient To Solve Trust Problems In Hardware”

An Open Assistive Robotic Arm To Help People Feed Themselves

Despite being otherwise capable, not everyone is able to feed themselves. [Julien]’s robot arm project aims to bring this crucial independence back to those people. Assistive devices in this space do exist, but as always they’re prohibitively expensive and the approval process is a nightmare. The development of the arm started by working closely with people who needed it at a local hospital. We note with approval, quite a few cardboard mock-ups to get the size and shape right before more formal work was done in CAD.

The robot arm only has to support a very light payload so its construction can be quite light. A frame of steel rods or plywood is all that’s required. We like how the motion is transferred from stepper motors to the joints of the arm by generously sized timing belts allowing the weight of the arm to remain towards the base. The team behind the project has gotten it to a point, but they’re hoping it will inspire community involvement as they move forward with it.

It’s worth noting, this is not the first assistive eating aid we’ve covered.

File Systems For Tiny Devices

Sometimes you build a computer and use it every day. Sometimes you build a different type of computer and it sits alone on a mountaintop for years. The design considerations for these two setups are remarkably different, right down to the type of file system used. For small computers like [Jo] is using, and for the amount of time they sit alone in remote locations, he decided to build his own file system for them.

Known as JesFs ([Jo]’s embedded serial File system), the file system is for SPI Flash and intended for use in scientific data logging. It can be used on the chip-scale processors found in many development boards, and is robust enough to use in applications where remoteness is a concern. It has a small RAM footprint, is completely open source, includes wear leveling, and has a number of security features built-in as well.

Some of the benefits of using a file system on such a tiny chip aren’t immediately obvious unless you’re doing a lot of data logging, but it does allow you to change virtually any aspect of the firmware much more easily if everything is accessible as a file, and not something you would have to change by reflashing the whole chip, for example. There are also a number of traps that you can easily fall into when working with file systems for tiny devices.

Robot Vs. Superbug

Working in a university or research laboratory on interesting, complicated problems in the sciences has a romanticized, glorified position in our culture. While the end results are certainly worth celebrating, often the process of new scientific discovery is underwhelming, if not outright tedious. That’s especially true in biology and chemistry, where scaling up sample sizes isn’t easy without a lot of human labor. A research group from Reading University was able to modify a 3D printer to take some of that labor out of the equation, though.

This 3D printer was used essentially as a base, with the printing head removed and replaced with a Raspberry Pi camera. The printer X/Y axes move the camera around to all of the different sample stored in the print bed, which allows the computer attached to the printer to do most of the work that a normal human would have had to do. This allows them to scale up massively and cheaply, presumably with less tedious inputs from a large number of graduate students.

While the group hopes that this method will have wide applicability for any research group handling large samples, their specific area of interest involves researching “superbugs” or microbes which have developed antibiotic resistance. Their recently-published paper states that any field which involves bacterial motility, colony growth, microtitre plates or microfluidic devices could benefit from this 3D printer modification.

Simplified AI On Microcontrollers

Artificial intelligence is taking the world by storm. Rather than a Terminator-style apocalypse, though, it seems to be more of a useful tool for getting computers to solve problems on their own. This isn’t just for supercomputers, either. You can load AI onto some of the smallest microcontrollers as well. Tensorflow Lite is a popular tool for this, but getting it to work on your particular microcontroller can be a pain, unless you’re using an Espruino.

This project adds support for Tensorflow to this class of microcontrollers without having to fuss around with obtuse build tools. Basically adding a single line of code creates an instance, all without having to compile anything or even reboot. Tensorflow is a powerful software tool for microcontrollers, and having it this accessible now is a great leap forward.

So, what can you do with this tool? The team behind this build is using Tensorflow on an open smart watch that can be used to detect hand gestures and many other things. They also opened up these tools for use in a browser, which allows use of the AI software and emulates an Espruino without needing a physical device. There’s a lot going on with this one, and it’s a bonus that it’s open source and ready to be turned into anything you might need, like turning yourself into a Street Fighter.

US Air Force Says They’re Developing An Open Source Jet Engine; We Say Show Us The Design

The economies of scale generally dictate that anything produced in large enough numbers will eventually become cheap. But despite the fact that a few thousand of them are tearing across the sky above our heads at any given moment, turbine jet engines are still expensive to produce compared to other forms of propulsion. The United States Air Force Research Laboratory is hoping to change that by developing their own in-house, open source turbine engine that they believe could reduce costs by as much as 75%.

The Responsive Open Source Engine (ROSE) is designed to be cheap enough that it can be disposable, which has obvious military applications for the Air Force such as small jet-powered drones or even missiles. But even for the pacifists in the audience, it’s hard not to get excited about the idea of a low-cost open source turbine. Obviously an engine this small would have limited use to commercial aviation, but hackers and makers have always been obsessed with small jet engines, and getting one fired up and self-sustaining has traditionally been something of a badge of honor.

Since ROSE has been developed in-house by the Air Force, they have complete ownership of the engine’s intellectual property. This allows them to license the design to manufacturers for actual production rather than buying an existing engine from a single manufacturer and paying whatever their asking price is. The Air Force will be able to shop ROSE around to potential venders and get the best price for fabrication. Depending on how complex the engine is to manufacture, even smaller firms could get in on the action. The hope is that this competition will serve to not only improve the design, but also to keep costs down.

We know what you’re thinking. Where is the design, and what license is it released under? Unfortunately, that aspect of ROSE seems unclear. The engine is still in development so the Air Force isn’t ready to show off the design. But even when it’s complete, we’re fairly skeptical about who will actually have access to it. Open Source is in the name of the project and to live up to that the design needs to be available to the general public. From a purely tactical standpoint keeping the design of a cheap and reliable jet engine away from potential enemy states would seem to be a logical precaution, but is at cross purposes to what Open Source means. Don’t expect to be seeing it on GitHub anytime soon. Nuclear reactors are still fair game, though.

[Thanks to Polymath99 for the tip.]