It should probably go without saying that the main reason most people buy an electric vehicle (EV) is because they want to reduce or eliminate their usage of gasoline. Even if you aren’t terribly concerned about your ecological footprint, the fact of the matter is that electricity prices are so low in many places that an electric vehicle is cheaper to operate than one which burns gas at $2.50+ USD a gallon.
Another advantage, at least in theory, is reduced overal maintenance cost. While a modern EV will of course be packed with sensors and complex onboard computer systems, the same could be said for nearly any internal combustion engine (ICE) car that rolled off the lot in the last decade as well. But mechanically, there’s a lot less that can go wrong on an EV. For the owner of an electric car, the days of oil changes, fouled spark plugs, and the looming threat of a blown head gasket are all in the rear-view mirror.
Unfortunately, it seems the rise of high-tech EVs is also ushering in a new error of unexpected failures and maintenance woes. Case in point, some owners of older model Teslas are finding they’re at risk of being stranded on the side of the road by a failure most of us would more likely associate with losing some documents or photos: a disk read error.
Continue reading “Worn Out EMMC Chips Are Crippling Older Teslas”
Throwies occupy a special place in hardware culture — a coin cell battery, LED, and a magnet that can be thrown into an inaccessible place and stick there as a little beacon of colored light. Many of us will fondly remember this as a first project. Alas, time marches inevitably on, and launching cheerful lights no longer teaches me new skills. With a nod to those simpler times, I’ve been working on the unusual idea of building a fully functional server that can be left in remote places and remain functional, like a throwie (please don’t actually throw it). It’s a little kooky, yet should still deliver a few years of occasional remote access if you leave it somewhere with sunlight.
A short while ago, I described the power stages for this solar-powered, cloud accessible Linux server. It only activates on demand, so a small solar cell and modest battery are sufficient to keep the whole show running.
Where we left off, I had a solar cell that could charge a battery, and provide regulated 12 V and 5 V output. For it to be a functional device, there are three high level problems to solve:
- It must be possible to set up the device without direct physical access
- You must be able to remotely turn it on and off as needed.
- It needs to be accessible from the Internet.
The funny thing is, this hardware reminds me of a satellite. Of course it’s not meant to go into space, but I do plan to put it somewhere not easy to get to again, it runs off of solar power, and there’s a special subsystem (ESP8266) to tend the power, check for remote activation, and turn the main computer (Raspberry Pi 3) on and off as necessary. This sounds a lot like space race tech, right?
As I have a bit more code than usual to share with you today, I’ll discuss the most interesting parts, and provide links to the full firmware files at the end of the article.
Continue reading “The Linux Throwie: A Non-Spacefaring Satellite”
The PocketBeagle single-board computer is now a few months old, and growing fast like its biological namesake. An affordable and available offering in the field of embedded Linux computing, many of us picked one up as an impulse buy. For some, the sheer breadth of possibilities can be paralyzing. (“What do I do first?”) Perhaps a development board can serve as a starting point for training this young puppy? Enter the BaconBits cape.
When paired with a PocketBeagle, everything necessary to start learning embedded computing is on hand. It covers the simple basics of buttons for digital input, potentiometer for analog input, LEDs for visible output. Then grow beyond the basics with an accelerometer for I²C communication and 7-segment displays accessible via SPI. Those digging into system internals will appreciate the USB-to-serial bridge that connects to PocketBeagle’s serial console. This low-level communication will be required if any experimentation manages to (accidentally or deliberately) stop PocketBeagle’s standard USB network communication channels.
BaconBits were introduced in conjunction with the E-ALE (embedded apprentice Linux engineer) training program for use in hands-on modules. The inaugural E-ALE session at SCaLE 16X this past weekend had to deal with some last-minute hiccups, but the course material is informative and we’re confident it’ll be refined into a smooth operation in the near future. While paying for the class will receive built hardware and in-person tutorials to use it, all information – from instructor slides to the BaconBits design – is available on Github. Some of us will choose to learn by reading the slides, others will want their own BaconBits for independent experimentation. And of course E-ALE is not the only way to learn more about PocketBeagle. Whichever way people choose to go, the embedded Linux ecosystem will grow, and we like the sound of that!
JeVois is a small, open-source, smart machine vision camera that was funded on Kickstarter in early 2017. I backed it because cameras that embed machine vision elements are steadily growing more capable, and JeVois boasts an impressive range of features. It runs embedded Linux and can process video at high frame rates using OpenCV algorithms. It can run standalone, or as a USB camera streaming raw or pre-processed video to a host computer for further action. In either case it can communicate to (and be controlled by) other devices via serial port.
But none of that is what really struck me about the camera when I received my unit. What really stood out was the demo mode. The team behind JeVois nailed an effective demo mode for a complex device. That didn’t happen by accident, and the results are worth sharing.
Continue reading “JeVois Machine Vision Camera Nails Demo Mode”
[Films By Kris Hardware] has started quite an interesting YouTube series on hacking and owning a PogoPlug Mobile v4. While this has been done many times in the past, he gives a great step by step tutorial. The series so far is quite impressive, going into great detail on how to gain root access to the device through serial a serial connection.
PogoPlugs are remote-access devices sporting ARM processor running at 800 MHz, which is supported by the Linux Kernel. The version in question (PogoPlug Mobile v4) have been re-purposed in the past for things like an inexpensive PBX, an OpenWrt router and even a squeezebox replacement. Even if you don’t have a PogoPlug, this could be a great introduction to hacking any Linux-based consumer device.
So far, we’re at part three of what will be an eight-part series, so there’s going to be more to learn if you follow along. His videos have already covered how to connect via a serial port to the device, how to send commands, set the device up, and stop it calling home. This will enable the budding hacker to make the PogoPlug do their bidding. In this age of the cheap single-board Linux computer, hacking this type of device may be going out of style, but the skills you learn here probably won’t any time soon.
Continue reading “PogoPlug Hacking: A Step By Step Guide To Owning The Device”
[Sami Pietikäinen] was working on an embedded Linux device based on an Atmel SAMA5D3x ARM-A5 processor. Normally, embedded Linux boxes will boot up off of flash memory or an SD card. But if you’re messing around, or just want to sidestep normal operation for any reason, you could conceivably want to bypass the normal boot procedure. Digging around in the chip’s datasheet, there’s a way to enter boot mode by soldering a wire to pull the BMS pin. As [Sami] demonstrates, there’s also a software way in, and it makes use of
mmap, a ridiculously powerful Linux function that you should know about.
Continue reading “Flashing An ARM With No Soldering”
Are you already comfortable working with Serial Peripheral Interface (SPI) parts and looking for a challenge? We suspect many of you have cut your teeth on 8-bit through 32-bit microcontrollers but how much time have you spent playing with hardware interfaces on embedded Linux? Here a new quest, should you choose to accept it. [Matt Porter] spoke in detail about the Linux SPI Subsystem during his presentation at FOSDEM 2017. Why not grab an embedded Linux board and try your hand at connecting some extra hardware to one of the SPI buses?
The hardware side of this is exactly what you’d expect from any embedded SPI you’ve worked on: MOSI, MISO, a clock, and a slave select. [Matt] gives a succinct overview of SPI and reading datasheets. Our own [Elliot Williams] has done an excellent job of digging through the basics and most common gotchas if you need to get up to speed on all the SPI basics.
The fun details in the talk start at about 18:30 into the video when [Matt] jumps into the Linux side of SPI. You need a controller driver and a protocol driver. The controller driver is responsible for dealing with the pins (actual hardware) and the protocol driver handles the job of making sense of the SPI packets (messages containing any number of transfers) going in or out. In other words, the controller drive just want bits and pushes them in or out on hardware, the protocol driver makes those bits meaningful to the Linux system.
Adding SPI devices (think devices like LCDs and sensors) to your own embedded systems means telling the OS the particulars about that hardware, like max speed and SPI mode. There are three ways to handle this but the Device Tree is the preferred method for modern systems. This paves the way for the controller driver which implements an API set that the Linux SPI subsystem will use to work with your new hardware.
Protocol drivers follow the standard Linux driver model and are pretty straight forward. With these two drivers in place the new device is hooked into the OS and opens up common SPI API calls: spi_async(), spi_sync(), spi_write(), and spi_read(), and a few others.
Continue reading “SPI On Embedded Linux”