Searching \ for 'USART interupts; Why use them?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serials.htm?key=usart
Search entire site for: 'USART interupts; Why use them?'.

Truncated match.
PICList Thread
'USART interupts; Why use them?'
1999\10\20@044753 by Darren King

flavicon
face
I've been programming the PIC16F877 using Pic C.  My question is about the
interupts.  With the Pic16F877 there is just one interupt vector right?  So
when ANY interupt happens it goes to the same procedure.  In order for this
to be usefull do I set up a "If this Interupt Flag is True then this" kind
of thing or what?  And as for the USART interupts.  I can understand using
the Recieve Interupt as that would allow you to buffer bytes and then read
them when you get the time, but why would you need a send Interupt?

DjK

1999\10\20@051942 by Keelan Lightfoot

flavicon
face
Darren King Wrote:
-snip-
>them when you get the time, but why would you need a send Interupt?

Just a guess -- If you are transmitting data at 300 Bps, for example, that
is a lot of time that would be wasted between bytes. With a send interrupt,
you could tell the USART to send a byte, go back to doing whatver you are
doing, then when the interrupt comes, send the next byte, and so on.

- Keelan Lightfoot

1999\10\20@065902 by Nigel Orr

flavicon
face
At 04:56 20/10/99 -0400, you wrote:
>I've been programming the PIC16F877 using Pic C.  My question is about the
>interupts.  With the Pic16F877 there is just one interupt vector right?  So
>when ANY interupt happens it goes to the same procedure.  In order for this
>to be usefull do I set up a "If this Interupt Flag is True then this" kind
>of thing or what?

I set up a 'ladder' checking the interrupt flags to decide which isr
routine to go to.  There are probably better ways but mine is just a string
of

btfsc int1_flag
goto int1_routine ... etc etc ...

at the interrupt vector, after the context saving code.

>And as for the USART interupts.  I can understand using
>the Recieve Interupt as that would allow you to buffer bytes and then read
>them when you get the time, but why would you need a send Interupt?

It can tell you when the send buffer is empty so you can go and load some
more data without wasting time polling it to find out

Nigel

1999\10\20@085636 by paulb

flavicon
face
Darren King wrote:

> I can understand using the Recieve Interupt as that would allow you to
> buffer bytes and then read them when you get the time, but why would
> you need a send Interupt?

 You are quite correct in your curiousity.  They are rarely used.  Most
transmit loops go along the lines of:

 While true do {
 txc=(producer_function)
 While not tx_reg_empty
   do { another_task_segment }
 send(txc)
 }

 You could of course use a transmit buffer but there will always be the
possibility that the "producer" function will run fast enough to fill it
and you then have to wait on the buffer anyway.  The buffer will spend
its time mostly either full or empty, not useful in either case.

 Receiver functions OTOH  will mostly be able to keep up with the
input but you need a buffer in case they *temporarily* don't.  If the
receiver buffer ever fills then you have a crash.  You may use flow
control to avoid this.

 The classic example of this are the CR/ LF functions on a VDU which
involve shifting many characters whilst just printing each character is
dead easy.

 In summary, you use a receiver buffer as you can't afford not to,
while having no transmit buffer may at worst slow down communications.

 As to the PIC, yes, one IRQ vector means you have to poll for all
possibilities in the service routine.  In itself a good reason for
using no more interrupts than you can avoid, preferably one or two.

 My suggestion is that RXD is an excellent use of an interrupt, TXD and
"heartbeat" timers aren't in most cases..
--
 Cheers,
       Paul B.

1999\10\20@095537 by Harold M Hallikainen

picon face
On Wed, 20 Oct 1999 04:56:08 -0400 Darren King <spam_OUTdarren.kingTakeThisOuTspamSYMPATICO.CA>
writes:
> I've been programming the PIC16F877 using Pic C.  My question is
> about the
> interupts.  With the Pic16F877 there is just one interupt vector
> right?  So
> when ANY interupt happens it goes to the same procedure.  In order
> for this
> to be usefull do I set up a "If this Interupt Flag is True then
> this" kind
> of thing or what?  And as for the USART interupts.  I can understand
> using
> the Recieve Interupt as that would allow you to buffer bytes and
> then read
> them when you get the time, but why would you need a send Interupt?
>
>

       Yep, you have to poll the interrupt flags in the ISR, typically with a
bunch of BTFSC, CALL sequences.  My ISR's start with a SAVECONTEXT macro,
the BTFSC, CALL's for each possible interrut (remembering the clear the
interrupt flag in the called routine).
       In my typical applications (ligting control), I use interrupts on both
transmit and receive.  I have a buffer in RAM holding all the DMX data I
want to transmit.  Based on an interrupt, the buffer data is transmitted
continuously.  Note, however, that in this case I use a timer interrupt
instead of the UART interrupt because I have to synchronize BREAK signals
with the transmitted data.  I found using a timer IRQ was easier than
trying to figure out when the UART had finished transmitting the byte.
       In a more typical serial transmission situation, I've used transmit
interrupts with a circular buffer in RAM.  The non-interrupt code then
does not have to wait around for the UART, just dump the data into the
buffer and go on.  The ISR pulls the stuff from the buffer and transmits
it.  I've done similar stuff with driving LCD modules, though they do not
generate an interrupt.  If you have a timer interrupt calling the ISR now
and then, then poll everything (including an LCD module status bit), you
can get a lot done in the background.


Harold

___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: dl.http://www.juno.com/dynoget/tagj.

1999\10\20@103859 by Robin Abbott

flavicon
face
Darren

As others have replied you have to test the interrupt flag in the common
interrupt routine. This would have been nicer if Microchip had implemented a
different interrupt address for each source, but it's not that hard to cope
with.

