Pumpkin, Inc.

Pumpkin User Forums

RAM limitations

If you can't make Salvo do what you want it to do, post it here.

RAM limitations

Postby luben » Sun Dec 31, 2000 10:56 am

Hello,

With OSLCO_XYZ you force the compiler to put its variables in some banks?

Question - if I put them in bank1 and I created many task, events and any timeouts, supertimer and any RAM consuming option - if the RAM in bank1 is not enough, will this bring error messages? If yes - then Salvo has limitations - how many task you can create, delay, timeout in PIC processors (16F877). I know that this limitation is due to the small size, but will be good if everything is clear - like:
---- Salvo supports up to n tasks - no timeouts, delays, events
---- Salvo supports up to m task - if k events, no timeouts, delays...

I mean - can you bring one clear formula that will show the needed RAM memory for any configuration? Because Salvo calculates the RAM in the process of compiling and this resources are the same in the run time. And would be grate if I could operate with this value, to know my limitations.

Well, the simpliest way is to compile the project and to see if the RAM fits. But this is unclear - I don't know exactly the amount of memory used for Salvo's features.

So, my question could be modify like a request for adding in the manual one clear and calculatable formula. And from this formula I should be able to understand the size of RAM for Salvo's different features like events. timeouts, basic operations, etc.

Would be grate if in the description of OSCreateXYZ() you add how many RAM consumes. Well, I know that settings like OSBytes_OF_DELAYS change the size dramatically. It's a good idea if you have wizard for calculating the RAM needed for Salvo. The user don't need to make complicated calculations - just filling the fields of one sheet he receives the answer on the screen or like printed list. Salvo in fact don't have any executable programs (from what I saw in the manual), so why not to add one or two wizards for making config file and calculating the RAM size. By the way, this 2 wizards could be made in one, only there should be a boz - to write the data to salvocfg.h file or just to see the RAM size after calculation competed.

Regards
Luben

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: RAM limitations

Postby aek » Mon Jan 01, 2001 8:55 am

There is no simple formula that can be used, because of the effects of your compiler, your target processor and Salvo configuration options.

Remember, you can set each OSLOC_XYZ to a unique value. For instance, you can place the tcbs (OSLOC_TCB) in one bank (e.g. bank2) and everything else in bank3. For an 'F877, with 96 bytes of RAM, this means that you could have as many as 24 tasks (no delays or timeouts enabled, events supported, 4 bytes per task) to as few as 9 (16-bit delays, timeouts and circular queues enabled, 10 bytes per task). For nearly all applications, tasks consume the single largest block of memory. Only events and message queue control blocks are also in blocks of RAM.

For users of the freeware libraries, this isn't an issue, as the Salvo configuration, the number of tasks and events, and the banked RAM location of the Salvo variables is fixed.

For full-version users, it's best to play around with the configuration options on a test program and see how RAM usage varies.

For the PIC16 series, nearly all applications can get by with tasks requiring 7 bytes each (8-bit delays, timeouts and events, 7 bytes per task), yielding up to 13 tasks. On the PIC17 series, that yields 36 tasks. And on the PIC18 series, although the tcbs are larger for the same configuration, RAM is no longer banked, so it's not so much of an issue.

So, with an empty Salvo project, set OSLOC_TCB to be a bank that's "empty", compile the project, and then change the configuration options and compile again. The RAM usage of the tcbs will be shown (alone) in that bank. You can then do a similar thing with other OSLOC_XYZ's.

By having so many different OSLOC_XYZ's at your disposal, you can squeeze Salvo's variables into the PIC's limited RAM. You can even "mix and match", by putting some Salvo variables and some of your variables into the same bank ...

Also, even if you don't have the full version, you can look in salvo.h, where the tcb, ecb, mqcb, and event structs are defined, and figure out how big they are as a function of your compiler, target processor and Salvo configuration options. For example, RAM pointers on the PIC16 and PIC17 are just a single byte, but they're bigger on the PIC18 ...

[This message has been edited by aek (edited January 01, 2001).]

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: RAM limitations

Postby aek » Mon Jan 01, 2001 9:01 am

I'd like to add one more point...

In our experience, it's not Salvo's RAM requirements per se that lead to running out of memory on the PIC. It's the complexity of the application, because PIC C stores function parameters, local variables and interrupt context saves all in bank0.

Therefore, for complex applications, we recommend that you put all of your variables, and Salvo's variables, in a RAM bank other than bank0. This will maximize the available RAM for the compiler's use, especially if you use RAM-intensive functions like the sprintf() library function.

If I recall correctly, the IAR compiler allows a bit more control over the placement of parameters and local variables.

[This message has been edited by aek (edited January 01, 2001).]

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: RAM limitations

Postby luben » Tue Jan 02, 2001 6:52 am

Hello,

I understand that this is very complicated question and maybe the only one way is to try different settings in the real project and to see the changes of RAM usage.

Anyway, will be good if you have some not exactly formula, that can bring to users the amount of used bytes +/- 5 bytes or something like that.

Because you menshened in the manual that the resources of Salvo are fixed on compilation level, then immediately appears the question - what is the exactly value of used RAM and ROM resources? I know that they depend on compiler, optimization and many other factors

Regards
Luben

luben
 
Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria


Return to Coding

Who is online

Users browsing this forum: No registered users and 2 guests

cron