There’s no better way of improving a project than logging data to make informed decisions on future improvements. When it came to [Brian]’s latest project, an electric bike, he wanted to get as much data as he could from the time he turned it on until the time he was finished riding. He turned to a custom pyBoard-based device (and wrote it up on Hackaday.io), but made it stackable in order to get as much information from his bike as possible.
This isn’t so much an ebike project as it is about a microcontroller platform that can be used as a general purpose device. All of the bike’s controls flow through this device as a logic layer, so everything that can possibly be logged is logged, including the status of the motor and battery at any given moment. This could be used for virtually any project, and the modular nature means that you could scale it up or down based on your specific needs. The device is based on an ARM microcontroller so it has plenty of power, too.
While the microcontroller part is exceptionally useful ([Brian] talks about some of its other uses here and gives us even more data on his personal webpage), we shouldn’t miss the incredible bike that [Brian] built either. It has a 3 kW rear hub motor and can reach speeds of around 60 mph. While we let the commenters below hash out the classic argument of “bicycle vs. motorcyle” we’ll be checking out some electric vehicles that are neither.
When the only tool you have is a hammer, all problems look like nails. And if your goal is to emulate the behavior of an FPGA but your only tools are FPGAs, then your nail-and-hammer issue starts getting a little bit interesting. That’s at least what a group of students at Cornell recently found when learning about the Xilinx FPGA used by a researcher in the 1990s by programming its functionality into another FPGA.
Using outdated hardware to recreate a technical paper from decades ago might be possible, but an easier solution was simply to emulate the Xilinx in a more modern FPGA, the Cyclone V FPGA from Terasic. This allows much easier manipulation of I/O as well as reducing the hassle required to reprogram the device. Once all of that was set up, it was much simpler to perform the desired task originally set up in that 90s paper: using evolutionary algorithms to discriminate between different inputs.
While we will leave the investigation into the algorithms and the I/O used in this project as an academic exercise for the reader, this does serve as a good reminder that we don’t always have to have the exact hardware on hand to get the job done. Old computers can be duplicated on less expensive, more modern equipment, and of course video games from days of yore are a snap to play on other hardware now too.
Thanks to [Bruce Land] for the tip!
In the early 1980s when the 8-bit microcomputer boom was well under way, [Alan Faulds] was a student, and an owner of a Sinclair ZX81. He had ambitions to use it, in his words, “to control the world“, but since the Sinclair lacked an I/O port he was thwarted. He bought an expander board and a couple of I/O card PCBs from the British electronic supplier Maplin in the days when they were a mail order parts stockist rather than a chain of stores chasing Radio Shack’s vacated retail position.
Sadly for [Alan], he didn’t have the cash to buy all the parts to populate the boards, then the pressures of a final year at university intervened, and he never built those Maplin kits. They sat forgotten in their padded envelope for over three decades until a chance conversation with a friend reminded him of his unfinished student project. He sought it out, and set about recreating the board.
The ZX81 had a single port: a PCB edge connector at its rear that exposed all the Z80 processor’s lines. It was notorious for unreliability, as the tiniest vibration when a peripheral was connected would crash the machine. Maplin’s expansion system featured a backplane with a series of edge connector sockets, and cards with bare PCB edge connectors. Back in the 1980s it was easy to find edge connectors of the right size with the appropriate key installed, but not these days. [Alan] had to make one himself for his build.
The I/O card with its 8255 and brace of 74 series chips was a double-sided affair with vias made through the use of little snap-off hand-soldered pins. [Alan] put his ICs in sockets, a sensible choice given that when he powered it up he found he’d put a couple of the 74 chips in the wrong positions. With that error rectified the board worked exactly as it should, giving the little ZX three I/O ports, albeit with one of them a buffered output.
We haven’t featured the little Sinclair micro as often as we should have here at Hackaday, it seems to have been overshadowed by its ZX Spectrum successor. We did show you a VGA ZX81 emulated on an mbed though, and a rather neat color video hack for its Brazilian cousin.
If you have ever spent a while delving into the bare metal of talking to the I/O pins on a contemporary microprocessor or microcontroller you will know that it is not always an exercise for the faint-hearted. A host of different functions can be multiplexed behind a physical pin, and once you are looking at the hardware through the cloak of an operating system your careful timing can be derailed in an instant. For these reasons most of us will take advantage of other people’s work and use the abstraction provided by a library or a virtual filesystem path.
If you have ever been curious enough to peer under the hood of your board’s I/O then you may find [Ken Shirriff]’s latest blog post in which he explores the software stack behind the pins on a BeagleBone Black to be of interest. Though its specifics are those of one device, the points it makes have relevance to many other similar boards.
He first takes a look at the simplest way to access a Beagle Bone’s I/O lines, through virtual filesystem paths. He then explains why relying so heavily on the operating system in this way causes significant timing issues, and goes on to explore the physical registers that lie behind the pins. He then discusses the multiplexing of different pin functions before explaining the role of the Linux device tree in keeping operating system in touch with hardware.
For some Hackaday readers this will all be old news, but it’s safe to say that many users of boards like the BeagleBone Black will never have taken a look beyond the safely abstracted ways to use the I/O pins. This piece should therefore provide an interesting education to the chip-hardware novice, and should probably still contain a few nuggets for more advanced users.
We’ve seen a lot of [Ken]’s work here at Hackaday over the years, mostly in the field of reverse engineering. A few picks are his explanation of the TL431 voltage reference, a complete examination of the 741 op-amp, and his reverse engineering of the 1970s Sinclair Scientific calculator.
We appreciate [Fustini]’s tip on this story.
BeagleBone Black image: BeagleBoard.org Foundation [CC BY-SA 3.0], via Wikimedia Commons.
The Raspberry Pi Model B+ was just released, and now everyone who picks one of those up has a few more GPIO pins to play around with. For the millions of people with the two-year-old version of the Pi, we’re still stuck with the same old, same old: 17 GPIOs on the big header, and that’s about it as far as toggling pins goes.
The Broadcom SoC on the Pi has far more GPIO pins than are broken out on the large header, and a few of those go to the CSI camera interface. These GPIOs can be broken out with a few flat cables (Portuguese, Google Translatrix), giving you four more GPIOs, and this technique can also be used with the new, expanded Model B+.
The CSI camera connector has two I²C lines that go directly to the camera, controllable in Linux as GPIO0 and GPIO1. There are two more GPIO connectors on the CSI connector controllable as GPIO5 and GPIO21. By carefully slicing and soldering wires to a flat cable, these GPIO lines can be broken out onto a breadboard.
There’s a video below demonstrating these GPIO lines being used to control a few LEDs. Of course, anything that is possible with a normal Raspi GPIO is possible with the CSI connector GPIO lines.
Continue reading “Adding GPIOs To The Raspberry Pi With The Camera Interface”
[Emilio] has a Raspberry Pi with a few sensors running totally headless. It’s a great way to gather data and post it on the Internet, but for the rare occasions when the Pi needs to be turned off for maintenance, [Emilio] needs to connect a monitor, a keyboard, and a mouse. Not a perfect solution when a simple pushbutton and indicator LED would suffice. There’s one problem with adding a simple button and LED combo: there’s only one GPIO pin available in the setup. That’s nothing a few resistors won’t fix.
After wiring up a very simple circuit on a piece of perfboard, [Emilio] met his design goal of being able to tell if the Pi was running and giving it a software reset button using only a single GPIO pin. The circuit requires only two resistors, and the software to make everything run – a simple Python script – toggles the pin between input and output, checking if the button is held down for five seconds. If it is, the Raspi powers off for [Emilio]’s routine maintenance.
[Andrew Smallbone] wrote in with a link to his latest open source project. This is phatIO, a USB I/O device that uses a mass storage file system for control. The idea is that any operating system can manipulate files on a USB storage device. This enumerates as mass storage, and any alterations you make to its file system will result in pin manipulation on the I/O header.
We’ve long been Linux advocates and enjoy the fact that everything on a *nix system is a file. This simply extends the idea across multiple platforms. [Andrew’s] guide for the hardware gives an overview of how the system is structured. The top ‘io’ directory contains sub-directories called mode, pins, status, and a few others. Inside the directories are files for each pin. Writing to these files has much the same effect as writing to a data direction register, port register, or reading a pin register on a microcontroller.
The board is not yet in production and the github link to his hardware files gives us a 404 error. But there is code available for several software demos. After the break we’ve included video of the phatIO driving a Larson scanner.
Continue reading “PhatIO Uses File System To Control External Hardware”