Page 1 of 1

Deep changes for OSRpt() that will make it usable

PostPosted: Tue Nov 06, 2001 9:14 am
by luben

When debugging a project one of the most useful functions in SALVO is the OSRpt() that creates report of the current status of the kernel. For sure if you can use it you should use it without hesitations. Because the Franklin C compiler (with build in RTOS) has software emulator with very good status of kernel window, I enjoyed how nice is to usage of this function.

But why usually OSRpt() is hard to be used? Let's count the bad sides:
- it needs a big code size in ROM. Even for some small PIC the needed ROM for this function could be greater then total ROM size of the processor (like PIC12C508 or 16C54).
- it's very slowly functions and to create the report needs a big amount of time. This automatically makes it "non real time" function. In addition SALVO should make some calculations - at least to produce ASCII characters and to convert binary to ASCII data.
- needs working printf() function - some serial channel or something like this.

Well, let's think about the core of OSRpt() - what we send to the user - just information, that is both - "pure" information (what exactly the user needs - digits, info for tasks, etc.) and "extra" information, that is needed to order the digits on the screen, any support messages, etc. Even the "information" rows with only digits need TABs and spaces - that is extra information.

I didn't count the rate of pure to whole information, but for sure it will be near 1:10 and more for the whole OSRpt(). Of course you can't remove the additional information - it helps the user to understand what's up, I mean it's so important, like the "pure" one.

What come like idea in my mind is:
- SALVO sends only the pure information in pure type (HEX).
- In the PC should stay resident program (could be some additional PC or Notebook) that watches the serial port. Before it begins to watch the serial it takes the information from SALVOCFG.H file for the settings of kernel or this could be done manually from user when checking some check boxes. And this program "knows" the algorithm of the OSRpt() - I mean, which byte where should be placed on the user screen. So the resident program will "UNZIP" the information and will create the readable report on the screen for the user from hex coming data. Will assemble the puzzle of coming HEX data. This will totally reduce the amount of resources and time for OSRpt(). It should only send some amount of HEX bytes in some order, that represents the status of the kernel. No printf() functions, no precoding, no extra information, no unnecessary information. Pure SALVO status.
So the OSRpt() will send only the pure information in HEX, for sure it will be not readable without additional software and PC where to reside this software. But this is not special equipment, I meant - you can even use some old PC like terminal. And if SALVO brings the program for free, nobody will hesitate to use it.

In short:
- The idea is - OSRpt() to send only pure information to the user in hex format. If you count the bytes sent in OSRpt and then you count the "information" hex bytes needed to create the report you'll see how big is the difference.
- some software that understands this information is required. It will reside in PC or notebook and could interpret the coming data. And if this is free program, that comes with SALVO package nobody will deny to use it.

Even I think that some setting could be made for OSRpt(), like
OSCREATE_REPORT with values OS_COMPACT and OS_NORMAL. If OS_NORMAL the OSRpt() will work like now and no change from the current function you can mark. If OS_COMPACT - other libraries will be loaded and the report will begin to work faster and will much less memory (even on PIC12C508??)

