Steven Seeger wrote: > There is a awful amount of code in this project, and I should point out that > this same code did not exhibit these problems under a fusion cvs from
You code contains a wrong assumption about the execution context. Older Xenomai/fusion versions may have concealed this due to different internal design. > October. I can see about posting the full code, but my supervisors don¹t > want anything having our hardware addresses in it going out. > > This is an x86 board, so inb/outb are just instructions. Then please shrink down your scenario so that a) no proprietary code or addresses are contained AND b) only a minimum of surrounding code is used AND c) the problem (timing issues) still show up. This first of all means to replace the specific detection of deadline misses (flickering LEDs) with a generic mechanism - e.g. the latency tool. Then we can try to reproduce your problem or already find the issue in the test code. As I pointed out: mixing non-RT with RT code is feasible but requires careful design. > > I know about the volatile thing but that isn¹t my problem. I¹m having > realtime preemption issues. > > Steven > > On 2/21/06 1:20 PM, "Jeroen Van den Keybus" <[EMAIL PROTECTED]> > wrote: > >> It would be helpful if a complete code could be posted. That means, including >> the main() function, in which the task dispatching is done as well. >> >> Furthermore, be sure to declare counting variables inside waiting loops with >> the 'volatile' specifier. The compiler might optimize it away otherwise. >> >> Another, maybe dumb suggestion: how is inb() / outb() actually implemented on >> your platform ? >> >> >> Jeroen. >> >> > > > Jan
signature.asc
Description: OpenPGP digital signature