So as we can see from the prior read me information we have a lot of the board functioning in a basic way.
Q:So why do this?
A: We have a perfectly working device apart from firmware, Also i've been wanting to dig into canbus etc for a while and this seemed like a good way by mistake of course.
So hardware wise it will be doing what it was designed for, reading cars obd ports to get codes, delete codes and report information. Now a quick browse of the various providers of OBD tools you get massive ones like snapon that do the kitchen sink to ELM devices that act as gateway for pc software.
Always carrying a pc with when i had rare chance to investigate a cars obd seemed as daft as the drunken sailor taking a nature moment at the end of the plank And no buried treasure to buy the Snapon tools.
The OM127 is a fit in the moddle with easy to read screen and BUS power as well as all the needed "bits" to access most OBD systems, whats missing is the decent software. In the short time i used the original software I found it limited, this may be by design to use K.I.S.S standards, many mechanics shy away from the dreaded 12V+ words and the other nasties like CAN 'who' BUS ,hmm, that sounds like a Egyptian god, a quick google later it seems not, Anubis is closest. Is it because it's ment to be cheap and basic in the function department so they can sell another bigger model, well to be honest it's normal practice for the latter, sell other model's with other features off one hardware platform, I will also come back to this as sometimes that one hardware platform changes but yet is still the same.
Anyway, Back OT,
Thanks to a few great OSS projects like u8x8/u8g2 , winbond spi for stm32, STM32duino , HardwareCAN lib also from the stm32 duino forums I have got a device that can sniff CAN and save to eeprom , it also displays the sniffed CAN signals.
Most of the code is test code to bring up the various parts of the original hardware, Thats LCD, Buttons, USB, CAN, K/L-Line/SAE , SPI (EEPROM) .
Most of the time was spent building a idea of how the hardware was tied together, what problems did the designers have (Like the C128's bus wire to eliminate a reflection) , did they fix it or ignore it or fix it in software ?
I'll fill you in on those choices/idea/theories in the net log update.