Re: [Xenomai-help] Accessing the dev_private field of the RTDM driver context
Indeed. Thanks and sorry for bothering. Jeroen. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] no-brainer issue found, but not solved
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 ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] Accessing the dev_private field of the RTDM driver context
The dev_private data field of an rtdm_dev_context is defined as char[0]. How do I access such a field properly (given the fact that I defined a nonzero context_size in the rtdm_device structure during driver registration) ? E.g. trying to do: (struct my_struct *)context-dev_private = NULL; results in: error: incompatible types in assignment I _am_ able to compare though: if ((struct my_struct *)context-dev_private == NULL) ... seems to compile fine. Jeroen.
Re: [Xenomai-help] no-brainer issue found, but not solved
Title: Re: [Xenomai-help] no-brainer issue found, but not solved 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 October. I can see about posting the full code, but my supervisors dont want anything having our hardware addresses in it going out. This is an x86 board, so inb/outb are just instructions. I know about the volatile thing but that isnt my problem. Im 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.
Re: [Xenomai-help] no-brainer issue found, but not solved
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
RE: [Xenomai-help] Newbie Question : Compile vxWorks test programm
[EMAIL PROTECTED] wrote: thank you for the hint to the vxworks-skin-examples (ksrc/skins/vxworks/demos/) Unfortunately a new problem occured with these examples : Executing the Makefile, I get the following Error-Message : ppc-linux-gcc -o satch satch.c -I. -I~/xenomai-2.1-rc2/_install/include -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__ -Wall -pipe -D__XENO_UVM__ -u__xeno_skin_init -L~/xenomai-2.1-rc2/_install/lib -luvm -lnucleus -lpthread -lvxworks /opt/eldk/usr/bin/../lib/gcc-lib/ppc-linux/3.2.2/../../../../ppc-linux/bin/ld: cannot find -lvxworks collect2: ld returned 1 exit status make: *** [satch] Fehler 1 - As far as I understand, gcc is looking for library called vxworks. Unfortunately such a library is not generated by the Xenomai build process (I could not find it anywhere in the install-directory, nor in the Xenomai-directory, nor in the kernel-directory, although I configured the vxWorks-skin to be generated as a module in the kernel configuration (make menuconfig)). Having a look in the Xenomai/src/skin/vxworks-directory, there are no source files at all, in contrast to all other skins. Is this intentional, or are the sources missing ? Could you give me a hint, where I can find the vxworks library or how I can generate it. Of course I could have a look in the makefile sources, but as I am not an expert in Makefiles and autoconfiguration, this would take quite a long time. Therefore I would appreciate your help very much, even if my question should be silly. libvxworks is generated only when UVM are enabled. You need to enable building the UVM skin as a kernel module using menuconfig, and build user-space libraries for the UVM skin using the configure option --enable-uvm. -- Gilles Chanteperdrix.
