I am growing a sort of interest for hardware projects; and lately I started to experiment with BeagleBone and various types of sensor.
Now I realize that, to reduce the size of your hardware (and costs of course), you can't always have an Arduino or a BeagleBone attached to your sensors, to drive the I2C chain. So I am looking for alternatives, that allows me to have a I2C chain of sensors, without using the beagle bone or the Arduino.
The first idea would be to use a computer to drive the sensors (after all, the hardware would run in conjunction with an application that is running on a computer). I have done a search for USB to I2C, but seems that most of these adapters are not simple translators but they have a ton of features that I don't need (hence the high cost).
Either via USB or via wireless would be fine; all that I need is to drive these sensors, gather the data and then send it out for processing. At the moment I can do it with the beagle bone, but I would like to explore alternatives. My sensors works either with I2C and with SPI, I have 5 of them.
I am new to the world of hardware hacking; I barely was able to connect a temperature sensor to the BeagleBone, and write a console app to process the data from it; so I am not even sure if this is possible with normal means, or if I need more experience and skills to make my own interfaces and boards. Although it seems quite strange to reinvent the wheel every time 🙂 If hardware development is similar to software development; there must be someone else that already had that issue and made a solution, so you don't have to write the same thing over and over.
Best Answer
A BeagleBone actually is the right sort of answer.
I fully understand the problem. A BeagleBoard is vastly overpowered for this job. it is inefficient and physically vulnerable.
There's no technical reason you couldn't get this down to a small, reliable, compact, durable $5 adapter, with USB on one end and 3 screw terminals on the other. Such adapters exist for USB to RS-232, for example.
The reason such adapters do not exist is simple: low potential sales volume.
The first step towards the ideal, starting from a general-purpose development board like the BeagleBone, is to switch to the smallest microcontroller that can drive both a USB and I²C bus simultaneously at the full data rate of the I²C side.
This is how the early USB to RS-232 adapters worked. They were rather costly and bulky by current standards, but because they were made entirely from off-the-shelf hardware, they were quick to get to market.
Because of the low potential sales volume, I'd expect to pay at least $20 for such thing, and would only expect to find it from a company like Adafruit or SparkFun, since their product diversity combines many small income streams into a single large one.
The reason you've found others charging much more than this is that is that a specialist manufacturer must go for the high end of the market. It's the only way to survive when the market size is naturally small.
Consider PC database systems.
In the early days of personal computing, general-purpose database systems didn't really exist for PCs. Many of the dedicated geeks who bought these early PCs solved problems we'd now solve with a DBMS with custom BASIC code, or even assembly. If you have any personal computing magazines from the late 1970s or early 1980s, look for the ads by companies selling $100 sorting programs!
That level of technology is analogous to what you're doing now: writing BeagleBone code to lash I²C peripherals to a USB bus, so they can talk to a computer that doesn't have an external I²C bus.
Getting back to the historical analogy...
In the early 1980s, word processors and spreadsheet programs started to get bundled with simple general-purpose DBMSes. By the mid-1980s, most everyone had a database system. The software bundle often came with the computer.
As the 1980s wore on, many of the uses for PC DBMSes started being better addressed by custom software, shrinking the user set size for DBMSes, increasing specialization. Feature set sizes and complexity grew, so that by the early 1990s, DBMSes started dropping out of office suites, because they had turned into software developer tools.
The PC DBMS market eventually stabilized, with a wide gap between Excel-as-DBMS and Access/FileMaker, because the middle ground is unprofitable. (As a Mac user, you probably watched the failure of Bento, which sat itself right in the middle of that gap.)
The gap continues to widen. Access and FileMaker are development environments unto themselves, and will continue to get more complex as they focus more on custom development and less on one-offs by solo dilettantes. I expect them to die off, too, at some point, as DBMS development moves to mobile and the cloud, further increasing complexity and specialization.
The I²C equivalent in this analogy is that I²C is now a commodity microcontroller peripheral, a datasheet checklist item. In the same way that true DBMSes are now served by a cadre of specialist software developers, most I²C work is done by specialist EEs writing code to talk to their μC's I²C peripheral.
The only way to get from that point to the point where you could expect to buy a $5 plastic-molded mass-produced adapter from the local computer store is for someone to come out with a custom IC, an I²C equivalent of the ubiquitous PL2303. I can't see this happening, ever.
The market size is fundamentally limited but the fact that USB is an outside-the-case sort of interconnect, but I²C is an inside-the-case interconnect, owing to the combination of relatively high data rate and single-ended signaling. The only reason USB to RS-232 adapters exist — despite the fact that RS-232 is also single-ended — is that RS-232 normally maxes out at 115,200 bps, just barely faster than the slowest I²C links. At normal I²C speeds, you really need differential signaling if you're going a long distance outside a shielded enclosure.
The point is, USB to I²C adapters are going to remain special-purpose things, hence expensive, bulky, clumsy, and/or overpowered.