There have been numerous parts of D-DAQ that I've had to theorize in order for things to function as I desire. First order of business was figuring out the baseline hardware I'd need. I couldn't find any MCUs that had multiple parallel interfaces and it's be very costly in board space to implement 3 of them. Serial was next on the list and SPI was the best contender out of what was available due to its sheer speed. Since I was simplifying the workload and dedicating 1 SPI channel to each display, I didn't have a need to use the CS lines and I could tie the pin to ground plus there is no MISO pin on the SEPS525, thus I only need the CLK and MOSI lines from the PIC32MX.

As there are a few different configurations that the user would probably want to alter, I need some way for the user to interact with D-DAQ. The bare minimum number of buttons needed for a UI is 3, imho. Now, though the display has no use for the MISO line, it will stay active on the PIC32MX so I might as well use it for one of the buttons. I also need a few LEDs for accent lighting as I know part of the community this idea originates has a particular interest in indigo and I'm sure there are others as well. A set of visual warnings is needed for each display as well in case a parameter is exceed; tack on one control line. Also, a lot of driving occurs as night so tack on another control line for brightness adjustment of the accent and warning lights, of which will be PWM based. Cannot forget about power, both 3.3 V and 14 V for the display. Though I could do on-board 14 V generation for each display, or I could use 1 regulator on the main board and send it to each display. The latter of which I've chosen to do. Now when you sum this all up, there are 9 lines I need to run to each display. Ironically, this is just as cumbersome as a parallel interface, though only 2 lines are dedicated for data transmission.

I quickly figured out I needed to find a highly dense connector with 9 conductors or more. A custom solution was out of the question due to cost an proprietary nature. Though a 5x2 pin header could work, it'd take up more space than desirable; plus the cable wouldn't be shielded and a greater immunity to noise is is desired. With the introduction of a newer generation of Mac Minis, I became aware of the Mini DisplayPort connector. It's 7.4x4.5 mm which makes it nice and compact, which is a little larger than 2 MicroUSB terminals stacked on top of each other but with more than 2x the pin count. Long story short, it turns out that mDP to mDP cables are actually apart of the DisplayPort standard. Each cable has 20 conductors, 6 of which are dedicated grounds and are attached to shielding different parts of the cable. The next option was Mini HDMI, but the standard calls for royalties... Decent quality mDP cables can be had for less than $5 each. Receptacles are $3-$4 each, which is a little high, but worth the cost. Due to the newer interface name, Thunderbolt, several mDP receptacles are being phased out and replaced by Thunderbolt ones. The only difference is a standardized pin out which happily means no change to the plug.

Now, 3 displays. Each 160x128 pixels with up to 18-bits-per-pixel, though I'll only be running at 16-bpp. In order to not redraw an entire display, its simplest to only draw what has been changed. I'd need to compare what is already on the display and what will next be on the display in order to do this. On the PIC32MX795 and PIC32MX695 I have 128 KB of RAM. Ohhhh that much makes me all tingly :). Though to hold a copy of each display in RAM, I'd need 120 KB. Oops. Now I can avoid this by adding a whole bunch of complicated code and always having to draw out each display in it's current state and future state and then compare them, but I'm not fond of that type of inefficiency so I figured I'd have to store a copy of each display somewhere. Microchip documents a Low-Cost Controllerless solution for graphics display using DMA and their parallel interface. It turns out, 128 KB is 1 Mbit, which is a fairly standard size for SRAM, of which I can use in place of a display in their LCC setup. According to the datasheet, it takes 5 clocks of the PBus to do a 16-bit read and 6 clocks to do a write with the PMP (Parallel Master Port) which is plenty fast enough for the buffer.

Here is the fun that I encountered just before I started screen shots to document the evolution of my schematic capture... When I found out that I'd need the PMP interface, I was a little dismayed due to the extra complexity of the board layout. I quickly found out that the PMP interfaced, albeit with or without multiplexing the data and address lines, knocked out 2 of the 4 SPI interfaces on the 64-pin TQFP package since they occupied the same pins. I would then have to move up to the significantly larger 100-pin TQFP or use one of the 2 non-leaded packages; the latter 2 of which are highly undesirable at this point in time. So, I have to make the 100-pin TQFP package in Eagle and start anew. 

Next up were my analog inputs. Having a dozen or more makes things a bit cumbersome so I wanted a compact, robust, and preferably shielded. After establishing that there is a need to use amplifiers for certain types of sensing and the fact that other various sensors need power, it was clear that I'd have to figure out how to provide power and input lines in a compact form. Fortunately most USB cables are shielded and the Micro USB Type B fits the bill nicely. I have 14 inputs, a few of which are utilized on-board, so this nicely divides up into pairs. I'm using the standard pins of 1 and 4 for power and ground and then utilizing D+ and D- for the analog inputs.

My last additions to D-DAQ were to provide some alternate checks and balancing of pressure inputs and assisting with logging. I've previously mentioned logging in other lab posts and some might wonder what this is. When a car's performance is modified it usually becomes a custom application because each engine is different. As such, the tuner needs to know how fuel, air, timing, and maybe a few other things are behaving. 

14 Analog inputs using Micro USB Type B

Numerous digital I/O pins for buttons

Two I2C busses for barometer and temperature, accelerometer, and separately a Micro SD card

All 4 Output Compare pins (PWM pins) - Together these will control the accent light brightness and warning lights

JTAG via a Micro USB port

ICSP pin

Optional CAN connectivity