Pumpkin, Inc.

Pumpkin User Forums

Serial ISR indepentant of SALVO?

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

Serial ISR indepentant of SALVO?

Postby Unregistered User » Mon Jan 21, 2002 9:30 am

I'd like to be able to run a very fast backbone under interrupt control using one of the built in Serial Communications Ports, with 9 bit addressing active. The ISR would do nothing more than pack data into a circular buffer and count bytes to match message byte count before it would set a flag or semaphore true. The message sizes will be small ( < 65 bytes).


The system traffic will be slow, on the order of a few 10's of messages per sec, more during a download or dump. The SCI baud rate will be 0.5 to 1 mega-baud if possible and Synchronous over a 485 network.

Can it be done under Salvo?

Thanks for your help.

Unregistered User
 
Posts: 36
Joined: Thu Aug 09, 2001 11:00 pm

Re: Serial ISR indepentant of SALVO?

Postby aek » Mon Jan 21, 2002 10:09 am

I don't have any direct experience using the PIC's SCI in synchronous mode, but I think I can answer your question. The short answer is Yes, but you'll want to read on ...

The problem that you're faced with in these cases is always the interrupt latency that the RTOS introduces. For example, a simple context switch on the PIC takes (roughly speaking) 150 cycles, so at 4MHz that's 150us that interrupts are disabled. It's actually about half that (because interrupts are enabled and disabled in the middle of the process), but let's stick to that figure for now.

This means that if you have an incoming datastream, and a 1-byte-deep receive buffer, you absolutely must be read the incoming data within somewhat less than 150us in order to avoid an overrun error. For 9-bit data and a 4MHz PIC, this means that 60kbps is the maximum rate you can support. For 20MHz PIC, that goes up to 300kbps. In theory, double- or triple-buffering of the receive register can up this rate by 2-3x.

But all is not lost, since a synchronous channel has a Master and a Slave, and you, as the programmer, control the rate at which the Master sends out data. So, here is how you could implement this scheme very elegantly using Salvo and relatively slow PICs:

The key is to separate the first transmission from the rest, and it will work in your case because the packets are relatively small. The idea is to send the first byte (I'll call them bytes even though they're 9 bits long), and then wait a predetermined time before sending the rest as fast as possible. (Even better, you could have the receiver send a single packet back to the transmitter, saying "I'm now configured and ready to receive the remaining bytes"). The reason for the delay or handshake is to 1) eliminate any latency problems on the receiver side, i.e. guarantee that the receiver got the RCIF interrupt and read the first byte correctly, and 2) to lock the receiver into a tight loop that excludes the RTOS and simply waits for the rest of the incoming characters.

Once the last byte has been received (either by explicit size info in the overall packet format, or by timeout), the receiver exits this tight "receive bytes 2 through n" loop and returns to normal multitasking operation. The only impact on multitasking in this scheme is the amount of time that the Salvo scheduler is prevented from running. 65 bytes x 9bits/byte x 1 us/bit = 585us, plus maybe another 200us for the delay or handshake between byte 1 and byte 2, is still less than 1ms. Since you're likely to set the Salvo system timer to something between 2 and 10ms, you'd have very minor timing jitter for delayed tasks, and there wouldn't really be any other substantial impact.

So, the key here is to be creative with the receiver, and recognize that the receiver needs to guarantee reception of the first byte, and then be ready for a blast of the rest. I would prefer the handshaking implementation, as it will result in the fastest and most robust system. I would even re-transmit the first byte (which I presume is a device address) in the "2 through n" packets so that the receiver always verifies that the data it gets is really for it.

So, to summarize, the receivers have to operate in one of two modes. Mode 1 is standard Salvo-based multitasking, and is the default. An RCIF detected in Mode 1 triggers Mode 2. Mode 2 probably occurs entirely within an ISR, involves being both a Slave and a Master (for the handshake case), and operates without any interrupts enabled. During Mode 2, Salvo is essentially stopped. Reception of the final byte reverts to Mode 1.

I hope I've answered your question. If anything's not clear, please let me know.

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

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

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


Return to Coding

Who is online

Users browsing this forum: Baidu [Spider] and 1 guest

cron