The Compromises Of Raspberry Pi Hardware Documentation

June 23, 2021 by Maya Posch 86 Comments

[Rowan Patterson] informed us about a recent ticket he opened over at the Raspberry Pi Documentation GitHub repository. He asked about the the lack of updates to the Raspberry Pi 4’s USB-C power schematics for this board. You may recall that the USB-C power issue was covered by us back in July of 2019, yet the current official Raspberry Pi 4 schematics still show the flawed implementation, with the shorted CC pins, nearly two years later.

[Alasdair Allan], responsible for the Raspberry Pi documentation, mentioned that they’re in the process of moving their documentation from Markdown to AsciiDoc, and said that they wouldn’t have time for new changes until that was done. But then [James Hughes], Principal Software Engineer at Raspberry Pi, mentioned that the schematics may not be updated even after this change due to a of lack of manpower.

As [James] emphasized, their hardware will probably never be open, due to NDAs signed with Broadcom. The compromise solution has always been to publish limited peripheral schematics. Yet now even those limited schematics may not keep up with board revisions.

An easy fix for the Raspberry Pi 4’s schematics would be for someone in the community to reverse-engineer the exact changes made to the Raspberry Pi 4 board layout and mark these up in a revised schematic. This should be little more than the addition of a second 5.1 kΩ resistor, so that CC1 and CC2 each are connected to ground via their own resistor, instead of being shorted together.

Still, you might wish that Raspberry Pi would update the schematics for you, especially since they have updated versions internally. But the NDAs force them to duplicate their efforts, and at least right now that means that their public schematics do not reflect the reality of their hardware.

PyGame Celebrates 20 Years By Releasing PyGame 2.0

October 28, 2020 by Tom Nardi 7 Comments

Python is an absolutely fantastic language for tossing bits of data around and gluing different software components together. But eventually you may find yourself looking to make a program with an output a bit more advanced than the print() statement. Once you’ve crossed into the land of graphical Python programming, you’ll quickly find that the PyGame library is often recommended as a great way to start pushing pixels even if you’re not strictly making a game.

Today, the project is celebrating an incredible milestone: 20 years of helping Python developers turn their ideas into reality. Started by [Pete Shinners] in 2000 as a way to interface with Simple DirectMedia Layer (SDL), the project was quickly picked up by the community and morphed into a portable 2D/3D graphics library that lets developers deploy their code on everything from Android phones to desktop computers.

Things haven’t always gone smoothly for the open source library, and for awhile development had stalled out. But the current team has been making great progress, and decided today’s anniversary was the perfect time to officially roll out PyGame 2.0. With more than 3,300 changes committed since the team started working on their 2.0 branch in July of 2018, it’s a bit tough to summarize what’s new. Suffice to say, the library is more capable than ever and is ready to tackle everything from simple 2D art up to 4K GPU-accelerated applications.

If you haven’t given PyGame a try in awhile, don’t worry. The team has put special effort into making the library as backwards compatible as possible, so if you’ve got an old project kicking around that you haven’t touched in a decade, it should still run against the latest and greatest version. If you’ve never used it before, the team says they’ll soon be releasing new tutorials that show you how to get the most out of this new release.

Whether you’re putting together your own implementation of Conway’s “Game of Life” or creating the graphical front-end for your own Linux distribution, PyGame is a powerful tool to have in your collection. Our sincere congratulations to all PyGame developers, past and present, for making it to this auspicious occasion. We can’t wait to see what the next decade will bring.

[Thanks to deshipu for the tip.]

WiringPi Library To Be Deprecated

September 18, 2019 by Maya Posch 60 Comments

Since the release of the original Raspberry Pi single board computer, the WiringPi library by [Gordon] has been the easy way to interface with the GPIO and peripherals – such as I2C and SPI – on the Broadcom SoCs which power these platforms. Unfortunately, [Gordon] is now deprecating the library, choosing to move on rather than deal with a community which he no longer recognizes.

Among the points which he lists are the (commercial) abuse of his code, and the increasing amount of emails and messages on social media from folk who either failed to read the friendly manual, or are simply rude and inconsiderate. As [Gordon] puts it, WiringPi was never meant to be statically linked into code, nor to be used with anything other than C and RTB BASIC programmers. He never supported the use of the library with other languages, or having it statically integrated into some Java/JavaScript/NodeJS project.

As this secondary use is what’s draining the fun out of the project, he has decided to put out one final release, before making it a closed-source project, for use by himself and presumably paying clients. What the impact of this will be has to be seen. Perhaps a new fork will become the new ‘WiringPi’?

Suffice it to say, none of this is a good thing. The illegal use of open source code and the support nightmare that gets poured on the authors of said code by less than informed users is enough to drive anyone away from putting their projects out there. Fighting abuse and junking the ‘spam’ is one way to deal with it, but who has the time and energy (and money) for this?

What are your thoughts on this news, and this issue in general? How should an open source developer deal with it?

Thanks to [Dirk-Jan Faber] for sending this one in.

10 Year Old Bug Crushed By Hacker On A Mission

October 31, 2017 by Christian Trapp 11 Comments

PCI pass through is the ability of a virtualized guest system to directly access PCI hardware. Pass through for dedicated GPUs has just recently been added to the Linux kernel-based virtual machine. Soon afterward, users began to find that switching on nested page tables (NPT), a technology intended to provide hardware acceleration for virtual machines, had the opposite effect on AMD platforms and slowed frame rate down to a crawl.

