Pumpkin, Inc.

Pumpkin User Forums

OSRpt() output is unusual

For issues specific to the 8051 family, including compilers (e.g. Keil C51) and IDEs (e.g. uVision2).

OSRpt() output is unusual

Postby aek » Thu Jun 27, 2002 5:15 am

Hi Jeff.

That certainly is mangled OSRpt() output ...

In OSRpt(), we format printf() data as unsigned, simple decimal or hex, depending on the data of interest. In the platforms where we have extensively tested it (PIC, x86) this has not been a problem, probably because the compilers have automatically converted the types. It looks like it is a problem with the C51 compiler (I'm assuming you're using C51).

We'll take a look at this immediately.
In the meantime, since you are a Salvo Pro user, here's what you can do:

1) Copy rpt.c to myrpt.c and add myrpt.c as a node in your project.

2) Modify the printf() format specifiers as required (either change them or cast the item of interest to e.g. unsigned).

3) Re-make your project. Since C51 will link in the functions in myrpt.c before it pulls in those from the library, you should get the "revised" functionality.

Sorry about this ...

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

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

Re: OSRpt() output is unusual

Postby aek » Thu Jun 27, 2002 6:37 am

Hi Jeff.

1) You'll also need to add salvo ask4.c as a node to your project (contains OSTaskRunning()).

2) I am sending you a modified rpt.c to use -- it has the basic functionality fixed, though it does not report the final element of the eligible and delay queues properly.

Since uVision does not allow me to cut-and-paste from the Serial Window, I can't post the results. Suffice it to say that the task's address is shown in a data-space dependent format, e.g. i:0ba6 means that the pointer is 0ba6 and is located in idata space ...

Though I have not tested it with your version 3.0.4, I think this rpt.c will work fine as long as you add this line:

code:
/* printf() supports p (pointer) format. */
#define OSUSE_PRINTF_P_FORMAT TRUE

to your salvoincportkc51.h.

Regards,

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

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

Re: OSRpt() output is unusual

Postby JBevis » Thu Jun 27, 2002 9:46 am

I've only just started using Salvo. In the last couple days, I have attached the OS to my existing application. The output of the OSRpt() function is a bit mangled, and I am wondering why that would happen. Here's what it looks like:

Salvo 3.0.4 Ticks: 0
EligQ: t512
task stat prio addr t-> e->
256* elig 2560 0000872Ch t556 n/a
556 elig 2604 0000897Eh . n/a
894 undf 1918 0000C1D4h

evnt type t-> value
468 ERR
724 ERR
980 ERR
1236 ERR
1492 ERR

------

It looks as though the task numbers and priorities are stored as bytes, but printf'd as 16-bit (int) values. Upon browsing thru the rpt.c source, it seems as though this is in fact the case. Have I misconfigured Salvo, or is this a genuine bug?

------------------
Jeff Bevis
jbevis@graviton.com

Jeff Bevis
jbevis@graviton.com
JBevis
 
Posts: 16
Joined: Mon Jun 24, 2002 11:00 pm
Location: La Jolla, CA, USA

Re: OSRpt() output is unusual

Postby JBevis » Sun Jun 30, 2002 9:31 am

OSRpt() output is looking good now:

code:

Salvo 3.0.4 Ticks: 25
EligQ: t2
DelayQ: t3,t4 Total delay: 19204 ticks
task stat prio addr t-> e->delay
1* elig 10 00009278h t 2 n/a
2 elig 10 0000950Ah . n/a
3 dlyd 10 000093F2h t 4 75
4 dlyd 10 00004EE6h . 0
5 elig 11 000096A4h n/a

Thanks for the quick fix! Salvo is working quite well - I am impressed. It has been very little trouble to integrate into my existing application, aside from a couple very minor bumps that could probably be avoided with some additional documentation bullet points. It's just starting to get fun :-)

One interesting thing to note - I don't have a fifth task created, though my salvocfg.h allows five tasks to exist. Why does it show that last task to be eligible to run?

quote:
Originally posted by aek:
1) You'll also need to add salvo ask4.c as a node to your project (contains OSTaskRunning()).

By the way, why do I need task4.c? I tried the modified rpt.c file alone and it seemed to work fine.

------------------
Jeff Bevis
jbevis@graviton.com

Jeff Bevis
jbevis@graviton.com
JBevis
 
Posts: 16
Joined: Mon Jun 24, 2002 11:00 pm
Location: La Jolla, CA, USA

Re: OSRpt() output is unusual

Postby JBevis » Mon Jul 01, 2002 6:35 am

