Pumpkin, Inc.

Pumpkin User Forums

Salvo Context Switching and Timer Issue

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

Re: Salvo Context Switching and Timer Issue

Postby ben.phillips » Tue Jan 03, 2017 5:36 pm

Ah, I didn't see notice those, thanks! I've also discovered the hard way that one should not call a function from within a task and try to context switch from that function because it won't maintain the return address when it switches back to that function.

Just to verify, it mentions needing to define OSMCC30_LARGE_CM for all salvo modules and goes on to tell where the setting for a preprocessor macro is. How exactly is setting that in the IDE settings different from simply doing #define OSMCC30_LARGE_CM in my code? Is this something that can simply be in the salvocfg file, or does it need to be set through the IDE's settings?

With your help everything looks like it's finally behaving properly, now it's just a matter of getting to know salvo a bit better as I go along. Thank you so much!
Posts: 8
Joined: Mon Dec 12, 2016 12:23 pm

Re: Salvo Context Switching and Timer Issue

Postby aek » Wed Jan 04, 2017 10:48 am

Glad it's working now. I typically set OSMCC30_LARGE_CM by adding
Code: Select all
to the preprocessor defines in the gcc tabs of the project's options. Alternatively, you could probably simply add it to your salvocfg.h.

In your case (a Salvo library build), the only effect that defining OSMCC30_LARGE_CM has is to properly configure the Salvo objects in salvomem.c. The library that you're linking to (because you're doing a Salvo library build) is precompiled (and was compiled with OSMCC30_LARGE_CM defined), and so it cannot be changed and already has a "world view" of the large code model. But failing to define OSMCC30_LARGE_CM in your project would lead to a mismatch between the large-model Salvo library and salvomem.o; that's why the definition is required, and without it all sorts of things do not work properly.

Here, you see that Salvo's objects (tasks control blocks, event control blocks, etc.) are all statically defined. This makes for a potentially more robust application, as Salvo does not uses any malloc, etc. The "cost" of doing static definitions is that the build environment must be consistent across compiled-now (salvomem.c and your application code) and previously-compiled objects (Salvo libraries).

Salvo's three rules are a byproduct of Salvo not maintaining task stasks ... the upside is of course that RAM requirements are very, very low. Admittedly not as important on a bigger PIC24 than on a smaller part. Here's a full-fledged Salvo app on a chip with 41 bytes of RAM! http://www.pumpkininc.com/content/doc/appnote/an-6.pdf
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm


Return to Coding

Who is online

Users browsing this forum: No registered users and 0 guests