FreeEMS-Tuner Development Diary - Comments

[BenFenner]

Yah, good idea Fred. Now I just need to think of things to add that won't be binned and aren't too hard. =/

As for the orange button; great first step. Even if someone else does it before me I should still give it a try. I'll be able to start on it in about an hour.

[sry_not4sale]

Before anyone gets too stuck into this, I am about to commit a tidy up of the code. Its a rearrange of the file structure, and splitting up the monolithic gui source into seperate files for each element.

[sry_not4sale]

I would love to help out and brush up on python (i have never done anything serious with python) - let me know what you have in mind and i'll see if i can do anything about it. The next 2-3 weeks are going to be hectic for me - so i might be a little sluggish in responding......

Hey mate,

Just have a read through the source and ask any questions. Stuff is happening really quick so no point in giving you jobs until ya have time

[BenFenner]

I tried to download the *.zip of the new source but got a stupid error. I'd check that out. Had to do it manually again. I've just finished installing everything again (different computer) and I'm going to start on getting the display to show human readable as well as raw data.

[Fred]

Ben, if you haven't, you should sign up to the tracker so we can formalise the sharing of tasks a little better.

Also, if you have msn/aim, exchange that with Aaron and myself so we can keep in touch.

Fred.

[BenFenner]

I'll sign up for the tracker. PM sent with AIM screen names (pass them on).

Also, I like how there's a bunch of little things left out. It's like a good mystery novel. =P

Things I had to do to get it to run this time:

data directory missing (I added it and put my_config.ini in there)
"Fake" has changed to "Test" in the config (who knew? =D )
libs directory missing __init__.py file (I added a blank one)
protocols\FreeEMS_Vanilla directory missing __init__.py file (I added a blank one)

It runs again!

[sry_not4sale]

Not sure about the missing __init__.py files, as they are in the repo.

But yes, should have made it more clear about changing the comms plugin Fake to Test.

And I might have to alter the data directory behaviour (at the moment it is created on app startup if it doesn't exist, and will not exist in new installs)

[Fred]

Given that the ID's and names will only be for debug once the gui progresses I think the ID should still be visible with the name. Perhaps this :

19 : request beer from bar

or something.

The thing is, the ID is the ID, whereas the name mapping *could* be wrong.

I'm wondering why the incoming packets aren't labled with the same names as their packet types are the same? Is it that they aren't decoded yet?

I mentioned this before (in private maybe) but the ID is ONE number, not two. so its not 0,15 its just 15. if it was 1,15 it would be 271 (256 + 15), they are 16 bit numbers that you are reading one byte at a time.

Good work guys :-)

I should be able to get the comms interface to a semi final state in the next week or so which will move the weight off my shoulders and firmly onto yours :-)

I can't wait for the automated testing plugin ;-) It would be really cool to work out how to test every single comms code path in the firmware by bouncing packets off it repeatedly! Each release could be verified to ensure it's bug free if we had that :-)

If you didn't see, there is a VERY ROUGH matrix of possible errors to have with comms in the docs dir. I'm accepting patches to that document!

Fred.

[sry_not4sale]

Theres a very rough testing frame too That doesn't do anything...

Yeah getting on to the payload id numbers... they only display like that cos they are sent as two packets and the original diagnostics grid was quick and nasty

[Fred]

well, you could look at the packet as one stream of bits or a stream of bytes, or a stream of variable sized blocks. The serial interface provides them to you as bytes though :-) I know why you did it, just making sure it's clear that they shouldn't be like that. I don't care right now, but I do care that we all understand each other well! There is nothing worse than doing throw away work, and work based on a poor understanding of "requirements" is almost always that sort.

Fred.