FreeEMS-Tuner Development Diary - Don't Post!

[sry_not4sale]

Lots of little things including:
- Internal settings interface - now saves column widths between sessions
- Fixed bugs in receive code
- Added generic packet type for parser, to be used for unknown/unimplemented packet types
- Fixed receive buffer code to not loose data or possibly get stuck in infinite loops

[sry_not4sale]

No code updates, just been handwriting structure for some new features. Been busy giving wife/child/mazdas attention

[sry_not4sale]

Diverged a bit from the important stuff and start playing with the opengl eye candy

[sry_not4sale]

Merged bens changes into the master/trunk branch.

UI code is now organised a little better, moving stuff out of a monolithic gui/__init__ file, into gui/tab/* files.

Next job in that area is to remove any ui element code out of the tab code, and use generic layout functions to make it easy for people to customise the interface. Baby steps tho!

Also updated the receive code to make the distinction between protocol and firmware payload ids. Now Fred can try again with the hardware and see if that fixes some of the problems

[sry_not4sale]

Merged bens stuff in to master branch finally (sorry ben!), just have to push upstream

[sry_not4sale]

Pushed...

Changelog:

Code: Select all

commit cfd786227d0f8c9eb46e6880f5c9eda0f3c5ea3d
Merge: b1e866b... f7488f1...
Author: Aaron Barnes <aaron.barnes@hbcosmo.com>
Date:   Tue Dec 9 17:46:06 2008 +1300

    Merge branch 'benfenner'

commit b1e866b0ced9216e0fbfbbbf9b1101fe2b4b999c
Author: Aaron Barnes <aaron.barnes@hbcosmo.com>
Date:   Wed Dec 3 08:25:07 2008 +1300

    Adding JSON data file support, including interface for updating.
    
    Now loads memory location ids from data file
    Renamed protocol type to IFreeEMS_Vanilla

commit f7488f17b63e582fb3a4449967f07abdeb81a67e
Author: BenFenner <fenfam@sc.rr.com>
Date:   Tue Dec 2 07:42:58 2008 -0500

    make realtime data display ints as right justified to avoid shifting numbers

commit 973dbe0b551d126f664a6750ddf3b6d9402c03a4
Author: BenFenner <fenfam@sc.rr.com>
Date:   Mon Dec 1 20:19:17 2008 -0500

    Add new tab for real-time data display and clean up some old code of mine

[sry_not4sale]

Alright, pissed around with threading on the train last night.

Have the comms class in its own thread now. Was relatively easy, just extending the base class for comms plugins to include the threading code, and moving generic code out of the plugins.

Worked out the threading.Condition class wasn't really what I wanted, and went with threading.Event which just blocks until another thread to run its .set() method.

So had it running on my dev box with no other threads set up yet, it was segfaulting when it tried updating the gui from the comms thread. But that is code that needs to be changed as I add the other threads anyway - so sorta expected. Still happy that everything seemed to go according to plan so far!

The thread is created when the program starts up and first creates the comms object, and then creates the blocking Event and just sits dormant until it another thread runs the .connect() public method. Then loops sending its buffer and handling received data. No handle of disconnect events or program shut down yet, I'll do that next.

While I was in there I also setup support for multiple comms connections. All the api's are the same and still simple, with the 'default' connection being returned if none specified. Also, protocols are now attached to comms connections, which should simplify accessing protocol methods. connection.protocol.method()

Will keep this thread updated with progress since its not a one train ride job

[sry_not4sale]

Continued my threading adventures again today.

Now have a app controller object/thread, which at the moment manages the startup and shutdown of the child threads.

It has an action queue, where it takes string actions + data from the gui, and feeds them to the controller method named after the action. That method would contain logic, and possibly create a worker thread for bigger jobs or jobs that required concurrency. If this thread got locked up, it would slow any gui updates so I am probably looking at threading most actions.

Next job is altering the gui thread to use the controller, and working out any flaws in the plan so far.

Then send/receive threads.

[sry_not4sale]

Last night on the train I fixed some segmentation issues I got when shutting down the app.

Seems the best way to do things is to leave the gui in the master thread, since it throws around the most global variables, interfaces with c libraries and controls alot of inter-thread events. Originally, I had the gui in a new thread, however this was giving me problems.

Added a .exit() method to all the threads that turns off the ._alive flag and wakes the thread if its asleep. The thread then will run its logic loop, see that its not alive and exit nicely

[sry_not4sale]

OK, this morning on the train I did a bit refactor of the thread and thread control code. There is now a tuner specific thread class to inherit from, which includes the relevant setup/shutdown functions, blocking/sleeping, and thread safe logging.

I found that the standard python logging to file module was not thread safe at all, and causing all sorts of issues.

Code is *alot* tidier, and *alot* simpler now. Starting to move gui actions into the controller thread, this should give me an idea on how to implement the send/receive threads best.