Along with the new boards, I has also designed a relatively simple testing board, bringing all of the simulated control signals from a messy breadboard full of jumper cables and loose earths to a proper board with nice clean signals. In my rush to design it I had made a couple of silly errors in the design that required a little bit of re-wiring of the underside but after a some time, I managed to successfully test all outputs as working correctly.
The next phase was to test each function one by one, buy opening up my partially developed Arduino sketches, altering the inputs as necessary and going through the laborious process of checking the received signals, writing or re-writing the associated functions and then testing the output.
A major hurdle here was the fact that I am using presently 3 separate Teensy Arduinos which all share data via serial connections. The code that I wrote in version 1 worked ok, but I was sending too much data, too often, leading to overload of the message buffers and partial or truncated messages resulting in some spurious data creeping into my functions. This took quite a while to study how serial actually works to write some much more elegant and simple code to minimise the message length and send only what is necessary by sending only changed values or repeating the value every once in a while. I did eventually succeed with a rock solid send and receive code that I have used on all three sketches. It appears bullet proof and now shows no spurious readings at all while maintaining a data rate that is observed as real time.
With the data sharing code completed, I set about the next challenging task of digging right into the CAN bus and OBD-II code. Again what I had worked ok, but if CAN wasn't plugged in then my code would introduce long delays waiting for return messages which killed the performance. Also changing input source from Analogue to CAN and vice versa was clunky and introduced errors, resulting in another complete rewrite, and introduction of a new setup menu that allowed the user to easily see the current setup values for input sources, speed in MPH or KPH as well as calibration of the gear position sensor and other features. This took some time but I now have something nice and solid that's easy to use and stores all setup values in the EEPROM.
On to the TVR switchpacks and control of the LEDs. This I pretty much had to leave on the first version as I hadn't correctly specified the circuitry to properly control the LEDs requiring ground switching by using the wrong chip. This time around after some testing it appears that I have got the correct chipset, but I had made some silly errors and specified a couple of the control inputs on the wrong Arduino pins. I was able to re-route these via jumpers between my ribbon cable and the PCB input connector but still one was in a position that couldn't be tested. Lesson learned here and a new board design has been made and ready for manufacture but I think I'll wait until I've completed the testing and development of the software and the aluminium housing before I order this hopefully last revision.
Interestingly control of the LEDs wasn't as simple as I was expecting and required switching of not just the pin output level but the pin mode its self (input vs output) to get the LED to light and extinguish completely. In many cases I'm using the Arduino pin directly to earth or not earth an individual LED and without changing pinmode to enact a diode, the LED would extinguish but remain with a feint glow. With a little work this hurdle was overcome and eventually I achieved getting all but one (attached to the wrong pin) to switch correctly.
The next issue was trying to make sure that as lights lit incrementally on the light switch pack, that between positions the lights didn't switch off (i.e when between side lights and main beam mode). I ended up writing a little algorithm that counts how long since the lights were supposed to be on to keep them on until a positive message of on or off is received. This seems to work nicely so I think for LED control we're now done.
I added a couple more fiddly functions where the user could activate "dark mode" from the other arduino OLED to switch off all interior lighting for perhaps long motorway drives. This required a serial command running to the lighting board to then intervene on all operations to fade out and keep off all lights, then fade them back on when normal service was resumed. Another was shutdown mode, so when one board detects that the ignition signal is killed, it commands the servo board to re-set the steppers, the OLED to return to a TVR logo, and the lighting board to fade down all lights if currently on. Small touches but they make the experience feel much closer to an OEM feel.
After around 40 bug fixes and a load of new functions followed by some careful code optimisation and de-cluttering I now have around 3500 lines of code to control the whole pod - quite a lot more than I expected to have to write - and that's not including any of the libraries for the display, CAN bus, signal smoothing or anything else!
Here's a rather dry video made half way through the process showing the gear position and alarm screen takeovers:
Then another from a little later on with some more features implemented:
Comments
Post a Comment