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.

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:

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:

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?

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.

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.

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.

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.

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".

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 ...

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.