Later i'll see if i can share the photo or ours, which i developed over the last year..
5 Analog out, 2 SENT out, four GPIO out, three digital out that can output in frequency or pwm. Each output is copied x4
16 Analog in, 8 sent in, 12 digital in, some with special pullup circuitry
switched 12V and 5V with current measurement
provision for communication and gpio lines on a secondary connector, to be used to implement programming and data download/upload
leds and buzzers to indicate the state of most things
ECU connector (because we had some laying around and more than 100f pins were used)
To test our products we have some hardware testers built by hand, some boards with a different firmware and some NI DAQs, we wanted to try and make a single more powerful tester (because all of the others lacked in some way, especially on the software side)
I looked around to see what was available and in my opinion everything i found either sucked somehow or cost an arm and a leg and probably worse required you to deal with labview and the need to keep an outdated computer because you know, this year's daq won't work with labview four years from now.
Also we had some "special" needs like SENT which required that we either build an interface board and give the data via analog/digital means, losing all the diagnostics in the protocol, or we needed devices with programmable bits. Some NI boards would have the capabiltiy, but again crazy prices, labview and not so open protocol. ugh.
I am planning to make my device standalone at some point, otherwise the API i came up with is very simple, one usb edpoint handles the setup (IO, configuration, test script) and another endpoint spouts out 32ms worth of data, plenty of time for the master to acquire, put in buffers and update the display..
But i digress.
What i didn't like of the available offerings was:
- IO connections. Having stripts, terminal blocks or ICD is fine until you have to deal with higher speed or more than a handful of signals. Another solution is needed or you have to make it easy for the user to design in an interface board. Terminal blocks are the worst. After a couple of years those in the NI DAQs became loose and should be substituted
- Most seemed to rely on either external power or VUSB for the analog supply. Worse, some also used it for reference. In our boards we technically need to test for 12V but most of the time 5V only is fine. But we need to test for 5V, not for 4.5 and something. In my board i put a sepic converter after VUSB. so the power comes from either the SEPIC or the 5V LDO. the SEPIC is switched off if power from the DC IN block is detected
- I couldn't find an API document or a way to write my own application around it
- I didn't find a way to program custom protocols
What could be interesting:
Hardware that solves the first two problems above, and hardware that i can freely program myself. So having a schematic , to see if my custom application is feasible with the board. Just not having to build and test the hardware is a HUGE cost saver.
To give a metric, i'm almost running at full capacity with the 8 sent in / two out, the program cycle is executed at about 40 KHz with a dsPIC running at 140MHz/70 MIPS. Most things are DMA'd but a good software SENT implementation takes lots of processing time. With a simplistic one, skipping most of the diagnostic, i could probably run the thing at half the speed