Pumpkin, Inc.

Pumpkin User Forums

Serial Comm Best Practice

If you have a general question or comment regarding Salvo, post it here.

Serial Comm Best Practice

Postby aek » Thu Jan 24, 2002 1:43 am

Hi Eduardo.

We're very happy to hear of your enthusiasm about Salvo.

Your approach is pretty good. The one change I might make would be to use a a-variant library (like sfp42Caa.lib) and signal a binary semaphore directly from inside the ISR once the buffer is full or a <CR> has been received. Then the task (that waits on the binsem) will run asap as opposed to having to wait for the main loop.

However, there isn't really much difference between what you are doing and what I described above as long as your "main loop" looks something like this:

code:
for ( ; ; ) {
if ( flag ) {
OSSignalBinSem(RX_BUFF_FULL);
OSDisableInts();
flag = 0;
OSEnableInts();
}
OSSched();
}

The only real difference is that if you had more than one such event that triggered the running of a task, your method will not preserve the order in which the tasks run -- instead, order is defined by the order in which you call OSSignalXyz() in your main loop.

Salvo maintains the order of signaled events, so if you happen to have two tasks at the same priority, where TaskA() waits binSemA and TaskB() waits binSemB, then if binSemB is signalled, then binSemA, all before the next main loop iteration (and from inside an ISR), then TaskB() will run before TaskA(). If this isn't an issue for you, then don't worry about it.

The tricky / unfortunate thing about signalling from inside ISRs with PICs and PICC or PICC-18 is that neither compiler generates reentrant code. Therefore there are some issues (that revolve around the #pragma interrupt_level) that must be addressed for a successful compile. They are:

1) If you use an a-variant library, you must call OSSignalBinSem() and OSCreateBinSem() (and similarly for other event types that you're using) both from mainline code and from an ISR. This means that most applications will need a "dummy" call to OSCreateBinSem() from inside an ISR(), something like this:

code:
if (0) OSCreateBinSem(RX_BUFF_FULL);

This is because the a-variant libraries have been compiled with #pragma interrupt_level 0 applied to both OSCreateBinSem() and OSSignalBinSem(). It's not pretty, but it works.

2) There is also the fact that when a PICC or PICC-18 functions is declared with #pragma interrupt_level, interrupts must be disabled prior to calling the function from mainline code and reenabled thereafter. Otherwise you will get parameter corruption. Therefore you must write:

code:
OSDisableInts();
OSSignalBinSem(RX_BUFF_BULL);
OSEnableInts();

in your mainline code. Again, it's not pretty, but it's a fact of life with the non-reentrant code that PICC and PICC-18 generate. The advantage of these compilers is that they generate very small and fast code ...

These issues are discussed and illustrated at length in App Notes AN-8 and AN-9.

So, the short answer is that I'd recommend you stick to your existing method. You'll eek a little bit more performance out of the alternative method, but it's more work.

Regards,

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

[This message has been edited by aek (edited January 24, 2002).]

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

Re: Serial Comm Best Practice

Postby aek » Thu Jan 24, 2002 1:49 am

Hi Eduardo.

I forgot to answer your question re a software implementation...

App Note AN-8 has four software USARTs running inside a PIC16F877 or 18C452, plus the hardware USART. The App Note details how I split up the transmit and receive USARTS in a manner that guaranteed good performance and worked well with Salvo. It might give you some ideas...

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

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

Re: Serial Comm Best Practice

Postby Eduardo Robles » Thu Jan 24, 2002 9:29 am

Hi,

So far I have sucesfully implemented my first robotic application that uses Salvo RTOS. I must say that I am pretty enthusiastic about it and I like the performance of the software. In this application, I use a serial console to monitor a few activities and program some parameters for the robot (a sort of line tracker project for my son's school) but I wonder about what could be the best approach for serial communications using Salvo.

Let's say that I use the hardware UART embedded in some PIC's. Today I am using the interrupts from the UART to collect the incoming characters and assemble them into a string (still in the interrupt routine). Then, when the buffer is filled or a <CR> is received, I set a flag (not an OSEFlag, just a global var) that is monitores regularly in the main loop. If the flag is set, then I signal an event to a tast that will process the incoming buffer.

Is there a better way of doing this?
What if I do not have a hardware UART, but a SW implementation?

Any ideas are welcome!

Regards,

Eduardo

Eduardo Robles
 
Posts: 14
Joined: Mon Jun 18, 2001 11:00 pm
Location: Sao Paulo, SP, Brazil

Re: Serial Comm Best Practice

Postby cstocks » Fri Jan 25, 2002 1:30 am

Eduardo,

I have been using a different approach to parse input streams. Using a state machine (implemented as a switch statement), the input strings are interpreted character by character. Although the interrupt code is long, the time spent in it is short because each operating state is simple (it just checks for the legitimate characters, processes them if necessary, or jumps to an "error" state if the input were invalid).

The completed projects that have used this technique were developed before I came across Salvo, but once I recognise a valid sequence, and have determined the appropriate system action, a flag (effectively a semaphore) is sent to the background to cause the action to take place. In Salvo, this would be very easy to implement.

Parsing input in this way has the benefit of making compact code (if you collect common statements together at the END of switch "case"s, PICC is very good at merging them into a single instance of object code), and prevents "lumpiness" in the processor demand because each character is processed individually, rather than having to evaluate an entire string in one hit.

Regards,

Colin

cstocks
 
Posts: 7
Joined: Tue Oct 23, 2001 11:00 pm
Location: Crowborough, East Sussex, UK

Re: Serial Comm Best Practice

Postby tbims23822 » Tue Jul 07, 2009 7:04 am

www.drop-shopping.com is a premium website for cheap air jordans shoes and other more really nike air jordan shoes.We have varity of cheap air jordan shoes available for wholesale.Cheap China wholesale shoes including cheap Nike shoes and cheap jordan shoes,nike sneakers,nike sneakers discount,air jordan sneakers,air force sneakers.We supply nike sneakers,jordan sneakers,air jordan sneakers,air force sneakers wholesale.You can buy very cheap jordans shoes including cheap women shoes,cheap nike shoes,cheap running shoes from us.
tbims23822
 

Re: Serial Comm Best Practice

Postby tbims23822 » Wed Jul 08, 2009 11:31 am

www.drop-shopping.com is a premium website for cheap air jordans shoes and other more really nike air jordan shoes.We have varity of cheap air jordan shoes available for wholesale.Cheap China wholesale shoes including cheap Nike shoes and cheap jordan shoes,nike sneakers,nike sneakers discount,air jordan sneakers,air force sneakers.We supply nike sneakers,jordan sneakers,air jordan sneakers,air force sneakers wholesale.You can buy very cheap jordans shoes including cheap women shoes,cheap nike shoes,cheap running shoes from us.
tbims23822
 


Return to General

Who is online

Users browsing this forum: No registered users and 1 guest

cron