High level requirement in the short/medium term and extending into the future :
Sounds fairly reasonable with the possible exception of timely which is a fairly stiff demand of volunteers, but it's a double edged sword.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
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.