 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : question about AUTOSAVE
| Author | Message | ||||
| robert.rozee Guru  Joined: 31/12/2012 Location: New ZealandPosts: 2463 |
this is probably going to be one for peter and/or geoff. i've been looking at the C code behind AUTOSAVE, trying to figure out ways to interact with it more reliably while still having a fast upload speed. while thinking things over, it occurred there may be a slight flaw in the way it works that potentially 'robs' you of a few hundred bytes of allowable program size. the relevant few lines of code are: p = buf = GetTempMemory(EDIT_BUFFER_SIZE); while((c = (getConsole() & 0x7f)) != 0x1a) // while waiting for the end of text char { if(isprint(c) || c == '\r' || c == '\n' || c == TAB) { if(c == TAB) c = ' '; // turn any TAB into a single space *p++ = c; // put the input character into RAM if(UARTTransmitterIsReady(UART1)) // skip the echo if console TX is busy { if(!(c == '\n' && prevc == '\r')) MMputchar(c); // echo character back if(c == '\r') MMputchar('\n'); // trick to turn <CR> into <CR><LF> } prevc = c; } } the problem is: 1. when typing directly into the console from the keyboard, lines are seperated in RAM by single <CR> characters (via presses of the ENTER key). what is echoed back to the console has an <LF> character inserted after every <CR> as terminals won't line feed without this; 2. when pasting into a terminal screen (if using teraterm) from a file, <CR><LF> pairs will be saved into RAM, causing each line in the program to consume an extra byte and filling the RAM more quickly. on (very) rare occasions, you may therefore strike a program that can be typed in OK, but can not be loaded using AUTOSAVE. i think the solution would be to change the following lines: if(isprint(c) || c == '\r' || c == '\n' || c == TAB) ... if(!(c == '\n' && prevc == '\r')) MMputchar(c); to instead be: if(isprint(c) || c == '\r' || c == TAB) ... MMputchar(c); but then is there now an issue with files using just a <LF> as the line separator? cheers, rob :-) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10572 |
Simplest way would be to implement XON/XOFF. Very easy to do and very little code but would be one for Geoff as only really affects MM2 (MM+?) MMX, Pi-cromite, and Armmite are all fast enough to save at 38400. |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9753 |
On my MM+ development platform, I have the console set to 230k4 baud, and AUTOSAVE works fine even at that speed. For a big program, the faster speed saves quite a lot of time.... Smoke makes things work. When the smoke gets out, it stops! |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2463 |
the currently released version of GFXterm counts up the number or <CR> characters sent, and counts down the number of <CR>s received (but the count can not go below zero). if the count gets to 2, then transmission is suspended. also, if no <CR> is seen for 200ms then a timeout sets the count to zero. effectively this is a 'sliding window'. but with the above scheme i was still seeing the odd glitch on what was echoed back (but NOT in the saved program). changing to a simple wait for the response from each <CR>, and instead looking for <LF> as the response, got rid of the glitches and slowed down uploading a 42k file from 20 seconds to 35 seconds. the above schemes are a departure from my earlier approaches, which were largely based upon fixed delays between lines. this is all when 'fast' pasting. 'slow' pasting kicks in whenever an escape sequence is seen in the echoed response stream, and throttles things back to 15ms/character and a 300ms Rx silence mandated at the end of each line. BUT - this is all slightly peripheral. i'm a bit more interested in hearing about my analysis of the C code used by AUTOSAVE. does it look like it is allowing superfluous <LF> characters to be saved into RAM? i am quite happy that this is not a big problem, and that it will only have an impact under quite rare circumstances (basic code almost filling RAM while being buffered, streamed from a source that does not strip out <LF> characters). cheers, rob :-) |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
Some RAM can be saved but I don't think that it is that critical. There are lots of factors that control what sized program can be buffered in RAM then transferred to flash. These include the amount of free RAM but also the amount of compression (or indeed expansion) when the program is tokenised for writing to the flash and so on. However it would be a sin to waste even a small amount of RAM. Thanks for the pointer, I will add it to my list. Geoff Graham - http://geoffg.net |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
