I've talked at length about the mainboard for D-DAQ because that is where so much has to go right for anything else to be functional. In order to do something with D-DAQ so it's not a lifeless brick, there needs to be a way to see what's going on (duh!) so that brings me to the displays. So, though I've mentioned some details about these boards, here is the design philosophy behind the boards and why they're a little more complicated than just an adapter.
First up is how we get to the displays and that obviously means a physical tether, a cable, unless we're going RF. Come to think of that, it would be kind of awesome for that to happen but I digress. The minimum connections I need are power, ground, SPI Clock, SPI MOSI, and 1 line to toggle between commands and data. In fact, you could almost use a standard USB cable with this though due to other design considerations, I need a few more connections.
D-DAQ is capable of 16 inputs, albeit 2 are digital and may not need to be visually monitors. Even on 3 displays, this is still a bit of info and especially so when the design scheme, a gauge, means that at least 1 piece of info is largely dominant on the screen. So, 14-16 inputs on 3 displays? How do you figure out what goes where? Do I dictate that or let the user decide? Who here has a product that your interaction is dictated by the manufacturer in a frustrating and non-intuitive way? Yeah, I'm trying to avoid that, but nothing will ever be perfect. Anyhow, this brings me to the point where I need some sort of user interaction so buttons are getting tossed into the mix.
If time and space were not a concern, I'd mux the buttons and send them over the MISO line back to the PIC32 on D-DAQ. However, I don't have the space for such an encoder at the time. A basic UI needs at least 3 buttons to walk through it and then some very intelligent design to minimize frustrations. I'm adding on 3 more connections required for the buttons.
One detail that I nearly overlooked is whether or not a display is plugged in. This is commonly referred to as Hot Plug Detect[ion]. Pull a pin high or low, it matters not. It's just nice to know if I'm sending data to a display on the other end or not ;)/ Add 1 more connection.
Next up, this stems from the idea of being a gauge. A gauge tells you about a physical aspect of, well anything, the device under operation. What happens if all of a sudden this physical aspect goes beyond it's acceptable parameters? I love the OLED screen because each pixel emits it's own light. Though this is advantageous, they usually are not bright enough for illumination, just indication. I could go with sound, but who here likes the door chime in their car when you leave a door open or headlights on (intentionally). Besides, speakers are big, even piezos, and they need some additional circuity for driving and the modulated signal for a tone, etc, etc. This is ignoring the fact that our eyes have better spacial acuity than out ears. Well, that leaves the good 'ole LED for a warning light. I don't like the fact of just 1 degree of warning because with physical devices, there is a zone where you're stressing the device, but not at a threshold. I happen to find the perfect 1 chip, 2-color LED that outputs red and yellow; perfect!
Well, while I'm on light(ing), I figure that there will be some people who want to integrate this into their vehicle with some semblance of it looking or matching the stock appearance. I know this is a particular desire for the 4th gen Volkswagen Jetta owners. The blue on their dashboard is indigo, which is not quite blue, but not quite violet. From looking around online, this comes out to a wavelength of about 430 nm. Though I'm not catering D-DAQ to one particular manufacturer, let along a model or generation, I am still paying homage to the community from which this idea first existed and where I've drawn inspiration from. As such, indigo accent LEDs are on the PCB. In fact the layout supports any pair of LED that sports a series forward voltage below 13 V. This is basically any red, yellow, blue, green, cyan, magenta, etc LED you can shake your fist at. The display board can be adjusted relatively easily by a resistor change and, if needed, a package footprint change as the indigo LED is on a 1206 (US) footprint.
LEDs are amazing little devices, but they vary in brightness and current draw heavily. Some are too dim to be seen when in direct sunlight while others are blinding. On top of that there are various control methods utilized for adjusting their brightness. I have native PWM on the PIC32 I'm using so I figure I might as well put it to use. Though it's not able to source enough voltage to drive a single LED while doing the multitudes of other operations, the PWM signal is strong enough to control a MOSFET to sink more power into the LEDs with short duty cycles. Since the Warning and Accent LEDs are functionally different, they need separate control lines. Add 2 more to the mix.
As I mentioned a short while ago, the I have a nice high(er) voltage rail I'm using to power the LEDs. Now I could just run a 14V line up the the display board and a 3.3V line for logic, but having individual regulators, linear or SMPS, on board will just create expense and headache and heat that will hinder development. This is why I had to do a bit of an overhaul on the power subsystem of the 3rd prototype. Despite that headache, it's simpler and less costly to have 1, 14V source and feed it to the displays, imho. Tack on an addition power line.
Now, reason would have it that for a specialized device, being pretty distracts from danger. As such, I have to make it so when the Accent LEDs are on, the Warning LEDs are off and vise versa. This is convenient too as it reduces power consumption ;). Well, before I found out I have extra control pins, I had to come up with a clever solution to this. This is why it's tricky:
Though the Warning LEDs are single chips, they are 2 LEDs. I've decided to utilize the duty cycle of the PWM wave and use a P-channel MOSFET complimented by an N-Channel MOSFET, both on the same IC too, to accomplish this and not need 2 PWM lines for this single feature. I'd also need to turn this circuit on or off and due to the MOSFETs I'm using the only reliable way to do this is to actually cut the power power. I'd need an additional control pin for that and I don't have any.
Well a PWM signal can be passed into an RC circuit to get a rough analog voltage. Using a 2nd order filter smooths that our considerably though. I happen to be using some SSRs (solid state relays) on D-DAQ's main board for similar control. Using a Normally Closed SSR that is driven by the output of a RC filter on the Accent light LEDs means that there will be no power for the warning LEDs. I tuned the filter to turn on at approximately 10% brightness output of the Accent lights so there should be plenty of distinction between the two sets of LEDs.
Separately I'd need another control line. Through limitations and designing around them, I don't need a 3rd PWM line or additional control lines. So, even if I've not talked on them specifically, I need the following lines to have a functional display board:
- 3.3V Power
- 14V Power
- SPI Clock
- SPI MOSI
- RS Toggle for changing the display between Command and Data
- Buttons 1 to 3
- PWM for Warning LEDs
- PWM for Accent LEDs
This tallies to 11 conductors that I need in a cable. I could run 3 USB cables, use custom ribbon cables, or find a high count, production cable. Mini DisplayPort was opted for due to size, royalty free use, and pin count. It beat out micro HDMI because a mDP to mDP is a standard cable but micro HDMI to micro HDMI is not. Though there are technically 14 conductors available, I thought it wise to keep the outer most SMD pins unused so I have more receptacle options and avoid shorting out the board, just in case ;). If the will of the people will have it, and this project becomes desirable for purchase, I'll spend the time to rework the mainboard's layout to utilize those 3 extra pins I have and remove the 2nd order RC filter that controls the Warning LEDs. I have that 1 pin open ;).