I definitely don't have a fifth task. In The Beginning, I created one task of priority 10 (basically, my original superloop setup as a single task). Then I split that up into a total of four, each of priority 10 (it had already been structured into into several independent state machines). Nowhere did I define another priority besides 10. Since I don't have Keil docs at home, I can't really say for sure what their initialization guarantees... but I agree that it does sound like the xdata "BSS" isn't getting zeroed. That wouldn't surprise me. I have noticed no problems though...

Of course, this observation is out-of-date now that my app has grown to six tasks :-) I'm really quite stunned and the meager additonal memory consuption from Salvo.

(using Monty Burns voice) Exxxxxcellent, Smithers... :-)

------------------
Jeff Bevis
jbevis@graviton.com

Jeff Bevis
jbevis@graviton.com
JBevis
 
Posts: 16
Joined: Mon Jun 24, 2002 11:00 pm
Location: La Jolla, CA, USA

Re: OSRpt() output is unusual

Postby aek » Mon Jul 01, 2002 8:03 am

Hi Jeff.

Just a quick note re more than 5 tasks with library builds -- please be sure to review the Libraries chapter in the User Manual w/regard to "Overriding Default RAM Settings".

You can get a successful compile and run more than 5 tasks without adding mem.c as a node in your project, but sooner or later something else will be sitting on the memory where the 6th and higher tasks are allocated, and then you'll have a heckuva time figuring out what's wrong ... so be sure to add mem.c as a node to your project.

Regards,

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

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

Re: OSRpt() output is unusual

Postby JBevis » Mon Jul 01, 2002 9:24 am

Not a problem - your warnings about this were very clear in the documentation from the start. I immediately added "mem.c" into the build and modified the appropriate salvocfg.h defines (# tasks, etc) when I went from the freeware to the standard library, as prescribed, and without any worries! So hopefully, I'm not stomping on anything I shouldn't :-)

Thanks for the good reminder, though. Pumpkin sure is getting a "nice and friendly" reputation at Graviton.

------------------
Jeff Bevis
jbevis@graviton.com

[This message has been edited by JBevis (edited July 01, 2002).]

Jeff Bevis
jbevis@graviton.com
JBevis
 
Posts: 16
Joined: Mon Jun 24, 2002 11:00 pm
Location: La Jolla, CA, USA

Re: OSRpt() output is unusual

Postby DHenry » Mon Jul 01, 2002 9:42 am

Please forgive a lurker's intrusion, but just a quick note just in case the issue of xdata initialization has been overlooked...

If you are using xdata, you'll need to copy the template STARTUP.A51 (in Keil's lib directory) to your project and modify it to suit your memory structure. My recollection is that the default startup code pulled in from the library (i.e., if you don't have an explicit STARTUP.A51) only clears internal RAM from 0x00-0x7F -- no xdata.

The STARTUP.A51 issue is discussed in Chapter 10 of Keil's "Getting Started with uVision" (gs51.pdf) and Chapter 6 of the "Cx51 Compiler User's Guide".

Regards,

--Dan Henry

DHenry
 
Posts: 18
Joined: Sat Aug 04, 2001 11:00 pm
Location: Boulder, CO, U.S.A.

Re: OSRpt() output is unusual

Postby aek » Mon Jul 01, 2002 10:10 am

Hi Dan.

Thanks for the heads-up. We're perhaps not quite as well-versed in C51/8051/memory space intricacies as we should be ... non-zeroed data in that fifth task in Jeff's OSRpt() dump is about the only explanation I could come up with ...

Regards,

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

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

Re: OSRpt() output is unusual

Postby aek » Mon Jul 01, 2002 10:34 am

Hi Jeff.

I was also wondering about that fifth task ... I'm still trying to figure out how that could happen ... You're sure you didn't create another task somewhere with a priority of 11?

There's a chance that there is simply junk data in that uninitialized task, but normal ANSI C compiler behavior is to zero global variables, and the task address seems reasonable. But note that there is not a '.' in the t-> (next tcbP) field, suggesting that this is in fact junk data. Is it possible that because you have Savlo's global variables in the xdata space, that C51 won't initialize them at startup?

In any event, having an unitialized task won't cause any problems so long as you don't attempt any discrete operations on it (g.g. OSStartTask()).

I was wrong about task4.c -- you'd only need that in a source-code build, not the library build like what you're doing. I did my fix to OSRpt() in a source-code build project, and that's why I needed task4.c.

Regards,

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

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


Return to 8051 family

Who is online

Users browsing this forum: No registered users and 1 guest