 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 : Do I degrade something when loading programms?
Page 1 of 2   |
|||||
| Author | Message | ||||
andreas Senior Member  Joined: 07/12/2020 Location: GermanyPosts: 207 |
Hello, I have a question in regard of memory degradation of the raspberry pi pico MCUs. When I do a context switch by "RUN-chaining" programs from the flash filesystem A:\, does this cost lifetime of the MCU/Ram or something else? Example: Two programs Prog1 and Prog2 call each other possibly endless ' Prog 1 Sub myint() End Sub Text 0,0,"Prog 1 running..." Pause 10000 Run "Prog2" The last line will run program "Prog2". ' Prog 2 Sub myint() End Sub Text 0,0,"Prog 2 running..." Pause 10000 Run "Prog1" The last line will run "Prog1" again. > files A:/ <DIR> . <DIR> .. 00:00 01-01-2000 4 bootcount 19:05 26-10-2024 896 option.opt 00:12 01-01-2000 88 Prog1.bas 00:11 01-01-2000 90 Prog2.bas On the display I see that the programs are chaining endless - but I have concerns in regard of memory degradation. -andreas |
||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
RAM doesn't degrade, flash does. It wears out eventually on write operations only. Reads don't have any effect. So, programs that read repetitively will be fine. Wear on flash isn't always straightforward. Sometimes it has a cache and when you write it will look to see if the data already exists, in which case it will store a pointer to it. Even normal flash is good for thousands of write operations though. Most flash is guaranteed to be better than 100,000 write cycles, with some saying 1,000,000. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| andreas Senior Member Joined: 07/12/2020 Location: GermanyPosts: 207 |
Hello Mick, and what does this mean in my case? When I "run" a program stored in the filesystem A:\ is this a RAM operation or does "run" mean: write something into flash? I write the programs only once but will run them many times - is the running of a program using up flash or is it an RAM only operation? I remember a OPTION RAM instruction on the CMM2 to prevent degradation but the pico has no OPTION RAM, isn't it? -andreas |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 866 |
PMJI You are executing from memory, not writing to it. Is my understanding. |
||||
| andreas Senior Member Joined: 07/12/2020 Location: GermanyPosts: 207 |
ok! Thank you both! |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
When you run a program it doesn't matter where it is stored, it is always a read operation. Any variables are stored in an area of RAM, which doesn't degrade. The framebuffer is also in RAM. If you use a VAR SAVE operation then that writes to flash. Likewise, whenever you upgrade MMBasic or write to A:, that's also a write to flash. Simple chaining of programs doesn't produce any flash wear providing you aren't using VAR SAVE to save variables repeatedly. It's all read operations. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| andreas Senior Member Joined: 07/12/2020 Location: GermanyPosts: 207 |
Ok, that sounds good  I plan to write a kind of program-selector for my "picopad". The programs will be independent - so they don't need any common variables. Every program will have a final line calling the top-level menu to select the next program to start. the top-level program will just start the program selected. So it will be a large menu and many independent programs without common variables. Sorry for the German text - it was generated with obsidian for myself only but could possibly show what I intend to do? It is a kind of state diagram.  -andreas Edited 2024-11-07 05:22 by andreas |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
When you run a MMBasic program it can have a file$ and a commandline$. So in theory you can have: In the menu program: RUN "Myprograms","200" When Myprograms.BAS runs it can use GOTO MM.CMDLINE$ . . . . 200: 'do a program here GOTO LEAVEIT LEAVIT: RUN "MENU" I've not tried this, but it looks like it should work. :) You can put a lot of small programs into one big one in this way. FLASH RUN doesn't take a command line argument so it becomes more complex to do this sort of thing. I've usually had to resort to VAR SAVE. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| andreas Senior Member Joined: 07/12/2020 Location: GermanyPosts: 207 |
I will take that into account! I just read today about the details of the RUN Command while searching for a chaining possibility. In the beginning I don't know all the programs which will be programed at some later time. The whole thing shall be open for expansion. May be I will start with a "carott-counter" and later add some astronomical calculations or simple math problems like tax (vat) calculations etc. So if I would use the CMDLINE$ parameter - I have to remember at least the command lines and reserve space in the "Myprograms" program. But I will simply add a new basic.bas into the A: store and add a line to the last screen of the menu program. So I have less coordination to do ("i.e. which is the next free slot to jump to in the Myprograms program?"). So I prefer independent programs which can be run, written and debugged on their own. -andreas |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9122 |
If you are using the run command to swap between programmes then you are wearing out the flash memory. To do this sensibly load the two programmes into flash slots and use the flash run or flash chain commands. |
||||
disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 897 |
FLASH RUN n or FLASH CHAIN n will run the program from where it its currently stored and not touch the program memory (which is flash) RUN by itself will run the program in program memory and is only a read operation. RUN filename will copy the program to program memory (flash) and run it there. So every RUN filename will be a flash write to the MMBasic flash program memory. P.S. Too slow Edited 2024-11-07 06:58 by disco4now Latest F4 Latest H7 |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
Thanks anyway. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| andreas Senior Member Joined: 07/12/2020 Location: GermanyPosts: 207 |
Shock in the morning  I start missing the OPTION RAM of the CMM2 in PicoMite! Would be nice to have an OPTION not to copy something from flash to flash (RUN filename) but from flash to ram for execution.   -andreas |
||||
| andreas Senior Member Joined: 07/12/2020 Location: GermanyPosts: 207 |
Hey! How about an OPTION RAM (the CMM2 style;) -andreas |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
There isn't enough RAM in a PicoMite to have an OPTION RAM command. It appears that I was naïve in thinking that it had enough to run programs from there! The CMM2 is a different beast entirely! Quite a lot of RAM and extendable. Use the FLASH, Luke... ;) FLASH CHAIN is ideal. You can simply put the name of the program to run into a string then CHAIN. The new program can just read the string to find out where to jump to. Unfortunately we only have 3 flash slots. I'd suggest that you make extensive use of SUBs or even GOTO to split up your programs. It could be done neatly, using GOTO in the menu program. If a program is too big then it's GOTO entry would be a CHAIN to another flash slot. If you use the Library then all your programs could share common routines, which could keep the sizes of your programs down. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| andreas Senior Member Joined: 07/12/2020 Location: GermanyPosts: 207 |
I planned to have larger number of programs than there are flash slots, so your method of using SUBs will be the only possible way... I have already programmed a library for Input (from the keypad) and Output (to the RP2040-LCD). The Input is represented by a 'LastKey$' Variable defined and updated within the library and output is realized by two commands 'Show' and 'ShowTab' which put either a single line of text into a dedicated display line with a dedicated color or put a 2 x 3 table of six strings, predefined colors and some framing on screen.It looks nice and works already well. The library is really important to make all this working and hide the details of input and display from the application programs. -andreas |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
You could use the menu selections to point to a "jump table". Each entry in the table points to the "address" of the program (i.e. a label). At each label location there is either the program or a FLASH CHAIN to point to it. That makes the menu items nice and easy to maintain. You can change their destinations in the jump table without moving programs around, you can replace one program with another - even if it's in the other flash slot - permanently or temporarily without disturbing anything. You can work with numbers from the menu selection and the "jump table" converts them to label strings. It could be DATA statements. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4042 |
Before you get "tricksy", 100,000 write cycles would allow 20 program loads per day for over 10 years. If you just stick the menu (i.e. the program you will load most often) in a flash slot then you should be fine ... and you might not even need to do that depending on how heavy you think your use is going to be. The only time I worry about flash wear is when I'm developing on the device in an EDIT/RUN cycle in which case you can easily knock off 100 or more writes per session. I guess the other issue is logging to the flash, didn't Tesla have an issue with that ? Best wishes, Tom Edited 2024-11-07 21:29 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
And the replacement cost of a Pico isn't staggering. :) I still have PIC chips that I used for years, constantly erasing and writing to the flash. AFAIK none of them ever failed for that reason. Reverse polarity and 12V on the pins is something else. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| andreas Senior Member Joined: 07/12/2020 Location: GermanyPosts: 207 |
Yes and no - the display-pico (RP2040-LCD) costs more than 10 and less than 20 but costs me a day to put it into place (cutting the box, soldering, testing). May be it would be a good idea to have an ic-socket? Currently it is fixed by the soldering and can't be dragged out. -andreas |
||||
| Page 1 of 2 |
|||||
 Print this page |
