I revisited Windows IoT Core a few weekends ago and found it to be useful in a quick project that involved dumping my wireless headset’s electrically erasable programmable read-only memory (EEPROM). In other words, just another weekend at Rafael’s place.
But first, a little background.
Sign up for our new free newsletter to get three time-saving tips each Friday — and get free copies of Paul Thurrott's Windows 11 and Windows 10 Field Guides (normally $9.99) as a special welcome gift!
"*" indicates required fields
I own a reasonably old wireless headset–Turtle Beach Ear Force PX3–that I’ve been keeping on life support because of its premium recording capabilities. Thus far, I’ve found no other headset that can record audio as well as the PX3. (Well, there was the Plantronics Audio 995 but I’ve gone through all the reserves left on this planet.) So I’ve invested in reverse engineering my headset to ensure I can restore function to pieces that need replacement. For example, I’ve rebuilt its poorly designed plastic buttons in CAD software for 3D printing on-demand.
The headset has a nugget of memory (EEPROM) that stores configuration information for the programmable audio equalization features of the headset. And while I don’t use these features, the headset fails to boot up if that data is corrupted or missing. And with EEPROM having a finite amount of reads before going kaput, it’s a ticking time-bomb. I need to back up its contents.
So let me walk you through what I did.
First, I pulled down the Windows IoT Core Dashboard and set up a new device. I flashed a MicroSD card with the latest build of Windows IoT Core and popped it straight into the Raspberry Pi 2 (Amazon, ~$40). After a bit of configuration, the device was online and ready to receive instructions from Visual Studio.
I then skimmed through the datasheet and attached some test clips to the EEPROM chip (ACE24C256) for Ground, Serial Clock and Serial Data access. I routed those to the Raspberry Pi’s GPIO2, GPIO3 and Ground pins where Two-Wire Serial (TWI)/Inter-integrated Circuit (I2C) communication is expected to occur.
That was the extent of the hardware configuration I performed.
(Two-Wire Interface is mostly identical to I2C, cleverly created to sidestep trademark issues with I2C. I say mostly because it’s missing a few niceties like 10-bit addressing.)
Windows IoT Core runs apps targeting the Universal Windows Platform (UWP), but the templates that ship with Visual Studio are way overkill for what I needed. So, I instead installed the Background Application Template from the Visual Studio Marketplace. This template creates a simpler project with a bare-bones implementation of a Background Task.
Using that starter code, I followed the usual deferral pattern (to prevent the app from killing my asynchronous tasks) and started laying down the code I needed:
I paused at calling the I2cDevice.Read method for a moment, because it only took one parameter – a buffer to store data clocked out of the chip. It doesn’t support addressing. But I remembered I2C/TWI isn’t limited to just storage applications – it’s higher level than that. So I needed to review the datasheet again to understand the protocol implemented on top of I2C/TWI to read data correctly from the chip.
Here’s what I picked up from the datasheet:
I implemented this logic using the I2CDevice.Read and I2CDevice.Write methods on the Device object I created earlier. Because the I2cDevice class handles I2C/TWI addressing and other minutia (in green) for me, I only had to worry about the data portion of the protocol (in purple). In this case, to set the internal address pointer to 0, I had to write two zeros (8 bits each). Got it.
With the dummy write out of the way, I switched to using the I2CDevice.Read method to complete the Random Read operation. The I2C classes did the heavy lifting while I dumped my buffer to disk. I then come behind the app to scoop up the file with the IoT Dashboard.
With a fresh EEPROM dump in hand, I was done.
skane2600
<p>Interesting. I'll have to look at your code in more detail and MS's classes. Trying to write a general purpose I2C handler is difficult because of the different ways that different devices have to be addressed. Not much of a problem when addressing a single I2C device, but a pain when multiple devices need to be handled within a single program. Particularly difficult when the I2C is interrupt driven. </p><p><br></p><p>Then again I was writing the code for a microcontroller in C without an OS, which is a quite different scenario.</p>
Pargon
Premium Member<p>As a nuclear engineering student and former navy electronics technician and reactor operator, who made a radiation detector with a raspberry pi 3 and some logic gates just 2 weeks ago I'd understand this much more if *any* explanation was given of what I2C is, or why you wanted to dump an EEPROM. I'm familiar with basically every part of this article except the glue between all the pieces, ie your lack of what, how, why. Was the headset broken, wanted to upgrade it with a faster chipset, did you connect it via USB, why would a raspberry pi be the method of choice? It really just was not written well for probably the majority of your audience. It's as if I would have turned in my lab report with no introduction or theory section and jumped straight into the results of pulsing the reactor. </p>
skane2600
<blockquote><a href="#226331"><em>In reply to Pargon:</em></a></blockquote><p>In simplest terms I2C is a two-wire serial communications bus that is typically used in embedded systems to connect microcontrollers to other devices. Its advantage is that it allows a processor access to devices without having to add additional hardware for decoding addresses as would be the case if the devices were connected to a parallel bus. For more information see http://www.i2c-bus.org/</p><p><br></p><p>Only Rafael can explain why he wanted to dump the EEPROM, but he may have just wanted to experiment with I2C.</p>
skane2600
<blockquote><a href="#226460"><em>In reply to skane2600:</em></a></blockquote><p>Wow, some people will down-vote anything. I didn't attack anything, just provided the background information on I2C Paragon asked for.</p>