Andrew Kalman wrote:
Thanks!
But how do You presume that anything else might be executed, when
sending chars.
You can't. That's the whole point of interrupts.
In your code one UART TX interrupt, is forcing another.
Usually the UART transmition is not time critical, and chars could be
sent only when processor is free. So for long time I am thinking about
something like:
for(;;){
if (processor_free()){
usart_put_next_char(ch);
}
}
robert
There isn't any point in doing one character-per-main-loop execution via
interrupts. In your code above, just feed TxBuff and go do something
else. Check to ensure that the Tx buffer can handle the outgoing
character first, of course.
You will be "stuck" waiting for the outgoing character to clear anyway,
because e.g. at 9600 baud, one character takes 1.04ms to send, which is
a relative eternity. You may have nothing to do many, many times in
1.04ms while waiting to be able to send the next character.
processor_free() can be discerned pretty easily if you have some sort of
scheduler / RTOS. In our Salvo RTOS, you could put that call in
OSIdlingHook(). Then it would automatically send one character each time
the scheduler sees that there are no tasks eligible to execute and the
Tx buff can take the next char.
Even using Salvo RTOS, you would enter processor_free() at a much higher
rate that you can send 9600 baud characters ...
I'd use interrupts and send things out as fast as possible, and control
interrupts globally in case you can't tolerate being interrupted.
It all boils down to your "and chars could be sent only when processor
is free" statement. You need to resolve what you mean by that, and
whether Tx ISRs can run in the foreground while your processor is
running in the background, doing mainloop code or tasks. Since each Tx
INT will only occur every 1.04ms, and will be very fast, you should not
have any problems sending these characters out.
Andrew Kalman wrote:
Does anyone has experience with uart transmit interrupt handling.
I would like to send long string of data, but not more, then one
character per main loop execution.
Is there interrupt based chars sending ever possible ?
I experienced, that during chars sending nothing is run, except
other interrupts.
robert
I presume, that by 9600 baud you mean 9600 bps. So 1.04ms by 9600
should give 1000. But it gives 10 000. Something is wrong, isn't it ?
So I presume 0.104 ms, which gives 104us.
With 115200 it is 12 times less, which is around 8us.
with MCLK 7372800 one clock tick i 0.13us
Maybe I don't understand sth, but msp430 is almost close to it's limits!
Cheers
robert
There was a long thread on USART TX ints a while back (2 months?) in
the MSP430 Yahoo group.
I posted my Tx USART code, which used a method of controlling TXIE
that solved the problem(s) of the original poster.
Here it is: http://groups.yahoo.com/group/msp430/message/13559
I use it so serve up web pages over TCP/IP on the MSP430 -- so the
strings are quite long, and there are lots of other things happening
while the ISRs are active and sending data. tested at 9600 baud with
buffers ranging from 60 to 512 bytes.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
