If you missed the live Sensor Fusion and Contextual Awareness Hangout, you can watch the playback on the ARMFlix channel on Youtube here:
You can find bios of all the participants on the intro blog here.
I asked Will Tu of ARM, who facilitated proceedings, for his 'Top 3' highlights:
1) Innovation in sensors is happening on multiple vectors
2) But some of the challenges are the same...
3) Ecosystem is key
The second point really jumped out at me as playing to what many would call the core strengths of ARM and our partners - including that balancing of power versus performance in ever more varied and demanding applications.
Enjoy the show!
Yes, just signal and ground..
I definitely like combining power and data into a single wire, so only two wires would be necessary in total.
Cost: size dependant, perhaps a proprietary protocol-interface would be suffice, add a 6 pin micro to each sensor/s cluster some bit bashing to design a single phantom powered (OC) wire half duplex slave interface back, (with sleep and sensor ID flashed in to the device ( etc)) to the main CPU. This would save on the cost of wiring/interconnection and connectors/space.
The master CPU broadcasts as sensor ID to all sensors connected on the bus, master wait for response etc etc.. Just a thought !!
pcbscape wrote: Is your design is restricted by BOM costs, PCB real estate etc ?
pcbscape wrote:
Is your design is restricted by BOM costs, PCB real estate etc ?
The sensor-bus is more a "generally speaking" suggestion, but normally, I would of course try reducing the used PCB space, including the number of external components.
Sometimes you want to place many sensors outside the PCB; such as several meters from the CPU (example: temperature sensors on a boiler).
Sometimes you need the PCB to fit in a tiny space and have several high-speed sensors on the PCB (perhaps on both sides).
If you could have a single 'sensor-bus', it might reduce the code size, because all code written for the sensors share the same interface, and thus do not need to set up different interface types and speeds each.
I very much fancy SPI, due to its simplicity (a shift-register is basically all you need in order to create an SPI device) and the flexible speed.
However, if SPI was combined with the auto-enumeration CANBUS has (eg. a verification of the Data-Out pin, so each device could stop transitting as soon as it discovers that someone else is talking), then I would find it vastly improved; this would also reduce the need for a CS pin.
I agree it would great to have a standard sensor bus that would reduce glue logic, I/O CS at the front end and or slot parsing at the back end.