Annoyed by this [gnif] set out to to fix the problem. His first step was to run graphics benchmarks to isolate the source of the problem. Having identified the culprit in the GPU, [gnif] began to read up on the involved technology stack. Three days of wrapping his head around technical docs allowed [gnif] to find the single line of code that resulted in a faulty memory set up and to implement a basic fix. He then passed the work on to [Paolo Bonzini] at patchwork.kernel.org, who released a more refined patch.

The bug affecting PCI pass through had been around for ten years and had received little attention from the manufacturer. It gained prominence when graphics cards were affected. In the end it took one very dedicated user three days to fix it, and then another day to roll out a patch for Open Source operating systems. In his notes [gnif] points out how helpful AMDs documentation was. With the right to repair in debate, DRMed technical docs and standards locked behind paywalls, [gnif]’s story is a reminder of the importance of accessible quality documentation.

Steve Evans Passes Away, Leaves An Inspiring Legacy

April 24, 2017 by Mike Szczys 27 Comments

It is with great sadness that Hackaday learns of the passing of Steve Evans. He was one of the creators of Eyedrivomatic, the eye-controlled wheelchair project which was awarded the Grand Prize during the 2015 Hackaday Prize.

News of Steve’s passing was shared by his teammate Cody Barnes in a project update on Monday. For more than a decade Steve had been living with Motor Neurone Disease (MND). He slowly lost the function of his body, but his mind remained intact throughout. We are inspired that despite his struggles he chose to spend his time creating a better world. Above you can see him test-driving an Eyedrivomatic prototype which is the blue 3D printed attachment seen on the arm of his chair.

The Eyedrivomatic is a hardware adapter for electric wheelchairs which bridges the physical controls of the chair with the eye-controlled computer used by people living with ALS/MND and in many other situations. The project is Open Hardware and Open Source Software and the team continues to work on making Eyedriveomatic more widely available by continuing to refine the design for ease of fabrication, and has even begun to sell kits so those who cannot build it themselves still have access.

The team will continue with the Eyedrivomatic project. If you are inspired by Steve’s story, now is a great time to look into helping out. Contact Cody Barnes if you would like to contribute to the project. Love and appreciation for Steve and his family may be left as comments on the project log.

ImplicitCAD: Programmatic CAD Built With 3D Printing In Mind

April 18, 2016 by Moritz Walter 26 Comments

Cornerstone of many useful things: This Prusa i3 part was modeled in OpenSCAD.

Programmatic CAD, in particular the OpenSCAD language and IDE, has accompanied the maker movement for a while now. After its introduction in 2009, it quickly found its way into the 3D printing toolbox of many makers and eventually became what could be called an Industry Standard among open hardware labs, makerspaces and tinkerers. The Prusa i3, one of the most popular DIY 3D printers, was designed in OpenSCAD, and even Makerbot, the company that sold 100.000 3D printers, uses the language for its “Customizer” – an online tool that allows users to customize 3D printable models with minimal effort.

OpenSCAD is indeed a wonderful tool, and we have been using it a lot. We have become used to its quirks and accepted working with polygon mesh approximations of the models we are trying to design. We have made our peace with excessive rendering times, scripting workarounds and the pain of creating fillets, and we have learned to keep our aesthetic expectations low. We are happy with the fact that there is a way to programmatically create and share virtually any object, but sometimes we wish there was a better way in the open source world. Hint: there is.

Continue reading “ImplicitCAD: Programmatic CAD Built With 3D Printing In Mind” →

Announcing The Five Finalists For The Hackaday Prize

October 13, 2014 by Mike Szczys 79 Comments

Six months ago we challenged you to realize the future of open, connected devices. Today we see the five finalists vying for The Hackaday Prize.

These five were chosen by our panel of Launch Judges from a pool of fifty semifinalists. All of them are tools which leverage Open Design in order to break down the barriers of entry for a wide range of interests. They will have a few more weeks to polish and refine their devices before [Chris Anderson] joins the judging panel to name the winner.

Starting on the top left and moving clockwise:

ChipWhisperer, an embedded hardware security research device goes deep into the world of hardware penetration testing. The versatile tool occupies an area in which all-in-one, wide-ranging test gear had been previously non-existant or was prohibitively expensive to small-shop hardware development which is so common today.

SatNOGS, a global network of satellite ground stations. The design demonstrates an affordable node which can be built and linked into a public network to leverage the benefits of satellites (even amateur ones) to a greater extent and for a wider portion of humanity.

PortableSDR, is a compact Software Defined Radio module that was originally designed for Ham Radio operators. The very nature of SDR makes this project a universal solution for long-range communications and data transfer especially where more ubiquitous forms of connectivity (Cell or WiFi) are not available.

ramanPi, a 3D printed Raman Spectrometer built around a RaspberryPi with some 3D printed and some off-the-shelf parts. The design even manages to account for variances in the type of optics used by anyone building their own version.

Open Source Science Tricorder, a realization of science fiction technology made possible by today’s electronics hardware advances. The handheld is a collection of sensor modules paired with a full-featured user interface all in one handheld package.

From Many, Five

The nature of a contest like the Hackaday Prize means narrowing down a set of entries to just a few, and finally to one. But this is a function of the contest and not of the initiative itself.

The Hackaday Prize stands for Open Design, a virtue that runs far and deep in the Hackaday community. The 50 semifinalists, and over 800 quarterfinalists shared their work openly and by doing so provide a learning platform, an idea engine, and are indeed the giants on whose shoulders the next evolution of hackers, designers, and engineers will stand.

Whether you submitted an entry or not, make your designs open source, interact with the growing community of hardware engineers and enthusiasts, and help spread the idea and benefits of Open Design.