After much research, I managed to track down the Arduino source code from the example project that sparked my interest. It wasn't complete, but it at least gave me some insight into how it is supposed to work.
Having coded visual basic to a reasonable level the coding didn't scare me too much, but the language was quite foreign, so it took a bit of time to figure out how to talk to it. To help me understand, I purchased a couple of pre-made projects from skpang.co.uk. One was a CAN bus reader, the other a CAN bus emulator - the plan was to emulate a CAN bus signal, and then write my own code based on the source code I already had to replace that on the reader. Once I had a working model, I could build out from there and add functionality.
This took quite a while, and a lot of failing and error messages until finally after about a week I got something to compile. Within a few more attempts I actually got it to work; reading a CAN signal, and displaying it on the OLED display. Woohoo!
My plan was to build a small display that would be nice and neat and small, though be able to display the information that I would need less frequently - I wanted to make the dash as clean as possible, but still functional so I could get the information that I needed. To do this, I would need a display that could cycle through various "pages" showing different data and performing different functions which would pull information from a variety of sources.
First off, I needed to have a a rough idea of what I actually wanted the display to do, so I set about building up my proposed menu system, with various displays for speed, temperatures and pressures, and warnings/alarms for variables running out of range. I mostly copied the example that I had to use as a starting point; once I had a working model it would be easy to tweak it and by then hopefully I would have a clearer picture of what I wanted to see.
This Took SO Long to Reach...
I realised during this process that I would need some memory functions in order to remember the mileage, odometer reading and some other figures that might be helpful to remember between runs of the car so I then spent some time understanding the Arduino EEPROM memory, and its limitations - each address will only take 100,000 or so write actions before it stops working. This may seem like a lot, but if incorrectly managed it could be exceeded very quickly. Some thought was required, but I ended up with code which only wrote to the EEPROM if the car was shutting down (once the ignition signal was lost), and if the values had changed since loaded. Furthermore, if 100,000 writes was approaching (a counter was employed) then I would shift the write addresses by a few figures on a rolling basis, so I should never burn out an address, and have millions of writes available as there are around 1000 memory addresses to choose from - this should easily outlast the car!
 |
| It Lives! |
Once complete, I decided to turn my eye closer to the CAN bus, before quickly realising that the GM system that comes with the engine I've ordered (an 2019 LT4) uses the GM-LAN protocol, based on CAN, but using a little understood protocol, and two single wire comms systems - one high for major engine functions, and one low for ancillaries and non-essential car functions. I read up on the system and quickly lost interest - this would not be a remotely simple task, especially without a live system to test on, so I elected to instead use the analogue signals that I would have available from the new loom for speed, tacho, oil pressure, oil temperature, water temperature and fuel level. This would be plenty to begin with, and I will wire up the CAN wiring to the Arduino so I can add functionality to it later if I see value in doing so, and the protocol becomes a little more publicly accessible.
This did simplify the code quite considerably which was nice, so I moved on to trying to take my signal and try and operate a pointer servo. Rodney from Caerbont had very kindly donated me a collection of VID branded servos, some with acrylic shafts for backlighting, and some without so I could test out some development scenarios. The first thing I realised after some internet research was that I couldn't easily directly drive a servo from the Arduino; I would need a servo driver chip, so I bought some chips designed to work with these servos "VID-6606". Each chip can drive 4 servos which is perfect for my application, and there is some freely available code on github which can be used to drive the chip and servos relatively simply. I say simply, it still took a fair amount of fiddling to get the syntax right but finally I managed to make my servo move - joy!
 |
| Rodney's Servos |
Sadly it moved very slowly, and after much debugging and diagnosing I simply couldn't understand why, so I consulted the Arduino forums. Whilst extremely helpful, they did slightly make me feel very novice in my ability and general understanding of electronics (good to keep the ego in check!), though I learned a lot - a very helpful resource. After much discussion, it transpired that while the Arduino processes very quickly (in my case a Teensy 3.2 so even quicker than an average Arduino), the time taken to fully communicate enough data packets to update the OLED was taking a huge amount of time in relative terms. As such, the Arduino spent so much of its time communicating with the OLED that the time spent sending commands to the servo was brief and infrequent, resulting in poor response and performance. Bugger.
Slow Moving Servo
It seemed I would need a second Arduino; one to manage the OLED, and one to manage the servos - not the end of the world but more complexity to consider. The next thing to do then would be to start to make sense of how this little system would look to understand more about the components I would need. Ultimately I will need to design and build my own PCB - an extremely daunting challenge - so I began to read up on how one actually goes about achieving this.
Before long, I landed upon AutoDesk Eagle, and after a few minutes playing with it, realised that my brain was about to get stretched far beyond its comfort zone.
Comments
Post a Comment