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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to