Em 4/7/2010 18:23, William "Chops" Westfield escreveu:
> On Jul 4, 2010, at 1:23 AM, solarwind wrote:
>
>> In this way, the ISR stays relatively free most of the time. It only
>> executes some short code when a byte is received. So, even if the
>> processing of the message data takes a long time (for whatever
>> reason), the ISR is free to continue pushing data into the buffer.
>> Meanwhile, the processing thread runs "in the background" to handle
>> the received data.
> Your ideas are fine and relatively standard for device drivers on  =

> pretty much any class of processor.  You can end up saving significant  =

> amounts of CPU time overall by adding a little bit more intelligence  =

> to the ISR; detecting end-of-packet before waking up the "processing  =

> thread", for example.   You use more cycles in the ISR, but the data  =

> is already in registers and such, and the processing wakes up a lot  =

> less.  (and one learns to appreciate protocol definitions that make it  =

> easy to do significant portions of processing in the ISR.  Terminating  =

> byte values avoided in the packet itself: good; byte count at start of  =

> packet: less good.)
>
> It'll depend somewhat on what else is going on...  Multitasking  =

> kernels are fundamentally dependent on having a surplus of actual  =

> computing power...
>
> BillW

For ASCII protocols it is easy to have start and end markers that can't
appear inside the packet itself, but ASCII protocols are less efficient
than binary protocols.

For machine-to-machine communication I prefer binary protocols, with a
start marker, length, payload and a checksum. I stipulate a maximum
delay between any two bytes of a packet (1 to 10ms usually), so if for
any reason the receiving state machine gets confused (because some data
is lost and a byte inside a packet matches the start marker, for
instance), it is easy to stop transmitting until the other side detects
this timeout and re-synchronizes. Usually this is accomplished
automatically, because the transmitter will wait for the response of the
previous packet before transmitting the next, and this wait is enough
for the other side to re-synchronize.


With protocols like this, it is more efficient if the ISR understands
the packet structure and assemble a complete packet before waking the
processing task. It just takes a very compact, simple and fast state
machine.
I wrote once a system where the ISR replies a low-level packet telling
that the packet arrived OK (it inserted a packet directly into the
transmission queue and enabled the TX interrupt), or if there was any
error and a retransmit was needed. The main task then replied a second
packet, with the result of the processing of the original packet.


Best regards,

Isaac

__________________________________________________
Fale com seus amigos  de gra=E7a com o novo Yahoo! Messenger =

http://br.messenger.yahoo.com/ =


-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist