Pumpkin, Inc.

Pumpkin User Forums

OStypeMsgP

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

OStypeMsgP

Postby luben » Mon May 21, 2001 8:14 am

Hello,

If OSBIG_MESSAGES is <false> the OStypeMsgP are type byte and when is <true> cosnt int, right?

In the manual you recommend to use for definition of pointers only OStypeMsgP. But OStypeMsgP is not always the best type that I have to use. For example if I take etalon or constants from the ROM and I use the pointer defined like OStypeMsgP with OSBIG_MESSAGES TRUE, every increment of the pointer like pointer++ or even pointer += 1 will advance the address of the pointer by 2. So I need to use complicated way of reading the constants or to use other pointer defined like <const char>.

My question is - is it possible to overwrite the OStypeMsgP type and to use my own type and if this is posiible what is the criteria to use the correct type. For example why not to use <const char> instead of OStypeMsgP.

Maybe my question is stupid, but without having the sources I can only make suggestions what's wrong and what's true.

Regards
Luben

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

Re: OStypeMsgP

Postby aek » Tue May 22, 2001 6:29 am

quote:
If OSBIG_MESSAGES is <false> the OStypeMsgP are type byte and when is <true> cosnt int, right?

One byte or two byte pointers, yes.

Two things:

2) You have the source in this issue -- OStypeMsgP is defined in portpicc.h, and ther are also lots and lots of typedefs, etc. in salvo.h.

1) You MUST use OStypeMsgP because of banking issues -- otherwise your code is guaranteed to fail. What you can do is cast it to a char pointer (in the proper bank) if you want to increment/decrement it on a strictly byte basis.

quote:
For example why not to use <const char> instead of OStypeMsgP
Because of banking.

Your best approach is to test the high bit of the pointer -- that tells you if it's a const pointer or a RAM pointer. Then, you can cast it to a char pointer and do the math you want. Butyou must ensure that it's in the right bank for this to work properly. Review AN-3 and make sure you understand it completely before trying this ... it's not easy.

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

Re: OStypeMsgP

Postby luben » Tue May 22, 2001 11:03 am

Hello,

What I can imagine immediately is to copy the OStypeMsgP value to a new const char pointer. After that I can read the values both from ROM and RAM. Of course the new pointer will consume 2 additional bytes.

Is this correct or not?
Example:

code:

OStypeMsgP pointer;
static const char pointer_new;

...... after receiving the event

pointer_new = (const char *)pointer; // typecasting


In my oppinion the pointer_new will get the address of the message and you can operate with it like standard const char pointer. Is it possible some problems with banks to occure?

Regards
Luben

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

Re: OStypeMsgP

Postby aek » Wed May 23, 2001 10:46 am

I think you mean:

code:
static const char * pointer_new;

Yes, I think that will work, if the message is located in ROM.

If pointer points to (a message in) ROM, then the cast makes perfect sense, and you can pointer_new++ to increment its value by one (byte) address.

If the message pointer points to RAM, then it (pointer) is just some hex value, say 60h (RAM Bank 0). Typecasting it probably doesn't make sense, as a const char pointer has the msb (bit 15) set to 1.

If the message were at 145h (RAM Bank 2), then you would have to do this cast:

code:
pointer_new = (bank2 char *) pointer;

in order to use the pointer properly.

One way to think of this (RAM pointers) is that when you enqueue (send) a message, PIC C simply passes a numeric, 8-bit value regardless of which Bank the variable is in (9 bits of information, since Bank 0-1 is 000h-0FFh and Bank2-3 is 100h-1FFh). Therefore information (the 9th bit) is lost. Also, since you typecast the pointer to be of type OStypeMsgP (as per example in OSCreateMsg() in Salvo User Manual), the compiler ensures that the message pointer is of the appropriate size. How is that information (9th bit) recovered? It's recovered (when needed) via the typecast that you use to extract the message from the message pointer, e.g.

code:
char = *(bank2 char *) pointer_new;

i.e. the typecast causes PIC C to place RAM-bank-setting instructions in the code such that when the variable is read, it's read from the correct RAM bank.

I don't see how you can start with 8-bit (RAM pointers) as messages and "extend them" to 16-bit ROM and RAM pointers -- but I haven't tried it.

I think I misunderstood your original message slighlty, so I'll re-phrase my comment(s) on OStypeMsgP:

*** Don't change OStypeMsgP because there's no reason to. OStypeMsgP can point to anything because it declares message pointers to be void pointers. ***

If you redeclared OStypeMsgP to be const char * then you would have all sorts of type mismatch problems if/when you attempted to pass a message of another type (e.g. an int). Instead of redeclaring OStypeMsgP, simply use the fact that it's a void pointer, and use typecasts when dereferencing the pointer and/or copying the pointer. IOW, you only have to worry about typecasts when you receive the message / dereference (or copy) the pointer.

[This message has been edited by aek (edited May 23, 2001).]

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

Re: OStypeMsgP

Postby luben » Mon May 28, 2001 7:50 am

Hello,

I agree with you that there is no sense to change OStypeMsgP just to avoid many additional headaches after that.

My question was just about how I can access message, defined in ROM byte by byte, using a pointer. Because OStypeMsgP is a void pointer, the increment moves the pointer 2 cells, not 1. So there are 2 approaches:
- to fetch 2 bytes like int and to analyze first or second part of it
- to copy the value into new const char *pointer and to use this pointer to fetch byte by byte the data (the increment will move the pointer to the next byte)

I though that could be some other way, for example to change the OStypeMsgP definition, but now I changed my mind - this is realy dangerous approach. SALVO is not only RTOS, but it also brings some good rules, some style that improves the quality of the programming. Until you keep this good style you will expect less troubles. And of course everybody is free to change the sources in SALVO, but I'm afraid that in more of the cases this will be just adding more problems and bugs.

Regards
Luben

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

Re: OStypeMsgP

Postby aek » Mon May 28, 2001 8:22 am

quote:
to copy the value into new const char *pointer and to use this pointer to fetch byte by byte the data

is the right way to do it. My point was that this will only work if you are using const pointers to begin with, i.e. if OSBIG_MESSAGES is TRUE.

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

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


Return to Coding

Who is online

Users browsing this forum: No registered users and 1 guest

cron