DIYEFI.org Forum

Aaron asked for it, and here it is. The place where I say "I want!" and these guys go "you make NO sense, Fred, explain??!!" or similar.

High level requirement in the short/medium term and extending into the future :

I want to be able to conveniently interact with all implemented firmware features in a fairly timely way with respect to when it gets implemented on each side

Sounds fairly reasonable with the possible exception of timely which is a fairly stiff demand of volunteers, but it's a double edged sword.

The balance is to not expend excess effort into making stuff work for me now without tangible benefits into the future.

Aaron specced his second release goal as support for another EMS, clearly that is going to be MS2 (well, that makes the most sense to me in terms of harnessing maximum testing power). I think this is an admirable goal and worth pursuing for sure.

So, what does this mean right now :

The tables that bens stuff pulls, I would like to edit and send back. edit mode should be in replace only and Hex unless parsed into its real structure. replace only mode = can't mess up the length...

I'd like to be able to use the cell and axis setting functions to adjust the cells in memory on top of raw editing.

It would be nice if the fetch of blocks and send back came to and went from individual specific places, maybe auto generated tab with hex and editor and embedded payload ID and location ID pairs. I imagine that could be implemented generically and give quick/easy access to all the data with the 5 basic memory functions.

i'd like to be able to kill and enable the datalog stream and request datalogs when the stream is off. the requests should be able to adjust the length of the datalog sent. The datalogs should be parsed and displayed in a readable way.

i'd like to be able to reset the device (implemented already)

i'd like debug messages to be displayed as such

i'd like error messages to be displayed as such

i'd like the tuner to keep up with the data flow at less than 50% cpu load.

i'd like packet parsing to be reliable and accurate.

i'd like the tuner to know its talking to freeems or the serial monitor and offer to switch between with appropriate commands/switch movement.

ordering these tasks....

hmmmm....

1) right now, cell and axis setting and datalog on/off are important. as is speed and reliable accurate packet parsing. This lets me use it at all and lets me test the comms stuff and flash stuff properly.

2) after those I'd like to see the numeric values of the datalog packets displayed. This lets me work on the math code.

3) block editor and/or auto tabs for each location id - this is my configuration editing facility with which i can adjust things in real time to test without a reburn as i have been doing till now

500) gui eye candy to keep the public interest ;-)

888) interrogation with version display and code matching and serial monitor detection etc. important to the app, but not so much to me right now though it would be nice to have.

999) error and debug are unimportant as I can read the hex and look up the errors, and I can read the ascii and see the debug message already.

I'm not sure I can do much better than that :-)

I think I've been pushing you and ben to do number one and two and three fairly solidly already, so just keep up the good work i guess.

Fred.

Sweet thanks for that mate

If you have an questions or want to discuss anything etc, just post :-) Some of it may be vague or unclear. Ben tells me I'm good at that... I don't doubt it. If you aren't certain, just ask :-)

Fred.

Fred wrote:The place where I say "I want!" and these guys go "you make NO sense, Fred, explain??!!" or similar.

Just stop using pronouns. Pronouns are not allowed anymore. You can't use them. Pronouns that is. You cannot use pronouns. Sorry. Fred cannot use pronouns. Clear?

Hahahaha

que?? it she they you them us

2008-12-08 11:21:11,817 DEBUG comms.Serial - Size of pySerial buffer: 4092
2008-12-08 11:21:11,837 DEBUG comms.Serial - Size of internal buffer: 434820

Hmmm, something is wrong with that...

2008-12-08 11:21:11,817 DEBUG comms.Serial - The pySerial buffer is overflowing constantly.
2008-12-08 11:21:11,837 DEBUG comms.Serial - Size of internal buffer is growing rapidly and in an out-of-control fashion!

Fixed! :-)

Looks like threading could solve those checksum and escape issues perhaps, you could be getting escape bytes as the last byte in a buffer followed by a totally different block of data.

Fred.

Mate, bear in mind that if we get the threading and accuracy sorted and performance is still a problem that is difficult to solve we can just disable full speed logging and you can poll for the data by setting up a timer to send request packets at a rate the app CAN handle. This will get us running and using it sooner. For me to attempt to run the carina with it early next year I'll need a semi decent interface, but I don't need uber fast datalogs, just datalogs and display of data at a reasonable rate, (4/second would be OK probably for a start.

Threading and accuracy (along with the front end and decode stuff) matter the most IMO.

Fred.

This may be optimistic, but I've turned on the board to warm it up ready for some epic datalogging action :-)

Also, I'm ready to have your children as discussed. If not, I guess I can have dinner instead.

Fred.

Very optimistic

Gonna start a thread to discuss the options on threading... its doing my head in