Secondly it takes about 1mS to transmit a byte at 9600bps. If you had to
wait for the transmitter to be empty then that's 1mS each byte transmitted -
it could slow your code to unuseability. In the FED library routines for our
C Compiler and visual assembler we provide interrupt driven communications
routines which provide a transmit buffer - you add as many bytes as you wish
to the transmit buffer and the interrupt handler transmits them one after
another in the background whilst your program does some useful work !

Robin Abbott - .....robin.abbottKILLspamspam@spam@fored.co.uk

**************************************************************************
*
* Forest Electronic Developments
* http://www.fored.co.uk
*
**************************************************************************

{Original Message removed}

1999\10\20@111811 by Wagner Lipnharski

picon face
Isn't time to someone produce a microcontroller with somekind of
programmable "dma" for fast uarts?
You just program the internal or external memory "transmit data buffer"
address and byte count, it will generate just one interrupt when all the
buffer was sent, so you can refill the buffer with new data to be tx.
The same is valid for reception.

This kind of "dma" could be used for several other functions, as to keep
polling few port bits and wait for a programmable bits combination to
generate an interrupt, useful for keyboard polling routines and other
devices.
Of course, all of this done in hardware, and if possible without holding
the main processor, could bust up the model in the market. We are at the
dawn of a new era, new dogs with old tricks are needed (the reverse is
also valid).

The actual very low cost of uC cores could allow to include more than
one CPU at the pkg, to deal with different intelligent tasks.  Two CPUs
running at 20Mhz will not consume the same power of one CPU at 40Mhz,
but certainly will do more job, since reducing interruptions it also
reduces lots of stack usage, and wasted time.

One can say that we should be thankful that we don't need to interrupt
the CPU for each bit transmitted at the UART, but then, why not just
interrupt for each complete message instead?

Just in time; An internal third CPU could be implemented with math and
special routines factory hard coded or custom code eeprom, how much
would cost that? extra $30 cents per unit?  I have done it externally,
using a second uC, single wire communication, just to do long math
(+-/*^SqrSinTanLog) to a very busy main uC.  Cost the fantastic amount
of $2.30, believe me, cost more the PCB real estate and designing labor.
So, why not have this inside the same package?

I bet that more sooner than later you will be hearing such monster roar.

Wagner.

Robin Abbott wrote:
[snip]
> Secondly it takes about 1mS to transmit a byte at 9600bps. If you had to
> wait for the transmitter to be empty then that's 1mS each byte transmitted -
> it could slow your code to unuseability. In the FED library routines for our
> C Compiler and visual assembler we provide interrupt driven communications
> routines which provide a transmit buffer - you add as many bytes as you wish
> to the transmit buffer and the interrupt handler transmits them one after
> another in the background whilst your program does some useful work !

1999\10\20@113237 by hris Fanning

flavicon
face
I'm hoping I can ask you a quick question about FED C.

I'm looking to create a user upgradable product.  The 16F877 has
the ability to write to flash program memory which can give me this
capability.

In order to do this I want to create an assembler loader of a few
hundred bytes that can reprogram the device via serial port.   After
reprogramming (or not) I would then jump into the C program entry point.

Will your compiler allow me to reserve a specific program location for
such a piece of code?

i.e. reserve the first 200 bytes of program space that will never be
used or touched by the compiler?

Thanks,
Chris

1999\10\20@143619 by William Chops Westfield

face picon face
   Isn't time to someone produce a microcontroller with somekind of
   programmable "dma" for fast uarts?

Yes.  Motarola did, of course, in their 68302, QUICC, and powerQUICC
chips (which are a bit more than "microcontrollers", I guess.)

DMA isn't normally very simple, though.  You still need interrupt routines
to handle buffer terminations, and those routines are much more complex than
a character-based transmit scheme (if you're not copying the data, it needs
to be locked against modifications during DMA, for instance.)  (The
fundamental problem is that serial IO is MUCH slower than processing
speeds.)  Handling "responsiveness vs efficiency" issues for a typical
interactive UART receive routine using DMA is a real bitch.  Most
manufacturers simply increase the FIFO size of the UART.  Once the FIFO size
exceeds the "typical" message size, you get behavior similar to what you're
asking for (however, since you still have to copy the messages, you don't
gain quite as much efficiency - you only save N*interruptoverhead, which can
be small compared to the rest of the processing.)  I'm not sure whether
there are any deep-fifo UARTS in microcontrollers - RAM is "expensive" on a
chip, remember, and when controller people are talked into adding it it
usually shows up as general purpose ram so that it can be used for things
OTHER than the uart as well.


   The actual very low cost of uC cores could allow to include more than
   one CPU at the pkg, to deal with different intelligent tasks.  Two CPUs
   running at 20Mhz will not consume the same power of one CPU at 40Mhz,
   but certainly will do more job, since reducing interruptions it also
   reduces lots of stack usage, and wasted time.

Also present in the motarola chips I mentioned.  And you're (seriously)
underestimating the overhead and complexity of runing a multiple processor
system, which goes up exponentially with the degree of "general purposeness"
of the additional processors.


   Just in time; An internal third CPU could be implemented with math and
   special routines factory hard coded or custom code eeprom, how much
   would cost that? extra $30 cents per unit?

It'd double the size of the die.  I dunno if PICs price is still
proportional to die size (seems like the dies should have shrunk by now,
but the price hasn't gone down much!)  Sounds like an interesting idea
for any design where you have extra space left on the die.

Or do you mean like the FPU in a big processor?  Seems to me the
difference in price between a 486sx (no FPU) and a 486dx (FPU) was
pretty substantial!

BillW

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...