[Mike Harrison] produces so much quality content that sometimes excellent material slips through the editorial cracks. This time we noticed that one such lost gem was [Mike]’s reverse engineering of the 6th generation iPod Nano display from 2013, as caught when the also prolific [Greg Davill] used one on a recent board. Despite the march of progress in mobile device displays, small screens which are easy to connect to hobbyist style devices are still typically fairly low quality. It’s easy to find fancier displays as salvage but interfacing with them electrically can be brutal, never mind the reverse engineering required to figure out what signal goes where. Suffice to say you probably won’t find a manufacturer data sheet, and it won’t conveniently speak SPI or I2C.
After a few generations of strange form factor exploration Apple has all but abandoned the stand-alone portable media player market; witness the sole surviving member of that once mighty species, the woefully outdated iPod Touch. Luckily thanks to vibrant sales, replacement parts for the little square sixth generation Nano are still inexpensive and easily available. If only there was a convenient interface this would be a great source of comparatively very high quality displays. Enter [Mike].
This particular display speaks a protocol called DSI over a low voltage differential MIPI interface, which is a common combination which is still used to drive big, rich, modern displays. The specifications are somewhat available…if you’re an employee of a company who is a member of the working group that standardizes them — there are membership discounts for companies with yearly revenue below $250 million, and dues are thousands of dollars a quarter.
Fortunately for us, after some experiments [Mike] figured out enough of the command set and signaling to generate easily reproduced schematics and references for the data packets, checksums, etc. The project page has a smattering of information, but the circuit includes some unusual provisions to adjust signal levels and other goodies so try watching the videos for a great explanation of what’s going on and why. At the time [Mike] was using an FPGA to drive the display and that’s certainly only gotten cheaper and easier, but we suspect that his suggestion about using a fast micro and clever tricks would work well too.
It turns out we made incidental mention of this display when covering [Mike]’s tiny thermal imager but it hasn’t turned up much since them. As always, thanks for the accidental tip [Greg]! We’re waiting to see the final result of your experiments with this.
Most of us have our fair share of digital debris. After all, with drives measured in one-million-million byte increments it’s tempting to never delete anything. The downside is you may never be able to find anything either. [Johnny Noble] must have gotten pretty fed up with clutter when he decided to formalize and publish his own numeric system for organizing everything he comes in contact with. It’s called Johnny Decimal and it’s actually pretty simple!
This is of course a play on words for the Dewey Decimal system. Dewey is one of a variety of information organization systems used by libraries to sort the books on their shelves. It’s based on moving books into sets of fixed, predefined categories which are uniform across all users of the Dewey. To locate a volume the user composes categories of increasing specificity to build a number which specifies the approximate space a particular book should live in. Each individual volume has a slightly more verbose assigned number which includes the author’s name to reduce confusion in cases where there are multiple works. Wikipedia has an instructive example which you can see here.
Johnny Decimal works similarly but [Johnny] has a specific method he’s devised for the user to create their own categories with somewhat less specificity than Dewey. This makes it less onerous for the user to adapt to their needs, and if it’s easier to use it’s more likely to be used. I won’t spoil the process here, go read his site for instructions.
Ok so why bother? [Johnny] hints at it, but part of the point is to force the user to think about organization in the first place. With no system and an endless torrent of incoming files it’s easy to end up with the giant “~/Downloads” of doom and never improve from there. But with a clearly defined system (which is easy to execute!) the bar to improve things gets much lower. Certainly the thought of a well-organized file system gives us the shivers!
If you’re interested in implementing it in your own systems, the Johnny Decimal site has many pages devoted to explaining how to put together areas and categories, how to handle running out of buckets, the process for developing your own system, and more. If you try it and have luck, send us a note! We’d love to hear about anything you discover. If you’ll excuse us, we’re off to go fix up our parts bins with a marker and some sticky notes.
Here at Hackaday, we love knobs and buttons. So what could be better than one button? How about 16! No deep philosophy about the true nature of Making here; [infovore], [tehn], and [shellfritsch] put together a very slick, very adaptable bank of 16 analog faders for controlling music synthesis. If you don’t recognize those names it might help to mention that [tehn] is one of the folks behind monome, a company built on their iconic grid controller. Monome now produces a variety of lovingly crafted music creation tools.
Over the years we’ve written about some of the many clones and DIY versions of the monome grid controller, so it’s exciting to see an open source hardware release by the creators themselves!
The unambiguously named 16n follows in the footsteps of the monome grid in the sense that it’s not really for something specific. The grid is a musical instrument insofar as it can be connected to a computer (or a modular synth, etc) and used as a control input for another tool that creates sound. Likewise, the 16n is designed to be easily integrated into a music creation workflow. It can speak a variety of interfaces, like purely analog control voltage (it has one jack per fader), or i2c to connect to certain other monome devices like Ansible and Teletype. Under the hood, the 16n is actually a Teensy, so it’s fluent in MIDI over USB and nearly anything else you can imagine.
Filesystems for computers are not the best bet for embedded systems. Even those who know this fragment of truth still fall into the trap and pay for it later on while surrounded by the rubble that once was a functioning project. Here’s how it happens.
The project starts small, with modest storage needs. It’s just a temperature logger and you want to store that data, so you stick on a little EEPROM. That works pretty well! But you need to store a little more data so the EEPROM gets paired with a small blob of NOR flash which is much larger but still pretty easy to work with. Device settings go to EEPROM, data logs go to NOR. That works for a time but then you remember that people on the Internet are all about the Internet of Things so it’s time to add WiFi. You start serving a few static pages with that surprisingly capable processor and bump into storage problems again so the NOR flash gets replaced with an SD card and now the logs go there too. Suddenly you’re dealing with multiple files and want access on a computer so a real filesystem is in order. FAT is easy, so the card grows a FAT filesystem. Everything is great, but you start to notice patches missing from the logs. Then the SD card gets totally corrupted. What’s going on? Let’s take a look at the problem, and how to reach embedded file nirvana.
Hitting the electronic surplus shop is probably old hat to most of our readership. Somewhere, everyone’s got that little festering pile of hardware they’re definitely going to use some day. An old fax is one thing, but how would your partner feel if you took home an entire pallet-sized gene sequencing rig? Our friend [kaspar] sent along an interesting note that the folks at Swiss hackerspace Hackteria got their hands on an Illumina HiSeq 2000 last year (see funny “look what we got!” photo at top) and have generated a huge amount of open documentation about whats inside and how to use it.
Okay first off, what the heck is this machine anyway? The HiSeq is designed to automatically perform the sequencing step of Illumina’s proprietary multi step gene sequencing process (see manufacturer’s glossy for more), and to do so with minimal human intervention. That means that the unit contains a microfluidics system to manipulate samples, an extremely high performance optical scan system complete with controllable stage, imager, fluorescence modes, etc, and lots of other things this author isn’t sufficiently trained to guess at.
The folks at Hackteria have done a pretty thorough teardown of the system and produced block diagrams of most of its modules. They’ve also run some of the tools and recorded logs of what they were up to, including the serial commands sent to and from the machine to control certain subsystems. Of course a tool like this was meant to be driven by Illumina’s specific software, but unusually those are available and surprisingly usable which is how the aforementioned logs were captured. Right now it looks like Hackteria has put together tools to use the system as a fluorescent microscope.
Oddly the most interesting thing here might be how available these systems are. It appears that they’re being replaced en masse and have become easily available in the range of thousands of dollars on the secondary market. At that price point they’re almost worth snapping up for the enclosure and parts! But we prefer Hackteria’s goal of enabling the Citizen Scientist to make use of these incredible machines for their intended purpose. Who knows what exciting projects we’ll find when hackers start sequencing their cats!
Interfacing with the outside world is a fairly common microcontroller task. Outside of certain use cases microcontrollers are arguably primarily useful because of how easily they can interface with other devices. If we just wanted to read and write some data we wouldn’t have gotten that Arduino! But some tasks are more common than others; for instance we’re used to being on the master side of the interface equation, not the slave side. (That’s the job for the TI engineer who designed the temperature sensor, right?) As [Pat] discovered when mocking out a missing SPI GPIO extender, sometimes playing the other role can contain unexpected difficulties.
The simple case for a SPI slave is exactly that: simple. SPI can be wonderful in its apparent simplicity. Unlike I2C there are no weird addressing schemes, read/write bits, stop and start clock conditions. You toggle a clock line and a bit of data comes out, as long as you have the right polarity schemes of course. As a slave device the basic algorithm is of commensurate complexity. Setup an interrupt on the clock pin, wait for your chip select to be asserted, and on each clock edge shift out the next bit of the current word. Check out [Pat]’s eminently readable code to see how simple it can be.
But that last little bit is where the complexity lies. When you’re the master it’s like being the apex predator, the king of the jungle, the head program manager. You dictate the tempo and everyone on the bus dances to the beat of your clock edge. Sure the datasheet for that SRAM says it can’t run faster than 8 MHz but do you really believe it? Not until you try driving that clock a little quicker to see if there’s not a speedier transfer to be had! When you’re the slave you have to have a bit ready every clock edge. Period. Missing even a single bit due to, say, an errant print statement will trash the rest of transaction in ways which are hard to detect and recover from. And your slave code needs to be able to detect those problems in order to reset for the next transaction. Getting stuck waiting to send the 8th bit of a transaction that has ended won’t do.
Check out [Pat]’s very friendly post for a nice refresher on SPI and their discoveries working through the problems of building a SPI slave. There are some helpful tips about how to keep things responsive in a device performing other tasks.
If adding a cell modem is dealing with a drama queen of a hardware component, then choosing from among the many types of modules available turns the designer into an electronics Goldilocks. There are endless options for packaging and features all designed to make your life easier (or not!) so you-the-designer needs to have a clear understanding of the forces at work to come to a reasonable decision. How else will Widget D’lux® finally ship? You are still working on Widget D’lux®, aren’t you?
OK, quick recap from last time. Cell modems can be used to add that great feature known as The Internet to your product, which is a necessary part of the Internet of Things, and thus Good. So you’re adding a cell modem! But “adding a cell modem” can mean almost anything. Are you aiming to be Qualcomm and sue Apple build modems from scratch? Probably not. What about sticking a Particle Electron inside to bolt something together quickly? Or talk to Telit and put a bare modem on a board? Unless you’re expecting to need extremely high volume and have a healthy appetite for certification glee, I bet you’ve chosen to get a modem with as many existing certifications as possible, which takes us to where we are today. Go read the previous post if you want a much more elaborate discussion of your modem-packaging options and some of the trade offs involved. Continue reading “Finding the Goldilocks Cell Module”→