Some other ideas, that has connection with this.
Some times ago I played with SONY S-Link interface. I made a bridge -RS232 to SONY S-Link. One of the biggest disadvantages of the OSRpt() (I'm not speaking about the new idea to change the format of data) is that usually the processor has no free serial ports. Even if you implement TASK (like you described in your application notes) that drives RS232 software output it needs at least precision oscillator, OSTimer() functions. RS232 interface has +/- 5% tolerance to the coming frequency.

What I propose is: some extra big tolerance, frequency independent interface for sending OSRpt(), that is easy to be build in every project and will not consume resources. There are many such interfaces - like DALLAS, S-Link, etc even I have ideas for at least two new types. The basic idea is - you don't need exactly frequency and precise periods to transmit data.
But this of course needs some additional hardware. My vision is - simple PIC chip (maybe 16F873 or even 16F870), RS232 buffer. This will be "frequency independent" to RS232 bridge. And all this on small plate with SMD element (if the user want to take it whole form Pumpkin) or you can put in the SALVO install file the source code of this processor - so every one can build, program and use this bridge by himself.

I offer to you to make you such chip and to send you the source code of it payfree, will be my pleasure to help SALVO to become better and better. I can even make the resident program that will display the information on the PC screen (the resident terminal program), but for sure this will take more time and resources. For sure I have very clear vision of the whole working project - how the bridge should look like, what the terminal program should do.

So, if you have such RS232 - "SALVO interface" bridge, if OSRpt() sends only pure HEX information and additional terminal program shows this information on the screen you'll get one really excellent debugger.

Best regards

Re: Deep changes for OSRpt() that will make it usable

PostPosted: Tue Nov 06, 2001 9:32 am
by aek
Hi Luben.

A better means of "seeing into" a Salvo application would be welcome!

After all, all one really needs to do is dump all the Salvo variables in raw data to a PC, which, using salvocfg.h and a little knowledge of the target environment, then displays it in a more useful manner. It could also be quite fast -- most Salvo applications won't use more than 100 bytes of RAM, which can be sent quite fast (SPI, UART, I2C, etc.).

We would be happy to include this "debugger" in Salvo. I think the hardest part would be to write the PC application -- it needs to be quite "aware" of the configuration that Salvo is using.


Re: Deep changes for OSRpt() that will make it usable

PostPosted: Wed Nov 07, 2001 5:41 am
by luben

I know that the heaviest part of this project is the program that recognizes the coming data and understanding which byte where to put on the screen.

Because the user settings are kept in salvocfg.h - this makes possible the terminal program to "understand" the meaning of hex bytes.

I'm ready to make such program (and will offer it for payfree for SALVO users), but I need additional information. Well, because SALVO full version brings the source codes to the user, I could somehow get this information alone, but for sure will waste too much time.

In the beginning I'll write the program on CROSSTALK - it's very simple for programming enviornment and then to remake on Delphy. Many years ago I used to write a complicated email program on CRASSTALK, so I'm really good known in communications.

I'll think more about this idea and with what kind of information you can help me.

Other approach is to see the code of OSRpt() and to send only hex data.


Re: Deep changes for OSRpt() that will make it usable

PostPosted: Wed Nov 07, 2001 7:46 am
by luben

Talking about the OSRpt() I saw the sources and I think that the idea should look like:

OSRpt() sends the OSECB and OSTCB information to the terminal. Knowing the salvocfg.h settings like number of tasks and events and which type of events are used I can rebuild the picture of internal status. Then I need the tick counter (if used) and some other memory cells. Sounds easy, but I know that many details should be defined...

I even played with the idea how to transfer data if no free serial or I2C or SPI port exists. As I told you I used to work with S_Link and DALLAS interface and I got something that's between them and is totally time independent, or let's say - time autoadjustable. The start bits and zeros are sent like 2 pulses, ones like 1 pulse. The time between their falling edges of the START bit is took like base for calculating the acceptable periods between bits and words. I mean - if the oscillator is RC and the processor can't generate precision time periods, the protocol will still work in extremely wide range of speeds - maybe from 33600 bps to 100 bps.

START 1 0 ......

The user should use only 2 types of delay routines - one for length of the zero and one for the pause between next bit. The hardware (I guess PIC16F873) that will translate this sequence to RS232 interface and will autoadjust its time rates from the first START bit (that even could be made with 3 pulses, to ensure that no other bit will look like it). So if the time between pulses in START bits is Ts, then we could take the time between bits 3Ts < Tbits < 5Ts to guarantee that even big variation of the frequency will not wrong the process. If no pulse come between this time - process will be terminated.
In addition the hardware should support I2C and SPI to RS232 features, controlled with simple jumper switching.

By the way I always wished to build something like that - if you don't have ICE real time debugger, for some processor is good to know what's up inside.

But as you told the biggest job should be done in the terminal program. The way how we translate the data is not so important, I mean - we could always get some way to do this.

So my question is:
After I get the data from OSTCB and OSECB what other data I should take? And what I exactly need from OSECB and OSTCB - the whole information, or a part of it?

I think that one good and quick OSRpt() with complementary terminal program will bring a lot of advantages to the users of SALVO.


Re: Deep changes for OSRpt() that will make it usable

PostPosted: Wed Nov 07, 2001 9:20 am
by aek
After I get the data from OSTCB and OSECB what other data I should take? And what I exactly need from OSECB and OSTCB - the whole information, or a part of it?

You'll probably want everything -- take a look at the screen dump for OSRpt() in the manual. Some of the counters (e.g. OStimerTicks) are more important than others ...

I was thinking about this issue today -- here are some of my thoughts:

1) There's really no way to buffer the Salvo objects -- most systems have no extra RAM for a second "copy" of ecbs, tcbs, ptrs, etc. So the data has to be sent immediately / directly.

2) You have to get all the Salvo objects atomically -- if you get just some, and then some time elapses, and then you get some more, then when you "parse the data" it may not make any sense. This means that either i) you need to get all of Salvo's objects quickly, with interrupts disabled, or ii) you need to stop/halt execution while you do a "core dump", and then resume from there.

3) Since Salvo is so configurable, especially with the OSLOC_XYZ configuration parameters, I think that the only reasonably simple way to do this would be to have an OSDump() function that runs in the target system and sends all of the Salvo objects out in a standardized format. This way, OSDump() is compiled along with your project's salvocfg.h, and so it will be able to grab Salvo objects from whatever bank, etc. they are located in, and send them out in a serial bitstream. If you change, say, OSLOC_ECB, then all you have to do is recompile ... So the idea is to send the Salvo objects and some "headers" of extra information to help the receiver understand the format of what's coming ...

4) On the other end, if there was a standardized format to the bitstream, e.g. byte #1 = OSTASKS, byte #2 to #m = tcbs, byte #n = OSEVENTS, byte #n+1 to #n+p = ecbs, etc. then a PC/terminal application ought to be able to receive the data quite handily. Remember, data will grow and shrink in size (i.e. sizeof(tcb), etc.) depending on the configuration. So somehow the sender in the Salvo application should inform the receiver (perhaps via a byte of bits, where b0 = EVENTS enabled, b1 = DELAYS enabled, b2 = timeouts enabled, b3 = little/big-endian, etc -- all done at compile-time) of the overall configuration (number of bytes in the delay field, etc.) so that a single receiver can handle all incoming bitstreams.

5) Let's talk speed -- realistically, an average Salvo app (on a PIC) probably uses 40-80 bytes of RAM for Salvo objects. If we figure 7 instructions/per bit (just guessing) for software bit-banging, and 20% overhead for the "headers", then we get 2.7-5.4ms to dump all the data, for a PIC 16F877 running at 20MHz. Is that acceptable?