Re: [rtl] Passing numbers from RT thread to Linux thread
I think that the best way is to use union, it's nice and fast. Stephane On Fri, Aug 17, 2001 at 03:24:36PM +0200, David Olofson wrote : On Friday 17 August 2001 01:29, Calin Culianu wrote: On Thu, 16 Aug 2001, Victor Yodaiken wrote: On Thu, Aug 16, 2001 at 04:17:48PM -0400, Calin Culianu wrote: Notice that unlike the rtf_put() function in rt-linux, the read() system call actually was well enough written to work with void *. It escapes me why the rt-linux developers chose char * as opposed to void * for their second argument to rtf_put(). All I have seen it to do to date was confuse novices. Can anyone enlighten me on this fine point? Yes. The answer is lack of thought - rtf_put was quite early and the early UNIX read was prior to the invention of void * so we didn't think about it. Actually it's pure aesthetics. char * works fine. Except that you have to do an explicit typecast to keep the C compiler from warning and the C++ compiler from refusing to compile. And you can say that it emphasizes that the third argument is number of bytes. OTOH, just as sizeof() returns the size in bytes, it makes sense if every size argument in every C API uses units. The only potential theoretical issue is if mankind ever builds a machine that runs rt-linux and that somehow has sizeof(char *) != sizeof(void *). :) You know, that's not all that unrealistic. Note that some MCUs use different memory areas (and different addressing modes) for read-only and random access data. And certain architectures (read: x86) still support obsolete and cumbersome memory models where there can be multiple, differently sized kinds of pointers in a system at the same time. Now, someone else will have to figure out how that would make a void * different from a char *. :-) In that case weird unexpected errors could occur. Hopefully on that machine the compiler will be smart enough to copy the pointers correctly anyway :). If the pointers would really be different, it's entirely possible that they one type can't be translated into the other, and possibly vice versa. (Think about near and far pointers; one can be converted into the other, but not the other way around - copying the buffer is the only way.) Uuurgh!!! I have to go and or something - too many DOS memories are coming back! ;-) //David Olofson --- Programmer, Reologica Instruments AB .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | ` http://www.linuxdj.com/maia -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-- [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/ -- Stéphane LIST -- [EMAIL PROTECTED] Alcôve, l'informatique est libre -- http://www.alcove.com/ -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
Re: [rtl] Can I call regular kernel functions?
On Fri, 17 Aug 2001, David Olofson wrote: On Friday 17 August 2001 03:34, Calin Culianu wrote: Let's say your real-time thread were (erroneously) making use of some kernel services that could potentially block. (Like, oh, writing to a Linux fifo that might not have its buffers in memory, for instance). Could such cases cause the whole system to lock? Basically our real-time thread is non-preemptible (not even by hardware-interrupts) so we would never get out of the linux kernel routines that are blocking (since no interrupts would ever make their way in to any sort of interrupt handler both in RTL and in the regular kernel). Actually, I think the exception handling would still work, and invoke the swapper - although I'd rather not try it on my system to see what happens after that... :-) Oh yes that's a good point. :) Although I imagine that once the swapper tries it's swapping magic, it will hang as the hard disk drivers will never be able to properly communicate with the hard disk (no interrupts will make their way in). Either way, you don't have a hard real time system any more. Agreed. :) //David Olofson --- Programmer, Reologica Instruments AB .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | ` http://www.linuxdj.com/maia -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-- [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/ -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
Re: [rtl] Can I call regular kernel functions?
On Fri, 17 Aug 2001, Anders Gnistrup wrote: Calin Culianu wrote: Let's say your real-time thread were (erroneously) making use of some kernel services that could potentially block. (Like, oh, writing to a Linux fifo that might not have its buffers in memory, for instance). Could such cases cause the whole system to lock? Basically our real-time thread is non-preemptible (not even by hardware-interrupts) so we would never get out of the linux kernel routines that are blocking (since no interrupts would ever make their way in to any sort of interrupt handler both in RTL and in the regular kernel). Way are you using RTLinux for this, if it should bee non-preemptible Don't you have a pthread_wait_np call or other suspend funktion??? (every RTLinux suspend funktion will preemp the CPU (and Linux) when the task is ready, if it is needed.) I was attempting to understand how rt-linux interacts with/preempts the Linux Kernel, that's all. My question was more hypothetical than real. I wanted to simply understand how/why rt-linux accomplishes it's magic. -Calin -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
Re: [rtl] Passing numbers from RT thread to Linux thread
On Saturday 18 August 2001 15:50, Calin Culianu wrote: On Fri, 17 Aug 2001, David Olofson wrote: [...] If the pointers would really be different, it's entirely possible that they one type can't be translated into the other, and possibly vice versa. (Think about near and far pointers; one can be converted into the other, but not the other way around - copying the buffer is the only way.) Actually, maybe I am too young to know this, but what is a far pointer? Is this a concept used with segmented memory schemes? Yes. Intel CPUs can actually still use 16:16 and 16:32 addresses, although most modern operating systems set the selector part (same registers as used for the segment part of Real Mode addresses) to fixed values. Then they play around with the memory mapping tables instead, allowing all normal code to reach all accessible memory within a linear 4 GB address space. (That is, you never have to pass the full 16+32 bit far address; the 32 bits of the short pointer are always enough.) //David Olofson --- Programmer, Reologica Instruments AB .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | ` http://www.linuxdj.com/maia -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-- [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
Re: [rtl] user space program hangs
On Saturday 18 August 2001 09:36, Herman Bruyninckx wrote: On Fri, 17 Aug 2001, Dan Peters wrote: [...] I believe it all has to do somehow with interrupting X calls. Do you have any experience with running X under rtlinux? I have work with X many times in a non RT environment and have not had these problems. Is there a better alternative to running X for doing graphical stuff under RT linux. Don't use X! Or make sure you've got a properly configured X server and a video card with a decent driver... Some work, but shouldn't by a major issue if you need RTLinux on the machine in the first place. (You don't run RTLinux on the average workstation anyway.) Unless you know exactly what your X driver is doing... The polygons-rendered-per-second race of card manufacturers makes many drivers behave _very_ unfriendly towards other processes (disabling interrupts for too long etc.) Yeah. Some of this can be fixed by configuring the server properly, though. (AFAIK, very few cases are actually hardware problems. Even this debated PCI bus stall is a driver bug - some drivers allow the card to block the bus, rather than checking the command FIFO status before writing.) //David Olofson --- Programmer, Reologica Instruments AB .- M A I A -. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | ` http://www.linuxdj.com/maia -' .- David Olofson ---. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-- [EMAIL PROTECTED] -' -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
Re: [rtl] user space program hangs
On Fri, 17 Aug 2001, Dan Peters wrote: [...] I believe it all has to do somehow with interrupting X calls. Do you have any experience with running X under rtlinux? I have work with X many times in a non RT environment and have not had these problems. Is there a better alternative to running X for doing graphical stuff under RT linux. Don't use X! Unless you know exactly what your X driver is doing... The polygons-rendered-per-second race of card manufacturers makes many drivers behave _very_ unfriendly towards other processes (disabling interrupts for too long etc.) Herman -- I decry the current tendency to seek patents on algorithms. There are better ways to earn a living than to prevent other people from making use of one's contributions to computer science. D.E. Knuth, TAoCP 3 -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
Re: [rtl] Examples and such
Okay, it's my turn to dine on crow. Once I got back to my saved mailing list archive and re-read the documentation, I discovered that I was trying to compile the current version of rtlinux code with (the equivalent of) a makefile designed for v1-code. There are apparently a bunch of compiler switches and command-line #defines that are setup in rtl.mk.mk that are absolutely necessary for the current .h-files that weren't needed in v1. After including that file into my makefile AND using the CC defined in it instead of my own version of CC, I found that everything compiled with no problem at all. Which brings me to two points:: 1. My original, plaintive cry for help went out over two weeks ago. How come no-one answered it until now? But much more importantly 2. There are some things about what rtl.mk does that see to me to be less than ideal: A. It seems to me that turning off some warnings, e.g. -Wstrict-prototypes -fno-strict-aliasing to avoid a flood of diagnostics isn't the right way to get a clean compile because it mignt suppress diagnostics about my own code that I might have needed to see B. Implementing #defines fromt the compiler command-line -D__KERNEL__ -D__SMP__ -DCPU=586-D__RTL__ -DMODULE -D_LOOSE_KERNEL_NAMES most of which (I believe) only affect the rtl-header files and should have been in rtl.h rather than cluttering up the command-line. Further, some of these ( like __SMP__) might have no applicability to my system and at least one ( CPU=586) could be wrong for some implementations. All of this makes we wonder exactly what woes we're trying to cover up with these things. Norm - Original Message - From: Michael Barabanov [EMAIL PROTECTED] To: Norm Dresner [EMAIL PROTECTED] Cc: rtlinux, [EMAIL PROTECTED] Sent: Sunday, August 19, 2001 7:18 AM Subject: Re: [rtl] Examples and such So examples/v1api/frank doesn't compile? Did you enable CONFIG_RTL_USE_V1_API and recompile RTL? Norm Dresner ([EMAIL PROTECTED]) wrote: Okay, I confesss, I've seen these questions a hundred times. But I'm not at work and my main e-mail computer at home is down and I don't have the archive on the backup e-mail server. So I appologize for asking it yet once again. I was first trying to get an old v1-api program to compile and had no luck, just a flood of diagnostics about things being multiply-defined and/or unknown. So I took a step back and decided to try to emulate one of the examples. After that didn't improve the situation, I tried to compile just one of the examples. Below is the output and source from frank_module. The errors I get there are similar to (some of) what I see in my own program so I feel that if I can get past frank, I'll be a long way toward getting my program compiled too. All help is appreciated. BTW, the system is RH 6.2 w/2.2.18 and RTL 3.0 Norm Dresner Fellow Systems Engineer ARE/SGI Laboratory Administrator Radar Systems Engineering Department MS 520/1154 Voice: (410) 993 - 2096 Mornings in Flight Test; all-day voice-mail (410) 765 - 9235/82 Occasionally in the SGI Lab; all-day voice-mail (410) 969 - 8068 Afternoons at home; answering machine FAX: (410) 993 - 8084 On-site in Flight Test (410) 969 - 8068 Afternoons at home; call first to arrange E-Mail: Mornings: [EMAIL PROTECTED] Afternoons: [EMAIL PROTECTED] here are the errors # cc -I/usr/src/rtlinux/linux/include -I/usr/src/rtlinux-3.0/include -I/usr/sr c/rtlinux-3.0/include/compat -D__KERNEL__ -Wall -Wstrict-prototypes -fno-st rict-aliasing -D__SMP__ -pipe -fno-strength-reduce -m486 -malign-loops=2 -ma lign-jumps=2 -malign-functions=2 -DCPU=586 -g -D__RTL__ -DMODULE -D_LOOSE_KE RNEL_NAMES -O2 -I/usr/src/rtlinux/linux/include -I/usr/src/rtlinux-3.0/inclu de -I/usr/src/rtlinux-3.0/include/compat -I/usr/src/rtlinux-3.0/include/posi x -c frank_module.c -o frank_module.o In file included from frank_module.c:5: /usr/src/rtlinux-3.0/include/rtl_sched.h:89: `RTL_PTHREAD_KEYS_MAX' undeclared here (not in a function) /usr/src/rtlinux-3.0/include/rtl_sched.h: In function `pthread_getspecific': /usr/src/rtlinux-3.0/include/rtl_sched.h:216: warning: control reaches end of non-void function /usr/src/rtlinux-3.0/include/rtl_compat.h: At top level: In file included from /usr/src/rtlinux-3.0/include/rtl_sched.h:380, from frank_module.c:5: /usr/src/rtlinux-3.0/include/rtl_compat.h:41: parse error before `RTIME' /usr/src/rtlinux-3.0/include/rtl_compat.h:42: warning: function declaration isn't a prototype /usr/src/rtlinux-3.0/include/rtl_compat.h: In function `rt_task_make_periodic': /usr/src/rtlinux-3.0/include/rtl_compat.h:44: `start_time' undeclared (first use in this function) /usr/src/rtlinux-3.0/include/rtl_compat.h:44: (Each undeclared
Re: [rtl] DOUBT ABOUT PROGRAMMING RS232 USING C-lang
I'll give you some advice that will be of great help: do your own homework. On Sat, Aug 18, 2001 at 08:25:43AM -0700, madan mohan wrote: sir, i am a student and very much interested in doing programs in C language. i request YOU to help me in doing programming ON RS232 , and give a small program , how to read data from RS232 PORT AND STORING INTO A TEXT FILE OR INTO A DATABASE FILE LIKE FOXPRO ETC. SIR,IF POSSIBLE PLEASE GIVE THE LIST OF MAJOR SITES WHICH ARE GIVING A COMPLETE DESCRIPTION ABOUT RS232 PORT , AND DOING PROGRAMMING IN C-LANGUAGE ON RS232 THANKING U SIR, YOURS TRUELY, MMREDDY.B __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/ -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
Re: [rtl] DOUBT ABOUT PROGRAMMING RS232 USING C-lang
On 20 Aug 2001 10:43:52 -0600, Victor Yodaiken wrote: I'll give you some advice that will be of great help: do your own homework. And have your CAPS LOCK key fixed :-) On Sat, Aug 18, 2001 at 08:25:43AM -0700, madan mohan wrote: sir, i am a student and very much interested in doing programs in C language. i request YOU to help me in doing programming ON RS232 , and give a small program , how to read data from RS232 PORT AND STORING INTO A TEXT FILE OR INTO A DATABASE FILE LIKE FOXPRO ETC. SIR,IF POSSIBLE PLEASE GIVE THE LIST OF MAJOR SITES WHICH ARE GIVING A COMPLETE DESCRIPTION ABOUT RS232 PORT , AND DOING PROGRAMMING IN C-LANGUAGE ON RS232 THANKING U SIR, YOURS TRUELY, MMREDDY.B __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/ -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/ -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
Re[2]: [rtl] user space program hangs
Has anyone else noticed that Gnome runs an app called magicdev which can screwup realtime? It keeps polling the (IDE) CDROM and writing bogus media swapped messages to syslog then writing syslog to disk. I found if you go into control_panels-peripherals-CD_ROM and turn off all of the options it will write a config file in ~/.gnome/magicdev and then all of the CD-ROM automount polling won't happen. Jon Clifton. -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
[rtl] ANNOUNCE: xenodaptor
Hi everyone, FYI, aside of CarbonKernel (for the few who are aware of its existence :o) I've just started a new free software project (GPL) called XENODAPTOR. It is an attempt to facilitate the migration of applications based on proprietary embedded RTOS to hard real-time Linux variants such as RTAI and RTLinux. Because the proprietary RTOS have much in common, especially from the thread scheduling and synchronization standpoint, it is possible to define an abstraction layer exporting a set of generic services on top of which emulation modules of these RTOS can be built. It is roughly the same approach that was used for CarbonKernel (i.e. http://www.sourceforge.net/projects/carbonkernel/), the RTOS simulator, but based on a real (i.e. not simulated) operating system. In other words, the principal motivation behind XENODAPTOR is clearly to help application designers relying on proprietary commercial RTOSes to move as smoothly as possible to Linux-based hard real-time extensions. I will first aim at providing this abstraction layer to support API emulations of embedded real-time operating systems on top of hard real-time variants of Linux. Those emulation modules will mimic the corresponding real-time kernel APIs. For instance: +---+ | RTAI | RTLinux| +---+ | XENODAPTOR abstraction layer | | | | XENO emulation of pSOS+ | XENO emulation of VxWorks | + | pSOS+ user application | VxWorks user application | +---+ The obtained abstraction layer will rely on the underlying real-time Linux variant for hardware control and architecture-dependent system software, and provide a high-level interface to the emulation modules. This project is hosted on savannah.gnu.org/projects/xenodaptor/. As of now, there is only a roadmap and a source tree containing the initial work (non-functional) on a nanokernel standing for the abstraction layer. I expect this nanokernel to be functional on top of RTAI/x86 in a few weeks, and perhaps the first emulation module mimicking a commercial RTOS being available by mid-October or so. I haven't made up my mind on the first RTOS personality I will write an emulator for, but it surely will be among pSOS+, VxWorks, VRTX32, Chorus Micro or perhaps Virtuoso. I will try hard to write some early documentation about the nanokernel interface, but don't expect it before November. Well, that's it. Questions, suggestions and volunteers are welcome as usual. PS: I wish to thank the RTLinux and RTAI people who, by their long-term effort in making real-time Linux a viable solution, have also made this project possible, which I hope will be useful to them somehow. Best regards, Philippe. -- Philippe Gerum IDEALX S.A.S. - OSS Engineering Embedded/RT - Chief Consultant 15-17, avenue de Ségur +33 (0)1 45 51 32 46F-75007 PARIS [EMAIL PROTECTED] http://www.idealx.com/ [EMAIL PROTECTED]http://www.carbonkernel.org/ -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
Re: [rtl] Examples and such
Once I got back to my saved mailing list archive and re-read the documentation, I discovered that I was trying to compile the current version of rtlinux code with (the equivalent of) a makefile designed for v1-code. There are apparently a bunch of compiler switches and command-line #defines that are setup in rtl.mk.mk that are absolutely necessary for the current .h-files that weren't needed in v1. After including that file into my makefile AND using the CC defined in it instead of my own version of CC, I found that everything compiled with no problem at all. Yes, rtl.mk is essential for building RTLinux programs. Which brings me to two points:: 1. My original, plaintive cry for help went out over two weeks ago. How come no-one answered it until now? Can't speak for others; I've been on vacation. The compiler flags are (mostly) not specific to RTLinux. Any time you compile a Linux kernel module, you'll see something very similar. Michael. But much more importantly 2. There are some things about what rtl.mk does that see to me to be less than ideal: A. It seems to me that turning off some warnings, e.g. -Wstrict-prototypes -fno-strict-aliasing to avoid a flood of diagnostics isn't the right way to get a clean compile because it mignt suppress diagnostics about my own code that I might have needed to see B. Implementing #defines fromt the compiler command-line -D__KERNEL__ -D__SMP__ -DCPU=586-D__RTL__ -DMODULE -D_LOOSE_KERNEL_NAMES most of which (I believe) only affect the rtl-header files and should have been in rtl.h rather than cluttering up the command-line. Further, some of these ( like __SMP__) might have no applicability to my system and at least one ( CPU=586) could be wrong for some implementations. All of this makes we wonder exactly what woes we're trying to cover up with these things. Norm -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
[rtl] Help on telescope control by stepper motor
Hi, I am trying to control a telescope by using three stepper motors, I worked out the transfer function of VR two-phase excitation stepper motor but I need standard values for different types of stepper motors of the following parameters: r stator-circuit resistance L shelf inductance of each phase D viscous damping coefficient J w natural angular frequency K dimensional constant to give a measure of of the inherent damping potential motor Thanks Kostas Douslatzis
[rtl] DOUBT ABOUT PROGRAMMING RS232 USING C-lang
sir, i am a student and very much interested in doing programs in C language. i request YOU to help me in doing programming ON RS232 , and give a small program , how to read data from RS232 PORT AND STORING INTO A TEXT FILE OR INTO A DATABASE FILE LIKE FOXPRO ETC. SIR,IF POSSIBLE PLEASE GIVE THE LIST OF MAJOR SITES WHICH ARE GIVING A COMPLETE DESCRIPTION ABOUT RS232 PORT , AND DOING PROGRAMMING IN C-LANGUAGE ON RS232 THANKING U SIR, YOURS TRUELY, MMREDDY.B __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ -- [rtl] --- To unsubscribe: echo unsubscribe rtl | mail [EMAIL PROTECTED] OR echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
Re: [rtl] Examples and such
So examples/v1api/frank doesn't compile?
Did you enable CONFIG_RTL_USE_V1_API and recompile RTL?
Norm Dresner ([EMAIL PROTECTED]) wrote:
Okay, I confesss, I've seen these questions a hundred times. But I'm not at
work and my main e-mail computer at home is down and I don't have the
archive on the backup e-mail server. So I appologize for asking it yet once
again.
I was first trying to get an old v1-api program to compile and had no luck,
just a flood of diagnostics about things being multiply-defined and/or
unknown.
So I took a step back and decided to try to emulate one of the examples.
After that didn't improve the situation, I tried to compile just one of the
examples. Below is the output and source from frank_module. The errors I
get there are similar to (some of) what I see in my own program so I feel
that if I can get past frank, I'll be a long way toward getting my program
compiled too.
All help is appreciated. BTW, the system is RH 6.2 w/2.2.18 and RTL 3.0
Norm Dresner
Fellow Systems Engineer ARE/SGI Laboratory Administrator
Radar Systems Engineering Department
MS 520/1154
Voice: (410) 993 - 2096 Mornings in Flight Test; all-day voice-mail
(410) 765 - 9235/82 Occasionally in the SGI Lab; all-day voice-mail
(410) 969 - 8068 Afternoons at home; answering machine
FAX: (410) 993 - 8084 On-site in Flight Test
(410) 969 - 8068 Afternoons at home; call first to arrange
E-Mail: Mornings: [EMAIL PROTECTED]
Afternoons: [EMAIL PROTECTED]
here are the errors #
cc -I/usr/src/rtlinux/linux/include -I/usr/src/rtlinux-3.0/include -I/usr/sr
c/rtlinux-3.0/include/compat -D__KERNEL__ -Wall -Wstrict-prototypes -fno-st
rict-aliasing -D__SMP__ -pipe -fno-strength-reduce -m486 -malign-loops=2 -ma
lign-jumps=2 -malign-functions=2 -DCPU=586 -g -D__RTL__ -DMODULE -D_LOOSE_KE
RNEL_NAMES -O2 -I/usr/src/rtlinux/linux/include -I/usr/src/rtlinux-3.0/inclu
de -I/usr/src/rtlinux-3.0/include/compat -I/usr/src/rtlinux-3.0/include/posi
x -c frank_module.c -o frank_module.o
In file included from frank_module.c:5:
/usr/src/rtlinux-3.0/include/rtl_sched.h:89: `RTL_PTHREAD_KEYS_MAX'
undeclared here (not in a function)
/usr/src/rtlinux-3.0/include/rtl_sched.h: In function `pthread_getspecific':
/usr/src/rtlinux-3.0/include/rtl_sched.h:216: warning: control reaches end
of non-void function
/usr/src/rtlinux-3.0/include/rtl_compat.h: At top level:
In file included from /usr/src/rtlinux-3.0/include/rtl_sched.h:380,
from frank_module.c:5:
/usr/src/rtlinux-3.0/include/rtl_compat.h:41: parse error before `RTIME'
/usr/src/rtlinux-3.0/include/rtl_compat.h:42: warning: function declaration
isn't a prototype
/usr/src/rtlinux-3.0/include/rtl_compat.h: In function
`rt_task_make_periodic':
/usr/src/rtlinux-3.0/include/rtl_compat.h:44: `start_time' undeclared (first
use in this function)
/usr/src/rtlinux-3.0/include/rtl_compat.h:44: (Each undeclared identifier is
reported only once
/usr/src/rtlinux-3.0/include/rtl_compat.h:44: for each function it appears
in.)
/usr/src/rtlinux-3.0/include/rtl_compat.h:44: `period' undeclared (first use
in this function)
/usr/src/rtlinux-3.0/include/rtl_compat.h:44: warning: passing arg 1 of
`pthread_make_periodic_np' from incompatible pointer type
make: *** [frank_module.o] Error 1
### here's the source code #
#include linux/errno.h
#include rtl.h
#include time.h
#include rtl_sched.h
#include rtl_fifo.h
#include control.h
pthread_t tasks[2];
static char *data[] = {Frank , Zappa };
#define TASK_CONTROL_FIFO_OFFSET 4
void *thread_code(void *t)
{
int fifo = (int) t;
int taskno = fifo - 1;
struct my_msg_struct msg;
while (1) {
int ret;
int err;
ret = pthread_wait_np();
if ((err = rtf_get (taskno + TASK_CONTROL_FIFO_OFFSET, msg, sizeof(msg)))
== sizeof(msg)) {
rtl_printf(Task %d: executing the \%d\ command to task %d; period
%d\n, fifo - 1, msg.command, msg.task, msg.period);
switch (msg.command) {
case START_TASK:
pthread_make_periodic_np(pthread_self(), gethrtime(), msg.period *
1000);
break;
case STOP_TASK:
pthread_suspend_np(pthread_self());
break;
default:
rtl_printf(RTLinux task: bad command\n);
return 0;
}
}
rtf_put(fifo, data[fifo - 1], 6);
}
return 0;
}
int my_handler(unsigned int fifo)
{
struct my_msg_struct msg;
int err;
while ((err = rtf_get(COMMAND_FIFO, msg, sizeof(msg))) == sizeof(msg)) {
rtf_put (msg.task + TASK_CONTROL_FIFO_OFFSET, msg, sizeof(msg));
rtl_printf(FIFO handler: sending the \%d\ command to task %d; period
%d\n, msg.command,
msg.task, msg.period);
pthread_wakeup_np (tasks [msg.task]);
}
if (err != 0) {
return -EINVAL;
}
return 0;
}
/* #define DEBUG */
int init_module(void)
{
int c[5];
pthread_attr_t attr;
struct sched_param sched_param;
int
