Hi, I am looking at solutions for small, simple car/boat/airplane gauges and starting with something simple–a compass. I am thinking that a Microview in the center of a 16-Neopixel LED ring would provide a nice combination of a digital readout on the screen and an analog indication of which way is north on the LEDs. Would a Microview have enough pins and processing power to run a magnetic sensor, the LEDS, and perhaps a rotary encoder switch for adjusting settings and brightness? Cheers, Matthew
Pick your sensor, pick your method of driving the LEDs, pick your method of reading a rotary encoder, subtract the number of pins required to drive those things from the number of pins available on the uView.
There’s your answer…
Keep in mind that the rated life, to half brightness, for the OLED display is 10000 hours. That’s a little over 1 year, if powered on continuously. You may wish to consider putting the MicroView in a socket, so it can be replaced when it fades below an acceptable limit.
I’ve also heard, but have no specific data, that OLEDs have a “shelf life” and can fade over time even when not powered up.
Also note that, when considering how to interface to your external devices, the hardware SPI interface is dedicated to the MicroView’s display, so not available (at least easily) to the user. You’ll have to use I2C or general purpose I/O, possibly using bit banging.
Thanks. I know that the Neopixels, OLED or segmented LED display and barometric sensor are all available in I2C versions, so that should help, not sure about the rotary encoder.
PS–On the rated life of OLED displays, 10,000 hours is about five overhauls in an airplane, or 500,000 miles in a car averaging 50 mph, so I think that will do fine.
A standard rotary encoder only requires 2 digital I/O lines, plus one more if it has a built in push button that you wish to use.
As for processing power, you will probably have plenty for your purposes. Available program memory space may be a consideration, depending the number of different devices you wish to hook up and the size of the libraries required to drive them.
Thanks, then as long as the sensor and LEDs are running off the I2C lines then the rotary encoder and button should be no problem.
On a related note, I have been very interested to learn just how many devices can be run off an I2C data bus. It seems to me that you could use a single central controller to run an entire panel in which each instrument is, in fact, just a “dumb display” (say a small OLED matrix or alpanumeric LED display, a ring of Neopixels, and a rotary encoder/switch all running off I2C). I would probably need to step up to a more powerful controller with more memory, but the principle would be scalable and installation would be a snap with pre-made four-wire cables and connectors.
I2C uses 7 bit device addresses. In theory you can address up to 112 physical or logical devices (16 addresses are reserved) but in practice you will be limited by the capacitance of your wiring. The capacitance will be determined by the type and length of the wires and also, to some extent, the capacitance of the inputs. The speed and voltage that you run the bus at will determine that maximum capacitance allowed.
There are I2C multiplexors available to allow increasing the the number of devices or to deal with address conflicts. One such device is the Texas Instruments TCA9545A:
http://www.ti.com/product/tca9545a
Here’s one available breakout board that uses it:
http://www.switchdoc.com/i2c-4-channel- … out-board/
In addition to wiring capacitance, a consideration for your scalable “plug and play” idea is termination. An I2C bus needs to be terminated with the proper values of pull up resistors. You may need to have switches on each pluggable device, or some other means to set up proper termination.
Thanks, scotta, I am still learning so this is all very helpful. I guess that there are still quite a few things to figure out for the central processor and slave display concept…
-
Do the components that I would like to use all allow a sufficent number of I2C address options to avoid the use of multiplexors?
-
Are capacitance issues likely to be a problem with the short (6"-4’ or so) wire runs typical of a vehicle instrument panel?
-
How to deal with the termination issues?
On the last point, I suppose the two basic wiring options would be 1) a hub-and-spoke approach with individual four-wire cables from the central processor to each display, and each display with its own terminating resisitors, or 2) a daisy-chain approach in which the central processor connects to the first display, the first display connects to the second display, etc. and only the last one needs to be terminated. Both would be doable, with the daisy-chain likely lighter but also more susceptible to one loose connector knocking out multiple displays.
Keep that feedback coming, thanks!
Q1: I assume you understand that this is something only you can determine, based on the devices you would like to use. You’ll have to look at each device’s specifications for address assignment capability.
Q2: 6" shouldn’t be a problem but 4’ could be. I2C is really only intended to be a short distance internal bus. Mostly on a single board or within a small case. There are other communication specifications and protocols for reliable communication over longer distances, for example RS-485 for the hardware bus.
Q3: It’s possible to put terminators just on the master device but you might have to change their values as you add or remove slave devices. I2C terminators are actually mainly pullups, since the drivers are all open collector/open drain. They aren’t so much to match impedances to minimise reflections.
Here’s some fairly technical info:
Thanks, much of this is beyond me at the moment but there is a lot of food for thought.
If I2C is really not a reliable technology for distances of a few feet or so, then perhaps the central controller concept is not the best for this application. With indvidual microcontrollers like the Arduino Pro Mini available for less than $10, it might be simpler (and provide better redundancy) to make each instrument a standalone device, perhaps even each with its own small battery backup.
The all-in-one microcontroller with multiple sensors would still make sense for a complete, integrated electronic flight information system (EFIS) or primary flight display (PFD) or just a homebrewed aviation GPS with charts and airport data. A Rasberry Pi with a touchscreen seems like it would be perfect for that kind of use, but that’s for another time and another thread.