 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 : PcoMite "Variable" question
| Author | Message | ||||
| stef123 Regular Member  Joined: 25/09/2024 Location: United KingdomPosts: 83 |
Hi, i have a few programs which should be called by a Main program, because they wont fit together into one. I am in the need to swap between the main program and other Programs by Request, but the underlying programs shouldnt do certain intialisations again after being called the first time (since bootup of the Pico). One method which came into my mind was fiddling around with an external, small Table per Program, stored in the File area, which contains the last (not the actual!) boot count, compare it to the actual bootcount and write the actual count back into the file. This would inhibit those programs to perform some actions again, after being called the first time since booting up, which i want. But i wonder if there is a better method by using in SRAM a fixed, free available memory area of a certain size which can be used for that purpose by poking and peeking it. But since the variables of the programs are different in their amount and size, i cannot assure that a certain memory area is always kept free (i'm using GUI controls on an attached GLCD as well, btw). I know about the "var"- Command, which stores variables in NVRAM, but if i understand the manual correctly, any time when a new program is loaded and being started, the 16K NVRAM area will be overwritten, because i assume that loading and running a program, other than the currently running program, is equal to performing a "NEW" or "autosave" command. Or am i wrong in my assumptions? In case of poking and peeking into memory - are SRAM areas also being erased as soon as i start another program, or are they consistent unless i power off and back on? Best regards! Stef Edited 2025-03-27 15:21 by stef123 |
||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 3998 |
Would CHAIN be good enough? John |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1139 |
I am a bit challenged when it comes to comprehending these types of questions but if I'm on the right track, would the memory in a RTC device be of any use? |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7499 |
If you are having problems fitting all the programs into memory are you being efficient? Could you use the Library to hold several routines that all your programs need so that they then don't need to appear in any of them? The Library routines could use LOCAL and/or STATIC variables so that you need less globals. You could also use the Library to automatically set up some globals every time you boot. Then there's: . Edited 2025-03-27 21:33 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| stef123 Regular Member Joined: 25/09/2024 Location: United KingdomPosts: 83 |
The thing is that i am using the Pico for controlling several external Synthesizers with different GUI apperances, Many different control structures, different memory mappings and so on. Each program is fairly complex and has a lot of tables in it, especially for memory mapping (which CC/NPRN/Sysex is mapped to which internal memory address of the Pico and if, which bit pattern at a certain memory adress of the Synthesozer is assigned to which control etc) and vice versa, Tables for mapping values from 0 to 127 to certain control names (eg for an Oscillator "SAW", "TRIANGLE", "PULSE") and so on. One Program alone eats 40 up to 50K of Memory - which i consider as rather small for that given purpose. I wont crawl trough tables by Filesystem IO while modifying controls, this would add a lot of overhead and the Pico has to handle Midi I/O as well - for example buffering and merging modified control Data into the Midi Data Stream from the PC through the Pico and to the Synthesizers - as fast as he could. So everything should be kept in SRAM as much as possible. Yes, there are some routines which are naturally used by all of these programs. but fitting everything into one single Program wouldnt do it anyway. Perhaps in Assembly, but i wont do that. There is some potential for optimization, but not much. Recreating everything in order to keep the main program as small as possible and fit -every- need, from tables to different GUI appereances and memory assignments into one (or more) fairly large, external File and load it when its needed would be not impossible, but an quite complex task, which i want to avoid. Writing the programs themself including implementing new GUI control methods, doing sometimes some faily complex Math and crawling through the Midi Implementation Charts of each Synthesizer was, to be honest, already complex enough. Anyway, thanks for the hint to "chain" and the other commands. I will try what i can do with them. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
