I still think that FIFO queuing of the DSRs is better than LIFO queuing, because in the absence of any DSR priority information, the best that can be done is temporal priority (ie FIFO). This prevents the case (that I'm seeing) where a lower priority ISR's DSR preempts a higher priority ISR's DSR (the priority is lost in the LIFO DSR queue).
I located the kernel versions of the DSR code (kernel/current/src/intr/intr.cxx), and discovered that there are two implementations for the DSR handling (CYGIMP_KERNEL_INTERRUPTS_DSRS_LIST, and CYGIMP_KERNEL_INTERRUPTS_DSRS_TABLE). The default is to use the LIST, which is LIFO, but the TABLE implementation is FIFO. I switched my configuration to the TABLE implementation, and my code works. So a second reason to use FIFO for the DSR LIST implementation is to match the behavior of the TABLE implementation. Jay -----Original Message----- From: Grant Edwards [mailto:[EMAIL PROTECTED] Sent: Friday, January 13, 2006 3:42 PM To: [email protected] Subject: [ECOS] Re: DSR Scheduling Problem > The test begins by transmitting data, which is looped back to the receiver. > It starts out with: > TX ISR -> TX DSR > TX ISR -> TX DSR > ... > TX-ISR -> TX DSR > > Then I get the RX ISR during the TX DSR, which just schedules > the RX DSR. However, the RX DSR does not run until 39 ms > later, And TX DSRs are running during that entire 38ms? > resulting in an overrun error. During this time period, the > TX ISR and TX DSR continue their work transmitting the > remaining data. After all of the data has been sent, THEN the > RX DSR runs. It appears you don't have enough CPU time to run all of the DSRs you want in the alloted time. > Looking at the code post_dsr() and call_dsr() in > hal/common/current/src/drv_api.c, I noticed that the DSRs are > queued at the head of the list, and dequeued also from the > head of the list. Yup. DSRs are scheduled in a LIFO manner. > This seems wrong, It seems to work for everybody else. ;) > as it can (and apparently does) cause DSRs to get delayed by > other DSRs that are queued later. Seems like it would be > better to queue them on the end of the list and dequeue them > from the head of the list, so that the DSRs would get run in > the order in which they are queued. If the DSRs that you're scheduling require 150% of the available CPU time, then something's going to fail. In your particular case, perhaps it is better to fail in manner B than in manner A. But, very few eCos users have the option of failing, so nobody put in much extra effort to make things fail in manner B rather than in manner A. Did that make sense? -- Grant Edwards grante Yow! I'm having an at EMOTIONAL OUTBURST!! But, visi.com uh, WHY is there a WAFFLE in my PAJAMA POCKET?? -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
