> 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
Linux serial port dropping bytes
Started by ●March 31, 2008
Reply by ●April 1, 20082008-04-01
Reply by ●April 1, 20082008-04-01
On 2008-04-01, Didi <dp@tgi-sci.com> wrote:> 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 onlyIn 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!!
Reply by ●April 1, 20082008-04-01
Grant Edwards wrote:> CBFalconer <cbfalconer@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. -- [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
Reply by ●April 1, 20082008-04-01
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. 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. -- [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
Reply by ●April 1, 20082008-04-01
CBFalconer 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.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/ CBFalconer wrote:> 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. 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. > > -- > [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
Reply by ●April 1, 20082008-04-01
In article <47F29C7D.A95916CB@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. 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 -- Posted via a free Usenet account from http://www.teranews.com
Reply by ●April 1, 20082008-04-01
CBFalconer wrote:> 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.
Reply by ●April 1, 20082008-04-01
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. -- [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
Reply by ●April 1, 20082008-04-01
On 2008-04-01, CBFalconer <cbfalconer@yahoo.com> wrote:> Grant Edwards wrote: >> CBFalconer <cbfalconer@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?
Reply by ●April 1, 20082008-04-01
On 2008-04-01, Robert Adsett <sub2@aeolusdevelopment.com> wrote:> In article <47F29C7D.A95916CB@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
