Linux serial port dropping bytes
Derek Young
I'm using an Arcom Viper PXA255 single board computer running Linux, and
I'm trying to receive bytes over the built-in RS-422 serial port at
921.6 kbps. The received packets are 1500 bytes long. The UART is a
16C2850 (dual port version of the 16C850 with 128 byte FIFO).
Everything works fine at low speeds, but if the packet rate increases, I
start to lose bytes.
I believe this is caused by the Linux serial port interrupt handler not
responding fast enough. Some testing revealed that this problem only
occurs when other peripherals (such as the flash drive or ethernet port)
are active.
I searched online and found a utility called IRQtune which promises to
fix exactly this sort of problem by allowing control of ISR priorities
in Linux. Unfortunately, IRQtune only works for x86 processors.
Does anybody know of a simple way to modify the priorities of interrupts
in Linux? I don't mind recompiling the kernel, but I don't have a lot
of expertise in that sort of thing. (In fact, I would have preferred
skipping the whole OS thing and implementing the entire solution on an
FPGA/uController, but oh well... one doesn't always get to choose.)
Any advice would be greatly appreciated. Thanks!
Derek
--
remove the .nospam and rearrange appropriately to e-mail.
cs_po...@hotmail.com
> I believe this is caused by the Linux serial port interrupt handler not
> responding fast enough.
Or not being relieved of the packet payloads fast enough by whatever
is
supposed to consume them.
> Does anybody know of a simple way to modify the priorities of interrupts
> in Linux? I don't mind recompiling the kernel, but I don't have a lot
> of expertise in that sort of thing.
You'll want to go looking around in the processor / board specific
code,
and especially the serial port driver, perhaps plus whatever
programs the interrupt hardware. Look in places like
drivers/serial
drivers/char
arch/processorname/
Didi
>...
> I'm trying to receive bytes over the built-in RS-422 serial port at
> 921.6 kbps. The received packets are 1500 bytes long. The UART is a
> 16C2850 (dual port version of the 16C850 with 128 byte FIFO).
>
This means you have 1.388 mS to fill the FIFO - plenty of time to
process
it.
> Everything works fine at low speeds, but if the packet rate increases, I
> start to lose bytes.
>
> I believe this is caused by the Linux serial port interrupt handler not
> responding fast enough. Some testing revealed that this problem only
> occurs when other peripherals (such as the flash drive or ethernet port)
> are active.
If some of these IRQ handlers hogs the CPU for 1mS or so you will have
no way out, but if they do that they will be broken anyway.
I am not a wintel/linux etc person and I don't know how much can be
achieved in click-and-try-this mode on your problem, you may be lucky
and hit some working combination for all I know.
Without luck you would want to know the worst case system IRQ latency,
your
UART IRQ load etc. and locate and fix the problem.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
CBFalconer
>
> I'm using an Arcom Viper PXA255 single board computer running Linux,
> and I'm trying to receive bytes over the built-in RS-422 serial port
> at 921.6 kbps. The received packets are 1500 bytes long. The UART
> is a 16C2850 (dual port version of the 16C850 with 128 byte FIFO).
>
> Everything works fine at low speeds, but if the packet rate
> increases, I start to lose bytes.
Your numbers indicate that you would need an interrupt roughly
every 1 microsec. Not a chance.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
Grant Edwards
> Derek Young wrote:
>>
>> I'm using an Arcom Viper PXA255 single board computer running Linux,
>> and I'm trying to receive bytes over the built-in RS-422 serial port
>> at 921.6 kbps. The received packets are 1500 bytes long. The UART
>> is a 16C2850 (dual port version of the 16C850 with 128 byte FIFO).
>>
>> Everything works fine at low speeds, but if the packet rate
>> increases, I start to lose bytes.
>
> Your numbers indicate that you would need an interrupt roughly
> every 1 microsec. Not a chance.
Huh?
If he sets the FIFO threshold to 64, then the interrupt
frequency is 921600.0/10/64 == 1440Hz.
If he sets it FIFO threshold to 96, then the interrupt
frequency is 921600.0/10/96 == 960Hz. 960Hz should be no
problem at all unless some of the other ISRs are running too
long.
--
Grant Edwards grante Yow! .. the MYSTERIANS are
at in here with my CORDUROY
visi.com SOAP DISH!!
Derek Young
I've done some poking around through drivers/serial and drivers/char,
but I couldn't find anything that looks like it would control the
interrupt priority. I did see something that defines the software
buffer size (I think it's supposed to be 8K).
But I'll look through arch/... to see if there's anything there.
Thanks...
Derek
Derek Young
> frequency is 921600.0/10/64 == 1440Hz.
>
> If he sets it FIFO threshold to 96, then the interrupt
> frequency is 921600.0/10/96 == 960Hz. 960Hz should be no
> problem at all unless some of the other ISRs are running too
> long.
>
Thanks everyone for all the responses so far...
Yes, I feel like there should be plenty of time to handle the
interrupts. But from what I understand (which isn't a whole lot mind
you :P), Linux isn't strictly a real-time OS. It doesn't normally have
a preemptible kernel (I've turned on the "experimental" preemptible
kernel flag) and it doesn't really have a standard way to tweak
interrupt priorities.
Was wondering if anybody knew of a straight-forward hack. I just want
the serial port ISR to get priority over the device driver ISRs.
Derek
cs_po...@hotmail.com
> Was wondering if anybody knew of a straight-forward hack. I just want
> the serial port ISR to get priority over the device driver ISRs.
For which you need to find the code that sets up the interrupt
hardware.
Another thing worth doing is looking in the processor/chipset manual
and figuring out what registers would have to be programmed to
do what you want. Then figure out what linux calls those registers
(it will be in a board-specific include file), then grep the source
tree for that name...
Grant Edwards
> Yes, I feel like there should be plenty of time to handle the
> interrupts. But from what I understand (which isn't a whole
> lot mind you :P), Linux isn't strictly a real-time OS. It
> doesn't normally have a preemptible kernel (I've turned on the
> "experimental" preemptible kernel flag) and it doesn't really
> have a standard way to tweak interrupt priorities.
>
> Was wondering if anybody knew of a straight-forward hack. I
> just want the serial port ISR to get priority over the device
> driver ISRs.
Changing ISR priority isn't going to make any difference.
It only determines which of two pending interrupts get
serviced. It doesn't allow "higher" priority interrupts to
preempt lower priority ones. If a low-priority ISR runs for a
long time, it's still going to block high-priority ISRs for the
whole time it's running.
--
Grant Edwards grante Yow! As President I have
at to go vacuum my coin
visi.com collection!
Didi
> ....
> Changing ISR priority isn't going to make any difference.
>
> It only determines which of two pending interrupts get
> serviced. It doesn't allow "higher" priority interrupts to
> preempt lower priority ones. If a low-priority ISR runs for a
> long time, it's still going to block high-priority ISRs for the
> whole time it's running.
Sadly true, except on 68k/coldfire platforms. Some newer
PPC parts from Freescale offer separate mask bits for two interrupts
(6809 F and I like), which is not bad either.
Of course if the system has been designed properly and written
properly (are they ever in commecrial land?... :-) ), every IRQ
handler
would reenable IRQ after a few cycles only - some of the Freescale
PPC parts have a good priority encoder in front of the core IRQ input
and things will then in effect be as good as in a 68k/CF. But good
luck
enforcing that if more than 1 person is doing the work... -).
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Derek Young
> Changing ISR priority isn't going to make any difference.
>
> It only determines which of two pending interrupts get
> serviced. It doesn't allow "higher" priority interrupts to
> preempt lower priority ones. If a low-priority ISR runs for a
> long time, it's still going to block high-priority ISRs for the
> whole time it's running.
>
Darn. I thought a high-priority ISR would preempt all lower priority
ones. Thanks for the heads-up.
Derek
Grant Edwards
> Grant Edwards wrote:
>> ....
>> Changing ISR priority isn't going to make any difference.
>>
>> It only determines which of two pending interrupts get
>> serviced. It doesn't allow "higher" priority interrupts to
>> preempt lower priority ones. If a low-priority ISR runs for a
>> long time, it's still going to block high-priority ISRs for the
>> whole time it's running.
>
> Sadly true, except on 68k/coldfire platforms. Some newer PPC
> parts from Freescale offer separate mask bits for two
> interrupts (6809 F and I like), which is not bad either.
The Hitachi H8 series has the same feature, but linux doesn't
allow one ISR to preempt another ISR even if the hardware is
capable of that.
> Of course if the system has been designed properly and written
> properly (are they ever in commecrial land?... :-) ), every
> IRQ handler would reenable IRQ after a few cycles only
In Linux, the point where interrupts can be re-enabled is the
end of the ISR. The portion of the event handling that can be
done with other interrupts enabled is done in a different
context. Back in the day, Linux ISRs used be divided into a
top half and a bottom half, with the re-enabling of interrupts
occurring between the two (both halves ran in a single ISR
context). But, now the portion of the ISR that used to run with
interrupts enabled is a "soft irq" or a tasklet or something
like that (it runs in a different context, not in an ISR
context). At least that's the way it was the last time I
looked...
> - some of the Freescale PPC parts have a good priority encoder
> in front of the core IRQ input and things will then in effect
> be as good as in a 68k/CF. But good luck enforcing that if
> more than 1 person is doing the work... -).
Even with only 1 person, you're chances aren't great. :)
--
Grant Edwards grante Yow! I need to discuss
at BUY-BACK PROVISIONS
visi.com with at least six studio
SLEAZEBALLS!!
CBFalconer
> Derek Young wrote:
>>...
>> I'm trying to receive bytes over the built-in RS-422 serial port
>> at 921.6 kbps. The received packets are 1500 bytes long. The
>> UART is a 16C2850 (dual port version of the 16C850 with 128 byte
>> FIFO).
>
> This means you have 1.388 mS to fill the FIFO - plenty of time to
> process it.
Oh? The unit fills up, with 1500 bytes, and interrupts. Bytes can
be coming in at one per microsec (roughly) until you get at least
some out. That doesn't happen until the interrupt is serviced, and
control is transferred to the unloading code, after doing all the
checks (for error, etc.) So that must have all happened in about
one microsec, to avoid rejecting further input. Now the discharge
loop has to remove items in less that 1 microsec per byte, just to
keep up with the input line. I have doubts that you can even talk
to the UART that fast.
CBFalconer
> CBFalconer <cbfal...@yahoo.com> wrote:
>> Derek Young wrote:
>>>
>>> I'm using an Arcom Viper PXA255 single board computer running
>>> Linux, and I'm trying to receive bytes over the built-in RS-422
>>> serial port at 921.6 kbps. The received packets are 1500 bytes
>>> long. The UART is a 16C2850 (dual port version of the 16C850
>>> with 128 byte FIFO).
>>>
>>> Everything works fine at low speeds, but if the packet rate
>>> increases, I start to lose bytes.
>>
>> Your numbers indicate that you would need an interrupt roughly
>> every 1 microsec. Not a chance.
>
> Huh?
>
> If he sets the FIFO threshold to 64, then the interrupt
> frequency is 921600.0/10/64 == 1440Hz.
>
> If he sets it FIFO threshold to 96, then the interrupt
> frequency is 921600.0/10/96 == 960Hz. 960Hz should be no
> problem at all unless some of the other ISRs are running too
> long.
I know of UARTs that can hold 64, or even 128, results. I gather
that that one has a 128 byte storage. Okay, now consider how long
it takes to empty that buffer, when full. That has to be done at
least every 921600/128 (I don't know where you got /10/96), or
roughly 10 khz, for about 100 uS between interrupts. Now you don't
know how many items are stored, so that implies a one by one
discharge loop. Nobody has mentioned the CPU speed, but I still
have grave doubts. Don't forget that during the discharge the FIFO
is still filling up, at roughly 1 item per microsec.
I would guess you are assuming the speed mentioned is a bit speed,
not a per byte port speed, and the '10' is the length of the
character, in bits. Nobody computes serial port speeds that way.
Didi
> >> I'm trying to receive bytes over the built-in RS-422 serial port
> >> at 921.6 kbps. The received packets are 1500 bytes long. The
> >> UART is a 16C2850 (dual port version of the 16C850 with 128 byte
> >> FIFO).
> >
> > This means you have 1.388 mS to fill the FIFO - plenty of time to
> > process it.
>
> Oh? The unit fills up, with 1500 bytes, and interrupts. Bytes can
> be coming in at one per microsec (roughly) until you get at least
> some out.
Oops, sorry, I have taken the 1500 for FIFO depth, not the 128, hence
the wrong result.
This means he will have (1388/1500)*128 uS to fill the FIFO, or about
118 uS.
Still plenty of time to empty a FIFO into memory on most if not all
todays
CPUs which would have a 128 byte deep FIFO on the UART.
But latency is bound to creep in as an issue in this context given
that under
linux other IRQ handlers will not unmask early (I am relying on Grants
word for
that), so there is probably no working linux option - which is I
believe what
you suggested initially.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Robert Adsett
> I would guess you are assuming the speed mentioned is a bit speed,
> not a per byte port speed, and the '10' is the length of the
> character, in bits. Nobody computes serial port speeds that way.
I don't remember ever seeing serial port speed specified as other than
bits/sec. And geven a lack of other information 10 seems like a
reasonable place to start for a character with start and stop bits
included.
Robert
Hans-Bernhard Bröker
> Didi wrote:
>> Derek Young wrote:
>>> ...
>>> I'm trying to receive bytes over the built-in RS-422 serial port
>>> at 921.6 kbps. The received packets are 1500 bytes long. The
>>> UART is a 16C2850 (dual port version of the 16C850 with 128 byte
>>> FIFO).
>> This means you have 1.388 mS to fill the FIFO - plenty of time to
>> process it.
>
> Oh? The unit fills up, with 1500 bytes, and interrupts.
No. Derek's unit is a FIFO'ed UART, and it already fills up with 128
bytes. And for the sake of sanity, let's hope it interrupts at a
(configurable) threshold considerably below those 128.
> Bytes can be coming in at one per microsec (roughly) until you get at
> least some out.
No. He wrote 921.6 kbps. Assuming he didn't have some disfiguring
typing accident, that's roughly a _bit_ per microsecond, not a byte.
100 kByte/sec is not exactly trivial to handle over a UART link --- but
it's certainly possible. That's what FIFO UARTs exist for.
Grant Edwards
> Grant Edwards wrote:
>> CBFalconer <cbfal...@yahoo.com> wrote:
>>> Derek Young wrote:
>>>>
>>>> I'm using an Arcom Viper PXA255 single board computer running
>>>> Linux, and I'm trying to receive bytes over the built-in RS-422
>>>> serial port at 921.6 kbps. The received packets are 1500 bytes
>>>> long. The UART is a 16C2850 (dual port version of the 16C850
>>>> with 128 byte FIFO).
>>>>
>>>> Everything works fine at low speeds, but if the packet rate
>>>> increases, I start to lose bytes.
>>>
>>> Your numbers indicate that you would need an interrupt roughly
>>> every 1 microsec. Not a chance.
>>
>> Huh?
>>
>> If he sets the FIFO threshold to 64, then the interrupt
>> frequency is 921600.0/10/64 == 1440Hz.
>>
>> If he sets it FIFO threshold to 96, then the interrupt
>> frequency is 921600.0/10/96 == 960Hz. 960Hz should be no
>> problem at all unless some of the other ISRs are running too
>> long.
>
> I know of UARTs that can hold 64, or even 128, results. I gather
> that that one has a 128 byte storage. Okay, now consider how long
> it takes to empty that buffer, when full. That has to be done at
> least every 921600/128 (I don't know where you got /10/96)
You divide by 10 bits/byte to convert from bits/sec to
bytes/sec. Then you divide by the interrupt threshold to
convert from bytes/sec to interrupts/sec.
> or roughly 10 khz, for about 100 uS between interrupts.
It's 921600 _bits_ per second (including start and stop).
That's 92160 bytes per second. If he configures the FIFO
threshold to be 96, then the _fastest_ he'll get interrupts is
one interrupt every 96 bytes. That means 92160/96 interrupts
per second.
> Now you don't know how many items are stored, so that implies
> a one by one discharge loop. Nobody has mentioned the CPU
> speed, but I still have grave doubts. Don't forget that
> during the discharge the FIFO is still filling up, at roughly
> 1 item per microsec.
You seem to be confusing bits and bytes.
> I would guess you are assuming the speed mentioned is a bit
> speed,
It is.
> not a per byte port speed, and the '10' is the length of the
> character, in bits. Nobody computes serial port speeds that
> way.
Yes they do. They always do.
--
Grant Edwards grante Yow! Why don't you
at ever enter and CONTESTS,
visi.com Marvin?? Don't you know
your own ZIPCODE?
Grant Edwards
> In article <47F29C7D...@yahoo.com>, CBFalconer says...
>> I would guess you are assuming the speed mentioned is a bit speed,
>> not a per byte port speed, and the '10' is the length of the
>> character, in bits. Nobody computes serial port speeds that way.
>
> I don't remember ever seeing serial port speed specified as other than
> bits/sec.
I've been doing serial port device drivers and serial
communication applications professionally for Linux and other
OSes for decades. Serial port speeds are 100% always specified in
bits/second (and they always have been).
> And geven a lack of other information 10 seems like a
> reasonable place to start for a character with start and stop
> bits included.
Exactly.
--
Grant Edwards grante Yow! .. I see TOILET
at SEATS...
visi.com
Didi
> > > This means you have 1.388 mS to fill the FIFO - plenty of time to
> > > process it.
> CBFalconer wrote:
> > ...
> > Oh? The unit fills up, with 1500 bytes, and interrupts. Bytes can
> > be coming in at one per microsec (roughly) until you get at least
> > some out.
>
> Oops, sorry, I have taken the 1500 for FIFO depth, not the 128, hence
> the wrong result.
Replying hastily while being tired has such an effect. Of course my
initial
calculation had been correct, after all these years doing that stuff I
do these things subconsciously.
Thus 128/(921600/10)=0.0013888..., or 1388.9 mS. Meaning he has 1 mS
for around 100 bytes. If linux would prevent him from doing _that_,
well, he'll
be looking for an OS which works.
Now I am even more tired - just going to bed - but I hope I put 1 and
1
together correctly this time.
And yes, they always specify serial speeds in bits per second, I have
never seen them specified in bytes per second last 20+ years.
The speed 921.6 kbpS suggests he may be using an NSC Bluetooth
module, they top at that speed, but this is only a speculation of an
almost asleep guy.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
CBFalconer
> CBFalconer says...
>
>> I would guess you are assuming the speed mentioned is a bit speed,
>> not a per byte port speed, and the '10' is the length of the
>> character, in bits. Nobody computes serial port speeds that way.
>
> I don't remember ever seeing serial port speed specified as other
> than bits/sec. And geven a lack of other information 10 seems
> like a reasonable place to start for a character with start and
> stop bits included.
Well, I habitually set my serial ports to 300, 600, 2400, 9600,
56000 etc., all measured in bytes per second.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
John Devereux
> Robert Adsett wrote:
>> CBFalconer says...
>>
>>> I would guess you are assuming the speed mentioned is a bit speed,
>>> not a per byte port speed, and the '10' is the length of the
>>> character, in bits. Nobody computes serial port speeds that way.
>>
>> I don't remember ever seeing serial port speed specified as other
>> than bits/sec. And geven a lack of other information 10 seems
>> like a reasonable place to start for a character with start and
>> stop bits included.
>
> Well, I habitually set my serial ports to 300, 600, 2400, 9600,
> 56000 etc., all measured in bytes per second.
Sounds like you have been doing it wrong for 40 years :)
Seriously, it's always bits per second. At *has* to be, since there is
a variable amount of overhead depending on parity on/off, number of
stop bits etc, optional address flags etc.
Do you think the bit rate magically adjusts itself so as to always
maintain 9600 *bytes* per second?
--
John Devereux
CBFalconer
I left the whole thing unsnipped. The time has come for me to
crave forgiveness. I think I have been afflicted with age or
something. The bits/persec crowd are absolutely correct, and I am
wrong.
So that leaves the real problem handling throughput of
approximately 1 char each 10 microsec.
David Brown
> Robert Adsett wrote:
>> CBFalconer says...
>>
>>> I would guess you are assuming the speed mentioned is a bit speed,
>>> not a per byte port speed, and the '10' is the length of the
>>> character, in bits. Nobody computes serial port speeds that way.
>> I don't remember ever seeing serial port speed specified as other
>> than bits/sec. And geven a lack of other information 10 seems
>> like a reasonable place to start for a character with start and
>> stop bits included.
>
> Well, I habitually set my serial ports to 300, 600, 2400, 9600,
> 56000 etc., all measured in bytes per second.
>
The phrase "when you're in a hole, stop digging" springs to mind. You
got this one wrong.
Communication rates are normally specified as the "bit rate", although
people often call it "baud rate" for UARTs. For UART signalling, the
"bit rate" and the "baud rate" are the same, although some physical
links (such as a modem link) will have different baud rates and bit
rates (the "baud rate" is the "symbols" per second, so if each "symbol"
codes several bits, the bit rate is higher than the baud rate).
UART, CAN, USB, Ethernet, Firewire, WLAN - almost all serial protocols I
can think of are specified in bits per second.
sprocket
>> Well, I habitually set my serial ports to 300, 600, 2400, 9600,
>> 56000 etc., all measured in bytes per second.
>
> Sounds like you have been doing it wrong for 40 years :)
I wonder how he communicated with anything... let's see, 9600 bytes/sec,
8N1... that's 96000 Baud (well, bits/sec anyway...) - a 20% mismatch
with 115200 Baud (well....)
David Brown
<snip>
> I left the whole thing unsnipped. The time has come for me to
> crave forgiveness. I think I have been afflicted with age or
> something. The bits/persec crowd are absolutely correct, and I am
> wrong.
>
I don't think you need forgiveness - you just made a mistake.
> So that leaves the real problem handling throughput of
> approximately 1 char each 10 microsec.
>
You need to handle an *average* of 1 character per 10 us. But the cost
of handling each character is peanuts - even if the UART is on a slow
bus, you should be able to read out characters at something like 20 per
us. The cost is in the handling of the interrupt itself - context
switches, cache misses, etc. That's why you use a UART with a buffer -
it takes virtually the same time to read 128 bytes out the buffer during
one interrupt, as to read 1 byte from the buffer during the interrupt.
So if you've set your UART to give an interrupt every 100 characters,
you get an interrupt every ms and read out a block of 100 characters at
a time.
John Devereux
Ignacio G.T.
No, that's typical of RTOS (like VxWorks), and only if the BSP (or
equivalent) is correctly implemented.
Grant Edwards
> Robert Adsett wrote:
>> CBFalconer says...
>>
>>> I would guess you are assuming the speed mentioned is a bit speed,
>>> not a per byte port speed, and the '10' is the length of the
>>> character, in bits. Nobody computes serial port speeds that way.
>>
>> I don't remember ever seeing serial port speed specified as other
>> than bits/sec. And geven a lack of other information 10 seems
>> like a reasonable place to start for a character with start and
>> stop bits included.
>
> Well, I habitually set my serial ports to 300, 600, 2400, 9600,
> 56000 etc., all measured in bytes per second.
Those numbers are bits per second.
--
Grant Edwards grante Yow! MERYL STREEP is my
at obstetrician!
visi.com
Grant Edwards
> I left the whole thing unsnipped. The time has come for me to
> crave forgiveness.
No worries. :)
> So that leaves the real problem handling throughput of
> approximately 1 char each 10 microsec.
That's where a large FIFO becomes important. Using Linux on an
XScale (which, IIRC, is is what the OP is using), I've done up
to 460K baud without problems. But, that was using a UART with
a 1K byte rx FIFO. That UART also allowed 32-bit wide accesses
to the tx/rx FIFOs so that you could transfer 4 bytes per bus
cycle.
With a 128 byte FIFO and byte-wide access, the timing
constraints are quite a bit tighter, but I think it should be
doable if you carefully vet the other drivers that are running
on the system.
--
Grant Edwards grante Yow! PARDON me, am I
at speaking ENGLISH?
visi.com
CBFalconer
That depends on your CPU speed. Within the interrupt, you have to
handle something like:
REPEAT
test for more in FIFO
take one, stuff in buffer, while checking for buffer full.
test for overflow or other errors.
if any, call appropriate handler
UNTIL FIFO empty
clear interrupt system
rearm interrupt
exit
Note that some operations will require several accesses to the
UART. Those will eat up time. They will be much slower than
on-chip memory access.
Derek Young
>
>> So that leaves the real problem handling throughput of
>> approximately 1 char each 10 microsec.
>
> That's where a large FIFO becomes important. Using Linux on an
> XScale (which, IIRC, is is what the OP is using), I've done up
> to 460K baud without problems. But, that was using a UART with
> a 1K byte rx FIFO. That UART also allowed 32-bit wide accesses
> to the tx/rx FIFOs so that you could transfer 4 bytes per bus
> cycle.
>
> With a 128 byte FIFO and byte-wide access, the timing
> constraints are quite a bit tighter, but I think it should be
> doable if you carefully vet the other drivers that are running
> on the system.
>
Unfortunately, I need to rely on drivers written by Arcom. I've sent
some questions to their tech support, but am still waiting for a reply.
I was thinking... at 921.6 kbps (8/N/1 -> 92160 bytes/sec), if the FIFO
interrupt level is set at:
128 bytes: 720 interrupts/sec (1.4 ms/int), 10.8 us allowed for the ISR
to respond and empty the FIFO
64 bytes: 1440 interrupts/sec (694 us/int), ~700 us for the ISR to
respond/finish
(I'm still trying to look through the driver code to figure out where
the interrupt level is set.)
The XScale CPU I'm using runs at 400 MHz. (I've forgotten who asked,
but it's communicating to with a TSM320F2812 DSP.) Hardware flow
control is not an option because it's not implemented in the Arcom hardware.
Do these interrupt frequencies sound reasonable for a non-realtime OS,
or is it hopeless as some of my coworkers here have suggested?
BTW, I'm going to give the guy who picked out this particular
hardware/software combo a really hard time. :P
Derek
Grant Edwards
>>> So that leaves the real problem handling throughput of
>>> approximately 1 char each 10 microsec.
>>
>> You need to handle an *average* of 1 character per 10 us. But
>> the cost of handling each character is peanuts - even if the
>> UART is on a slow bus, you should be able to read out
>> characters at something like 20 per us. The cost is in the
>> handling of the interrupt itself - context switches, cache
>> misses, etc. That's why you use a UART with a buffer - it
>> takes virtually the same time to read 128 bytes out the buffer
>> during one interrupt, as to read 1 byte from the buffer during
>> the interrupt. So if you've set your UART to give an interrupt
>> every 100 characters, you get an interrupt every ms and read
>> out a block of 100 characters at a time.
>
> That depends on your CPU speed.
True. The OP is running an XScale with Linux, so I'd guess he's
running at a couple hundred MHz.
> Within the interrupt, you have to
> handle something like:
>
> REPEAT
> test for more in FIFO
> take one, stuff in buffer, while checking for buffer full.
> test for overflow or other errors.
> if any, call appropriate handler
> UNTIL FIFO empty
> clear interrupt system
> rearm interrupt
> exit
>
> Note that some operations will require several accesses to the
> UART. Those will eat up time. They will be much slower than
> on-chip memory access.
People have been supporting 921K bps serial links for ages. You
do have to pay attention to what you're doing, but it's really
not that hard with a sufficiently large FIFO. However, IMO a
128 FIFO is getting close to being insufficiently large. I
wouldn't want to try to support it on a Linux system with
interrupt latencies imposed by a bunch of randomly chosen
device drivers. If it's an embedded system and you've got
control over what other ISRs are running, it should be doable.
--
Grant Edwards grante Yow! I would like to
at urinate in an OVULAR,
visi.com porcelain pool --
sprocket
> People have been supporting 921K bps serial links for ages. You
> do have to pay attention to what you're doing, but it's really
> not that hard with a sufficiently large FIFO. However, IMO a
> 128 FIFO is getting close to being insufficiently large.
If the board has USB, he could interpose a serial-to-USB converter- the
FTD2232 from FTDI has a 384 byte receive buffer, which should get him
down to 4ms or so per interrupt.
Derek Young
> If the board has USB, he could interpose a serial-to-USB converter- the
> FTD2232 from FTDI has a 384 byte receive buffer, which should get him
> down to 4ms or so per interrupt.
>
That's a really good suggestion. During early development on a
Windows/Labview machine, I used a Quatech RS-422 to USB2.0 converter
(with a 2K buffer) to get over this same problem. But in the current
hardware, there's not a lot of room for an adapter, and I'm worried
about getting a working driver for this particular flavor of Linux.
It took a couple of calls to Quatech to get their box working in
Windows. It was initially randomly duplicating bytes, so I would get
packets that were longer than expected!
Derek
David Brown
I've got a board that uses one of these devices, with a ColdFire running
at 150 MHz. I run the UART at about 2.5 Mbps (250 KB per second, if you
prefer :-). I'm not running Linux, but there are plenty of other
interrupts going on at rates of at least several kHz.
Grant Edwards
>>> So that leaves the real problem handling throughput of
>>> approximately 1 char each 10 microsec.
>>
>> That's where a large FIFO becomes important. Using Linux on
>> an XScale (which, IIRC, is is what the OP is using), I've done
>> up to 460K baud without problems. But, that was using a UART
>> with a 1K byte rx FIFO. That UART also allowed 32-bit wide
>> accesses to the tx/rx FIFOs so that you could transfer 4 bytes
>> per bus cycle.
>>
>> With a 128 byte FIFO and byte-wide access, the timing
>> constraints are quite a bit tighter, but I think it should be
>> doable if you carefully vet the other drivers that are running
>> on the system.
>
> Unfortunately, I need to rely on drivers written by Arcom.
> I've sent some questions to their tech support, but am still
> waiting for a reply.
>
> I was thinking... at 921.6 kbps (8/N/1 -> 92160 bytes/sec), if the FIFO
> interrupt level is set at:
>
> 128 bytes: 720 interrupts/sec (1.4 ms/int), 10.8 us allowed for the ISR
> to respond and empty the FIFO
That 10 us latency requirement is probably impossible.
> 64 bytes: 1440 interrupts/sec (694 us/int), ~700 us for the ISR to
> respond/finish
That might be possible as long as you can make sure there
aren't any other ISRs running that take more than a a few tens
of microseconds.
> (I'm still trying to look through the driver code to figure out where
> the interrupt level is set.)
>
> The XScale CPU I'm using runs at 400 MHz. (I've forgotten who
> asked, but it's communicating to with a TSM320F2812 DSP.)
> Hardware flow control is not an option because it's not
> implemented in the Arcom hardware.
>
> Do these interrupt frequencies sound reasonable for a
> non-realtime OS, or is it hopeless as some of my coworkers
> here have suggested?
It's definitely pushing the limits pretty hard. With enough
time and effort you might be able to make it work but all it
would take is one other ISR that runs for more than a few
hundred microseconds and you've lost data.
Whether the current architecture is acceptible depends on a
number of questions:
1) What are the consequences of loosing data? Does somebody
die, or is there merely a retry?
2) How much schedule risk is acceptible? Is it OK if it takes
a year of hacking on the source code for a few kernel
modules and a half-dozen different device drivers to get
the overall ISR latency down?
3) How much redesign risk is acceptible? Is it OK if you work
on it for three months before proving that it can't work
and a better UART or different interface has to be chosen?
--
Grant Edwards grante Yow! I'm having BEAUTIFUL
at THOUGHTS about the INSIPID
visi.com WIVES of smug and wealthy
CORPORATE LAWYERS ...
Didi
> ....
> That depends on your CPU speed. Within the interrupt, you have to
> handle something like:
>
> REPEAT
> test for more in FIFO
> take one, stuff in buffer, while checking for buffer full.
> test for overflow or other errors.
So far OK, although it sounds more complex than it actually is - 128
bytes
will be processed within 1000 CPU cycles easily, which would be taking
all the time on a 1 MHz CPU...
> if any, call appropriate handler
You don't call any "handlers" from an IRQ service routine.
You set a flag bit somewhere to indicate what happened and let the
non-time critical code deal with it.
> UNTIL FIFO empty
> clear interrupt system
> rearm interrupt
> exit
That "rearm interrupt" is actually part of the return from interrupt
opcode
on normal processors (perhaps even on Intel?), but generally this is
how
it is typically done. The "call this or that" mistake from a handler
seems
to be also frequently done, of course.
Here is how it has to be done to keep latency really low:
begin IRQ handler:
(save registers which will be changed)
disable UART interrupt
enable CPU interrupts
empty UARTs FIFO into memory and flag error(s), if some detected
disable CPU interrupts
enable UART interrupt
(restore saved registers)
return from interrupt
end IRQ handler
This must be applied to *all* interrupt handlers in a system in order
to
work, of course. The minimum latency gets a little worse, but the
maximum latency - which is the limiting factor - is dramatically
reduced.
Grant suggests this would not be that easy to do even if it is one
person
working on it and while I tend to agree with him based on what I have
witnessed last 20+ years, I must say I have been doing things like
that routinely over these 20+years myself... :-).
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
David Brown
<snip>
> That depends on your CPU speed. Within the interrupt, you have to
> handle something like:
>
> REPEAT
> test for more in FIFO
> take one, stuff in buffer, while checking for buffer full.
> test for overflow or other errors.
> if any, call appropriate handler
> UNTIL FIFO empty
> clear interrupt system
> rearm interrupt
> exit
>
> Note that some operations will require several accesses to the
> UART. Those will eat up time. They will be much slower than
> on-chip memory access.
>
This stuff is not magic - it's standard fare for embedded developers.
You seem determined to view the problem from the worst possible angle,
and pick the worst possible solution. You do *not* have to check for
overflows or other receive errors for each byte (buffered uarts provide
summary flags, and you would normally use higher level constructs, such
as crc checks, to check correctness on a fast link). You do *not* have
to check for space in your buffer for each byte. At the start of the
ISR, you ask the UART how many bytes are in the FIFO buffer, and you
check how much space you have in the memory buffer. That tells you how
often to execute your loop.
The requirements for the read loop are so simple that in many 32-bit
microcontrollers, you can set up a DMA controller to handle it.
Derek Young
Absolutely. So, for me, the dropped bytes mean that I'm losing
approximately 3% of my data packets, worst-case. I'm going to argue
that this is okay for now. It's just data. Each packet can be
considered a retry. And I can easily tell which are bad and resync.
I don't think I have the time (or expertise, really) to mess around any
more with the Linux kernel. I'm going to suggest redesigning the
hardware in the next version to avoid using the serial link. Also going
to suggest avoid using Linux (or any OS). It's really overkill for this
application, as it turns out, quite a hassle.
Thanks everybody for all your input and advice.
Derek
Didi
> but it's communicating to with a TSM320F2812 DSP.) Hardware flow
> control is not an option because it's not implemented in the Arcom hardware.
>
> Do these interrupt frequencies sound reasonable for a non-realtime OS,
> or is it hopeless as some of my coworkers here have suggested?
The hardware can do what you are after at < 10% overhead (more like
1%).
The OS (or should we call it a inOS?) or any software can be written
in a
way to make any hardware unusable, of course.
Not long ago I used a 400 MHz MPC5200; part of what it did was to
continuously (no pauses at all) update a serial DAC at apr. 16 MbpS
and read
4 ADCs at another 16 Mbps (4 MbpS per ADC, that is, but going over
a single 16 MbpS link).
The CPU is doing it all at a fraction of its resources, and I
actually used
*no* interrupts (this was for fun/experiment). I did not try the UART
at >76800 bpS
(had no faster port at the other end), but it had plenty of margin
(and 9600 would have been lpenty for the application).
Of course all seril ports work simultaneously.
(see some of it at http://tgi-sci.com/y2demo/ ).
Now the XScale is not a PPC but even if it were 16 times slower at the
same clock rate it would still be sufficient for your 1 MbpS with
plenty
of margin. So clearly the software is the inhibiting factor.
> BTW, I'm going to give the guy who picked out this particular
> hardware/software combo a really hard time. :P
Well increasingly more people seem to fall for things like that, it
seems the popularity of words like windows and linux and being
exposed all day to colourful websites make people think everything
will
just work no matter what - which sometimes is far from being
true... :-).
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Anton Erasmus
wrote:
This can be surprisingly slow. On a recent project I used an STR9 ARM
MCU with the onboard UARTs as well as an external Exar UART.
On the Exar UART one could read the number of characters available in
the RX FIFO, on the MCU uarts one can only check for character
avaiable, or FIFO full.
So with the EXAR onr could:
read number of chars available
repeat
read char
if buffer not full stuff into buffer
until chars read.
This turned out to be 5x faster than with the onboard UARTs where one
had to check the FIFO not empty flag every time.
On a 50MHz ARM9 it took about 25us per 16 characters having to do it
the way CBFalconer described it, while it only took about 5us per 16
characters where one could read how many chars were in the Rx FIFO.
Regards
Anton Erasmus
David Brown
> CBFalconer wrote:
>> ....
>> That depends on your CPU speed. Within the interrupt, you have to
>> handle something like:
>>
>> REPEAT
>> test for more in FIFO
>> take one, stuff in buffer, while checking for buffer full.
>> test for overflow or other errors.
>
> So far OK, although it sounds more complex than it actually is - 128
> bytes
> will be processed within 1000 CPU cycles easily, which would be taking
> all the time on a 1 MHz CPU...
>
>> if any, call appropriate handler
>
> You don't call any "handlers" from an IRQ service routine.
> You set a flag bit somewhere to indicate what happened and let the
> non-time critical code deal with it.
>
In this case (a fast UART on a Linux system), you don't want to do
anything with the incoming data except buffer it - processing is done in
a different process/thread, as you suggest. But it's worth noting that
in some embedded systems, it makes a lot of sense to do more specific
handling of data during interrupt routines - interrupt handlers do not
necessarily need to be as fast as possible, only as fast as necessary.
If you have a system where you have better knowledge of the interrupts,
the response times, and the required times, then you are free to do all
the work you want during an interrupt routine.
Didi
> ...
> If you have a system where you have better knowledge of the interrupts,
> the response times, and the required times, then you are free to do all
> the work you want during an interrupt routine.
Why would you ant to do it there?
Interrupts are meant to be as short as possible and do only what
cannot
be done outside their handlers - this is fundamental to programming.
I know it can be done otherwise, and I know they do such a mess to
no direct consequences because most of the hardware nowadays
is 10x to 1000+x overkill, but why want to do it so?
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Grant Edwards
> This turned out to be 5x faster than with the onboard UARTs where one
> had to check the FIFO not empty flag every time.
> On a 50MHz ARM9 it took about 25us per 16 characters having to do it
> the way CBFalconer described it, while it only took about 5us per 16
> characters where one could read how many chars were in the Rx FIFO.
There are a lot of micro-controllers out there with horribly
designed UARTs in them. One I've fought with recently is the
in the Samsung S3C4530. Half of the features don't work at
all. Half of the stuff that does work are useless because
whoever specified/designed the UART had never actually done any
serial communications only had a vague understanding of how
things like UARTs and FIFOs are used. For example, it has
FIFOs, but there's no way to flush them. It also has "hardware
flow control", but it doesn't work in a way that can be used
with any other UART on the planet.
--
Grant Edwards grante Yow! ... the MYSTERIANS are
at in here with my CORDUROY
visi.com SOAP DISH!!
John Devereux
> David Brown wrote:
>> ...
>> If you have a system where you have better knowledge of the interrupts,
>> the response times, and the required times, then you are free to do all
>> the work you want during an interrupt routine.
>
> Why would you ant to do it there?
> Interrupts are meant to be as short as possible and do only what
> cannot
> be done outside their handlers - this is fundamental to programming.
> I know it can be done otherwise, and I know they do such a mess to
> no direct consequences because most of the hardware nowadays
> is 10x to 1000+x overkill, but why want to do it so?
>
How about decoding SLIP or similar? If you wait until the end of the
frame, you have to have double the buffer size to cope with the worst
case scenario. If decoded "inline", in the irq handler, the maximum
size is just that of the decoded data.
Also protocols like modbus need to have protocol-level decisions
(e.g. about timing) done in the ISR. It doesn't work to have a generic
"read block" performed by the ISR followed by decoding in the task
level.
(Obviously all this depends on your definition of ISR, since no doubt
it can all be done at "task level" with a good enough RTOS. But in
that case the "task" is realy just another type of ISR, isn't it?)
--
John Devereux
John Devereux
Everything with a "industry standard '550 uart" is horrible.
--
John Devereux
Didi
> How about decoding SLIP or similar? If you wait until the end of the
> frame, you have to have double the buffer size to cope with the worst
> case scenario. If decoded "inline", in the irq handler, the maximum
> size is just that of the decoded data.
Actually it takes very little more than that - a few bytes - and you
will
not need to do it in the handler. Even a 16 byte FIFO organized in
memory will allow you to do it "normally" and only queue the incoming
data into the FIFO. But OK, I can see your point. I don't know SLIP,
but I have done PPP and this is doable since you will not enter a loop
anywhere in the handler, just make it a bit branchier. Not much more
than queueing the data.
Can be a valid choice, I agree - although it should be taken only if
there is a good enough reason not to take the other one, e.g. you
do need the 16 or so bytes, or if you can squeeze the last drop of CPU
performance if you do so and you need that drop etc.
> (Obviously all this depends on your definition of ISR, since no doubt
> it can all be done at "task level" with a good enough RTOS. But in
> that case the "task" is realy just another type of ISR, isn't it?)
Well no, the "task" can have a lot worse a latency than the ISR - in
the example above, 16 times. Make that 256 times if you can afford
a 256 byte deep queue (FIFO). Then you can spend this latency on
multitasking or whatever you can use it for in the particular design.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Hans-Bernhard Bröker
> Interrupts are meant to be as short as possible and do only what
> cannot
> be done outside their handlers - this is fundamental to programming.
Of course. But sometimes "what cannot be done outside" does include
some, or even all the processing of that incoming data. Resources or
response time constraints might not allow any other approach.
For just one example, let's consider that you're running XON/XOFF flow
control on a plain old RS232 link. That would mean even an interrupt
handler that would normally just stuff each byte received by the UART
into some software FIFO, had better look at the actual character, too,
to check if it's XOFF.
Didi
> For just one example, let's consider that you're running XON/XOFF flow
> control on a plain old RS232 link. That would mean even an interrupt
> handler that would normally just stuff each byte received by the UART
> into some software FIFO, had better look at the actual character, too,
> to check if it's XOFF.
Yes, XON/XOFF processing obviosly falls in the category of things
you cannot do outside of the IRQ handler in a reasonable way.
Another example in that line, which demonstrates to a further extent
how the work within the ISR must be minimised, it related to sending
the XOFF, when your ISR sees that the FIFO is nearly full.
Generally you cannot send the XOFF from within the receive ISR
because you may have to wait almost an entire serial character time
for the UART to be able to take it - this would be about 1 mS at 9600
bpS.
The way it is done (OK, the way I do it) is to flag the fact that
XOFF is due, and make sure the transmit IRQ will be asserted as soon
as possible (i.e. after the current character has gone out or
immediately);
then, within the imminent transmit IRQ handler the flag is detected
and
the first thing which is sent - overriding the output queue and
possibly some
Tx FIFO - is a XOFF.
I believe this illustrates pretty well what I mean by saying:
> > Interrupts are meant to be as short as possible and do only what
> > cannot
> > be done outside their handlers - this is fundamental to programming.
I wish I could remember when I first did it this way - was it on a
6800
or on a 6809, I really don't know. Perhaps a 6800, I did a terminal
with
it around 1985, may be it has been then.
Not such a demand for XON/XOFF things nowadays, UARTs, however
popular still, seem to be in the "phase out" phase - which may take
a few decades, that is :-).
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Robert Adsett
Of course this assumes the UART can tell you how many characters are in
the FIFO. I don't remember any of the ones I've used having that
capability (not to suggest they don't esist, just that it's not rare for
it not to be there).
Robert
CBFalconer
> David Brown wrote:
>> ...
>> If you have a system where you have better knowledge of the
>> interrupts, the response times, and the required times, then you
>> are free to do all the work you want during an interrupt routine.
>
> Why would you ant to do it there? Interrupts are meant to be as
> short as possible and do only what cannot be done outside their
> handlers - this is fundamental to programming. I know it can be
> done otherwise, and I know they do such a mess to no direct
> consequences because most of the hardware nowadays is 10x to
> 1000+x overkill, but why want to do it so?
The ONLY reason for that attack is to preserve a maximum of cpu
time for the 'unknown' projects. If you know precisely what the
system has to do, the most efficient mechanism is desireable. It
may also make the system better partitioned. For example, in the
serial input scheme, nothing outside the interrupt system needs to
know anything about the i/o ports, etc.
CBFalconer
> Didi wrote:
>> CBFalconer wrote:
>>> ....
>>> That depends on your CPU speed. Within the interrupt, you have to
>>> handle something like:
>>>
>>> REPEAT
>>> test for more in FIFO
>>> take one, stuff in buffer, while checking for buffer full.
>>> test for overflow or other errors.
>>
>> So far OK, although it sounds more complex than it actually is -
>> 128 bytes will be processed within 1000 CPU cycles easily, which
>> would be taking all the time on a 1 MHz CPU...
>>
>>> if any, call appropriate handler
>>
>> You don't call any "handlers" from an IRQ service routine. You
>> set a flag bit somewhere to indicate what happened and let the
>> non-time critical code deal with it.
That action is a 'handler'. Bear in mind that errors need to be
tied to the appropriate point in the buffered stream.
>
> In this case (a fast UART on a Linux system), you don't want to do
> anything with the incoming data except buffer it - processing is
> done in a different process/thread, as you suggest. But it's worth
> noting that in some embedded systems, it makes a lot of sense to do
> more specific handling of data during interrupt routines - interrupt
> handlers do not necessarily need to be as fast as possible, only as
> fast as necessary. If you have a system where you have better
> knowledge of the interrupts, the response times, and the required
> times, then you are free to do all the work you want during an
> interrupt routine.
This is fine IF you have adequate processing time left after the
interrupts. You always have to keep an eye on the available
throughput for the system.
CBFalconer
> CBFalconer <cbfal...@yahoo.com> wrote:
>
... snip ...
>
>> Note that some operations will require several accesses to the
>> UART. Those will eat up time. They will be much slower than
>> on-chip memory access.
>
> People have been supporting 921K bps serial links for ages. You
> do have to pay attention to what you're doing, but it's really
> not that hard with a sufficiently large FIFO. However, IMO a
> 128 FIFO is getting close to being insufficiently large. I
> wouldn't want to try to support it on a Linux system with
> interrupt latencies imposed by a bunch of randomly chosen
> device drivers. If it's an embedded system and you've got
> control over what other ISRs are running, it should be doable.
Well, I am not familiar with the particular hardware the OP is
using, and having started out with a ridiculous misapprehension
doesn't help my reliability reputation. However, I have just been
trying to point out the sort of things to consider.
Didi
> Didi wrote:
> > David Brown wrote:
> >> ...
> >> If you have a system where you have better knowledge of the
> >> interrupts, the response times, and the required times, then you
> >> are free to do all the work you want during an interrupt routine.
> >
> > Why would you ant to do it there? Interrupts are meant to be as
> > short as possible and do only what cannot be done outside their
> > handlers - this is fundamental to programming. I know it can be
> > done otherwise, and I know they do such a mess to no direct
> > consequences because most of the hardware nowadays is 10x to
> > 1000+x overkill, but why want to do it so?
>
> The ONLY reason for that attack is to preserve a maximum of cpu
> time for the 'unknown' projects. If you know precisely what the
> system has to do, the most efficient mechanism is desireable. It
> may also make the system better partitioned. For example, in the
> serial input scheme, nothing outside the interrupt system needs to
> know anything about the i/o ports, etc.
Well, the thing is, doing it this way typically one wastes more
resources.
Let us stick to the UART example and PPP.
If you do all within the ISR, this means you will have to add
at least the following overhead for each incoming character:
-retrieve/update the current state (flag $7e seen/not etc.)
-retrieve/update the pointer where to put the character
-retrieve some CRC table pointer
-retrieve/update the CRC value itself
-save/restore some more registers needed to do the above.
If you do this on a larger block of characters (tens or hundreds),
you will do the above tens or hundreds of times less.
As usual, things must be considered on a per case basis, but
the general rule stands - do in the ISR only what you cannot do
elsewhere. If you think doing more there will save you time or effort,
think again :-).
I don't claim there can be no exceptions to this rule, of course,
but in the vast majority of cases this would be both the best and
likely the simplest way to do it (although it takes some less
straight forward/layered thinking, it is in effect the simpler way).
Mel Wilson
Particular cases can be pretty overwhelming. We have an application
where serial data comes in containing a distinguished end-of-frame
value, and some escapes that ensure that data bytes are never mistaken
for end-of-frame markers. Looking at generated code for PIC18s or
AVRs shows that:
- retrieving a state flag (e.g. in-escape/not-in-escape) is one of
the cheapest things we do -- single byte fetch from a known location
- subscripted access to a data buffer is one of the most expensive
things we do
So it makes sense to un-escape our data and detect frame boundaries
while the incoming bytes are in our hands -- in the interrupt routine.
Less time wasted on laborious address arithmetic. It helps that
processing this serial input is the critical task for this
application. There is not a more important task that would be kept
waiting.
Mel.
Ulf Samuelsson
DMA is way superior to FIFO, since you dump to memory in the background.
The AT91 (and AVR32 implementation) support a Timeout interrupt
which is triggered if NO characters arrive in a certain number of bit
periods.
What really limits the speed in Linux is the error handling.
If you want to to proper error handling, you typically have
to handle the error before the next character arrives, and this
is pretty difficult in Linux, and will severly limit the speed.
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB
David Brown
> David Brown wrote:
>> ...
>> If you have a system where you have better knowledge of the interrupts,
>> the response times, and the required times, then you are free to do all
>> the work you want during an interrupt routine.
>
> Why would you ant to do it there?
> Interrupts are meant to be as short as possible and do only what
> cannot
> be done outside their handlers - this is fundamental to programming.
> I know it can be done otherwise, and I know they do such a mess to
> no direct consequences because most of the hardware nowadays
> is 10x to 1000+x overkill, but why want to do it so?
>
No, interrupts are not "meant to be as short as possible" - they are a
feature of the processor, to be used as appropriate in the given system.
If you have an OS handling multiple threads or processes, then
normally you want your interrupts to be as short as possible. But there
are many different ways to structure the software in an embedded system,
and doing real work during interrupt routines is a perfectly good way to
do it - as long as you are aware of the issues.
Interrupts can give you many of the benefits of a multi-threading RTOS
while keeping the system as simple as possible - they let you do things
in the background. I've written systems where the communication system
is handled entirely within the interrupt routines - telegrams are
checked as they come in, handled when the packet ends, and replies sent
out again from within the interrupt routines. In fact, I've written
systems where the *entire* running program is handled by interrupts -
the "main loop" is nothing more than a "sleep()" function.
Clearly, you need to think about response times, sharing data, nested
interrupts, and many other issues with interrupts - the more work you do
during the interrupt routines, the more relevant these issues become.
But interrupt routines can give you a convenient event-response
structure that is fast and built into the hardware - why bother doing
things indirectly (interrupt routines setting flags to be read by other
threads) or using extra RTOS software if it's not actually necessary?
Didi
Yes they are. This is fundamental.
They can be misused and make lengthier - many people do it - and
up to a point this may even be reasonable.
> ...
> out again from within the interrupt routines. In fact, I've written
> systems where the *entire* running program is handled by interrupts -
> the "main loop" is nothing more than a "sleep()" function.
What advantages did this approach buy you compared to polling?
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
David Brown
>> No, interrupts are not "meant to be as short as possible"
>
> Yes they are. This is fundamental.
No, this is not "fundamental". The only thing "fundamental" in embedded
programming is that the best solution depends on the system you are
working on.
> They can be misused and make lengthier - many people do it - and
> up to a point this may even be reasonable.
>
They can be used in different ways for different purposes - just because
a particular tool is used in a way you are not familiar with, does not
make it "misuse".
>> ...
>> out again from within the interrupt routines. In fact, I've written
>> systems where the *entire* running program is handled by interrupts -
>> the "main loop" is nothing more than a "sleep()" function.
>
> What advantages did this approach buy you compared to polling?
>
The code was smaller, faster, neater, clearer, and spent more of the
time asleep.
Anton Erasmus
I agree. The worst part is that it seems that it is becoming more
prevalent. The Philips LPC2000 series has got these horrible UARTs,
which have been badly implemented as well. If one needs 8 uarts or
more, then it seems that only '550 UARTs are available these days.
It is amazing how probably the worst UART ever designed, has become
the "Industry Standard".
Regards
Anton Erasmus
Didi
> >
>
> The code was smaller, faster, neater, clearer, and spent more of the
> time asleep.
Can you point us to the two systems you are comparing one of which
is yours with the above advantages you claim?
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Didi
>
> I agree. The worst part is that it seems that it is becoming more
> prevalent. The Philips LPC2000 series has got these horrible UARTs,
> which have been badly implemented as well. If one needs 8 uarts or
> more, then it seems that only '550 UARTs are available these days.
> It is amazing how probably the worst UART ever designed, has become
> the "Industry Standard".
Freescale have on more than one Power based part a relatively new
design, the call it a PSC (programmable serial conrtoller). They have
generally more than one would ask for, 512 byte FIFOs with
programmable
request tresholds, can work as UARTs, codecs, AC97, you name it.
The 5200 costs $18 at 1000+, not a bad deal for such a good design.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
CBFalconer
>
>> No, interrupts are not "meant to be as short as possible"
>
> Yes they are. This is fundamental.
> They can be misused and make lengthier - many people do it - and
> up to a point this may even be reasonable.
>
>> ...
>> out again from within the interrupt routines. In fact, I've
>> written systems where the *entire* running program is handled by
>> interrupts - the "main loop" is nothing more than a "sleep()"
>> function.
>
> What advantages did this approach buy you compared to polling?
This is basically what the common OS does.
Please don't strip attributions from your replies.
Didi
> ...
> >> out again from within the interrupt routines. In fact, I've
> >> written systems where the *entire* running program is handled by
> >> interrupts - the "main loop" is nothing more than a "sleep()"
> >> function.
> >
> > What advantages did this approach buy you compared to polling?
>
> This is basically what the common OS does.
So the common OS stays in a sleep loop and does the bulk of its work
while in an ISR. I suggest you stick to your anti-top posting
campain... :-).
(Hopefully you appreciate the smiley, I know you have valuable
experience,
it just does not seem to be in processing interrupts or serial
interfaces).
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
CBFalconer
> CBFalconer wrote:
>> Didi wrote:
>>> David Brown wrote:
>> ...
>>>> out again from within the interrupt routines. In fact, I've
>>>> written systems where the *entire* running program is handled
>>>> by interrupts - the "main loop" is nothing more than a "sleep()"
>>>> function.
>>>
>>> What advantages did this approach buy you compared to polling?
>>
>> This is basically what the common OS does.
>
> So the common OS stays in a sleep loop and does the bulk of its
> work while in an ISR. I suggest you stick to your anti-top
> posting campain... :-).
>
> (Hopefully you appreciate the smiley, I know you have valuable
> experience, it just does not seem to be in processing
> interrupts or serial interfaces).
Except much of it has been. An OS runs until something, usually an
interrupt, occurs and demands that the current process be changed
(possibly for time expiration). Then it does some heavy work to
change the visible memory and other things, including code
executed, and resumes the new process. This all has to be
carefully co-ordinated with such beasts as interrupt driven serial
ports. The present generation of multi-processor chips complicate
this again.
Note the OS is never in any sleep loop. It is just a set of
functions awaiting calling from the running process. Some things
can't be called from there, and need to be prevented, either by
traps or by refrainment.
I restored the attributions.
John Devereux
Yep - also the Sharp ARMs (LH79520 etc) and Analog devices ADUC7k
series ARMs. All the ones I work with, basically :(
--
John Devereux
John Devereux
>> >Everything with a "industry standard '550 uart" is horrible.
>>
>> I agree. The worst part is that it seems that it is becoming more
>> prevalent. The Philips LPC2000 series has got these horrible UARTs,
>> which have been badly implemented as well. If one needs 8 uarts or
>> more, then it seems that only '550 UARTs are available these days.
>> It is amazing how probably the worst UART ever designed, has become
>> the "Industry Standard".
>
> Freescale have on more than one Power based part a relatively new
> design, the call it a PSC (programmable serial conrtoller). They have
> generally more than one would ask for, 512 byte FIFOs with
> programmable
> request tresholds, can work as UARTs, codecs, AC97, you name it.
> The 5200 costs $18 at 1000+, not a bad deal for such a good design.
>
> Dimiter
Dimiter,
I appreciate your contributions.
And I am not going to get drawn into an argument about it.
But for the record: your insistence on destroying the "threading
model" of these posts is a real PITA...
--
John Devereux
David Brown
>>> What advantages did this approach buy you compared to polling?
>>>
>> The code was smaller, faster, neater, clearer, and spent more of the
>> time asleep.
>
> Can you point us to the two systems you are comparing one of which
> is yours with the above advantages you claim?
>
Polling code
============
main.c
------
extern volatile uint8_t doSomethingFlag;
void main(void) {
while (true) {
sleep();
if (doSomethingFlag) {
doSomethingFlag = false;
doSomething()
};
}
}
interrupt.c
-----------
volatile uint8_t doSomethingFlag;
void interrupt(void) {
getData();
if (ready()) {
doSomethingFlag = true;
wakeup();
}
}
Work done during interrupts code
================================
main.c
------
void main(void) {
while (true) sleep();
}
interrupt.c
-----------
void interrupt(void) {
getData();
if (ready()) {
// Re-enable interrupts if required
doSomething();
}
}
Does it make sense now? The "doSomething()" function is also much
simpler in the second version, since you don't have issues with locking
or synchronising data (such as UART buffers) shared between the main
loop and the interrupt function. If "doSomething()" takes a long time,
then it's easy to enable interrupts while it runs.
This is really nothing more than standard multi-threaded event-driven
code - it's just that the interrupt "thread" is "woken" directly by the
interrupt.
Since we are talking about Linux, it's worth noting that this second
structure is *exactly* the way interrupts used to be handled in Linux.
Modern kernels use the first version. The reasons for the changes are
mainly scalability to SMP, scheduling issues under varying loads, making
the kernel pre-emptable, and splitting the context for the critical
interrupt code (which must be run by the kernel) and the "doSomething",
which can often be done in user mode. If these issues don't apply -
which is the case in most small embedded systems - then the second
structure is often a better choice.
Didi
> ...
>
> Dimiter,
>
> I appreciate your contributions.
>
> And I am not going to get drawn into an argument about it.
>
> But for the record: your insistence on destroying the "threading
> model" of these posts is a real PITA...
>
OK, I'll try something else - like in this message, to provide a
pointer
to the complete context. If the link does not work, it will not be my
fault, and I will have indicated there is a complete context which may
apply.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
In reply to: http://groups.google.com/group/comp.arch.embedded/msg/15f18b9fa67351dd?dmode=source
David Brown
> John Devereux wrote:
>> ...
>>
>> Dimiter,
>>
>> I appreciate your contributions.
>>
>> And I am not going to get drawn into an argument about it.
>>
>> But for the record: your insistence on destroying the "threading
>> model" of these posts is a real PITA...
>>
>
> OK, I'll try something else - like in this message, to provide a
> pointer
> to the complete context. If the link does not work, it will not be my
> fault, and I will have indicated there is a complete context which may
> apply.
>
You don't have to add a link to the complete context in a Usenet post
(note that the google link is a link to an archive page - Usenet posts
do not have URLs). Just snip the parts of the post that are not of
interest in your reply, ensure that the attributions at the top of the
post are intact (for levels that are not snipped away completely), and
add your comments to the middle or bottom of the post as appropriate.
Then we can go back to disagreeing about interrupts and program
structure :-)
Albert van der Horst
Didi <d...@tgi-sci.com> wrote:
>CBFalconer wrote:
>> ...
>> >> out again from within the interrupt routines. In fact, I've
>> >> written systems where the *entire* running program is handled by
>> >> interrupts - the "main loop" is nothing more than a "sleep()"
>> >> function.
>> >
>> > What advantages did this approach buy you compared to polling?
>>
>> This is basically what the common OS does.
>
>So the common OS stays in a sleep loop and does the bulk of its work
>while in an ISR. I suggest you stick to your anti-top posting
>campain... :-).
>(Hopefully you appreciate the smiley, I know you have valuable
>experience,
>it just does not seem to be in processing interrupts or serial
>interfaces).
I've programmed the delay line software of ESO telescope array in
Paranal Chile. 1000 interrupts per second, with a mirror that had to
be at the correct nanometer at the correct microsecond. (14 nm RMS)
Does that count as experience?
Pre-emptible multiple interrupt levels were essential (Vxworks).
network < disks < motor < mirror
The system spent a considerable part of its time (>10%) in the highest
priority ISR.
There was a considerable calculation in f.p. needed
at the highest interrupt level, the reaction from the system to
actual atmospheric fluctuations. At this point a simulation of
the behaviour of the cart was taken into account, hence all the
f.p. (in double precision! 80 meter words of nanometers.
(On the nanometer scale carbon fiber looks like caoutchouc.)
This had to be ready before the command to the mirror could be
sent out. That message was under real time constraint.
That interrupt routines only should set a flag for a polling
main system is just bunk. Proponents of such dogma wouldn't
have got this system running on specs (as it did).
Maybe in simple embedded systems you get away in adhering to
the dogma. By the way: dogma it is. I have heard nothing
from proponents except:"This is the proper way to do it."
>
>Dimiter
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Michael N. Moran
> That interrupt routines only should set a flag for a polling
> main system is just bunk. Proponents of such dogma wouldn't
> have got this system running on specs (as it did).
> Maybe in simple embedded systems you get away in adhering to
> the dogma. By the way: dogma it is. I have heard nothing
> from proponents except:"This is the proper way to do it."
As frequently happens on this news group, there is a
broad spectrum encompassing the embedded experience.
We usually wind up with the simple "it depends on your
requirements."
In your case, you have what many of us would call a
hard real-time system constraint. Your design solved
the problem. Great!
Many of us, however, are not constrained so much by
the real-time aspect, but rather we must deal with
highly variable requirements across a range of products.
For us, reliability, extensibility, along with reusable
software components and architectures are the norm.
Any real-time aspects of the systems are often on a
scale that does not push the limits of the available
technology. The use of an RTOS and thread priorities
are sufficient to meet our timing constraints.
I suspect that Didi falls into this camp and
you do not :-)
There is no one-size-fits-all in this business.
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144 http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
"Already Gone" by Jack Tempchin (recorded by The Eagles)
The Beatles were wrong: 1 & 1 & 1 is 1
David Brown
> Albert van der Horst wrote:
>> That interrupt routines only should set a flag for a polling
>> main system is just bunk. Proponents of such dogma wouldn't
>> have got this system running on specs (as it did).
>> Maybe in simple embedded systems you get away in adhering to
>> the dogma. By the way: dogma it is. I have heard nothing
>> from proponents except:"This is the proper way to do it."
>
> As frequently happens on this news group, there is a
> broad spectrum encompassing the embedded experience.
>
> We usually wind up with the simple "it depends on your
> requirements."
>
That, I think, is precisely Albert's and my point - in this business,
there are few universal rules. That's why we object strongly to
Dimiter's claims that small, fast interrupt routines are the *only* way
to write interrupt functions.
> In your case, you have what many of us would call a
> hard real-time system constraint. Your design solved
> the problem. Great!
>
> Many of us, however, are not constrained so much by
> the real-time aspect, but rather we must deal with
> highly variable requirements across a range of products.
> For us, reliability, extensibility, along with reusable
> software components and architectures are the norm.
> Any real-time aspects of the systems are often on a
> scale that does not push the limits of the available
> technology. The use of an RTOS and thread priorities
> are sufficient to meet our timing constraints.
>
I've used "do your work in the ISR" structures precisely to make the
software simpler, more reliable, and more reusable (across similar
applications) - the smaller, faster and more predictable code is a
bonus. But of course, the best method depends on the situation.
Didi
> I've programmed the delay line software of ESO telescope array in
> Paranal Chile. 1000 interrupts per second, with a mirror that had to
> be at the correct nanometer at the correct microsecond. (14 nm RMS)
> Does that count as experience?
> The system spent a considerable part of its time (>10%) in the highest
> priority ISR.
So the rest of your system has been fine with 100mS latency (10% of 1
second).
Do you call this real time? I certainly do not.
> That interrupt routines only should set a flag for a polling
> main system is just bunk. Proponents of such dogma wouldn't
> have got this system running on specs (as it did).
You have misunderstood what I stated. Setting a flag to be processed
by a polling loop is one of a vast variety of cases. The general rule
is, again, "do in the ISR only what you cannot do reasonably
elsewhere".
(once you get unmasked you are no longer counted in an ISR, this
is just a variety of context switching).
If you think you need a 100mS long ISR, think again. This is never the
case.
If you do not need a few microseconds range latency, you can get away
with
a design like you describe - but do not call it good practice nor call
it real time.
There is little if any dogma I can fall for. I am just being practical
- you
do get that after about 1/3 of the first million lines of code you
have written.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/275c0032c1e966b3?dmode=source
John Devereux
> Albert van der Horst wrote:
>> ...
>> I've programmed the delay line software of ESO telescope array in
>> Paranal Chile. 1000 interrupts per second, with a mirror that had to
>> be at the correct nanometer at the correct microsecond. (14 nm RMS)
>> Does that count as experience?
>> ....
>> The system spent a considerable part of its time (>10%) in the highest
>> priority ISR.
>
> So the rest of your system has been fine with 100mS latency (10% of 1
> second).
> Do you call this real time? I certainly do not.
Just because 10% of 1 second is 100ms does not mean that is the
latency! Where did that come from? Why not say 10% of 1 microsecond is
100ns. Then the latency is better :) !
More likely it is something like 10% of 1/1000 seconds, or 100us. But
of course it could be anything without knowing the details.
[...]
--
John Devereux
Grant Edwards
> So the rest of your system has been fine with 100mS latency
> (10% of 1 second). Do you call this real time? I certainly do
> not.
It's real time if it meets the requirements. "Real time"
doesn't have a predefined limit of X milliseconds of interrupt
latency.
--
Grant Edwards grante Yow! Wow! Look!! A stray
at meatball!! Let's interview
visi.com it!
David Brown
> Albert van der Horst wrote:
>> ...
>> I've programmed the delay line software of ESO telescope array in
>> Paranal Chile. 1000 interrupts per second, with a mirror that had to
>> be at the correct nanometer at the correct microsecond. (14 nm RMS)
>> Does that count as experience?
>> ....
>> The system spent a considerable part of its time (>10%) in the highest
>> priority ISR.
>
> So the rest of your system has been fine with 100mS latency (10% of 1
> second).
You might want to think that one through once more. He has 1000
interrupts per second, with interrupts at that priority taking 10% of
the time. That means that each interrupt function takes about 100 us,
which is then the latency for for the next level of interrupts. That
doesn't sound too bad - I've worked with microcontrollers that have
close to 100 us overhead for interrupt processing (preserving critical
registers, handling the vectored jump, and the restoration of the
context before exit).
> Do you call this real time? I certainly do not.
>
In that case, you don't understand what "real time" means. It means his
system must react to certain events within certain timelimits. Even if
your initial misunderstanding about latencies were correct, and lower
interrupts were disabled for 100 ms at a time, the system could still be
"real time" if 100 ms reactions are good enough.
>> That interrupt routines only should set a flag for a polling
>> main system is just bunk. Proponents of such dogma wouldn't
>> have got this system running on specs (as it did).
>
> You have misunderstood what I stated. Setting a flag to be processed
> by a polling loop is one of a vast variety of cases. The general rule
> is, again, "do in the ISR only what you cannot do reasonably
> elsewhere".
This is *your* general rule - it applies to the way *you* write your
embedded systems. It also happens to apply to many other embedded
systems (including many of those I write), but it is not some sort of
law that all embedded programmers must follow. It is good enough advice
unless you have reasons for doing something different for the system in
hand.
> (once you get unmasked you are no longer counted in an ISR, this
> is just a variety of context switching).
You are changing your rule here - you've been claiming that the *only*
way to do time-consuming non-critical tasks triggered by an interrupt is
to set a flag (or similar mechanism) to be polled from the program's
main loop or other non-time-critical code. Now you are saying that it
is okay to to do work in the interrupt function as long as interrupts
are re-enabled, because you are no longer in the ISR? Well, of course I
agree with you that you can often re-enable interrupts (or some
interrupts) when doing the time-consuming part of the interrupt
response, but you are still very much within the context of the ISR, and
there are still plenty of situations (Albert's being an example) when
you want to keep all other interrupts disabled during the time-consuming
processing.
Real-time programming is about doing the time-critical processing within
the required time limits - if you can do that most simply and reliably
with long interrupt functions and no nested interrupts, then that's the
correct way to do it.
> If you think you need a 100mS long ISR, think again. This is never the
> case.
If you think you know all about every different embedded system and its
requirements, then think again - *that* is never the case.
I've written a system that spends over 90% of its time inside its
uninterruptable interrupt functions. The system works perfectly (and is
small enough that I did the cycle counting to prove it).
> If you do not need a few microseconds range latency, you can get away
> with
> a design like you describe - but do not call it good practice nor call
> it real time.
If your system needs interrupt latency to be in the range of a few
microseconds, then you've got the wrong hardware (baring a few very
specialised designs).
If the system can be shown to work well and reliably, is well coded in a
maintainable way, and is at least roughly as good and efficient as any
other design, then it is good practice - because it does exactly what is
required.
If the system responds to its needs within the time limits, then it is
real time - that's all that is required.
> There is little if any dogma I can fall for. I am just being practical
> - you
> do get that after about 1/3 of the first million lines of code you
> have written.
>
It is dogma when you can't give any explanation for your stance except
that it is a "general rule" which you always follow.
I'm not suggesting that "keep your interrupt functions short and fast"
is a bad rule - it is simply that many systems can be well designed and
well implemented without following it, and indeed some systems will be
significantly better if they ignore the "rule".
Didi
>
>
> Just because 10% of 1 second is 100ms does not mean that is the
> latency! Where did that come from? Why not say 10% of 1 microsecond is
> 100ns. Then the latency is better :) !
>
> More likely it is something like 10% of 1/1000 seconds, or 100us. But
> of course it could be anything without knowing the details.
>
OK. 100 uS is a huge latency nowadays as well.
And since he has at least one more interrupt, make this 200 uS. Still
worse.
This argument is pointless as long as we take for granted, that doing
work
in the ISR other than the work which must be done there is easier. It
is not.
It just indicates misguided thinking in the planning phase.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/a76377868ffe9aa4?dmode=source
Didi
> On 2008-04-06, Didi <d...@tgi-sci.com> wrote:
>
> > So the rest of your system has been fine with 100mS latency
> > (10% of 1 second). Do you call this real time? I certainly do
> > not.
>
> It's real time if it meets the requirements. "Real time"
> doesn't have a predefined limit of X milliseconds of interrupt
> latency.
I agree, I should have written "low latency" rather than "real time".
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/7281c5e0556d7fc0?dmode=source
Ulf Samuelsson
> I agree. The worst part is that it seems that it is becoming more
> prevalent. The Philips LPC2000 series has got these horrible UARTs,
> which have been badly implemented as well. If one needs 8 uarts or
> more, then it seems that only '550 UARTs are available these days.
> It is amazing how probably the worst UART ever designed, has become
> the "Industry Standard".
>
Then you did not try the SAM7/9/AVR32 UARTs...
Atmel wins many designs on the superior UARTs.
I had one 700ku/year design which was won solely
on one of the UART features.
I think they can be improved in many ways, but they
are still quite good.
David Brown
> John Devereux wrote:
>>
>> Just because 10% of 1 second is 100ms does not mean that is the
>> latency! Where did that come from? Why not say 10% of 1 microsecond is
>> 100ns. Then the latency is better :) !
>>
>> More likely it is something like 10% of 1/1000 seconds, or 100us. But
>> of course it could be anything without knowing the details.
>>
We *do* know the details - he said the interrupt in question was at 1000
times per second - so 100us is correct.
>
> OK. 100 uS is a huge latency nowadays as well.
It's only a "huge" latency if that is relevant in the system in
question. Unless you actually know the needs of his system (which
clearly does *not* need faster than 100us latency for other interrupts),
your statement is as absurd as claiming "8 MHz is terribly slow
nowadays" or "4K flash is tiny nowadays". I know that some people build
embedded systems based around processors at several hundred MHz - it
would apparently surprise you to learn that other people sometimes base
them around processors at a few MHz, and may be perfectly happy with
millisecond timings (and it's still "real time").
> And since he has at least one more interrupt, make this 200 uS. Still
> worse.
>
These numbers, of course, are totally fabricated just so that you can
pretend the latencies are twice as high as his system description
indicated. And even if the interrupt functions took 200 us - so what?
> This argument is pointless as long as we take for granted, that doing
> work
> in the ISR other than the work which must be done there is easier. It
> is not.
Those of us who write a variety of embedded systems, using a variety of
structures according to the needs of the system in question, are
perfectly aware that doing more work in an ISR can sometimes be the best
solution. We don't take anything for granted - we *think* about the
problem, and the best way to design the software. The only one taking
anything for granted here is you in your sweeping assumptions that a
particular design choice is ideal in all circumstances.
> It just indicates misguided thinking in the planning phase.
>
No, it's an indication of *thinking* in the planning phase, rather than
trying to cram the problem into a single model.
Grant Edwards
> OK. 100 uS is a huge latency nowadays as well.
It's certainly not huge on some of the platforms I work with
(where the CPU clock frequency is in KHz rather than MHz).
Even if it is "huge", there aren't any stone tablets handed
down form God that say huge is bad. If the system requirements
can tolerate interrupt latencies of hundreds of microseconds,
then what's the problem?
> And since he has at least one more interrupt, make this 200
> uS. Still worse.
I don't see how having multiple interrupts makes the latency a
sum of the ISR lengths...
> This argument is pointless as long as we take for granted,
> that doing work in the ISR other than the work which must be
> done there is easier. It is not.
Sometimes it is. If it means you can eliminate a foreground
task and the associated synchronization mechanisms, then it
almost certainly easier to just do the work in the ISR.
> It just indicates misguided thinking in the planning phase.
Apparenty the defintion of "bad" and "misguided" is anybody who
does things differently than you do.
--
Grant
David Brown
> Grant Edwards wrote:
>> On 2008-04-06, Didi <d...@tgi-sci.com> wrote:
>>
>>> So the rest of your system has been fine with 100mS latency
>>> (10% of 1 second). Do you call this real time? I certainly do
>>> not.
>> It's real time if it meets the requirements. "Real time"
>> doesn't have a predefined limit of X milliseconds of interrupt
>> latency.
>
> I agree, I should have written "low latency" rather than "real time".
>
"Low latency" is a relative term. A system that reacts to user input
within 50 ms is "low latency". A system that handles postal deliveries
that reacts within 50 minutes may be "low latency". A gigabit Ethernet
switch needs to identify packets within 500 ns to be "low latency".
Were all your millions of lines of code written for just the one
project? Because you seem to be having difficulty appreciating the
breadth of possible embedded systems, and how their requirements may
vary enormously.
Didi
>
> "Low latency" is a relative term.
It is, relative to the current state of technology. Readers of this
newsgroup are assumed to be aware of it.
> Were all your millions of lines of code written for just the one
> project?
No. You can see some of my projects at
http://tgi-sci.com/dsv/dsvpex.htm . Then take into account the fact
that "the 1 project" contains 7 processor designs so far - two of
them running DPS.
And there you will not see some which are too old - from the 1 MHz
6809 and 6800 times, some of which did latency related miracles
of their own (1985 or so). These sources are not included in the
line/byte counts I quote either.
> Because you seem to be having difficulty appreciating the
> breadth of possible embedded systems, and how their requirements may
> vary enormously.
I do not have this difficulty. You seem to have a difficulty to
comprehend
the fact that being able to afford overkill resources resulting in a
working
product does not mean your practice is worth being repeated by others.
If you design a 100 tonn car which will take you places at a speed and
cost you accept you may have solved your immediate problem, but
not many people would be well advised to repeat your design.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/c1ba1b61c78d2628?dmode=source
CBFalconer
> Didi wrote:
>
>
>> Do you call this real time? I certainly do not.
>
> In that case, you don't understand what "real time" means. It
> means his system must react to certain events within certain
> timelimits. Even if your initial misunderstanding about
> latencies were correct, and lower interrupts were disabled for
> 100 ms at a time, the system could still be "real time" if 100
> ms reactions are good enough.
It's even simpler than that. If the requirement is that an
external signal S be replied to with suitable controlling
adjustments within T seconds is met within that T seconds
REGARDLESS of what else is going on, you have met the requirement
for a real time system. If that timing constraint can ever be
missed, you have failed miserably.
'real-time' <> 'time-share'.
David Brown
> David Brown wrote:
>> "Low latency" is a relative term.
>
> It is, relative to the current state of technology. Readers of this
> newsgroup are assumed to be aware of it.
>
I think you are looking at a very narrow view of the technology used in
embedded systems. Just because fast devices are available cheaply and
easily, does *not* mean that fast devices are appropriate for every
embedded system. When designing a new system, I choose a
microcontroller running at 150 MHz if that's what suits the system - but
I might choose one running at 1 MHz if that's a better fit.
>> Were all your millions of lines of code written for just the one
>> project?
>
> No. You can see some of my projects at
> http://tgi-sci.com/dsv/dsvpex.htm . Then take into account the fact
> that "the 1 project" contains 7 processor designs so far - two of
> them running DPS.
>
> And there you will not see some which are too old - from the 1 MHz
> 6809 and 6800 times, some of which did latency related miracles
> of their own (1985 or so). These sources are not included in the
> line/byte counts I quote either.
>
>> Because you seem to be having difficulty appreciating the
>> breadth of possible embedded systems, and how their requirements may
>> vary enormously.
>
> I do not have this difficulty. You seem to have a difficulty to
> comprehend
> the fact that being able to afford overkill resources resulting in a
> working
> product does not mean your practice is worth being repeated by others.
< Hits head repeatedly on the table...>
The whole point of picking your program structure to match the
application is that you get smaller, faster, simpler, clearer, and more
reliable code by picking the most appropriate setup for the application
in hand.
Go back and re-read that paragraph.
You have been claiming it is *always* better to use the one single
technique (minimal work in the ISR) - despite repeated examples from
various other posters of when other methods can be better, and have been
used successfully in real world projects. Spending time thinking about
the design and using an appropriate interrupt structure results in a
better program using less resources (developers' resources as well as
run-time resources) - forcing your code to use a single structure
regardless of the application can easily result in wasted resources.
> If you design a 100 tonn car which will take you places at a speed and
> cost you accept you may have solved your immediate problem, but
> not many people would be well advised to repeat your design.
>
Again - it is *your* dogma that will lead to wasted resources. I (and
everyone else still following this branch) recommend using the best
interrupt routine structure for the given application. It *cannot* be
worse (assuming a competent developer!) than sticking to a general rule
such as yours - if minimal interrupt routines are the best for the job
in hand, then that's what we'll use!
To correct your analogy - *you* say that all vehicles must have four
wheels. I say that four wheels is a good number in many cases, but that
sometimes two or six wheels is a better choice, and you should pick the
right number of wheels for a given type of vehicle.
Anton Erasmus
<u...@a-t-m-e-l.com> wrote:
>
>> I agree. The worst part is that it seems that it is becoming more
>> prevalent. The Philips LPC2000 series has got these horrible UARTs,
>> which have been badly implemented as well. If one needs 8 uarts or
>> more, then it seems that only '550 UARTs are available these days.
>> It is amazing how probably the worst UART ever designed, has become
>> the "Industry Standard".
>>
>
>Then you did not try the SAM7/9/AVR32 UARTs...
>Atmel wins many designs on the superior UARTs.
>I had one 700ku/year design which was won solely
>on one of the UART features.
>
>I think they can be improved in many ways, but they
>are still quite good.
The Atmel UARTs are quite nice, and easy to use, but they are within
a MCU. Sometimes one require an external UART which is connected
to the external I/O or memory bus. The 68332 can be used as a
peripheral only by strapping one of it's pins. This disables the MCU32
core, and makes all the internal MCU available via the address and
data bus. If the SAMs can be used in such a manner, they would be
usable as an external peripheral.
Regards
Anton Erasmus
Ulf Samuelsson
You can use the AT91CAP7 and AT91CAP9 in this manner,
but the interface is non-standard and would require an FPGA
which contains a block which will regenerate the ARM AHB
bus and you will have to design an IP block which implement
a peripheral bus to AHB master bridge.
A better way would be to use one of the UARTs as an
uplink at high speed and the rest of the UARTs as downlinks.
Then you can use the GSM 07.10 multiplexing protocol
to multiplex the downloink UARTS on the uplink UART.
You can also use SPI, since it is quite fast as well on the AT91s.
Albert van der Horst
Didi <d...@tgi-sci.com> wrote:
>Albert van der Horst wrote:
>> ...
>> I've programmed the delay line software of ESO telescope array in
>> Paranal Chile. 1000 interrupts per second, with a mirror that had to
>> be at the correct nanometer at the correct microsecond. (14 nm RMS)
>> Does that count as experience?
>> ....
>> The system spent a considerable part of its time (>10%) in the highest
>> priority ISR.
>
>So the rest of your system has been fine with 100mS latency (10% of 1
>second).
>Do you call this real time? I certainly do not.
I don't understand where you get 100 mS latency.
If I process 1000 interrupts per second and spend 30% of my
total computing budget in those interrupts, the latency is about
300 uS worst case. Other parts of the system could live with
that latency, such as the 50 motor commands given out each second.
Didi
> ...
> total computing budget in those interrupts, the latency is about
> 300 uS worst case. Other parts of the system could live with
> that latency, such as the 50 motor commands given out each second.
>
100 uS latency used to be highish - but acceptable - on 1 MHz 8 bit
systems. 300 uS was too high even back then - and is a huge
figure nowadays. Your system is definitely no teaching example to be
given in a "low latency" or "interrupt handling" context.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/626a0e4514283519?dmode=source
David Brown
> Albert van der Horst wrote:
>> ...
>> If I process 1000 interrupts per second and spend 30% of my
>> total computing budget in those interrupts, the latency is about
>> 300 uS worst case. Other parts of the system could live with
>> that latency, such as the 50 motor commands given out each second.
>>
>
> 100 uS latency used to be highish - but acceptable - on 1 MHz 8 bit
> systems. 300 uS was too high even back then - and is a huge
> figure nowadays. Your system is definitely no teaching example to be
> given in a "low latency" or "interrupt handling" context.
>
Are you *still* having trouble understanding this one? 300 uS latency
is perfectly good if that's what works in your system.
It's quite simple, really. In this guy's project, he has certain
actions that occur 1000 times per second, and must be handled as fast as
possible - new data must be acted upon with a few hundred uS. Other
events can be delayed for perhaps several ms without a problem. So he
has a timer running at 1000 Hz, and does the high priority work then.
This work is higher priority than any other interrupts in the system, so
the work is done in the interrupt handler.
It's a good example of doing the right work, in the right place, at the
right time, and of getting your priorities right for the job in hand.
Didi
> Didi wrote:
> > 100 uS latency used to be highish - but acceptable - on 1 MHz 8 bit
> > systems. 300 uS was too high even back then - and is a huge
> > figure nowadays. Your system is definitely no teaching example to be
> > given in a "low latency" or "interrupt handling" context.
> >
>
> Are you *still* having trouble understanding this one? 300 uS latency
> is perfectly good if that's what works in your system.
if you think *I* am the one having trouble understanding this, think
again.
> It's a good example of doing the right work, in the right place, at the
> right time, and of getting your priorities right for the job in hand.
That it may well be. But it is not an example on how low latency
and interrupt handler programming is best done - any trouble getting
that?
If you think 300 uS latency is "low" and maintain it, well, I'll
begin feeling like trying to explain colours to a blind man - which I
don't
think is the case, you seem unwilling rather than unable to see.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/a6c5d0849777dc0c?dmode=source
David Brown
> David Brown wrote:
>> Didi wrote:
>>> .....
>>> 100 uS latency used to be highish - but acceptable - on 1 MHz 8 bit
>>> systems. 300 uS was too high even back then - and is a huge
>>> figure nowadays. Your system is definitely no teaching example to be
>>> given in a "low latency" or "interrupt handling" context.
>>>
>> Are you *still* having trouble understanding this one? 300 uS latency
>> is perfectly good if that's what works in your system.
>
> if you think *I* am the one having trouble understanding this, think
> again.
>
Are there others in this thread? There are no doubt other embedded
developers who think that *their* way is the *only* way to structure
interrupts. Most of us, I hope, think that the choice depends on the
task in hand.
>> It's a good example of doing the right work, in the right place, at the
>> right time, and of getting your priorities right for the job in hand.
>
> That it may well be. But it is not an example on how low latency
> and interrupt handler programming is best done - any trouble getting
> that?
> If you think 300 uS latency is "low" and maintain it, well, I'll
> begin feeling like trying to explain colours to a blind man - which I
> don't
> think is the case, you seem unwilling rather than unable to see.
>
Exactly *who* has been describing 300 us as "low latency" in some sort
of mythical absolute terms? I (and Albert) understand that for this
project, 300 us is a perfectly acceptable latency for this project. I
would never try to put some sort of figure on a phrase such as "low
latency", because it is meaningless without context. As has been
explained to you before, "low latency" for postal deliveries and "low
latency" for gigabit Ethernet are totally different things - arguing
absolute latencies is like arguing about the length of a piece of string.
Secondly, and again you seem to be the only one having trouble here, is
that Albert's system has very fast and low jitter timing for the
time-critical tasks that he is interested in. The latencies between his
1000 Hz timer interrupt and his system acting are probably less than a
microsecond. The 300 us potential latency is for non-critical, low
priority events.
Thus this *is* a good example of a way to get your high priority events
handled quickly and with low latency and low jitter.
Didi
whatever you say. I give up. If you don't get what I have been
saying so far there are little if any chances you will ever get it.
No matter how many times you repeat how you can walk
instead of run if you are not in a hurry this will not make your
point valid in the context of a running competition - unless talking
paraolympics, that is. Or do you see 1 minute/100 metres as
a running achievement?....
Dimiter
David Brown
> David,
>
> whatever you say. I give up. If you don't get what I have been
> saying so far there are little if any chances you will ever get it.
>
> No matter how many times you repeat how you can walk
> instead of run if you are not in a hurry this will not make your
> point valid in the context of a running competition - unless talking
> paraolympics, that is. Or do you see 1 minute/100 metres as
> a running achievement?....
>
And no matter how many times you try to tell people that a car is the
*only* way to get from A to B, I will continue to use a bicycle, a car,
or a boat as appropriate.
And I prefer to walk to my local shop rather than run - for the purposes
of going shopping, I will "beat" anyone running there.
But as for giving up, I agree there (unless you change your mind :-)
mvh.,
David
Albert van der Horst
Didi <d...@tgi-sci.com> wrote:
>Albert van der Horst wrote:
>> ...
>> If I process 1000 interrupts per second and spend 30% of my
>> total computing budget in those interrupts, the latency is about
>> 300 uS worst case. Other parts of the system could live with
>> that latency, such as the 50 motor commands given out each second.
>>
>
>100 uS latency used to be highish - but acceptable - on 1 MHz 8 bit
>systems. 300 uS was too high even back then - and is a huge
>figure nowadays. Your system is definitely no teaching example to be
>given in a "low latency" or "interrupt handling" context.
The critical part of the computer system had about 1.5 us latency
reacting to a hardware event happening sampling the telemetry
at ns precision.
The existence of some parts with 100 us latency in the same system
sort of demonstrates the viability of prioritized interrupts.
That you judge a system by the part that can tolerate the largest
latency, and attach an absolute meaning to it, instead of looking
at specifications, demonstrates your -- lets put it nicely -- lack
of experience in certain fields.
I have never seen a requirement that a valve in a chemical plant
has to close within 300 uS, "even back then". Real time requirements
are imposed by the environment, and are not a self inflicted measure
of performance that must get tighter with the availability of more
powerful hardware.
Didi
> ...
> reacting to a hardware event happening sampling the telemetry
> at ns precision.
> The existence of some parts with 100 us latency in the same system
> sort of demonstrates the viability of prioritized interrupts.
>
> That you judge a system by the part that can tolerate the largest
> latency, and attach an absolute meaning to it, instead of looking
> at specifications, demonstrates your -- lets put it nicely -- lack
> of experience in certain fields.
I can only judge by the info you give. You mention 1.5 uS latency
for the first time in this post. This is low latency indeed, but
staying in the IRQ handler for hundreds of uS after that demonstrates
your lack of experience with multi-task low latency systems.
Just because it worked does not mean you deserve the credit, in this
case all of it goes to the CPU designer. Had you needed a second
low latency response your approach would have been useless.
I have considered your approach when I was a beginner - this is
a classic beginners mistake. I must say I did understand I was making
a mistake back then (20+ years ago) and got things right - even
as a beginner.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/883b54e17704953b?dmode=source
David Brown
> Albert van der Horst wrote:
>> ...
>> The critical part of the computer system had about 1.5 us latency
>> reacting to a hardware event happening sampling the telemetry
>> at ns precision.
>> The existence of some parts with 100 us latency in the same system
>> sort of demonstrates the viability of prioritized interrupts.
>>
>> That you judge a system by the part that can tolerate the largest
>> latency, and attach an absolute meaning to it, instead of looking
>> at specifications, demonstrates your -- lets put it nicely -- lack
>> of experience in certain fields.
>
> I can only judge by the info you give. You mention 1.5 uS latency
> for the first time in this post. This is low latency indeed, but
> staying in the IRQ handler for hundreds of uS after that demonstrates
> your lack of experience with multi-task low latency systems.
> Just because it worked does not mean you deserve the credit, in this
> case all of it goes to the CPU designer. Had you needed a second
> low latency response your approach would have been useless.
>
When you are in a hole, stop digging.
Albert made it clear from his first post that it was fast handling of
critical events that meant long latencies for non-critical events. He
didn't mention the actual figure of 1.5 us, but it was clear that the
critical events were handled as fast as necessary.
Albert's handling of interrupts demonstrates clearly that he understand
the requirements of his system, and write code that is structured
appropriately in order to handle events within the required time limits.
If he had followed your approach of doing very little during the
critical interrupt, and handling the calculations and control from a
normal OS task, then it would be much harder to guarantee the results -
task switching latencies, other interrupts (however short),
non-pre-emptable code, locks, and other possible delays could conspire
to delay the calculations that had to be done within a time limit from
the critical events. Even if time limits can still be met, the
calculations *proving* that are vastly easier when the critical work is
done during the interrupts.
If Albert had needed a second low-latency response his approach would
not have been useless - he would have had a different set of system
requirements, and have written code appropriately (perhaps enabling only
that second interrupt during the calculations - or perhaps using your
structuring if that is the right choice).
You seem to be under the misunderstanding that we (Albert, myself, and
anyone else still paying attention to this thread) are advocating always
doing all your work in interrupt functions. We are, in fact, advocating
picking the right structure for the job in hand rather than
narrow-mindedly forcing a single structure onto all programs.
> I have considered your approach when I was a beginner - this is
> a classic beginners mistake. I must say I did understand I was making
> a mistake back then (20+ years ago) and got things right - even
> as a beginner.
>
With all due respect to your experience, I find it hard to understand
why someone in this branch would pick a single structure and defend it
fanatically as the *only* way for *all* programs written by *all*
developers for *all* tasks. If you have learned anything at all over
those twenty years in embedded development, surely it must be that the
answer is always "it depends" ?
Didi
> ...
> When you are in a hole, stop digging.
So you may really want to do that.
All you have been saying so far is stating the obvious: if you
do not need speed it is OK to use fast parts to go slow because
they are inexpensive anyway.
We all know that.
> Albert made it clear from his first post that it was fast handling of
> critical events that meant long latencies for non-critical events. He
> didn't mention the actual figure of 1.5 us, but it was clear that the
> critical events were handled as fast as necessary.
He did not make clear anything - his numbers followed from 1 second
decreasing down to 1.5 uS in subsequent messages. His last post
said something about sampling at nS precision with 1.5 uS
latency...
> With all due respect to your experience, I find it hard to understand
> why someone in this branch would pick a single structure and defend it
> fanatically as the *only* way for *all* programs written by *all*
> developers for *all* tasks.
It is by far not the only way. It is just the right way to do things
when low latencies & interrupts are involved. I explained that as well
a number of times already.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/58445d37fdd4683a?dmode=source