So a while back, I decided to test the client/server approach to the CarHUD with a simple server that just responded to the GUI client with random numbers. (I've been working on code and figuring other stuff out, I know, I should be posting what I'm doing) What I found was quite annoying.
It didn't work as well as I planned.
This happens in the Engineering world all the time. It's also why you do iterative testing throughout the design/build of your idea.
So what ultimately happened? The jsocket class I found and was using wasn't as responsive with the pygame GUI when I went from test code to actually trying to get everything talking to the car via the OBD-II device. There was also issues in getting everything working on bootup in the CarHUD OS.
I changed my method and added a threading feature to my ELM-327 library, this is in a separate branch in my bitbucket repo. The goal here is to establish the device within the pygame GUI and run that thread separately and use the Python Queue module to transfer data between the ELM-327 thread and the pygame thread.
I had attempted to test this, but it got cold where I live and I inadvertently blew a fuse in my car. Didn't know the seat heater was tied to the cigarette lighter circuit. Got a replacement fuse and some fuses for the old dvd player system that I'm using for a monitor (since I disassembled mine). Got the wrong size fuses for the dvd player...
Once I get a new set of smaller sized fuses for that cigarette lighter adapter, I'll be able to test again. Hopefully I can try that out tomorrow.
In other news, I've started another bitbucket repo for the CarHUD layer in Yocto. It isn't complete and I'm still trying to figure out how to get it work without modding or forking the Raspberry Pi layer.
Holidays are coming up and I'll be busy with those. If I get time and some results, I'll post them.
