FreeEMS-Tuner Development Diary - Comments

[Fred]

LOL, I scrolled up and found this :

Code: Select all

01:37:21 comms.handleReceivedPackets    DEBUG BasicDatalog packet received and processed 
01:37:21 comms.handleReceivedPackets    DEBUG BasicDatalog packet received and processed 
01:37:21 comms.handleReceivedPackets    DEBUG BasicDatalog packet received and processed 
01:37:25 comms.default.receive          ERROR processReceiveBuffer could not parse buffer. Unescaped bytes found in packet: 0x08,0x01,0x91,0x00,0x60,0x63,0x33,0x64,0x5E,0x00,0x00,0x62,0x80,

So it 'is' doing something... the message makes no sense though. It is 100% valid for escape, start and stop byte to be found inside a packet post unescaping it. You can't even search for pairs because they are valid after that phase too. Looking at the data above I see stop start pairs left right and centre. All of those packets were valid and should have been received. I'm willing to accept that some of my sent data is bad, but not that much!

LOL, the next MASSIVE block up says this :

Code: Select all

01:37:21 comms.default.receive          ERROR processReceiveBuffer could not parse buffer. Checksum is incorrect! Provided: 4, generated: 98 0xAA,0x08,0x01,0x91,0x00,0x60,0x63,0x33,0x64,0x5E,0x00,0x00,0x62,0x80,0xF3,0x1C,0x43,

At the top... which is just funny as it must have counted up ALL those bytes before realising something was wrong.

Definitely some filtering going wrong somewhere.

Fred.

[Fred]

I captured all that text into a file and catted it out, similar CPU usage :-) Still, it is a LOT of text : 1 meg

I'll zip and send. You can clearly find good packets in amongst it though which means your error handling is dodgy. It should never be possible to get massive blocks like that. Each AA start byte should mean a new block. Not sure what you are up to, but hopefully the text dump helps you out!

Fred.

EDIT BZIP2 FTW : 1meg >> 5k LOL must be a bit of parse-able repetition in there ey ;-)

[Fred]

Code: Select all

Exception in thread controller.app:
Traceback (most recent call last):
  File "/usr/lib/python2.5/threading.py", line 486, in __bootstrap_inner
    self.run()
  File "/home/fred/workspaces/home/freeems-tuner/controller.py", line 215, in run
    result = getattr(self, action)(data)
  File "/home/fred/workspaces/home/freeems-tuner/controller.py", line 259, in _actionShutdown
    thread.exit()
AttributeError: 'ReaderThread' object has no attribute 'exit'

Without connecting to the device and without flooding the console i get that when choosing quit/exit.

This is from within eclipse. I'm going to attempt to trace the code with a debugger now and see if I can fix it. I expect to fail, but it's worth a try :-)

Fred.

[Fred]

Well, I got it running from eclipse with the debugger, hooked up to the device and set a break point and stepped through and over and into bits of code. Unfortunately I don't understand the python well enough to make much sense of it. You would though. So get eclipse, get python-psyco and get the pydev plugin and get fixing :-)

http://pydev.sourceforge.net/features.html

LARGE image (200k 1680 1050) http://i260.photobucket.com/albums/ii15 ... clipse.png

Syntax colouring, code completion etc. You never know, you might even like it.

The way to use this would be with carefully constucted test data. You could know what the expected behaviour should be and watch to ensure it behaves as expected. Then again, unit testing of functions to perform such tasks would be a good way to go too. Then you can explicitly say "for this data the output should be this".

Do you have any unit tests on anything? The way it's written (unless I don't understand it, which is probable) might make it difficult to test. You might want to do some refactoring on various parts of it so you can prove it works correctly. Unit test != integration tests (such as the test data black box stuff).

No more time for that today, will work on the firmware more tonight and hopefully talk to you this evening about this.

Fred.

[Fred]

Give me the format and i'll draw you up some potential real life scenarios to test with!

Fred.

[sry_not4sale]

sry_not4sale revokes Fred's github privileges after he tries blowing up my repo

[sry_not4sale]

Ohh just noticed you can upload files for download!!! W00t. Hopefully it's more reliable than the commit downloads.

[Fred]

sry_not4sale revokes Fred's github privileges after he tries blowing up my repo :P

Oh come on! (what exactly did I do?)

Fred.

[sry_not4sale]

Nothing lol. Just reset HEAD to a commit from a month or so ago. All fixed

[Fred]

Woops :-(

I did pull and then commit and then push and it didn't work. I don't understand why. Then I made the mistake of trying force... I guess the lesson here is don't take long lunch breaks? :-)

Fred.