Pumpkin, Inc.

Pumpkin User Forums

Passing string (or other structure's) via SignalMsg

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

Passing string (or other structure's) via SignalMsg

Postby ChrisL » Tue Jan 14, 2003 10:09 am

I am feeling pretty stupid right now. My project is using Keil's C51 compiler w/ the large memory model. I am linking slc51lita.lib. My xxcfg.h file looks like:

#define OSUSE_LIBRARY TRUE
#define OSLIBRARY_TYPE OSL
#define OSLIBRARY_GLOBALS OSI
#define OSLIBRARY_CONFIG OST
#define OSLIBRARY_VARIANT OSA

I want to be able pass messages that are pointers to strings located in xdata. For example,

char String[10];

void taskSender(void)
{
...
OSSignalMsg( ..., String );
...
}

void taskReceiver(void)
{
char *msg;
...
OS_WaitMsg( ..., &msg );
...
}

He is a sample of my experimental code:

char Title[6];
void USProcessTitle(void)
{
OStypeMsgP x;
strcpy( Title, "Hello" );
x = (OStypeMsgP)Title;
OSSignalMsg(MSG_WIN_MAIN_UPDATE_P, x);
}

When I compile this code, x points to idata, not xdata. What do I need to do so OStypeMsgP points to xdata, not idata?

Thanks,
Chris Lincoln
ULTRAX, Inc.

Chris Lincoln
ULTRAX, Inc.
ChrisL
 
Posts: 5
Joined: Thu Jan 09, 2003 12:00 am

Re: Passing string (or other structure's) via SignalMsg

Postby ChrisL » Tue Jan 14, 2003 10:12 am

That was fast...

I tried to define OSBIG_MESSAGE_POINTERS which you have cleverly used to emit the message to use OS_MESSAGETYPE instead.
Thanks.

Chris Lincoln
ULTRAX, Inc.
ChrisL
 
Posts: 5
Joined: Thu Jan 09, 2003 12:00 am

Re: Passing string (or other structure's) via SignalMsg

Postby ChrisL » Tue Jan 14, 2003 10:26 am

Ooops. I spoke too soon. I am still somewhat lost. I am just posting this info in case someone else stumbles on the same problem. I am also hoping that Pumpkin tech supp. will bail me out if I am way wrong...

Recap:

I am compiling w/ Keil C51 using the large memory model. Default memory space is xdata here. I was linking slc51lita.lib which expects OStypeMsgP to be a void pointer to idata. Likewise, my SalvoCfg.h did not alter the typedef for OStypeMsgP, so it too pointed to idata.

I changed my SalvoCfg.h from this

#define OSUSE_LIBRARY TRUE
#define OSLIBRARY_TYPE OSL
#define OSLIBRARY_GLOBALS OSI
#define OSLIBRARY_CONFIG OST
#define OSLIBRARY_VARIANT OSA

to this:

#define OSUSE_LIBRARY TRUE
#define OSLIBRARY_TYPE OSL
#define OSLIBRARY_GLOBALS OSX
#define OSLIBRARY_CONFIG OST
#define OSLIBRARY_VARIANT OSA
#define OSMESSAGE_TYPE xdata

Now my messages pointers are passed as xdata instead of idata. I still have some dereferencing issues to bang out, then I think this will work.

Chris Lincoln
ULTRAX, Inc.
ChrisL
 
Posts: 5
Joined: Thu Jan 09, 2003 12:00 am

Re: Passing string (or other structure's) via SignalMsg

Postby aek » Tue Jan 14, 2003 10:58 am

Hi Chris.

First, just a general rule -- you must be able to compile without (serious) warnings or errors. Sounds like you're doing that just fine.

Second, you'll notice (in the user manual) that OSMESSAGE_TYPE is not one of the configuration options you can use with library builds. In fact, it's not even documented :-), but it is there for a reason.

You need a source-code build instead of a library build. That would allow you to change the message pointer type without changing anything else. See the source-code build projects for examples ...

You could do it with a source code build by

code:
#define OSMESSAGE_TYPE xdata

in your salvocfg.h. Since OSLOC_DEFAULT is idata, this will force the data pointer type to be different from everything else, which I think is what you want.

In short, in order to have Salvo access different areas of memory, you'll need to do a source-code build, because all of the libraries are built for only one area (roughly speaking -- C51 has som many memory models, etc.).

Regards,

------------------

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

Re: Passing string (or other structure's) via SignalMsg

Postby aek » Tue Jan 14, 2003 11:00 am

Or, you could just go with a pure "xdata library build" and use the appropriate library with
code:
#define OSUSE_LIBRARY TRUE
#define OSLIBRARY_TYPE OSL
#define OSLIBRARY_GLOBALS OSX
#define OSLIBRARY_CONFIG OST
#define OSLIBRARY_VARIANT OSA

in your salvocfg.h.

The only downside is that Salvo's internals will be somewhat slower because they're accessing Salvo global objects in xdata space instead of in idata space.

Regards,

------------------

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

Re: Passing string (or other structure's) via SignalMsg

Postby ChrisL » Tue Jan 14, 2003 11:32 am

Ok. I think I see what is happening. I do need to go to a source-level build. For example, calling OSSignalMsg( xxx, 0xA5B5 ) comes out on the OS_WaitMsg() end as 0xB500. It appears that OSSignalMsg() trickles down to a function w/ a variable length param list. The function probably assumes a different va_arg() type than what is getting passed in...

...Actually, I have only been tinkering with the metaphor of passing string data to waiting tasks. I will be able to use simple semaphores in my real application. Therefore, I don't really have any need to solve this problem (for now!).

Thanks,
Chris L.

Chris Lincoln
ULTRAX, Inc.
ChrisL
 
Posts: 5
Joined: Thu Jan 09, 2003 12:00 am

Re: Passing string (or other structure's) via SignalMsg

Postby aek » Tue Jan 14, 2003 11:50 am

Hi Chris.
quote:
The function probably assumes a different va_arg() type than what is getting passed in...
That won't be a problem ...

But, I misspoke about using a x- library ... the message pointers will still point to idata, regardless of the location of the Salvo global objects (data, idata or xdata). Perhaps we should change this so that the message pointer type tracks the Salvo global objects type.

So, in the meantime, to do what you want to do, you must do a source-code build.

Regards,

------------------

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

Re: Passing string (or other structure's) via SignalMsg

Postby Mark M » Thu Jun 24, 2004 1:55 am

quote:
Perhaps we should change this so that the message pointer type tracks the Salvo global objects type.

Hi Andrew,

I'd really like to see this changed -- I made the assumption that because I had set to OSLOC_ALL to "xdata", **ALL** Salvo objects would be located in xdata. I wasted most of a day tracking down a problem that was fixed by simply setting OSMESSAGE_TYPE to xdata.

You may want to mention this issue in AN-16.

Regards,

Mark

Mark M
 
Posts: 3
Joined: Wed Mar 24, 2004 12:00 am

Re: Passing string (or other structure's) via SignalMsg

Postby aek » Tue Jun 29, 2004 6:32 am

Hi Mark.

Thanks for the suggestion.

BTW, I have spent considerable time on the problem we discussed when I was in MI -- I think I'm very near a solution, which may also result in slightly better overall Salvo performance. I'll let you know as soon as it works its way into an 8051 distribution -- hopefully quite soon.

------------------

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

Re: Passing string (or other structure's) via SignalMsg

Postby aek » Mon Jul 12, 2004 7:06 am

Hi Mark.

In the upcoming v3.2.5 release, OSMESSAGE_TYPE has been set to default to OSLOC_ALL in portkc51.h. OSLOC_ALL in turn defaults to idata.

Therefore, by default, message pointers point into idata space. Changing OSLOC_ALL to xdata means that messages point into xdata space.

OSMESSAGE_TYPE can always be explcitly overridden in salvocfg.h if a value other than OSLOC_ALL's memory qualifier is desired.

------------------

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

Next

Return to Coding

Who is online

Users browsing this forum: No registered users and 1 guest

cron