Move/Copy model should not write EEPROM until user confirms the action

[GoogleCodeExporter]

Following on from Issue 73, we now need to make the model move/copy function 
not actually action the request given on screen until the final [MENU] to 
confirm has been pressed.

With a list for of simple models, it takes only a half second or so to do all 
the reading/writing, each time a model is moved or copied one position up and 
down the list. The delay is almost acceptable. But when we encounter my Trex500 
model -- or any other more complex/larger data set model -- the delay can be 
more than 3 seconds, which is disconcerting to the user and not acceptable.

"Working ..." pop-up required.

Finally, we really need to have a pop-up window come up that says, "Busy" or 
"Working" or "Wait" or "Saving", when the final actioning of the user's 
selection takes place. Again, this pop-up will appear only briefly for 
moving/copying simple models -- but for several seconds in the case of more 
complex models.

---
Thanks Bertrand -- you're a legend you know -- and I hate bogging you down on 
the boring stuff like this. But I'm really looking forward to being able to 
re-start the two week countdown clock again. :-)

Original issue reported on code.google.com by gru...@gmail.com on 20 Nov 2011 at 1:05

[GoogleCodeExporter]

Read, understood, agreed.

Original comment by bson...@gmail.com on 20 Nov 2011 at 8:07

[GoogleCodeExporter]

Three steps needed to be addressed:
1) only do write operations when [MENU] is pressed
2) accelerate these write operations which must be synchronous by avoiding the 
interrupt mechanism
3) popup on screen

Today I commited 1) in trunk. As more testing is needed at this stage. I would 
like to wait some feedback before commiting in frsky branch and going further 
with 2) and 3)

Original comment by bson...@gmail.com on 23 Nov 2011 at 10:15

[GoogleCodeExporter]

I have a stock 9X back in my possession. Testing now ...

Original comment by gru...@gmail.com on 24 Nov 2011 at 12:11

[GoogleCodeExporter]

Testing completed. Many bugs exist I'm afraid. SO many that's it really not 
worth trying to describe them all. I'm sure you'll see that moving and copying 
sometimes crashes (WDT reset) and sometimes, somehow, locks up completely with 
no watchdog reset.

The only reasonable clue I can give right now I think is that it seems to work 
mostly OK if copying or moving to location right next to existing models. But 
if I copy or move from, say, slot 1 to slot 10 or 14 (many gaps) then things 
start going seriously wrong, most times.

One time I did successfully move to slot 16. But the write process took at 
least four times longer than it should have. I mean, no key response for about 
five seconds -- on just a simple 4-ch default model.

Is it not a simply matter of recording the source, destination file numbers and 
the mode and then just using those three variables after [MENU] is pressed to 
do the operation? I'd have thought that part was easy and only the actual 
on-screen display manipulation was the new and tricky bit? (Sorry -- tried to 
read the code but couldn't make any sense out of it (quickly.) I'm not often 
very good at reading other people's C code and making sense of it in my head.)

Original comment by gru...@gmail.com on 24 Nov 2011 at 1:00

[GoogleCodeExporter]

Errors described above have been reproduced on a real TX and solved
To the steps described above, I will add this one:
1*) accelerate the MOVE operation when many moves are in progress. The 64 first 
bytes of EEPROM need to be writen only one time, not as many as move operations.

Original comment by bson...@gmail.com on 24 Nov 2011 at 8:25

[GoogleCodeExporter]

That sounds interesting. I guess you could get down to lower level and 
manipulate the root dir entries in the EEPROM file system, to do it even 
faster. But that's probably not a good idea. In fact, whilst it would be very 
clever -- that's a very bad idea.

I have to sleep early tonight. Very tired. I will test the bug-fixed code 
tomorrow morning.

Original comment by gru...@gmail.com on 24 Nov 2011 at 9:06

[GoogleCodeExporter]

Actually -- not such a bad idea if you implement a 'swapDirEntries(ent1, ent2)' 
function within the EEPROM file system itself -- and then only call that from 
the user model menu routine. That way it is safer and theoretically 
maintainable for the future.

On the SD card version, it would be a simple renaming of file names -- say, 
swapping names of MODEL01.DAT and MODEL02.DAT, to move MODEL01 down one 
position. But why am I talking about that? It doesn't even exist yet. :-P

Original comment by gru...@gmail.com on 24 Nov 2011 at 9:09

[GoogleCodeExporter]

Right, this is what I have in mind: a swap operation could avoid writing 
64bytes (which in a case of a 15 lines move could cost up to 15*64*6ms=5.76s). 
It will only write 2 bytes.

My previous idea of one unique 64bytes write at the end of all move operations 
(within memory) is bad, because it will be possible to loose many models.

Side note: today, during a copy operation, or a change within eeprom it's 
impossible to loose data (because we write in the TMP entry and then we write 
the index table). But during a move operation, I see a possibility of loosing 
one model. With the change I propose above, the possibility will be reduced 
because of the speed improvement.

Original comment by bson...@gmail.com on 24 Nov 2011 at 9:22

[GoogleCodeExporter]

Ok. Just tested on TX. The time needed for copy / move / delete operations has 
been really improved. Still needed some more testing before going to the frsky 
stable branch. I think that 1) and 1*) are done and 2) is not useful anymore. 
Agree?

Remains point 3) I think to something on screen which would be also blinking 
during an asynchronous operation (meaning that it's perhaps not a good idea to 
stop now, even if the most has been done to avoid EEPROM corruption)

Original comment by bson...@gmail.com on 24 Nov 2011 at 8:41

• Changed state: Started

[GoogleCodeExporter]

I tested this as best I could and find no problems. Only two commits to 
perfection. :-D

I agree about no need for no. 2. The the 'hour glass' message (3) now and we're 
done.

This is excellent.

Original comment by gru...@gmail.com on 24 Nov 2011 at 9:15

[GoogleCodeExporter]

Oh - did you notice I am learning French? I used French word to compliment you 
-- "excellent" :-P

Original comment by gru...@gmail.com on 24 Nov 2011 at 9:16

[GoogleCodeExporter]

Hay! Thanks! I wait for a feedback at issue #75 and it will be ported to the 
stable frsky version.

Now about the hour glass, what about a hour glass at the left of 1/10, and in 
all other menus near the menu number, always when we are writing on EEPROM.

It would also solve issue #61.

Agree?

Original comment by bson...@gmail.com on 24 Nov 2011 at 9:41

[GoogleCodeExporter]

I wasn't meaning hour glass literally. I'd prefer to see a large pop-up window 
-- like the 'Delete model? Y/N' one -- so there can be no doubt the user has to 
wait.

Original comment by gru...@gmail.com on 24 Nov 2011 at 10:44

[GoogleCodeExporter]

Done. "Copying model..." and "Moving model..." popups.
Still waiting for approval from you and Cam about this feature (+ the write 
indicator on all screens)

Original comment by bson...@gmail.com on 26 Nov 2011 at 5:19

• Changed state: Fixed