A quick look at the pinouts of an Intel 8086 & 8088 processor reveals a 20 bit address bus. There was high demand for the ability to address 1 meg (2^20) of address space, and Intel delivered. However, a curious individual would wonder how they can achieve such a feat with only 16 bit registers. Intel solved this riddle by combining two registers so they could make it compatible with code written for the 8008, 8080 & 8085. The process they use can be a bit confusing when trying to figure out where to locate your code in the ROM. In this article, we are going to go over the basics of how the Physical Address is calculated and how to locate your code correctly in ROM.
In a monumental effort to confuse young budding computer scientists in the late 70’s, Intel broke its 1 meg of address space into four 64k chunks, with each chunk represented by a 16 bit Segment Register. The value in a Segment Register, called the Segment Address can be thought of as the base address (0000h) of one of the 64k chunks. The address within the 64k chunk is found by an Offset Address. The combination of the Segment Address with the Offset Address is called the Logical Address, and can be transformed to form the elusive Physical Address. In a normal instruction fetch, the Segment Address is stored in the Code Segment (CS) register and the Offset Address is taken from the Instruction Pointer. So the Logical Address will be CS:IP or for example FFF0h:C000h.
The formation of the Physical Address is done by multiplying the Segment Address by 16, and then adding it to the Offset Address. By multiplying the Segment Address by 16, you turn it into a 20 bit value by appending four zero’s to the right side. This calculation is done by a dedicated adder within the processor. But you need to know how the addresses in your program are turned into a Physical Address if you want to know where to locate the code in ROM. This will become more clear below.
The Reset Vector
Now that we are thoroughly confused about the extremely logical and straight-forward internal workings of the x86 address calculations, we can move on to why this information is useful. When the 8086 processor recovers from a hardware reset, the very first address it puts out is FFFF0. This means PINS A0 – A3 are LOW, and A4 – A19 are HIGH.
FFFF0 is the Physical Address. So the Logical Address would be FFFF:0000. With FFFF coming from the Code Segment (CS) Register and 0000 coming from the Instruction Pointer (IP) Register. These are the states of the registers upon reset.
Now, you might have noticed that FFFF0 is really really really really close to the bottom of our memory map. Indeed, it is only 16 bytes away. So the first instruction has to be a far jump to somewhere higher up in memory, and load the Code Segment and Instruction Pointer to the place where your program actually starts. What a brilliant design!Why Knowing This is Important
Want to roll your own x86 computer from scratch? Consider this schematic (pdf warning) from [Scott’s] 8088 SCB project. Take a look at the processor – he’s only using 16 of the address lines. For the ROM, he’s using a 2764 8k x 8 EPROM, which has 13 address pins. So the question is: where in the ^*#$ do you locate the code in the ROM??? Wait…is it…0000h? Ohhh no, that would be WAY to easy.
First, we have to figure out the reset vector address that will be placed on the EPROM’s address pins. The 8088 will put FFFF0 on its address bus. But from the hardware’s perspective, this address is actually 7FF0.
But wait, there’s more! The 2764 EPROM only has 13 address pins, A0 – A12. This means that when the processor puts FFFF0 onto the address bus, the address seen by the EPROM will actually be 1FF0.
If you still haven’t had enough, now is where you figure out how to get your code (with the reset instruction) into the correct place on the ROM. In this case, the FAR jmp must be located at 1FF0. This is generally done with what is known as a Locator – a program the strips the .EXE generated from the linker into something that can be loaded into ROM. There are not many of these programs around, and if you’re lucky enough to get your hands on one, please let us know in the comments. I have yet to locate Intel’s TLOC.exe, and Paradigm has ignored my requests for theirs.
Below is a hex dump showing the correct placement of the reset vector for [Scott’s] 8088 SBC. The EA hex instruction is a far jump. Far means outside of the 64k segment.
Anyone motivated to make their own x86 SBC now? [Wichit] made this 80C188 SBC, and provides a good starting point. I’ll stick with Arduino.
Note: The screenshots for the binary/hex converter came from here.
Filed under: Ask Hackaday, Hackaday Columns
There’s a lot to learn from this 1966 Army training film about the International Morse Code, but the most crucial component of good keying is rhythm. A young man named [Owens] demonstrates very clean keying, and the instructor points out that skill is the product of sending uniform and short dits, uniform and short dahs, and correct spacing between dits, dahs, letters, and words.
Throughout the film, there are title cards in a typeface that shows the stroke order of military printing. The instructor points this out after a brief interlude about the phonetic alphabet (Alpha, Bravo, Charlie, &c). Right away, we see that the Morse Code for ‘H’ is four dits that gallop with the rhythm of a horse in a hurry to get to the hotel.
Such clever and memorable pictures are painted for a few other letters. We wish he would have covered them all, but that’s not the aim of this film. The Army is more concerned with good, clean rhythm and proper spacing that marks the difference between ‘low’ planes and ‘enemy’ planes. There’s a simple, three-step plan to getting what is called a ‘good fist’, and the Army demonstrates this in the best possible way: a giant J-38 and fake hand descending from the ceiling to match. Yes, really.
The first step is to adjust the key to ensure good contact alignment, proper gap spacing, and ideal spring tension. The second step is to develop good technique by resting one’s elbow on the table and holding the key rather than slapping it. The third step is simply to practice. Learning through imitation is helpful, as is taping one’s practice sessions and playing them back. [Owens] likes to use an RD-60 code recorder, which immortalizes his signals in ink.
Retrotechtacular is a weekly column featuring hacks, technology, and kitsch from ages of yore. Help keep it fresh by sending in your ideas for future installments.
Filed under: Hackaday Columns, Retrotechtacular
For one reason or another, we’ve been seeing a lot of builds featuring the Teensy 3.1 filtering in on the tip line recently. In retrospect, it’s somewhat obvious; it’s a good board that’s cheap and fast. Yes, somehow [Paul] hit all three in the good/cheap/fast mutually exclusive triumvirate.
Now, there’s a new Teensy. It’s the Teensy LC – Low Cost. It’s not as powerful as the Teensy 3.1, but it does give you the power of an ARM for something that’s just about as cheap as a board with an ATMega.
The chip [Paul] chose for the Teensy LC is the Freescale MKL26Z64 (datasheet here and 876-page reference manual here. PDFs of course). This is a 32-bit Cortex-M0+ running at 48 MHz with 64k of Flash and 8k of RAM. There are 27 digital I/O pins on this one, and the Teensy LC has been designed to be pin-compatible with the Teensy 3.0 and 3.1.
On board are 13 analog inputs, 8 PWM outputs, on 12-bit DAC output, three serial ports, two SPI ports, and two I2C ports. Most of the pins can drive 5mA with a few capable of driving 20mA, and there is a single 5v output pin for driving WS2812 Neopixel LEDs.
Since this is a cut-down version of the Teensy, everything available on the Teensy 3.1 just can’t fit into the BOM of the Teensy LC. The pins aren’t 5V tolerant, there’s no CAN bus, and there are only 4 DMA channels instead of 16 on the Teensy 3.1. Still, it’s a great ARM answer to the ATMega Trinket or other small dev boards.
Filed under: ARM
Certain parts of the Northern Hemisphere are very, very cold right now. For those of us living in these colder climates, [Aaron] has a simple yet effective hack for keeping your hands warm when you go out for a walk in the brisk cold. He’s wired his jacket up for USB charging so he can make sure his hand warmers are always working.
[Aaron] bought a set of handwarmers that conveniently charge over USB, but he always forgot to actually plug them in once he got home, ensuring that they were always dead. To make his forgetfulness a non-issue, he built the USB charger for the handwarmers into his jacket, but he didn’t just run a wire out of the pocket. The USB charging circuit runs through the coat hanger, using some conductive cloth and steel thread in the inside of the jacket’s shoulders. From there, the cloth makes contact with the metal arms of the hanger and runs out of the hanger to the wall outlet.
This is a great cold-weather hack that might help any forgetful people on the north side of the planet keep warm. You could even use this method to charge batteries used in other wearable electronics. This project is a great reminder that sometimes the best hacks are the simple ones that no one’s thought of yet!
Filed under: wearable hacks
To say Hackaday has passionate folks in our comments section would be an understatement. You’ve made us laugh, made us cry, and made us search high and low for the edit button. From the insightful to the humorous, Hackaday’s comments have it all. So, we’re putting you to work helping out an organization that has done incredible work for science over the years.
The European Organization for Nuclear Research (CERN) has quite a storied 60 year history. CERN has been involved in pursuits as varied as the discovery of neutral currents, to Higgs boson research, to the creation of the World Wide Web. Like any research scientists, CERN staff have always been good about documenting their work. Many of these records are in the form of photographs: hundreds of thousands of them. The problem is that no one kept records as to what each photograph depicts!
The folks at CERN are trying to remedy this by publishing over 120,000 unknown photos taken between 1955 and 1985. The hope is that someone out there recognizes the people and equipment in the photos, and can provide some insight as to what exactly we’re looking at.
Here at Hackaday we think these photos should be seen and discussed, and we’re going to have some fun doing it. To that end, we’re hosting the Caption CERN Contest on Hackaday.io. Each week we’ll add a project log with a new image from CERN’s archives. If you know what the image is, click on CERN’s discussion link for the photo and let them know! If you don’t know, take a shot at a humorous caption. Hackaday staff will pick the best caption each week. Winners will get a shirt from The Hackaday Store.
Here’s how it will work: A new project log will go up every week on Tuesday night at around 9pm PDT. The project log will contain an image from CERN’s archives. You have until the following Tuesday at 9pm PDT to come up with a caption, and drop it in the comments. One entry per user: if you post multiple entries, we’ll only consider the last one.
The first image is up, so head over and start writing those captions!
Filed under: contests, Featured
What’s cooler than learning about timers and interrupts on AVRs? Well, if you’re like [Matt], you can use that learning experience to build something useful – in this case, a timer for various camera flashes.
There are two ways to measure the speed of a flash. The first is the lag between when a button is pressed and when the flash goes off. As long as this is consistent, everything’s okay. The second type of speed is the pulse width. When looking at a xenon flash as time vs. brightness, they have a large spike at the beginning followed by a significant amount of decay. LED flashes are pretty much one cycle of a square wave.
To measure both types of flash speed, [Matt] used a $0.50 photodiode an a 3.5mm jack that ties into the flash remote. These bits are wired up to an Arduino, a little bit of fun work with timers and interrupts happens, and [Matt] learns how fast his flash is.
Filed under: Arduino Hacks, digital cameras hacks
Nexus 7 tablets, being cheap and really quite decent for the price, have long since been used in the dashboards of people’s cars. Sometimes they’re mounted quite good — sometimes not so good — but every once in a while, someone gets it right.
Usually the reason mods like this don’t work out so well is because people are worried about damaging their car’s interior. But [tsubie320] had a better idea — buy a radio bezel off eBay to mess around with — that way he can always revert to stock when he sells the vehicle.
With a crisp-new-freshly-injection-molded-bezel in hand, he got to work. Funny enough, Nexus 7’s tend to be almost the exact size of double DIN stereo slots — hence their appeal. He wrapped the tablet in blue painter’s tape and positioned it in the bezel. Using fiberglass, he created a new shell for the tablet to sit inside of the bezel. Lots of sandpaper later and a whole bunch of bondo, he was done.
The cool part of this mod is how he’s mounted the car stereo behind the tablet. He created a new mount for it using acrylic to allow the radio to sit farther back than it normally does. Then he threw on an inductive charger right behind the bezel, oh and Bluetooth — look mom, no wires!
Filed under: car hacks
The tubes you’ll find in guitar amps and high-end stereos were first designed in the 30s and 40s, and when you get to really, really advanced tube technology you’d be looking at extremely small tubes made in the 70s for military applications. For 40 years, there really haven’t been many advances in tube technology. Now, at last, there’s something new.
The Nutube 6P1, as this curious invention is called, is a full triode or half of a 12ax7 you’ll find in just about every tube amp ever. Unlike the 12ax7, it consumes 2% of the power required of a normal tube, is 30% of the size of the normal tube, and lasts for 30,000 hours.
This new tube-chip thing was brought to life by Korg, makers of fine musical equipment and Noritake Co., manufacturers of vacuum fluorescent displays. There’s no word on what these tubes will be used in and there’s no data sheet. There will be further announcements this year, so don your speculation spectacles and head to the comments.
Filed under: misc hacks
[Mike] has put up a great video on his [SmallEngineMechanic] YouTube Channel about a tool we don’t see very often these days. He’s using an armature growler (YouTube link) to test the armature from a generator. Armature growlers (or just growlers for short) were commonplace years ago. Back when cars had generators, just about every auto mechanic had one on hand. They perform three simple tests: Check armature windings for shorts to other windings, for open windings, and for shorts to the armature body. [Mike’s] particular growler came to him as a basket case. The wiring was shot, it was rusty, and generally needed quite a bit of TLC. He restored it to like new condition, and uses it to help with his antique engine and genset addiction hobby.
Growlers essentially are a transformer primary with a V-shaped frame. The primary coil is connected to A/C mains. The armature to be tested sits in the “V” and through the magic of induction, some of the windings become the secondary coils (more on this later). This means some pretty high voltage will be exposed on commutator of the armature under test, so care should be taken when using one!
Testing for shorts to the ground or the core of the armature is a simple continuity test. Instead of a piezo beep though, a short will trigger the growler to turn on, which means the armature will jump a bit and everything will emit a loud A/C hum. It certainly makes testing more interesting!
Checking for open windings is a matter of energizing the growler’s coil, then probing pairs of contacts on the commutator. Voltage induced in the windings is displayed on the growler’s meter. Open windings will show 0 volts. Not all the armature’s windings will be in the field of the growler at once – so fully testing the armature will mean rotating it several times, as [Mike] shows in his video.
The final test is for shorted coils. This is where things get pretty darn cool. The growler is switched on and a thin piece of ferrous metal – usually an old hacksaw blade, is run along the core of the armature. If a short exists, the hacksaw blade will vibrate against the core of the armature above the shorted windings. We’re not 100% clear on how the coupling between the growler’s primary and two windings causes the blade to vibrate, so feel free to chime in over in the comments to explain things.
Most commercial shops don’t troubleshoot armatures anymore, they just slap new parts in until everything works again. As such the growler isn’t as popular as it once was. Still, if you work with DC motors or generators, it’s a great tool to have around, and it’s operation is a pretty darn cool hack in itself.
Click past the break for [Mike’s] video!
Filed under: classic hacks
Amateur radio is the only hobby that offers its licensed operators the chance to legally design, build, and operate high power radio transceivers connected to unlimited antenna arrays for the purpose of communicating anywhere in the world. The most complicated part of this communication system is the single-sideband (SSB) high frequency (HF) transceiver. In reality, due to the proliferation of low-cost amateur equipment, there only exists a very small group of die-hards who actually design, build from scratch, and operate their own SSB transceivers. I am one of those die-hards, and in this post I will show you how to get started.Radio Architectures
To understand how an SSB transceiver works we must first review the basic architectures of radio receivers. My favorite way of abstracting radio architecture is to consider everything at the block diagram level: filters, amplifiers, multipliers (or mixers as we call them), and assume all blocks are impedance matched.
The earliest radio architecture was known as tuned radio frequency (TRF), which became widely adopted in the mid to late 1920s for use in consumer receivers. The signal chain consisted of an antenna to collect the radio signal which was fed into four stages of filtering interspersed with three stages of amplification. The output of the last tunable filter was fed into an envelope detector (a diode) where the demodulated audio was amplified and played out of a loudspeaker. To tune in a station you would simply tune each of the filters to the desired frequency. Later models mechanically coupled the variable capacitors of each filter section together so that the user would only need to turn one knob to tune in a station.
The problem with TRF architectures was that multiple stages of tuned filters were expensive. To address this problem Edwin Armstrong combined the use of a low-cost un-tuned filter and frequency multiplication to create what was known as the superheterodyne architecture.
Edwin Armstrong realized the value of frequency multiplication. When two sinusoidal waveforms, one at frf and the second at flo, were multiplied together the result was the sum and difference of these two frequencies, F_if = F_rf – F_lo and F_if = F_rf + F_lo.How a frequency mixer works.
In RF design, we refer to multipliers as frequency mixers. In a superheterodyne receiver the desired RF signal is multiplied down to an intermediate frequency (IF) by use of a mixer and a variable frequency oscillator (VFO or Local Oscillator) where there exists a multi-stage filter to select the signal to pass onto an envelope detector. In other words, one of the two products from the mixer must equal the center frequency of the IF filter. To change the frequency at which the radio is receiving all you have to do is change the frequency of the VFO.
The figure below shows a block diagram of a table-top AM radio from the late 40’s where the radio tunes in stations at the frequency frf = frequency of OSC1 – 455 kHz. Changing the frequency of OSC1 changes the frequency at which the radio is tuned to frf.SSB Receivers
Rather than demodulating the radio signal with an envelope detector a SSB receiver down-converts the IF one more time using a second frequency mixer to the audio frequency range (this second mixer is sometimes known as the product detector). The result is amplified and fed out of a loud speaker.
What is being heard on an SSB receiver is actually the radio frequency spectrum multiplied down to the audio frequency spectrum so we can listen to it. You are listening to the actual radio waves.
In this case the IF filter’s bandwidth is between 1.8 and 2.5 kHz, matched to the bandwidth of human speech. The IF filter’s center frequency and the 2nd local oscillator determine what side band is selected, either upper sideband (USB) or lower sideband (LSB). USB and LSB refers to shifting the human voice to just above and below the carrier frequency respectively.SSB Transmitters
An SSB transmitter is simply the SSB receiver in reverse. Filters and modern double-balanced frequency mixers work in both directions. Amplifiers are wired in such a way to relays or PiN didoes so they can be reversed in transmit mode. When you transmit SSB your voice is upconverted to the radio frequency spectrum, amplified, and radiated out of the antenna.Block diagram of a 20m SSB transmitter. 20m SSB Transceiver
The first SSB transceiver I developed was for 20m, which is arguably the most fun HF band. The marine net is on 14.300. Lots of DX during the daytime hours. From the shoreline in Connecticut I can routinely work Western Europe and deep into Russia with only 40 watts and a half-wave dipole antenna.
The block diagram of this transceiver is exactly as shown above. A lot of detail, schematics and additional info can be found here. This radio is representative of the vast majority of SSB transceiver architectures.Next Steps
I have abstracted radio circuitry to the block diagram level. Once blocks are understood then a design can be made at the high level. After the block diagram is in place then circuits, ICs, or modules can be selected to fill in the blocks. Some circuits are borrowed from books or scaled from a design in a book. A great source for 50 ohm ICs and modules is mini-circuits. Others require the synthesis of a custom ladder network, which will be the case for the RF front-end filters. These are great resources for finding, borrowing, or synthesizing those circuits or entire radio architectures even:
There is so much more to basic RF design and the only way to really learn is to start doing it. Borrow as many circuits as you can from others. Cobble together your radio. You will get better at every aspect of design after each radio you build. Jump right in! There’s nothing like the satisfaction of making a long distance contact on a transceiver you built yourself. I look forward to communicating with some of you on the air soon!Acknowledgement
My cousin, Juliet Hurley, MBA, MSF, MAC for type editing this post.Author Bio
Gregory L. Charvat only operates radio equipment he builds from scratch, is the author of Small and Short-Range Radar Systems, co-founder of Hyperfine Research Inc., Butterfly Network Inc. (both of which are 4catalyzer companies), visiting research scientist at Camera Culture Group Massachusetts Institute of Technology Media Lab, editor of the Gregory L. Charvat Series on Practical Approaches to Electrical Engineering, and guest commentator on CNN, CBS, Sky News, and others. He was a technical staff member at MIT Lincoln Laboratory where his work on through-wall radar won best paper at the 2010 MSS Tri-Services Radar Symposium and is an MIT Office of the Provost 2011 research highlight. He has taught short radar courses at MIT where his Build a Small Radar course was the top-ranked MIT professional education course in 2011 and has become widely adopted by other universities, laboratories, and private organizations. Starting at an Early Age, Greg developed numerous radar systems, rail SAR imaging sensors, phased-array radar systems; holds several patents; and has developed many other sensors and radio and audio equipment. He has authored numerous publications and has received press for his work. Greg earned a Ph.D in electrical engineering in 2007, an MSEE in 2003, and a BSEE in 2002 from Michigan State University, and is a senior member of the IEEE where he serves on the steering committee for the 2010, 2013, and 2016 IEEE International Symposium on Phased Array Systems and Technology and chaired the IEEE AP-S Boston Chapter from 2010-2011
Filed under: how-to, radio hacks, slider
Unless you’re some incredibly gifted individual with more dexterity than a fighter jet pilot, making anything on a Etch-a-Sketch is hard. So [Evan] decided to motorize it, and cheat a little bit.
He’s using an Arduino Uno to control two stepper motors that he has bound to the Etch-a-Sketch knobs using a short piece of rubber tube and Gorilla Glue. He 3D printed some custom motor mounts to allow the motors to be positioned directly above the knobs, and a ULN2803 to switch the 12V required for the steppers.
After he had the hardware all setup, he coded a simple Python script to take in .PNGs and produce vector art to be sent through the Arduino. In case you’re wondering, an Etch-a-Sketch has approximately 550 x 370 pixels, or about 500 x 320 for the “safe zone”.
Due to the limitations of the Etch-a-Sketch, like its inability to stop writing, some images might require some editing before sending it off to your new Etch-a-Sketch printer.
While Etch-a-Sketches have been the bane of existence for many people’s childhoods, there’s quite a few hacks out there of people getting their revenge. Etch-a-Sketch clock? Check. Etch-a-Sketch CNC? Check. Etch-a-Sketch Automatic? Check.
Filed under: Arduino Hacks
[Will] had a few reasons for turning a toaster oven into a reflow oven – he needed a project for an ECE lab, the lab’s current reflow oven was terrible, and the man is trying to keep [Will] down by not allowing toaster ovens in dorm rooms. What was born out of necessity actually turned into a great project – a reflow oven with touchscreen controls.
The toaster oven used for this build is a model [Will] picked up at Sears. It’s actually pretty unique, advertised as a ‘digital toaster’. This isn’t marketing speak – there’s actually a thermistor in there, and the stock toaster is closed loop. After disassembling the toaster and getting rid of the guts, [Will] whipped up a PCB for a Teensy 3.1 and the Adafruit capacative touch shield.
With the Teensy and touch screen, [Will] came up with an interface that looks ten times better than anything you would find on a Chinese auction site. It’s a great build, and since it’s kept in the electronics lab, will certainly see a lot of use.
Filed under: tool hacks
TL;DR It’s called the Raspberry Pi 2 Model B. Quad core ARM Cortex A7 with one Gig of RAM. It’s the same form factor as the Raspberry Pi Model B+. Available now at Newark, Element 14, Allied, and RS Components. It’s the same price as the old one. You’re not a child and you should learn to read.
The original Raspberry Pi released, three years ago, was looking a bit long in the tooth when it was first launched. That’s to be expected for a computer that sells for $35 USD. Three years is a long time in the world of electronics, and the Pi is due for an update. It’s here, now, and the biggest change is a faster quad-core chip, a better processor architecture, and 1GB of RAM.
The Raspberry Pi 2 Model B features a quad-core ARM Cortex A7 running at 1GHz with 1GB of RAM. This chip uses the ARMv7 architecture instead of the ARMv6 of the original Raspi. When playing around with it, it was noticeably zippier than my months-old Raspi Model B in web browsing tasks. Very, very cool, and something that opens up a few doors for CPU-intensive applications.
Although the CPU has been updated, there isn’t much else on the Pi that has changed. USB and Ethernet is still handled by the LAN9514 USB/Ethernet controller. If you’re looking for Gigabit Ethernet, sorry that’s not going to happen. We’re not going to get eMMC Flash, SATA ports, or anything groundbreaking other than the CPU with this hardware update. It’s pretty much just a CPU and RAM upgrade.
All the original ports found on the Raspberry Pi Model B+ are found on the Raspi 2; HDMI, audio, analog video, Ethernet, USB, CSI, the as-for-now unused DSI, and GPIO ports haven’t changed. Again, we’re looking at a CPU and RAM upgrade with this hardware release.
Instead of the odd Package On Package CPU and RAM stack featured in previous Raspberry Pis, the RAM has now moved to the back on the Raspi 2:
The RAM chip is an Elpida EDB8132B4PB-8D-F, an eight gigabit DDR2 RAM that has the same clock rate as the RAM in the original Raspi. Don’t look for an increase in memory performance or speed. Instead, just be glad there’s now a full gigabyte of RAM on the Raspi.
A few of you may remember the ‘upgrade’ all those Raspberry Pi early adopters missed out on. After the first few hundred thousand Raspberry Pi Model Bs shipped, someone realized they could upgrade the RAM from 256 MB to 512 MB. It is not yet known whether the Raspberry Pi 2 will be upgraded as easily. Sixteen gigabit RAMs do exist, but now that the CPU and RAM aren’t on the same package, there’s more to consider than just plopping down a new RAM chip.Compatibility
As far as software is concerned, just about everything that ran on the original Raspberry Pi will run on the Raspberry Pi 2. The capabilities of the Raspberry Pi 2 are a superset of the original. This is an entirely new processor architecture; the Pi 1 used a chip with the ARMv6 architecture, and the Cortex A7 uses the ARMv7 architecture. This is huge. The Raspberry Pi 2 can now run a modern Android system. There’s a ton of stuff that’s possible with the Pi 2 that was unimaginable with the Pi 1.
There is one caveat when it comes to software on the Pi. The Foundation sent me a Pi 2 and an SD card loaded up with a Raspbian distro. This worked well until I was a moron a few times and cut the power to the Pi 2 without doing a proper shutdown. The card was corrupted. I downloaded the current-as-of-a-week-ago Raspbian image. The Pi 2 will not boot this image. If you’re doing stuff with the kernel, there is a difference between the Pi 1 and Pi 2, and there will be specific disk images for the Pi 1 and Pi 2.
Interestingly, a Raspberry Pi 1 Model B+ will boot the Pi 2’s Raspbian image. This is somewhat interesting, as the CPU on the Pi 2 is effectively a superset of the CPU on the Pi 1. I’ve talked to people with about a century of combined experience with ARM and Linux, and nobody knows what’s up with this.
For hardware, everything you’d expect from the GPIO pins on the Raspberry Pi is present on the Raspberry Pi 2. It’s the usual 40-pin expansion header we’ve all come to expect, and as far as I can tell, there is no change between the Raspi and Raspi 2.
Concerning the form factor, just about every case that is compatible with the Raspberry Pi Model B+ should be compatible with the new Raspi 2 Model B+. I’ve tested the new Pi with a case from Hammond, CamdenBoss, and Pimoroni Pibow Coupe. Only the Pimoroni was incompatible with the new Raspi 2, but that’s only due to a piece of acrylic interfering with the new, larger CPU. A pair of dikes quickly solved that problem sent shattered acrylic shooting across the room. Use a thin saw or file. In terms of form factor, consider this identical to the Model B+.Other Models
There’s more than one Pi in the Raspberry Pi ecosystem, but for now, the Model A+ and the Raspberry Pi compute module will retain the old BCM2835 chipset. That’s not to say they won’t be upgraded in the future; the board layout between the Pi 1 Model B+, A+, and compute module are extremely similar around the CPU and RAM. An update to the ‘lesser’ Pis may just be a matter of futzing about with whatever EDA software the foundation uses.
Historically, the Raspberry Pi foundation has used the Model B as their flagship product that sees new innovations first. When the Model B+ received a new form factor and more GPIO pins, it took about four months for the Model A to move up to the new design standards. If you’re waiting for an ARM Cortex A7 board in the A+ or Compute Module form factor, you’ll probably be waiting until June or July.Benchmarks and Performance
Comparisons Since the Raspberry Pi was introduced a few years ago, there has been an explosion of small, cheap ARM Linux boards. Compared to the Banana Pi, Cubieboard2, or the Odroid, the 700MHz ARM11 CPU found in the original Raspberry Pi has seemed a little anemic for the last few years. This is not a fault of the Raspberry Pi; the idea of the Raspberry Pi was to produce a small, single-board Linux computer for about $35 USD. The ‘clone’ boards like the Banana Pi and Odroid came later, with access to better, cheaper silicon, and are not constrained by the $35 USD price point. There will always be better options at a higher price point.
Any comparisons between the Raspberry Pi, ‘clone’ boards, and larger, more capable, and more expensive boards like the Hummingboard and BeagleBone Black must take into consideration the price of the board. Currently, there are few boards that match the power and the price of the Raspberry Pi 2, the Odroid C1 being the one that matches the Raspberry Pi 2 in terms of performance and capability. I do not have an Odroid C1, though, and I’m not going to phone in a comparison between the two.
I do, however, have a Raspberry Pi Model B+. Tomorrow, I will be posting some benchmarks between the Raspberry Pi 2 and a Raspberry Pi Model B+.
I just so happen to have a FriedCircuits USB current/voltage/power meter sitting around. When monitoring the power consumption of the Raspi 2, there is a slight increase in power consumption over the Raspberry Pi 1.
When booting to a Raspbian desktop, the Raspberry Pi 1 draws about 290mA, dropping to about 250mA once the desktop is loaded. The Raspberry Pi 2 draws about 340mA at boot, dropping to about 270mA once the desktop is loaded. There is a slight increase in current draw from the Raspi 1 to the Raspi 2.
With a few experiments, I did determine the Raspberry Pi 2 will draw up to 500mA under heavy load. That’s the max spec for USB. If your current USB power adapter isn’t great, you might want to get a better one for the Raspi 2.
I’ll be posting something on the speed and benchmarks of the Raspberry Pi 2 tomorrow. Until then the time to boot to a desktop can serve as a sufficient characterization of the speed in the Raspberry Pi 2.
Using the same SD card in both tests, the Raspberry Pi 2 boots to a Raspbian desktop in about 22 seconds. For the same test, a few months-old Raspberry Pi 1 Model B+ boots to a Raspbian desktop in about 41 seconds. Test conditions were ‘from the point the Raspberry appears where Tux should appear on the console’ to ‘when the CPU monitor in the corner of the screen bottoms out’. By any measure, the Raspberry Pi 2 is significantly faster.Where to get one
Anyone who was around for the launch of the Raspberry Pi 1 will remember the months-long waits from Newark, Farnell, Allied, and RS components. Part of this was due to the huge demand, but a significant bit of the blame for the backorders would fall on the Raspberry Pi foundation. It’s understandable; at the time, they were looking at success they hadn’t dreamed of.
This time around, they’re prepared. [Eben] tells us there are 100,000 Raspberry Pi 2 Model Bs sitting in warehouses right now. It’s going to take a while before the new Pis make their way to Fry’s and Microcenter, but we’re looking at waiting a few weeks, not the months of the original launch.Wrap-up
For the most part, this is simply an upgrade to the CPU and RAM of the Raspberry Pi Model B. Right now, there are no distributions or software compiled specifically for the Raspberry Pi 2, and having the software that will take advantage of the much faster, multi-core CPU of the Raspi 2 will take a while.
The faster and larger CPU of the Raspi 2 opens a few doors for interesting applications. The somewhat anemic CPU of the original Raspberry Pi limited interesting applications of a tiny Linux board. Applications like computer vision and anything where a high amount of I/O was happening at any one time were out of the question. This hardware revision will fix that.
Future updates to the Raspberry Pi will include a Model A+ and Compute Module. Those will probably appear in a few months. You’re not going to hear anything about an improved Raspberry Pi 2 or a Raspberry Pi 3.
There will be a detailed breakdown and benchmarks for the Raspberry Pi 2 posted tomorrow.
If you’re searching for the word ‘disclosure’, there it is. At my request the Raspberry Pi foundation sent me a Raspberry Pi 2 Model B and SD card for this post.
Filed under: news, Raspberry Pi, slider
Transcend markets their DrivePro 200 camera for use as a car dashcam. We’re a bit surprised at the quality and apparent feature set for something relegated to a rather mundane task as this. But [Gadget Addict] poked around and found a nice little nugget: you can live stream the video via WiFi; the framerate, quality, and low-lag are pretty impressive. In addition to that, the next hack is just waiting for you to unlock it.
As it stands right now you turn on the camera’s built-in WiFi AP, telnet into two different ports on the device (sending it into smartphone connected mode) and you’ll be able to live stream the view to your computer using RTSP. Great, that in itself is a good hack and we’re sure that before long someone will figure out an automatic way to trigger this. [GA] also found out how to get the thing into script mode at power-on. He hasn’t actually executed any code… that’s where you come in. If you have one of these pull it out and get hacking! It’s a matter put putting files on the SD storage and rebooting. Crafting this file to enable shell access would open up an entire world of hacks, from things like time-lapse and motion sensing to special processing and filtering in real time. We think there’s huge potential so keep us up-to-date as you find new ways to pwn this hardware.
Filed under: digital cameras hacks, linux hacks, wireless hacks
It’s Sunday evening, and that means Hackaday Links, and that means something crowdfunded. This week it’s UberBlox. It’s a modular construction system based on Al extrusion – basically a modern version of an Erector set. Random musings on the perceived value UberBlox offers in the comments, I’m sure.
[Trevor] sent in something from his Etsy shop. Normally we’d shy away from blatant self-promotion, but this is pretty cool. It’s reproductions of 1960s Lockheed flying saucer plans. We’re not sure if this is nazi moon base/lizard people from the inner earth flying saucer plans or something a little more realistic, but there you go.
3D computer mice exist, as do quadcopters. Here’s the combination. It looks like there’s a good amount of control, and could be used for some aerobatics if you’re cool enough.
Who doesn’t love LED cubes? They’re awesome, but usually limited to one color. Here’s an RGB LED cube. It’s only 4x4x4, but there’s a few animations and a microphone with a beat detection circuit all powered by an ATMega32u4.
Filed under: Hackaday Columns, Hackaday links
Ah, the old HTTP versus HTTPS. If you want to keep people out, that trailing ‘S’ should be the first thing you do, especially if you’re trying to keep people out of a luxury automobile. It turns out that BMW screwed up on that one.
BMW has an infotainment feature called ConnectedDrive which builds your favorite apps and services right into the dashboard. You can even unlock the vehicle using this system which is built around a piece of hardware that includes a GSM modem and permanent SIM card. A security research group recently discovered that the commands sent for this system were being pushed over HTTP, the unencrypted sibling of HTTPS. The firm, hired by German automobile club ADAC, disclosed the vulnerability and an over-the-air upgrade has already been pushed to patch the flaw. The patch is described to have “turned on” the HTTPS which makes us think that it was always meant to be used and just configured incorrectly in the roll-out. We’ll leave you to debate that point in the comments. Seriously, how does something like this happen? It certainly sheds a lot more light on thieves being able to magically unlock high-end cars. Was this how they were doing it?
Filed under: news, security hacks, transportation hacks
There are a few dozen classic re-imaginings of classic game consoles, using hardware ranging from the ATMegas of the Uzebox to everyone’s favorite, stuffing some ROMs on a Raspi and calling it a day. You don’t necessarily learn anything doing that, which puts [Mike]’s custom game console head and shoulders above the rest.
The build started off as a plan for a Z80 computer with a dual ATMega GPU. He progressed far enough in the design where it would have been a masterpiece, but the inability to mill double-sided boards at home killed the design. Plans then moved on to an FPGA, then to an ATMega with the Analog Device AD725 PAL/NTSC encoder chip. That idea had a similar architecture to the Uzebox, but [Mike] wanted more power. He eventually settled on a PIC32 with the AD725.
This setup was capable of pumping out some impressive graphics, but for moving bits to a screen, you need DMA. [Mike] ran into a problem where the DMA timer runs at a maximum rate of 3.7 MHz. It’s a problem documented in a few projects, leading [Mike] to change his plan once again, this time to the STM32F4.
The bugs are worked out, and now [Mike] can stream a whole lot of pixels to a screen while still having some processing power left over to play a game. It’s a project that’s more than a year and a half old at this point, and so far he’s learned a lot.
Filed under: classic hacks, video hacks
Multimeters are one of the key tools in a hardware hacker’s bench. For 90% of us, the meter leads are perfect for making measurements and looking over at the results. Sometimes you need a bit more distance though, and for that, [Ken Kaarvik] has created the Multimeter remote display. Remote displays are pretty handy when you want to measure something several feet away from your bench. They’re also great if you need to check something in an enclosed space, like a server rack or a refrigerator. Fluke actually sells multimeters with wireless displays, such as their model 233.
The key to this project is the FS9721 LP3 chip by Fortune Semiconductor. (PDF link) The FS9721 is essentially a system on chip (SOC) for multimeters. It contains a digital to analog to digital converter, an LCD driver, and a microcontroller. It also can send data out over a 2400 baud serial link. Two of [Ken’s] multimeters, the Digitek DT-4000ZC and a Fluke 17B, both have this chip. The Digitek has a 1/8″ plug for connecting to the outside world, while the Fluke requires some simple hardware mods to enable data output.
Since this was his entry for the Trinket EDC contest, [Ken] connected the serial output of the FS9721 to an Adafruit Pro Trinket. The Trinket formats the data and sends it to an nRF24L01+ 2.4GHz radio module. The receiving end has an identical radio, and another Pro Trinket. [Ken] actually built two wireless displays. One is a dual-boot Game Boy advance which has a really slick background on the color display. The other receiver utilizes a 128×64 OLED. The trinket, nRF24L01+ and display all fit neatly inside an Altoids tin.
Click past the break to see both wireless remote displays in action!
Filed under: tool hacks
Humanity has taken one step closer to Skynet becoming fully aware. [Ahmed], [Muhammad], [Salman], and [Suleman] have created a vehicle that can “chase” another vehicle as part of their senior design project. Now it’s just a matter of time before the machines take over.
The project itself is based on a gasoline-powered quad bike that the students first converted to electric for the sake of their project. It uses a single webcam to get information about its surroundings. This is a plus because it frees the robot from needing a stereoscopic camera or any other complicated equipment like a radar or laser rangefinder. With this information, it can follow a lead vehicle without getting any other telemetry.
This project is interesting because it could potentially allow for large convoys with only one human operator at the front. Once self-driving cars become more mainstream, this could potentially save a lot of costs as well if only the vehicle in the front needs the self-driving equipment, while the vehicles behind would be able to operate with much less hardware. Either way, we love seeing senior design projects that have great real-world applications!
Filed under: transportation hacks