Re: [rtl] Installing software under RTAI
daniel sheltraw wrote: > > Hello RTers > > I have had trouble in the past compiling/installing new software > once RTAI is installed so would someone please tell me what is > the best way (or a way) to do this. Should I remove the soft link > from /usr/src/linux to /usr/src/linux-2.2.16-ert before installing > new software? Should I boot with my vanilla 2.2.14 linux kernel > before the install? Anything else? The only think that matters is the link from /usr/src/linux -> kernel. If you are installing a new RTAI, you need to: - download new linux kernel - remove /usr/src/linux symlink - untar the new link kernel - untar the new rtai - run make patch in rtai, build/install rtai - configure/build/install your new linux kernel Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Posix vs Semaphores
Marcus Högberg wrote: > > This might be a stupid question, but anyway, here goes. > What (if any) is the difference between Mutex and Semaphores? > I'm interested because I'm writing a paper on RTLinux as an examreport > Classically semaphore can have a value (other than 1 or 0), mutexes are either on or off. Usually access to a semaphore is protected by an (internal) mutex. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] printf with floats etc.
Hi Victor, Note that there is support for named fifos in the portable fifos package distributed with RTAI. I last tested it with a RTL/2.2 kernel, but it may work with a 2.4 (there is a regression test suite for the fifos that you can try). Regards, Stuart [EMAIL PROTECTED] wrote: > > Try this: the worst limitation is that the fifo number > is hardcoded - to be fixed soon. > > -- > - > Victor Yodaiken > Finite State Machine Labs: The RTLinux Company. > www.fsmlabs.com www.rtlinux.com > > > >print_app.cName: print_app.c > Type: Plain Text (text/plain) > >print_mod.cName: print_mod.c > Type: Plain Text (text/plain) -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Changing a Threads Period?
Hi Stephen,
You can change periods. The only thing that I've fallen foul of is that
if you are in periodic clock mode, changing the period can cause you to
get erratic frames at the changeover, using oneshot solved this.
Regards, Stuart
"Stephen D. Cohen" wrote:
>
> Gang,
>
> How the heck do I change a threads period? I am currently doing
> something like this:
>
> Before infinite loop:
>
> pthread_make_periodic_np(pthread_self(), gethrtime(), period);
>
> In the infinite loop:
>
> while (1 != 2) {
> pthread_wait_np();
> ... other stuff ...
> if (fifo says to do so) {
> pthread_make_periodic_np(thread_self(), gethrtime(),
> new_period_from_fifo);
> }
> }
>
> What happens is that the process hangs on the "if fifo says so"
> pthread_make_periodic_np call (or there abouts) and never gets awoken again.
>
> What gives? Is anyone successfully changing periods on periodic
> tasks? If so, how?
>
> Steve
>
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
> --
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] 'kmalloc: size too large'
Raul wrote: > > Hi everyone > I get the following error when I try to allocate quite > a lot of memory using kmalloc: > 'kmalloc: Size (40) too large' > I was wondering how could I know the maximum available > memory in kernel space and if it is possible to > reserve more memory at boot time. > Thanks for your help > Raul > Hi Raul, I believe that 128k (32 pages) is the limit. The alternative is to use vmalloc. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] suspend + delay mechanism?
Heinz Haeberle wrote: > > > Is it possible to do an pthread_suspend_np with a delay in RT-Linux > > (3.0)? I'd like to suspend a task, but if he isn't woken up (e.g. > > lost the interrupt), I want to pop out of the suspend and poll. > > > > The easiest way I see is to use pthread_wait_np(), in a periodic > > task, and use (if possible) pthread_wakeup_np() to awaken it from > > the intr handler. But based on the man pages, it isn't explicitly > > stated that I can "pthread_wakeup_np" a thread that hasn't used > > pthread_suspend_np() to suspend itself. > that's what I am doing and it looks like it is working. > > Would really be nice to know if it just works by accident! > Hi Heinz, The more conventional way to do this with pthreads is with a condition variable, and the call pthread_cond_timedwait. In this case, your thread wakes up when either the condition is signalled or you reach a timeout. I'm not sure if this is in RTL, but I think I recall that it is (check the docs). Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Virus sent via rtl@rtlinux.org
Der Herr Hofrat wrote: > > Hi all! > > There has been a virus sent to the list, it was not in an atachment it was in > the body and it was small enough to stay below the 40K limit. I'm currently > trying to figure out where it actually came from (and why it made it to the > list) . Sorry for the mess. > > have not had that problem up to now... looking for a M$ virus scanner for linux Hi Nicholas, Does this affect Linux users or just MS users ??? Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] beginner question
Hi Norm, Possibly there is a simpler way from userspace. I think that as long as your root you can open /dev/mem and get at the kernel address space directly ?? Regards, Stuart "Dresner, Norman A." wrote: > > Todd. > > It's always seemed to me to be much safer and simpler to implement ioctl(2) > functions to get & set parameters or data blocks. > > Also consider mmap(2) to give users access to kernel data segments (always a > risky proposition which is why I favor ioctl. > > Finally, using, for example, > append="mem=125m" > I can reserve the top 5 MB of memory in a 128 MB machine and then use it as > shared memory "directly." There are techniques that allow using the same > address for these blocks in both the kernel & user-land so data structures > can contain valid pointers. > > Norman Dresner > Fellow Systems Engineer > Radar Systems Engineering Department > Electronic Systems and Sensors Segment > Northrop Grumman Corporation > Baltimore-Washington International Airport > 7323 Aviation Boulevard > Baltimore Maryland 21240 > > Voice: (410) 993 - 2096Mornings; all-day voice-mail > (410) 969 - 8068Afternoons with answering machine > FAX:(410) 993 - 8084On-site > (410) 969 - 8068Afternoons; call first to arrange > E-Mail: Mornings: [EMAIL PROTECTED] > Afternoons: [EMAIL PROTECTED] > > > -Original Message- > > From: Gearheart, Todd [SMTP:[EMAIL PROTECTED]] > > Sent: Wednesday, February 07, 2001 11:15 AM > > To: 'Stuart Hughes' > > Cc: '[EMAIL PROTECTED]' > > Subject: RE: [rtl] beginner question > > > > You can also "access" private data in kernel address space from user mode > > programs, by employing a simple trick. A user program can request access > > to > > a section of private kernel address space (via fifos, shared memory, or > > whatever). Then a kernel module can copy the requested section of the > > kernel > > private address space "needed in user space" into shared memory. Then user > > mode program can view/modify the shared memory area and signal/indicate > > the > > change(s) made. Finally the kernel module can take care of "updating" the > > changes back into the kernel private address space (from the shared memory > > area). > > > > I was able to implement a similar "swapping technique" in my simulator > > application. It allows access to ALL kernel real-time storage from the > > user > > side as well... > > > > Regards, > > Todd Gearheart > > > > -Original Message- > > From: Stuart Hughes [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, February 07, 2001 7:43 AM > > To: Stefano Picerno > > Cc: [EMAIL PROTECTED] > > Subject: Re: [rtl] beginner question > > > > > > Stefano Picerno wrote: > > > > > > If I have two different realtime modules, can I access the address space > > > of one of them from the other? > > > > > > I mean, if task A have some private data at 0x1234578, can task B read > > the > > > same data at the same address? > > > > Yes, they occupy the same kernel address space. > > > > Regards, Stuart > > -- [rtl] --- > > To unsubscribe: > > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > > echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > > --- > > For more information on Real-Time Linux see: > > http://www.rtlinux.org/rtlinux/ > > -- [rtl] --- > > To unsubscribe: > > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > > echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > > --- > > For more information on Real-Time Linux see: > > http://www.rtlinux.org/rtlinux/ -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] beginner question
Stefano Picerno wrote: > > If I have two different realtime modules, can I access the address space > of one of them from the other? > > I mean, if task A have some private data at 0x1234578, can task B read the > same data at the same address? Yes, they occupy the same kernel address space. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Upgrade Documentation?
Norm Dresner wrote: > > I'm migrating some v0.9J RT-Linux code (under RH 5.x, kernel 2.0.36) from > one project to another. I'm also trying to decide whether it's worth my > while to upgrade to RT-Linux 3.0 (assuming a concurrent upgrade in kernel). > I was wondering if there are any documents available that describe the > upgrade, i.e. how does "each" API call change, etc. > Hi Norm, if you go to: http://opensource.lineo.com/rtai.html and download the common_api-01.tar.gz link, inside you find a header file that maps the RTL posix like API to the RTAI API (which is very close to the RTL V1 API). This, and the examples in the tarball should give you a good idea how to update your code to the RTL3API. Alternatively, you can either use the RTL V1 compatibility within RTL3, or use the common API header file. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Using RTFifos with multiple writers?
Hi Norm, The fifos found in RTAI include support for named fifos, which open and return the next free fifo, it the name is not already open. This module works with either rtai or rtl and provides all the usual API calls. Regards, Stuart "Dresner, Norman A." wrote: > > How about a simple kernel module that tracks which FIFO's are in use and > reserves and returns the next one. A simple time-out on a reservation would > protect against at least some faults? > > Norman Dresner > Fellow Systems Engineer > Radar Systems Engineering Department > Electronic Systems and Sensors Segment > Northrop Grumman Corporation > Baltimore-Washington International Airport > 7323 Aviation Boulevard > Baltimore Maryland 21240 > > Voice: (410) 993 - 2096Mornings; all-day voice-mail > (410) 969 - 8068Afternoons with answering machine > FAX:(410) 993 - 8084On-site > (410) 969 - 8068Afternoons; call first to arrange > E-Mail:Mornings:[EMAIL PROTECTED] > Afternoons: [EMAIL PROTECTED] > > > -Original Message- > > From: Eric Peterson [SMTP:[EMAIL PROTECTED]] > > Sent: Thursday, December 14, 2000 6:58 PM > > To: Stephen D. Cohen > > Cc: '[EMAIL PROTECTED]' > > Subject: Re: [rtl] Using RTFifos with multiple writers? > > > > On Thu, Dec 14, 2000 at 11:37:29AM -0500, Stephen D. Cohen wrote: > > > Hi, > > > > > > David Olofson offered an excellent treatise on why multiple open of > > a > > > FIFO is a bad idea. I would like to offer a fairly simple solution. > > > > > > Simply create a block of FIFOs on the RTL side of the house. Attach > > > them all to the same handler (it gets the FIFO number when it is > > > called, but since you were planning to multi-open, it probably > > doesn't > > > matter). > > > > > Then simply have your user-mode programs try opening FIFOs until > > they > > > succeed or run out of FIFOs to try. > > > > Steve, > > > > Thanks for the suggestion - I thought a bit about doing this, but it > > doesn't scale too well (n**2). Assuming I have a unique FIFO for each > > RT-task, and one for every Linux process, the number of FIFOs starts > > getting large. > > > > David O's suggestion of a message queue seems to be a good solution - > > now > > just to find one... > > > > Regards, > > Eric > > > > -- > > God made everything out of nothing, but the nothingness shows through. > > -- Paul Valery > > > > Eric Peterson WB6PYK (805)370-3046 [EMAIL PROTECTED] HOME: > > [EMAIL PROTECTED] > > -- [rtl] --- > > To unsubscribe: > > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > > echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > > --- > > For more information on Real-Time Linux see: > > http://www.rtlinux.org/rtlinux/ > -- [rtl] --- > To unsubscribe: > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > --- > For more information on Real-Time Linux see: > http://www.rtlinux.org/rtlinux/ -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupt Jitter
[EMAIL PROTECTED] wrote: > > On Thu, Dec 14, 2000 at 10:50:33AM -0500, Victor Iannello wrote: > > Paolo, > > > > Paolo, > > > > You are confirming what we suspected--the variation in time required to > > access the timer is a symptom rather than the cause of the jitter. You > > mention three possible causes at the hardware level--bus contention, DMA > > steals, and cache disruption. We have done some experiments with the cache > > turned off that have not improved jitter. So, we are probably at the > > hardware limits of x86 board architecture. It never was designed for > > cycle-by-cycle determinism. > > You might want to try, for example, the AMD SC520 board. The combination > of board design and chip design makes all the difference sub 20us. > Does anyone know what the time cost is for a cache miss on a given executable. I realize that this will vary greatly depending on processor etc. What interests me is that a lot of the jitter problems are associate with ISA/PCI bus etc, but I'd like to know what the worst case contribution for a cache miss on an x86/ppc is. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] insmod not found
daniel sheltraw wrote: > > Hello RTers > > This isn't really an RT question but I thought I could get a quick answer > here. After a major crash I reinstalled RadHat 6.2 (needed > for RTAI CD installation) and switched to a KDE workstation-class > installation (was GNOME prior to crash). Now insmod, rmmod, ldconfig, > etc can not be found. Is this a path problem? How should I fix it? > I know this is a dumb question but there are holes in my programming skills. Hi Daniel, The workstation install didn't put any SW dev stuff on for you. Either re-install and select more packages (is they a dev workstation option ???). Alternatively, you can use rpm to install the packages by hand (but there are quite a few you'll need). Regards, Stuart. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] mbuff problem - miniRTL or upgrade problem
Hi Janet,
Maybe you forgot to insmod mbuff.o ???
Regards, Stuart
"Estabridis, Janet P" wrote:
>
> All,
> I forgot to do the "mknod ..." but now I get the message,
>
> open failed: Operation not supported by device
>
> Any words of wisdom ???
>
> Janet
>
> -Original Message-
> From: Estabridis, Janet P
> To: 'Chris Hawks '; Estabridis, Janet P
> Cc: '[EMAIL PROTECTED] '
> Sent: 12/1/00 2:50 PM
> Subject: RE: [rtl] mbuff problem - miniRTL or upgrade problem
>
> Yes, I got the old shared memory working.
>
> I'll have to check the
>
> mknod /dev/mbuff c 10 254
>
> I thought of that after I sent the message and I was already gone from
> the
> office. I'll update either later today or Monday.
>
> Thanks --
>
> Janet
>
> -Original Message-
> From: Chris Hawks
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Sent: 12/1/00 1:25 PM
> Subject: Re: [rtl] mbuff problem - miniRTL or upgrade problem
>
> ---On Fri, 1 Dec 2000 11:35:22 -0800 , Estabridis, Janet P said
>
> > Hi,
> >
> > I have a Ampro Little Board P5X running at 266MHz with 128MBytes of
> memory.
> [...]
> > 2. I have changed to miniRTLV2.3 (rtlinux 2.3 with kernel 2.2.14) to
> embed
> > my system. Now when I run my user space code to get access to the
> shared
> > memory
> > with mbuff_alloc("adData", ...) I get --
> >
> > "open failed: no such file or directory"
> >
> > I have not tried any mbuff shared memory examples on my development
> station
> > to see if this is duplicated there, but can anyone help out?
> >
> > Am I missing something from my miniRTL that I need ??
>
> Janet:
>
> Did you create /dev/mbuff??
>
> mknod /dev/mbuff c 10 254
>
> BTW: did you get the (old) shared memory working??
>
> --re: [rtl] mbuff problem - miniRTL or upgrade problem
>
> Chris
> #include
> #include
>
> [EMAIL PROTECTED]
> Christopher R. Hawks Software Engineer
> Syscon Plantstar a Division of Syscon International
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] Zentropix 2.2 CD installation problems.
Reef Morse wrote: > > Installing an RTAI system with the gdbstubs is very time-consuming. I'm > having a jolly old time (sarcasim here...) trying to get the system onto my > computer. I seem to have hardware problems independent of the software, > but one time when all was working correctly, it took over 4 HOURS for my > computer to boot due to all the "module dependencies". At some point my > IDE hardware went nuts and I've been trying this on another system. My appologies for this, the CD was shipped with debug (-g) on for the modules, as well as the kernel, on slow machines with little memory, this is a problem. Note that the errata page at http://www.zentropix.com/products/rtlcd22/notes.html explains how to fix this problem (by stripping the modules). > > Zentropix web page states that this is because of all the modules that > support gdbstubs and they offer a program to remove that support from the > modules. However, upon trying to install my system onto a 486 with 8 megs > of memory, I set up the install to run overnight and 12 hours later it was > still accessing the CD and writing to the disk. I'm pretty frustrated at > this point. Okay, to solve this boot from a rescue disk and then run the following command: strip -g /lib/modules/2.2.10-rtai/*/*.o. If you're still having problems, please mail me off the list, and I'll try to get your problems resolved. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] implementation questions
Cort Dougan wrote: > > } I've been looking over the kernel patch and the rtl module code trying > } to figure out what needs to be done for an ARM port. I've been focusing > } on the 2.4 version where the patch is concerned. I'm using rev 3 of RTL. > } > } I have some questions. > } > } A. Does the MIPS version really work? > > Yes, with a different kernel tree. We're working with the MIPS guys to > merge our changes in a way that 1) fits our needs and 2) fits general > Linux/MIPS needs. A kernel patch won't be required when we're done (just > like PowerPC). > > Short answer, use the MIPS RTLinux kernel tree (not in the distributed > patch). Hi Cort, Does this mean that RTLinux has been made part of the standard Linux kernel for PPC ??? Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] sscanf function
Hi Raul, You can't use these standard functions. Even though they are subroutines, they may need to trap to the kernel to call malloc, read etc. This will not work reliably within the realtime environment. Your best bet is to look at the kernel stdio type functions, and re-write them to be rt safe (e.g no kernel service calls that can block). Regards, Stuart Raul wrote: > > hi there > I have noticed that some of functions from the header > file stdio.h need to be renamed in order to use them > within the rtl kernel. Thus, printf() becomes > rtl_printf() and so on. But what about the rest?. I > cannot load a module that uses for instance sscanf() > and fprintf(). As far as I have seen there is no > equivalent of these functions for rtl. > Is there a way I could get around this problem? Could > I somehow load those functions on the kernel and > afterwards load my program? > thanks a lot for your help > RAul > > > Do You Yahoo!? > Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk > or your free @yahoo.ie address at http://mail.yahoo.ie > -- [rtl] --- > To unsubscribe: > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > --- > For more information on Real-Time Linux see: > http://www.rtlinux.org/rtlinux/ -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI Debugging?
Ruben Lysens wrote: > > Hi all, > > We're considering porting one of our real-time applications to RTAI. > RTAI seems to offer all the features we need, except possibly for > debugging. RTlinux, another candidate for our port, comes with a nice > debug module that allows host debugging. RTAI doesn't. Instead it refers > to a commercial product: Lineo's Embeddix[tm] RealTime. > Is that correct? Are there alternatives? Can I debug RTAI real-time > threads without buying the Embedix CD? > The debugger source is available without buying the Embedix Realtime CD, the CD is just a more convient way of getting something installed that works in a complex environment, and it includes a reference manual. The debugger uses an extended gdbstubs, and runs host target over a serial connection. It allows a concurrent debugging scope for Linux, modules and rt-modules. Note that the stub works with RTL and RTAI. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] differences over 2.2a & 3.0
Craig Ireland wrote: > > Hello, > > I have already emailed this list regarding this problem but I put down the > limited response to some trivial oversight on my part. > > I have problems running a program under rtlinux22 bu recently recompiled it > under rtlinux30 and the problem disappeared. However, another, more serious > (from my viewpoint), problem emerged. This has led me to believe that > perhaps it is not entirely my causing. > > Basically, my problem under rtlinux22 is that a thread that runs > continuously for some period ~10seconds and then halts and is deleted, > causes linux to behave erratically, and responsive only to the keyboard. ie > mouse is disabled, floppy access impossible, a crash on shutdown. this > persists until my module and rtl_sched is uninstalled. I have not disabled > any interrupts. I presume that the lines in cleanup_module of rtl_sched are > what restore the system to its normal state. > > Under rtlinux30, this doesn't occur. However, the output of my module (a > parallel port digital waveform) can waver in duration by up to 10us for a 20 > us pulse. This is far in excess of the 1us jitter of rtlinux22. The only > calls in this code are to gethrtime(), rtl_delay, and outb(). I do not > understand why there is any difference to rtlinux22. The timing of the > pulse is all internal and unrelated to the scheduler. > > I would appreciate it if somebody could point me in the direction of a > solution, or if anybody would be willing to look at the code (it is very > short). Could it be that I've set up RTLinux poorly? > Hi Craig, The jitter you get is well within what would be expected. I don't understand why you're old setup gave +/- 1usec, to me this was probably a result of a system with no load. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] malloc and calloc
Raul wrote: > > Can the functions malloc() and calloc() be used in > rtl. > I have this file that make calls upon those funcions. > The compilation presents no problems but when I try to > load the module the following error comes up: > unresolve symbol malloc > unresolve symbol calloc > > If they cannot be used is there anyother similar > function? > Hi Raul, For the kernel kmalloc/kfree etc are used, but these are not safe in a realtime context. RTAI has support for dynamic memory allocation using rt_malloc/rt_free. I think I recall someone ported this to RTL recently (see the archive). Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Linux/RTLinux interrupt handlers
Hi Hans, When RTlinux takes over, a linux interrupt will be delivered as usual is RT is not running, otherwise it will be recorded and pended so that it will get run as soon as the RT system becomes idle. Regards, Stuart > Hans-Olof Danielsson wrote: > > Hi, > > I have looked into RTLinux FAQ but found no answer to the question: > > What happens to Linux interrupt handlers when moving to RTLinux? > > Possible answers: > > 1. They are automaticaly replaced with RTLinux versions that assures > that all communication between a device and a user space process goes > via soft interrupts and rtl_fifo. > > 2.You have to to this to get the system working with real time > performance: . > > What is the correct answer/s? > > TIA for comments. > > > Regards > Hans-Olof > > Danitek AB > Hans-OlofDanielsson > Dragspelsv. 20 > S-732 32 Arboga > Sweden > Tel: int +46 589 140 38 > Email: [EMAIL PROTECTED] > Web: www.node98.com/danitek > Member of Node98 www.node98.com -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI select and fifo problem
Hi Daniel, This is a bug in the fifo code, please go to the errata page at: http://www.lineoisg.com/products/ert3/install/appa.html Where you can download an update to the fifos and read the install instructions. Regards, Stuart daniel sheltraw wrote: > > Hello RTAI world > > I just upgraded to RTAI 1.3 (Linux 2.2 16) using the Embedix CD and > everthing seems to be working fine as far as compling my modules goes. > I am however having a FIFO problem. Code that was previously working > under RTAI 0.7 (Linux 2.2.10) is not working after my upgrade. > Communication between kernel-space using rtf_put() and user-space > using select() is no longer working properly. The select() function > used in user-space remains blocked despite writing to the > corresponding FIFO in kernel-space with rtf_put(). I should point out > that communication in the opposite direction appears to work fine in > that I am able to write to a FIFO from user-space and propely activate > a handler in kernel-space. > > Question: Does anyone know what may have changed between these two > RTAI versions >(or versions of Linux) that would be producing this > problem? Any suggestions >on how to narrow down what the problem is? > > Thanks again and have a great Thanksgiving, > Daniel > > -- > Get more from the Web. FREE MSN Explorer download : > http://explorer.msn.com > > -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail > [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail > [EMAIL PROTECTED] --- For more information on Real-Time Linux see: > http://www.rtlinux.org/rtlinux/ -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI module compile warnings
HI Daniel, It seems you're missing a header/patch , the first thing to check is: - your /usr/src/linux link is pointing at the new 2.2.17 kernel source tree - your /usr/include/rt linux is pointing to the new 22.2.4 rtai tree. Regards, Stuart daniel sheltraw wrote: > > Hello RTAIers > > I have installed RTAI Embedix from CD and all the modules (rtai.o, > rtai_sched.o, etc) can be loaded. When I try to compile > code which previuosly worked under rtai 0.7 using: > > gcc -g -D__KERNEL__ -DMODULE -O2 -Wall -I > /usr/src/linux/include /usr/include/rt rt_stim.c > > I get the following warnings: > > /usr/include/rt/rtai.h: In function `rt_spin_lock_irq': > In file included from /home/sheltraw/rt_stim_new/rt_stim.h:13, > from rt_stim.c:11: > /usr/include/rt/rtai.h:225: warning: implicit declaration of function > `hard_cli' > /usr/include/rt/rtai.h: In function `rt_spin_unlock_irq': > /usr/include/rt/rtai.h:232: warning: implicit declaration of function > `hard_sti' > /usr/include/rt/rtai.h: In function `rt_spin_lock_irqsave': > /usr/include/rt/rtai.h:245: warning: implicit declaration of function > `hard_save_flags' > /usr/include/rt/rtai.h: In function `rt_spin_unlock_irqrestore': > /usr/include/rt/rtai.h:255: warning: implicit declaration of function > `hard_restore_flags' > /usr/include/rt: file not recognized: Is a directory > collect2: ld returned 1 exit status > make: *** [rt_stim.o] Error 1 > > Can someone please tell me where the problem is? > > Thanks again, > Daniel > > _ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > Share information about yourself, create your own public profile at > http://profiles.msn.com. > > -- [rtl] --- > To unsubscribe: > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > --- > For more information on Real-Time Linux see: > http://www.rtlinux.org/rtlinux/ -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Mutex and Timers
Ralf Ramrath wrote: > > Hi folks, > > I have the following problem: > > I have a "main thread" that has to read data from the serial port only if > any data is available. On the other hand, the thread must not wait longer > than let's say one second. Hi Ralf, IMHO, the correct way to handle this would be to use pthread_cond_timedwait. Unfortunately neither RTL or RTAI currently implement this. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] rt_sleep_until question
daniel sheltraw wrote: > > Hello RTAIers > > If one schedules events in oneshot mode by > passing an array of times to rt_sleep_until() > what happens if two successive events have the > same time in the array? Will the second of the > two execute immediately after the first is complete? I think so. IIRC, the scheduler in oneshot mode just looks at the absolute time to wakeup, and it it has passed, you will be woken up. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
[rtl] Announce: RTL/RTAI fifos update
Hi everyone, I finally got around to updating the common rtai_rtl_fifos package. This is now inline with its parent (rtai-1.5/newfifos). I've tested it on rtlinux-3.0-pre9 and on rtai-1.5. This package includes the following updates: - bug fixes: Nasty stuff with select with the final parameter set to 0. - named fifos: This is now included to make it easier to avoid fifo device clashes - FIONREAD is supported You can find this at: http:[EMAIL PROTECTED] Click on rtai_rtl_fifos-06.tar.gz To install this, untar in the top-level directory of rtl/rtai. After installation, cd rtai_rtl_fifos-06 and then type make. This will a module called rt_fifos.o, which you can copy to your modules directory (note that the name is different to avoid overwriting the original). Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] power off suddely
Are you guys saying that you're machines power them selves off occasionally with no other symtom e.g no kernel oops or similar ??, not a reboot but a power off ?? If so, I can only think that this is an issue related to APM. Regards, Stuart Sam Bibler wrote: > > No answer, Im just a rtl newbie interested in same subject... random hard power >offs. In the RTL mail archives, dated 10 APR 2000 B.Kuhn responds to almost the same >qustion by > suggesting to mount root file system read-only and using a umsdos partition for the >data. Umsdos??? Can someone with more knowledge say that vFAT really is better for >sudden power-off > situations??? or am I misreading this?? > > thanks > Sam Bibler > > mai wrote: > > > Hi, > > I had insert my module test.o successfully,Thank everyone! > > I have another problem now,my system had to be power off suddenly,randomly,the >operating system can not shutdown normally,Can the rtlinux work normally again after >sudden power off? > > > > I anticipate your early reply! -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] insmod
mai wrote: > > Hi, > I start to use RT-Linux recently,I install a rtlinux2.3 on the redhat 6.2,I write a >module(test.o) then I want to insert it in the kernel. > > #insmod test.o > > then I saw this display: > > test.o:Kernel -module version mismatch test.o was compiled for kernel version >2.2.14-rtl2.3 while this kernel is version 2.2.14-5.0 > It looks as though you have build your new kernel, but not installed it on your system. You need to copy the new kernel to /boot, make sure the modules are installed (make modules_install) and put an entry for your new kernel in /etc/lilo.conf (copy a similar one and change it). Next you need to run (as root) /sbin/lilo. Make sure that you don't get any errors. Finally, reboot and at the lilo prompt, press tab and select your new kernel. You can always confirm which kernel you are running at the prompt with 'uname -r'. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] timex.h and RTAI 1.5 (over 2.2.16 kernel)
[EMAIL PROTECTED] wrote: > > Hello, > > I've found an unfortunate bug in the "linux/timex.h" file. This file include >"sys/time.h" and this cause any program that use the adjtimex syscall to be unable to >compile (You get a lot of multiple definition error message). The only work-around, >I've > made is to comment the "#include " line and add it myself in my >(user-mode) program that use the adjtimex syscall. > > However, if I comment out the include, any program that includes "linux/sched.h" >won't compile. This leads me to the conclusion that it doesn't solve the problem. > > I posted it a few days ago to the linux-kernel mailing list. The people there were >unable to reproduce the problem and thus I conclude that this might due to the RTAI >patch appliance. > Hi Laurent, I have built the 2.2.16 Linux kernel with RTAI-1.5 without problems. Can you send more information. In particular, some of the output from the failed build. What distribution are you based on (e.g RedHat x.x ??). Also, can you send your kernel .config file and I'll try to see if I can reproduce the error. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTLinux + UMLinux ???
[EMAIL PROTECTED] wrote: > > On Sat, Nov 04, 2000 at 03:29:19AM +0100, Bernhard Kuhn wrote: > > Denis Karpov schrieb: > > > > > is it possible to run RTLinux in User Mode Linux > > > > I didn´t tried it, but it´s rather unlikly that it > > will run: the UML-Kernel is patched in the areas > > of memory management, process scheduling and interrupt-handling > > in order to be able to run as usual application. > > > > I doubt that the rtl-patch could be applied without > > rejects to a kernel prepatched with UML. > > Even then, you have to redo the same work as for > > the kernel-scheduler etc. Beyond all this problems, > > the UML-RT-kernel wouldn´t be real-time capable any more. > > > > BTW: Everybody laughs about "printf-debugging" (means > > writting message-bytes to the printer port), but IMHO, > > for many hard-rt-applications(!) this is a quite > > convenient way to get programms bug-free. > > > > Other possibilites: R2D2 from Zentropics and LXRT from RTAI. > > Alternative include > 1. gdb which comes with RTLinux, > 2. XBD the CAD-UL remote debugger for RTLinux, > 3. CarbonKernel the RTLinux V3 emulation. > Also, the remote kgdb+kmod (remote serial gdb), this works with RTL & RTAI. It allows kernel+module+rt-module debugging in the same scope. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Memory allocation
Hi Everyone, As it is one of my pet subjects, I'd like to say that I think it is great that there has been a port of the rt_mem_mgr to RTL (remember, you don't have to use it if you don't want it, even in RTAI it is an option in the Rules.make file). I'd like to also see that this code becomes common for RTL/RTAI (the difference hidden by macros or somthing similar). I have attached rt_compat.h that comes with RTAI, which is a very simple set of macros, that shows how easy it is to find an equivlalent call for RTL/RTAI. The only thing that is a little complicated is the task_create stuff. Anyhow, the idea is not to say that this is *the* solution, just to plant the idea that it may not be so difficult to find a mechanism that will let us all benefit from optional modules that can be easily used for both RTL and RTAI. For my part I try to write/port apps that can work with both (the latest R2D2 and kgdb+kmod do) and also David Schleef does the same with rtnet and COMEDI. I think that this approach is helpful to users, without forcing the maintainers of RTL or RTAI to do something that they don't agree with. Regards, Stuart Karim Yaghmour wrote: > > This is very interesting indeed. > > I won't claim to be an expert on the rt_mem_mgr stuff, I guess Pierre would > have to take care of this one. Maybe the RTL guys could help you out too > for the verification and provide ftp space for this. But I can't speak > for anyone. Just hope the pointers help out. > > If nothing else, this gives a brief outline of the changes necessary to > port something between RTAI and RTL and vice-versa, which could be useful. > > Best regards > > Karim > > Joel Vallier wrote: > > > > I've done the porting to RTL 3.0 of the RTAI Dynamic Memory Manager > > (rt_mem_mgr) distributed with RTAI-1.5. > > > > It works for me, but I'd like that some RTL experts verify that all is Ok. > > > > Here is a list of main changes for the porting: > > - > > flags = rt_spin_lock_irqsave(&rt_mem_lock); // RTAI > > rtl_spin_lock_irqsave(&rtl_dmm_lock, flags);// RTL3.0 > > - > > rt_spin_unlock_irqrestore(flags, &rt_mem_lock); // RTAI > > rtl_spin_unlock_irqrestore(&rtl_dmm_lock, flags); // RTL3.0 > > - > > alloc_sysrq.srq = rt_request_srq(0, rt_alloc_sysrq_handler, 0) // RTAI > > alloc_sysrq.srq = rtl_get_soft_irq (rtl_alloc_sysrq_handler, "rtl_dmm") // RTL3.0 > > - > > rt_pend_linux_srq(alloc_sysrq.srq); // RTAI > > rtl_global_pend_irq(alloc_sysrq.srq); // RTL3.0 > > - > > void rt_alloc_sysrq_handler(void) // RTAI > > void rtl_alloc_sysrq_handler(int irq, void *dev_id, struct pt_regs *p) // RTL3.0 > > - > > kmalloc(granularity, GFP_KERNEL)// RTAI > > kmalloc(granularity, GFP_ATOMIC)// RTL3.0 > > - > > > > I can make source public if you give me a FTP server. > > > > Regards, > > > > Joel > > > > Karim Yaghmour wrote: > > > > > > You can dynamically allocate memory in real-time using the rt_mem_mgr > > > stuff in RTAI. > > > > > > Cheers > > > > > > Karim > > > > > > [EMAIL PROTECTED] wrote: > > > > > > > > I remember seeing many discussions on the list about memory allocation, > > > > but i am failing to find them now. > > > > I remember that you can only do memory allocation in initmodule. Is > > > > this right? I would like to allocate a few > > > > kbytes either in a fifo handler or a real time thread. Is this ok? > > > > eric // // Copyright © 2000 Zentropic Computing LLC // // Authors:Stuart Hughes // Contact:[EMAIL PROTECTED] // Original date: April 13th 2000 // Ident: @(#)$
Re: [rtl] semaphore between rt and user space
"S.A." wrote: > > I think that the use of a fifo seems to be more a secure solution than > using shared memory bits. > > It is important to guarantee an exclusive access to shared ressources . > > I tried RTAI_RTL_FIFOS from zentropix, this seems to solve the problem > for the exchange of semaphores between RT and linux space. > Did some people already use it ? > The package you speak of is just the rtai fifos package with some macros at the top to take care of the underlying differences between rtl and rtai (e.g header files and save_flags etc). I have not been keeping this up to date, as I was not sure if anyone was actually using it. I think that this package has some use, as for those that want it, it provides some IPC. I also think that it shows that it is not really too difficult to make the same code work for RTAI and RTL. IMHO, it would be nice to see more common code, as it makes the life of application writers easier (to write code that works on RTL & RTAI). Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] interrupt source for schedular
Mahadev K Cholachagudda wrote: > > Hello to all, > > Does any one know which interrupt is used as a source of input for realtime > schedular. ? > > Is linux and real time code uses same interrupt i.e. timer1 ?. > RTL/RTAI take over timer 0 (the normal linux tick interrupt), and re-program it for their own used. To keep linux runnining okay, they pend the normal linux timer ISR to run every 10 ms. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI saving flags Q
Arne Linder wrote: > > Hello Paolo, > > On 31 Oct 2000, at 2:32, Paolo Mantegazza wrote: > > > daniel sheltraw wrote: > > > > > > Hello RTAI world > > > > > > Would someone please tell me in what situation would one need to > > > use the routines rt_global_save_flags/rt_global_restore_flags and > > > rt_mount_rtai/rt_umount_rtai? > > > > > > > When you insmod rtai it stay dormant till you do nat call rt_mount_rtai > > in an application needing it. Clearly you must umount when you end the > > application, and all the other RTAI modules using rtai do the related > > mount by themselves. > > > > The global save_resotre functions are the equivalent of hard_save_flags > > and hard_restore_flags for SMP. > > > > Is it not explained in the manual? I must check. > > > > Is this a new feature of RTAI 1.5 ? We're using RTAI 1.3 / Kernel > 2.2.14 and don't call rt_mount_rtai / rt_unmount_rtai and everything > works fine. We only do insmod and can use all we need of rtai like > Phil explained in his tutorial under > http://www.realtimelinux.org/articles/linux- > expo/montreal/paper/indexc.html > > I hope, we haven't forgot something essential. > > Greetings from Wuppertal > > Arne Linder > Hi Arne, rt_mount_rtai/unmount have alway been there. It happens automatically when the fifos or scheduler modules are loaded/unloaded. You don't need to worry about them unless you want to do something minimal like have a single hard-irq module without inserting the scheduler (in which case you do the mount in the init_module and the unmount in the cleanup_module). Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] serious! (oops) rt fifo problem. (easily reproducable)
Hi Hans,
Possibly the new named fifo interface in rtai-1.4 may solve your
problem. If you're on RTLinux, you could port the rtai fifo module to
make it work on both (or add the code to the RTL module).
Regards, Stuart
Hans de Goede wrote:
>
> Hi all,
>
> I'm busy designing an realtime linux app using rtlinux and I encountered
> the following problem causing an oops, or if a module is loaded at the
> address of a previously loaded one even worse things. I have managed to
> reproduce it using something as simple as frank-app.
>
> I'll first describe my thought pattern that let me to the problem, to
> show that there is a deeper problem which is the cause of this. Then
> I'll describe the real problem, followed by an (ugly?!) solution to fix
> both.
>
> Problem:
> rtf_destroy is usually used from cleanup_module, cleanup_module is void,
> yet rtf_destroy can fail (when userspace progs still have the fifo
> open).
>
> This is usually fixed by just destroying all fifo's you use before
> creating them in init_module. I didn't want todo this since in our
> application multiple persons can write rttasks and I want to have the
> protection of rtf_create failing if multiple tasks accidentily try to
> use the same fifo.
>
> The fix for this is ofcourse to have a well defined list of fifo's so
> that people won't try to use the same fifo.
>
> But I still thought that having todo rtf_destroy in init_module is not
> clean, and that there really should be a way to INC_MOD_USE_COUNT of
> your module/task when the user opens an rtfifo you've created, so that
> cleanup_module won't be called with the fifo is open by a userspace
> program.
>
> While searching for a workaround since I didn't want to change the
> rt_fifo.c code I encountered the following scenario:
>
> rt_task.c:
>
> init_module
> {
>rtf_create(1, whatever)
>rtf_create_handler(1, my_handler)
> }
>
> cleanup_module
> {
> rtf_destroy(1)
> }
>
> now do the following:
> -insmod rt_task.o -> fifo is created successfully
> -have a task open /dev/rtf1
> -rmmod rt_task.o -> fifo is not destroyed because it is open
> -have the task write to /dev/rtf1 -> my_handler (which is no longer) is
> called -> oops (or worse if a new / other module was loaded at that
> address
>
> IMHO the only correct fix is to INC_MOD_USE_COUNT of rt_task.o when
> /dev/rtf1 is opened, and DEC it again when it is closed. This would
> require a callback function argument to rtf_create, since you can only
> use INC_MOD_USE_COUNT from the actual module itself. This seems to be
> the correct thing todo always, and is a must have when using handlers
> since in essence the rt_fifo module has a reference to the rt_task
> module, and hence the rt_task module is in use.
>
> For the unbelievers this can easiliy be recreated with the frank
> example,
>
> insmod frank_module.o
> ./frank_app&
> rmmod frank_module
>
> Now just wait for all the selects in frank_app to time out (about 100
> seconds) then it will try to write to /dev/rtf3 which has a handler to
> stop the tasks -> oops.
>
> Regards,
>
> Hans
>
> p.s.
>
> I'm working on a fix and I'll mail it as a patch to the list when I'm
> ready.
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
> ---
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] LXRT and LXRT-Informed
Erwin Rol wrote: > > Hello All, > > I have been looking at LXRT in RTAI 1.5 and saw there are basicly > two directories with LXRT, one lxrt and one lxrt-informed. I can't > really figure out which one to use, cause it seems the lxrt examples > don't compile with the header files in rtai-1.5/include/ directory. > And also i am not sure what the difference is between the two. > > And and other little thing, with lxrt(-informed) one uses the rtai*.h > headers in non modules, so wouldn't it be nice to install those headers > under /usr/include/rtai and use #include in programms ? > (of course it can be done , but it would be nice if it was done > automaticly > just like copying the modules to /lib/modules/linux*/misc/ ) Hi Erwin, The lxrt directory has the newest stuff (such as hard real-time in user-space and tasklets), lxrt-informed is the 'stable' version that has error recovery (but lacks some of these news features). You are correct, that the header files are not compatible, currently. The plan is to merge all the lxrt stuff into lxrt-informed, and standardize on one directory. You should use the lxrt-informed stuff (you'll see that the sim-links from include and modules go there) unless you are checking out the new features. As far as the link goes, the rtai-1.5 'make install' makes a link from /usr/include/rt to /include, the /include directory has links to the correct files. The practice I use is to use #include in my c files (with a -I/usr/include if necessary). The idea behind this is that you can easily move the link to a new installation (for example a test version etc), and also you cannot accidentally pull in the wrong header if there is a clash with the standard header files. This also helps me with stuff I want to run also on RTL, as I can #include , and pull in the correct rtlinux header files. I'm not saying that this is the best way to go, but it was something that helped me get my applications to work on both systems with the minimum misery. Regards, Stuart. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI lxrt liner error
Sven Garbade wrote: > > Dear List, > > I´ve tried to compile a rtai-lxrt-example programm with my own makefile, > but linking failed: > > make -k > gcc -I/usr/src/linux/include -I/opt/RTAI/rtai-1.5/include > -I/opt/RTAI/rtai-1.5/lrxt -O2 -o user_hrt user_hrt.c > [snip] > > I think it must be easy, but I haven´t found the trick... > > Here is the makefile: > > all = user_hrt > > RTAI_HOME = /opt/RTAI/rtai-1.5 > LINUX_HOME = /usr/src/linux > > INCLUDE = -I$(LINUX_HOME)/include -I$(RTAI_HOME)/include > -I$(RTAI_HOME)/lrxt > > user_hrt: user_hrt.c > gcc $(INCLUDE) -O2 -o $@ $< > > What went wrong? Many thanks, > Hi Sven, It's not really your fault, the problem is the current name collision problem with rtai_lxrt.h (between lxrt and lxrt-informed), this will be fixed when the versions get aligned. If you are using the user_hrt.c example in the lxrt directory, you will see that it includes ../rtai_lxrt.h, this is because it has to include that file and not the one found /include. If you are trying to build this example in a directory other than lxrt (did you copy it somewhere else ??) you will need to remove the ../ prefix in the include (make it #include and then change your make file as shown below: INCLUDE = -I$(LINUX_HOME)/include -I$(RTAI_HOME)/lxrt -I$(RTAI_HOME)/include Hope this fixes it for you Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTLinux as an initrd?
Paul Mundt wrote: > > Hello, > > I was wondering if anybody has used an rtlinux kernel as an initrd? > I'm curious about this for use as an installer. As far as I can tell, > rtlinux would be well suited for this kind of thing. > > However, before hacking away at it and quite possibly wasting my time > I figured I'd ask to see if anyone else has had similar experiences, > or has any words of wisdom in regards to this. Hi Paul, I've used it this way without any problems. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Use mbuff
Alessandro Coppelli wrote:
>
> Sorry for my ignorance but I do not know I do communication between
>
> rt task and user process using exellent mbuff driver : ( I'm sorry
> Tomasz )
> I want read and write a lot of char ( 8000-12000 ) between rt task and
> user
> process. My simple and wrong program is this :
>
static char *addr;
> void *thread_code(void *t)
> {
>
>while (1) {
> int ret;
> ret = pthread_wait_np();
>
> //Can I read data from here ? and How
> //sscanf(memname,"%s",stringa);
>
> rtl_printf("I read = %s",stringa);
// be sure that there is a string there.
rtl_printk("I read = %s\n", addr);
> }
> return 0;
> }
>
> int init_module(void)
> {
> pthread_attr_t attr;
> struct sched_param sched_param;
> int ret;
char c2;
>
> pthread_attr_init (&attr);
> sched_param.sched_priority = 1;
> pthread_attr_setschedparam (&attr, &sched_param);
> ret=pthread_create (&taskA, &attr, thread_code, (void *)1);
> pthread_make_periodic_np(pthread_self(), gethrtime(), 20);
> shm_allocate(memname, memsize, &addr);
size = shm_allocate(memname, memsize, &addr)
>
> // Must I read data from here ? I have to read a lot of data from user
> process
> // it are 8000 char to LPT1
// you can now read by dereferencing the addr pointer
// e.g to get the second byte:
c2 = addr[1];
>
> return 0;
> }
Regards, Stuart
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] v3pre8 and includes
Olaf Petzold wrote: > > Hello, > > I'm switching from rtl.2.2 to v3pre8 now and I found some problems with the > order of includes. The rtl.mk does include all paths e.g. /usr/rtlinux/include, > /usr/rtlinux/include/posix. The last ist very important else the cc doesn't > find the right includes and take the one from the kernel tree (e.g. time.h) > regardless of the right one from the /usr/rtlinux/include/posix dir. Why the > way of order of include paths and not do inside the rtl-includes an > #include anstead of #include . > To find this behavior hours. > > I don't use rtl.mk - I use autoconf && automake ! Hi Olaf, I agree, unless you prefix the RTL variants of standard headers with something, it is easy to pull in the wrong header. Although you can use -nostdinc to make sure that nothing is sucked in from /usr/include, it is too easy to get tripped up. I think that your method of saying is okay. Personally I'd like to see a common method that would work for rtai or rtl. A recent suggestion I like from David Schleef is: install headers in: /usr/i386-linux/realtime e.g: /usr/i386-linux/realtime/rtlinux/ /usr/i386-linux/realtime/rtai/ For rt-net: /usr/i386-linux/realtime/include/sys/socket.h /usr/i386-linux/realtime/include/net/* Then to compile a kernel module, use: cc -c -D__KERNEL__ -I /usr/realtime/include -nostdinc it.c' In your c files, you then need to include files using: #include This mechanism copes with both architecture and variant differences. This is just a straw man, and if anyone can see problems, or has a better solution, please feel free to disagree. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] rtl_printf
Dingrong Yi wrote:
>
> Hello,
>
> Maybe my question is stupid, wish you could forgive me as a beginner.
>
> Where could I find the output of rtl_printf(" running time %d\n", runtme)?
>
> If one can see the value of some variables during a code executing, it is
> helpful for understanding how the code behavies.
The output goes to /var/log/messages (do a tail -f /var/log/messages).
If you come out of X, you will also see the output at the console log
(without having to do the tail).
Regards, Stuart
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] ad hoc distrib hint req (little newbie quest.)
David Olofson wrote: > > Wed, 25 Oct 2000 Paolo Meriggi wrote: > > Dear all RTers, is there anybody out there who could give me (please, > > please please...) some hints on the following topic: > > I am managing and run RTLinux on an embedded system (as almost most of > > you...). I developed everything on a common HD, but now I have to take > > everything to just a 32 Mb flash disk, and some problems come out. > > Exactly what I'm facing eventually. However; 32 MB!? Lucky you! :-) I'll > probably have to run at least some versions (the one that will replace the > current DOS version when upgrading old instruments) of my software from floppy > disks... If you don't need X or compilers etc, but a reasonably full-up standard system, you can whittle RH-6.2 down to about 5 Megs uncompressed, one of the most obnoxious things to deal with is the pam libraries (by that I mean the extra complexity hence size they cause you). In the end I reduce pam.d to have just 'other', and put in the following: # # default; standard UNIX access # auth required /lib/security/pam_unix_auth.so account required /lib/security/pam_unix_acct.so password required /lib/security/pam_unix_passwd.so session required /lib/security/pam_unix_session.so This cuts the library cruft down considerable, even so, this is still a fairly fat (but standard system). Also, remember to strip -g your executables & libraries. If you want to go further, things become less standard, and you need to follow the ways of the linux router project and the like. In particular, busybox can be used to remove many fat utilities and replace them with a single executable. If hand tweaking is too problematic, tools have been developed that can take most of the pain out of this. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] GCC builtin ?
Joel Vallier wrote: > > [EMAIL PROTECTED] wrote: > > > > Hello, > > > > I'm trying to compile a small program I write (actually part of iit). >Unfortunately there are memcpy (and also strcpy) call in my code. I though that GCC >convert them to builtins and so no call are made. And it seems to work ... on some >filesonly ... > > I'm using GCC version egcs 2.91.66. Does anybody know an easy way to get these >builtin function working ? I even try to use the name __builtin_memcpy (as GCC doc >states) but a simple nm on my object file shows an undefined memcpy symbol. I'm sure >there > > must be a way to avoid it because the kernel code use memcpy and have no memcpy in >the system.map file so I can expect to be able to do the same. > > > > Laurent > > > > If you write a RT program, you should include linux/string.h file > which will include asm/string.h file where the memcopy is inlened. > > Joel Also, don't forget the -O2 flag to pull in the inline functions. Stuart. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Monitoring data points
Hi Kevin, I've used Perl/Tk reading from a rt-fifo. You could also use any other graphical library using this technique (reading the data from a rt-fifo). Regards, Stuart KEVIN ARCAS wrote: > > I'm working with RTLinux to make a controller of a MIMO > system. I don't have experience in GUI and graphics programming > and I cannot find the language/toolkit to use. I would like to know if > someone have experience in the design of the application thet > makes a continuous plot of some variables coming from my RTL > module. All help is welcomed. > Thanks > > Kevin > UPC (Universitat Politecnica de Catalunya) > -- [rtl] --- > To unsubscribe: > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > --- > For more information on Real-Time Linux see: > http://www.rtlinux.org/rtlinux/ -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RT Linux system calls
Randolph Lee wrote: > > I'm quite new to Linux so I apologize if my question seems quite trivial. I > noticed in the man pages that rt_task_init is only a RTL v1.x compatibility > function. Which system call would I use that is similar to this for v2.x, > without using threads? > Hi Randolph, Because you are programming kernel space modules, all tasks share the same address space, therefore they can be also thought of as threads. For this reason you can safely use pthread_create instead of rt_task_init (the best thing to do is look at some of the examples in the distribution to get some ideas). Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTNET / Linux Trace Toolkit
Joachim Herb wrote: > > Joachim Herb wrote: > > - In your package TracePackage-0.9.3.tgz you included patches named: > > patch-ltt-rtai-22.2.4-000822 and > > patch-ltt-linux-2.2.16-with-rtai-22.2.4-000822 > > As there is no RTAI-22.2.4 on the RTAI website, and the version of RTAI > > for the linux kernel version 2.2.16 is RTAI-1.4, I think your patches are for > > this version? > Sorry, now I have seen that it is for RTAI-1.3a. But its not too hard to > get it working with 1.4. Hi Joachim, 22.2.4 is AKA 1.4, this is the internal version number that makes it easier to do numerical comparisions of version numbers. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Getting Started With RTAI Linux
Hi John, "Sotack, John" wrote: > > Although I am relatively new to Linux I have been involved in Real Time SW > development for years. I am interested in getting started with RTAI Linux > and there seems to be more than one path to doing this. More specifically, > it appears that I can order a disk from November 1999 from > www.zentropixs.com or download a file from the same site. I got the > impression that the CD Rom was a bootable full install and that the > downloads were a means of patching / modifying an existing keral because the > downloads were on the order of <1MB (too small for a full districution). The current CD install a RedHat 6.0 with an RTAI/RTL kernel. I would recomend that you wait until the new CD is released (we are on the final runs of beta test) if you want the convenience and ease of installation for RTAI and the tools we provide. Note that the new CD installs on top of an existing Linux distribution, rather than installing a new Linux (it supports RedHat 6.2, Caldera 2.3, Mandrake 7.1, Suse 6.4, Debian 2.1 and probably more we haven't tested). If you only want RTAI and Linux, then you can just download the kernel from kernel.org and the RTAI code from rtai.org. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] about Create RT-FIFO
crzhang wrote:
>
> Hi all,
> I have install rtlinux2.2 with linux-2.2.14, but in the /dev I have only rtf0 ~
>rtf7, and how do I create the other RT-FIFOs.
>
Hi Wang,
one way is (as root):
cd /dev
perl -e 'foreach $i (0..63) { `mknod rtf$i c 150 $i` }'
This will make rtf0 to rtf63
Regards, Stuart.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] Question on interrupts (TEXT FORMAT)
Hi Maryam, Possibly you have run into a scheduler bug that existed on some versions of the 1.x series of RTL (I think it was 1.1). Try changing to the last released version for 1.x (better if you can upgrade to a later RTL/RTAI). It may not be this, in which case you will need to send some code. Regards, Stuart Maryam Moghaddas wrote: > > Hi > I found the following in the RTLinux news group and found it _different_ > from my results > - > 21 July 2000 daniel sheltraw wrote: > > > > Hello RTAIers > > > > Two questions: > > > > (1) Do RT interrupts always interrupt any RT task or is there some > > dependence on the priority level set for the task? > > Yes, unless the task disables them. > > > I have a similar question/problem to this. > I am using RTLinux V1. Network IRQ is registered through request_RTirq. The > timestamps and tests show as if my tasks do not get preempted by the > interrupt and the gap between its reception depends on the length of my > tasks... > > Interrupts are not disabled in tasks + tasks seem to run out of the scoop of > the interrupt handler. > > TEST1: > task length is 300 ticks > interrupt arrival: every 50 ticks > sched_const 120 tick > > If I send 5 messages > interrupt 1 @ 50 tick > interrupt 2 @ 100 > task start @ 120 > task end @ 420 > interrupt 3 @ 430 > interrupt 4 @ 470 and so on... > > if I increase task length: > > TEST2: > task length is 3000 ticks > interrupt arrival: every 50 ticks > sched_const 120 tick > > If I send 5 messages > interrupt 1 @ 50 tick > interrupt 2 @ 100 > task start @ 120 > task end @ 3120 > interrupt 3 @ 3220 > interrupt 4 @ 3240 and so on > > Can you explain this please?! > > thanx > maryam > > -- [rtl] --- > To unsubscribe: > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > --- > For more information on Real-Time Linux see: > http://www.rtlinux.org/rtlinux/ -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Tasks not in Interrupt handler!
kumsta wrote: > > Hi, > > > Maryam Moghaddas wrote: > > Using RTLinux V1, please tell me: > > > What is an RTTASK priority in comparison to the interrupt handler ? > > > > Normally, the Irq handler has no priority compared to threads ... if > enabled, irq interrupt all, save the context > of the processor, handle the Irq, and then restore the processor context > and return in his previous state. > This explaine that your RTSemaphore is handled by your thread only after > your Irq_handler totally done and if no > higher priority thread is running. To clarify a little as this has come up a few times. If any RT task (or anything else) is running (whatever the prioriy) and interrupts are enabled, a hard interrupt will preempt the task that is running. The ISR code will run and when it exits the interrupted task will be resumed. This effectively means that interrupts have the highest priority. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Split this list
[EMAIL PROTECTED] wrote: > > > c) since RTAI was so insistently argued as being inspired, from > >its birth, by everything but RTLinux, that is, RTAI has (had) > >nothing to do with RTLinux, allowing discussions that address > >those two "completely different" subjects might have proven > >to be a strange mistake that was made from the beginning of > >the creation of this list. Therefore, why don't we split this > >list into two different lists: the existing one exclusively > >for RTLinux technical discussions and a new one (to be created) > >only for RTAI? > > 1 vote for split. 1 vote against. Stuart. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI and RTLinux
[EMAIL PROTECTED] wrote: > Next month, when someone else from Lineo invents local variables or > the letter "a", we will undoubtedly see yet another one of these strange > episodes. Bitch How about we all lighten up a little. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI and RTLinux
[EMAIL PROTECTED] wrote: > > On Tue, Sep 05, 2000 at 10:18:25AM -0700, David Schleef wrote: > > I don't think that "running out of memory" and "running out of CPU > > time" are fundamentally different things. It's just that with a > > memory allocator, you are notified of a lack of resources and can > > do something graceful instead of locking the machine. > > Sure. But I think there is a significant difference between: > 1. At startup time, allocate N buffers for a pool > for a particular purpose and have an allocate/free > routine. > and > 2. Maintain a general purpose buffer pool with unknown > size and many users. > > Hi Victor, I think the big misunderstanding is that the pool of memory is only available to real-time tasks. This means that a design can be made based upon things you can control, whereas in a soft real-time system, you are subject to the interference of things you cannot control (such as a disk surge from an active web server for instance). In the same way you have to take care not to exceed the maximum frame time allocated per task (CPU budget), you must also take care that you understand the limitations of the memory allocator (e.g don't ask for too much too quickly). Remember also that people seem to be thinking here in terms of a task meeting its deadline with high precision every time. That is fine for the highest priority task, but if you have many task, the lower priority tasks will have significant jitter. Again, only a problem if you don't take this into account in the design. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI install
Wilken Boie wrote: > > Hallo RTAIers, > > > > it seems kind of strange, but each time I use ppp (for internet > > access, over a serial port and an external ISDN adadpter) I > > have to rmmod rtai_sched. Otherwise ppp still works but the > > throughput becomes practically unusable. > > > Details > > Looking at a thruput plot it looks as if a transfer was > > starting as normal but after a moment the thruput drops > > severely (mostly close to zero). After a few seconds this > > repeats. During a file download I can pretty consistenly > > switch the problem off and on by ins/rmmod rtai_sched > > (upscheduler). > > > System > > K6/233, serial: ISA 4port with standard driver irq 14 > > RTAI: both 1.1 (from http://www.timesys.com RT package) and 1.3 > > Linux: 2.2.14 > > Hi Wilken, I have tried to reproduce this problem on my system, but everything seems fine, no slow down. I started pppd and set a long ftp running. I checked the transfer rate by looking at the pacing of hash marks. There was no slow down. I'm using the latest RTAI-1.4 (but the result should be the same on 1.3). The only obvious difference is that you report the serial interrupt in 14 on your system, on most that I have looked at 14 is usually the ide hard drive interrupt (I don't know if this is significant). Here is my output from /proc/interrrupts: # cat /proc/interrupts CPU0 0: 106016 RT SPVISD timer 1: 3288 RT SPVISD keyboard 2: 0 RT SPVISD cascade 3: 8 RT SPVISD pcnet_cs 5: 236011 RT SPVISD serial 12: 48026 RT SPVISD PS/2 Mouse 13: 1 RT SPVISD fpu 14: 216611 RT SPVISD ide0 NMI: 0 Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI install
daniel sheltraw wrote: > > >From: Paolo Mantegazza <[EMAIL PROTECTED]> > >To: daniel sheltraw <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > >Subject: Re: [rtl] RTAI install > >Date: Thu, 31 Aug 2000 06:50:03 +0200 > > > >daniel sheltraw wrote: > > > > > > Hello RTAIers > > > > > > I finally got my new machine and I am ready to install the latest > > > and greatest version of RTAI. I guess that would be RTAI 1.3. > > > I have RedHat Linux 6.1 on my system presently. I don't recall > > > which kernel version is in 6.1 (If you know please tell me). > > > Anyhow, given the present state of my system (fresh out of the > > > box with RH 6.1 installed) how should I proceed in installing > > > RTAI 1.3? > > > >The latest is 1.3a for Linux 2.2.16. In a few day there will be 1.4. > >With 1.3a follow what is in README.QUICKINSTAL. > > > > > I will also be installing OSS (not the free version) sound drivers > > > and the latest version of SVGAlib. Should I do these installations > > > before installing RTAI 1.3. > > > > > > Any other up-to-date installation tips would be welcome. > > > >RTAI does not interfere with the installation of anyother package. > > > >Ciao, Paolo. > > When attempting to upgrade SVGAlib on my old machine running RTAI 0.7. > I could not compile the new version of SVGAlib. I received errors > concerning the defining of the RTHAL struct. I did not find a simple > work around for this although one may exist. I had similar problems > when trying to upgrade OSS (open sound system). My point is that > there does appear to be some interference at least for RTAI 0.7. > Has RTAI 1.3 changed in some manner that you would expect these > problems to no longer exist? The problem seems to occur when compiling other > code using some of the RTAI modified headers of the Linux > kernel? > > Please set me straight if I am wrong. Hi Daniel, The real problem is that SVGAlib (which is a userspace library) includes kernel headers, and gets away with it. To solve your problem, rebuild your SVGAlib before patching the kernel with RTAI. Regards, Stuart. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI and RTLinux
Hi Victor, The package mentioned below is portable, it contains fifos and other IPC's, but is is not Steve's pthreads package. Regards, Stuart [EMAIL PROTECTED] wrote: > > On Thu, Aug 31, 2000 at 12:52:58PM +0200, Paolo Mantegazza wrote: > > Apart from the fact that Steve's package cannot run with RTL, but only > > with RTAI, from my limited tests experience with Steve's POSIX the above > > Stuart? > > | > |From: Stuart Hughes <[EMAIL PROTECTED]> > |Organization: zentropix > |X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.3.99-pre8 i686) > |X-Accept-Language: en > |MIME-Version: 1.0 > |To: [EMAIL PROTECTED] > |CC: Gusa <[EMAIL PROTECTED]>, RTL <[EMAIL PROTECTED]> > |Subject: Re: [rtl] SEMAPHORE MODULE =?iso-8859-1?Q?DON=B4T?= COMPILE > |References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ><[EMAIL PROTECTED]> > |Content-Type: text/plain; charset=iso-8859-1 > |Content-Transfer-Encoding: 8bit > |Sender: [EMAIL PROTECTED] > |Precedence: bulk > |Status: RO > |Content-Length: 2970 > |Lines: 88 > | > |Hi Victor, > | > |That's correct, the portable fifos/semaphores/mailboxes can be found at > |http://www.zentropix.com/products/download.html by selecting > |rtai_rtl_fifos-04.tar.gz > |Please note that I have not tested this since RTLinux 2.0 or RTAI 1.0. > |Please let me know if you have any changes you want to go in. > | > |Regards, Stuart > | > | > | > | > |-- > |- > |Victor Yodaiken > |Finite State Machine Labs: The RTLinux Company. > | www.fsmlabs.com www.rtlinux.com > | > -- [rtl] --- > To unsubscribe: > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > --- > For more information on Real-Time Linux see: > http://www.rtlinux.org/rtlinux/ -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI and RTLinux
[EMAIL PROTECTED] wrote: > > On Wed, Aug 30, 2000 at 03:18:23PM +0100, Trevor Woolven wrote: > > BTW, can anyone *really* explain the point of non-portable extensions in a > > (supposedly) portable standard? I'm not saying they're wrong but they don't > > make sense (to me). > > We follow POSIX PSE51 for reasons of simplicity, coherence, programmer > familiarity, and because there is a real standard, not a creature of > any company. POSIX is specified so that implementation extensions can > be accomodated. For example, to reserve a RTLinux only processor in > an SMP system, we have >pthread_kill(pthread_linuxthread(),RTL_SIG_SUSPEND_LINUX ); > Of course, there is no signal RTL_SIG_SUSPEND_LINUX in the > POSIX specifications and this code will fail on Chorus -- but our > goal is to make RTLinux programming easy, not to make RTLinux as slow > and clumsy as Chorus. And the POSIX standard is designed to allow for > such extensions. I understand the reason for these non-portable extensions, but they unique features to RTLinux that lock-in users under the mask of perceived portability. > As I have pointed out before, the purpose of Steve Papacharalambous' > POSIX package is very much different from the purpose of our PSE51 > API -- even though we draw from the same base spec. Steve's package > is great for people who want to port code from Chorus or Lynx or > something to RTLinux. Indeed, very good for people porting real applications to RTAI. I guess from the late addition of pthread_mutex_xxx and pthread_cond_xxx to RTLinux that you agree with his philosophy of using the Linuxthreads package as a template. > But RTLinux is based on fundamentally > different design than those systems and we are trying to make a > convenient API for that design. So it misses the point to critique > Steve's package for lack of speed/determinism or our work for > exposing the RTLinux design. If you has some information that shows Steve's package is not deterministic, I'd love to see it. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] about string
Kirk Smith wrote:
>
> On 23 Aug 00, at 19:39, crzhang wrote:
>
> > Hi all:
> > Now i have a string "3*2*sin2+2*1", i want to get this string's mathematic result,
>but i don't know how to do.Can you help me?
> > Best Regards
This is off topic, but if you do:
perl -e 'print eval("3*2*sin(2)+2*1")'
You get 7.45578456095409 (dunno if it's right)
Regards, Stuart
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] thread scheduling in user space
Troy Davis wrote: > > Hello all- > I want to create a thread (or process) that executes on a regular > basis (about 20 times per second - 20 hz) in user space. Doing this > using the rtlinux thread library in kernel space is very easy, but it > does not appear to be the case in user space using the regular pthread > library in linux. Another method of doing this would be to utilize a > rtlinux timer or thread in a module but I'm unsure of how to trigger a > function in user space from an event in rtlinux. What I'm trying to do > is create an interrupt driven read/write function in user space to send > and poll for messages over a tcp/ip connection. The messages being sent > over tcp/ip do not need to occur in real-time, so a simple 'is there a > message? okay - send it or receive it' will work. Anyone have any > ideas on this? > > Troy Davis > Airborne Data Systems, Inc. Hi Troy, This can be easily done using (and there are some I've forgotten): 1/ A blocking read on the RTC (see linux/Documentation/rtc.txt) in the thread loop 2/ A blocking read on a RT fifo in the thread loop (trigger by a write to the fifo from an RT task) 3/ Using RTAI-LXRT using make_periodic and wait_period calls. IMHO, 3 is the easiest to implement. Bear in mind that all these approaches are soft realtime, and so you can be blocked by kernel activity etc. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Programming UDP in RT
> Tony Mouawad wrote: > > Just wondering if anyone has an examples for programming UDP sockets > in RT module?? > Hi Tony, Try: ftp://ftp.lineoisg.com/pub/rtnet/rtnet-0.9.0.tgz Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] networking
SERES Lucian wrote: > > Hi there! > I want to use RTLinux as suport in a distributed Realtime Java > application.Is there a modull which I can use to send/recive data in a > network? I only know about the rt_com modull, but I don't know if there is a > modull which has the same behaviour like socket, and so on, from the > traditional Linux. > Thank's a lot. Hi Lucian, If what you need is UDP/IP from a berkley sockets API, then take a look at: ftp://ftp.lineoisg.com/pub/rtnet/rtnet-0.9.0.tgz Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTLinux without MMU CPU
Mukaila olundegun wrote: > > RTLers, > > I have a cpu board that has no MMU (memory management unit) as a target > machine. Please I want to know if RTLinux will run on cpu which has no > internal MMU. > Hi Mukaila, A port of RTLinux 0.9 was done for uClinux by Kwonsk/Berhard, take a look at http://www.uclinux.org/ Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] debugging a module
Hi RTers, The debuggers available (zentropix/fsmlabs) are both based on gdbstubs (maintained by David Grothe, ftp.gcom.com). To work with modules, gdbstubs was enhanced by zentropix over a year ago to reply to the qOffsets with the correct sections for the modules (text, data and bss), the fsmlabs version works the same way, but can be used locally via fifos rather than a serial connection. The problem with this approach is that the offset is applied globally, and so only one module can be correctly debugged at a time. At the time I originally made the changes, I looked into the add-symbol-file command to allow multiple modules to be debugged, but this wasn't working. Since then, a lot of progress has been made by the gdb and gdbstubs team, and this feature seems to mostly work. We are currently working on using this method to allow multiple modules to be concurrently debugged. There are some problems to be resolved (it doesn't seem to work on some versions of gdb), but it looks promising. Until this approach is used, I think that you will be limited to debugging a single module at a time. Regards, Stuart Pavel Andris wrote: > > On Wed, Aug 02, 2000 at 09:29:57AM +0800, Wei Ren wrote: > > hi, > >I get some problem like that. I want to trace into some other modules use "s", >but I failed. > >I write some module A, and module B . The task created by module B called some >function in module A. > >I compile both modules with -g flag. > > Does the debug module support multi-module debug? > > > > Hi Wei, > > I'm afraid we are to wait for a reply by Michael Barabanov, the highest > authority. Which version of RTL, gdb do you use? I made my experience > with RTL 2.3 and 3.0, gdb version 5.0. It was mentioned in this list > an older version of gdb may help. I'm going to try. > > Regards, > pa > -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] 3.0 pre6d questions (psc and debugger)
Stuart Warren wrote: > > I've been trying out the rtl_sigaction feature of RTL3.0 pre6d. It > works nicely except for an occasional exception 14 occurring in the > psc.o module. I'd like to debug this but when I follow the instructions > and use remote target /dev/rtf10, gdb does nothing (ie no prompt, as > reported by Stuart Hughes in April). So... > > o What is exception 14? (The comments in the > rtl_debug code help with other exceptions > but not 14). > o Has anyone had similar problems with psc.o? > o pre6e has a lot of changes to psc.c. Are > any of these fixes or just new features > (is there a changelog?) > o Can anyone give me some pointers on getting > GDB to run (I _did_ follow the readme)? > Hi Stuart, Exception 14 is a page fault. Also note that I've found problems in general with gdb-4.18 and gdbstubs with respect to offsets and file positions not matching, switching to 4.16 fixed this for me (on gdbstubs). This may have a similar interaction with the RTL debugger, as that too is based on gdbstubs. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] pthread_wait_np
eric wrote: > > Does my thread really have to be periodic in order to use > pthread_wait_np? > I have created a thread that does something when my interrupt routine > ends, > and it isn't periodic but waits to be killed (woken up) by the isr. Now > i > see in the doco's for pthread wait that "the thread was previously > marked for execution using pthread_make_periodic_np" I think this is a > mistatement? > thanks, > eric "hopefully i am now 2k compliant" keller Hi Erik, I think it does have to be periodic to use this. If you just want to go into suspension, use pthread_suspend_np() Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] MIPS,
Hi Cort, Which eval board/processor, we may have one at another site and be able to get someone to test it. Regards, Stuart. [EMAIL PROTECTED] wrote: > > It will only run on an eval board we have, right. Indy doesn't work yet. > The hooks for each MIPS arch will be different since each Linux/MIPS > machine has a different irq.c. I've updated one port to work with the > modern irq_desc_t structure (just like PPC). I think it's possible to > combine all the Linux/MIPS irq.c files in a way similar to what I've done > on PPC. Good for Linux/MIPS, good for RTLinux/MIPS. > > If you'd be willing to try it out and make some tweaks on the Indy (we > don't have one) I'd be happy to work with you on it. > > } Am I correct that this will only run on an Indy? If not, I have an Indigo > } and an Indigo2 available. > } > } Norm > } > } At 09:38 PM 7/21/2000 -0600, [EMAIL PROTECTED] wrote: > } >Any enormously brave MIPS users out there who want to beta test > } >RTLinux/MIPS ? > } > > } > > } > > } >-- > } > > } >- > } >Victor Yodaiken > } >FSMLabs: www.fsmlabs.com www.rtlinux.com > } >FSMLabs is a servicemark and a service of > } >VJY Associates L.L.C, New Mexico. > } > > } >-- [rtl] --- > } >To unsubscribe: > } >echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > } >echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > } >--- > } >For more information on Real-Time Linux see: > } >http://www.rtlinux.org/rtlinux/ > } > > } > > } -- [rtl] --- > } To unsubscribe: > } echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > } echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > } --- > } For more information on Real-Time Linux see: > } http://www.rtlinux.org/rtlinux/ > -- [rtl] --- > To unsubscribe: > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > --- > For more information on Real-Time Linux see: > http://www.rtlinux.org/rtlinux/ -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RT and the VGA
daniel sheltraw wrote:
>
> Hello realtimers
>
> I have a function which writes to video memory in kernel-space (and the
> palette registers) after setting up the video mode using SVAGlib in
> user-space. I have used this function previously in a non-RT kernel
> module where it worked as expected. Now I am trying to use the same
> function in a RT kernel module and it keeps locking up my machine. So
> my question is: Is there some reason that I should not be able to write
> to video memory (at 0xA) under RTAI (or RTL)?
>
Hi Daniel,
In in the 2.2 kernels, you need to use the following to adjust the
physical address to the kernel virtual address as shown:
int init_module(void)
{
int err;
#if LINUX_VERSION_CODE >= 0x20100
GM = phys_to_virt(0xA);
#else
GM = (char *)0xA;
#endif
Regards, Stuart.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI interrupts
daniel sheltraw wrote: > > Hello RTAIers > > Two questions: > > (1) Do RT interrupts always interrupt any RT task or is there some > dependence on the priority level set for the task? > Yes, as long as interrupts are not masked. > (2) What does rt_free_linux_irq() do and why is it needed? Would > you please give me an example of when it might be used. If you add a handler to a linux irq by using rt_request_linux_irq, you need to free it when you're done. You do this using rt_free_linux_irq. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] upgrade
daniel sheltraw wrote: > > RTAIers > > I need to upgrade irrespective of the present difficulties that I am having > with fifo handlers and task resumes. > > So should I use AtomicRTAI floppy install? Hi Daniel, You could use that but it is a cut-down distribution, why not use the regular 1.3 release from http://www.rtai.org/ ?? Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] what is a PC104?
Ossi Laakkonen wrote: > > leeyang wrote: > > > > I always notice that when mentioned embeded hardware,"pc104" is talked >about.Howerver > I have no idea.Is it a kind of keyboard? > > Perhaps you should check http://www.pc104.org/ > > -- > Ossi PC-104 refers to a type of form-factor for a PC mother board. Think of them a small PC boards (about 3.5 inches square). Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] fifo question user space create is OK
Hi Herman, All valid points. I don't think it is a huge issue, both approaches are valid. The portable/newfifos is a superset of the RTL fifos and so the same API applies to the common set. If it has all the features you need, use the RTL version as it is smaller, if you need the extended functions (also has IPC's) use the portable version. The only idea is to offer something in addition, and that was common to RTL/RTL. Note the next release has named fifos, I hope this may be useful to all RTL/RTAI, and I hope if it is seen as useful it can become natively available in RTL too in a compatible way. Regards, Stuart Herman Bruyninckx wrote: > > On Thu, 13 Jul 2000, Phil Wilshire wrote: > > Phil, > > I hope you can comment on my comment on this post of yours... > > > The zentropix package ( Yes I do work for them ) allows you to create a > > fifo from a user space program. > [...] > > > To make them easier to use, fifos can now be created by the user at > > > open time. If a fifo that does not exist already is opened, it is > > > created with a 1K buffer. Any following creation on modules side > > > resizes it without any loss of data. Again if you want to create a > > > fifo from the user side with a desired buffer size you can use: - > > > rtf_open_sized(const char *dev, perm, size). > > ... in combination with Victor Yodaiken's independent reply to the > original post, in which he (Victor) claims that the RTL approach is > ``easier to use'' because it is clear and simple... > > All depends on the definition of ``easier to use'' of course... My (very > non-authorative) ideas and questions about this issue: > > - A `feature' like ``If a fifo that does not exist already is opened, > it is created with a 1K buffer'' carries IMHO the danger that is > found all over the place in so-called ``user friendly'' software: > the fact that the fifo does not exist already and the user tries to > access it nevertheless looks (to me at least) very much like a > programming error from the user, and ``hiding'' this error from the > user by not telling him and using a default _will_ give problems > later on (which will be _much_ more difficult to trace...). > > - Moreover, the 1K default is another source of potential errors: for > example, a user writes a first program, using a fifo created by default > and the buffer size doesn't create problems _for that particular_ > program. He thinks ``waw, nice feature, doesn't have to bother about > fifos ever again'', and the next time he writes another program > (needing much more than a 1K buffer!) and oops, program doesn't work > anymore... > > - as a user the most ``user friendly'' thing I can imagine is _one single_ > well defined and well documented and unambiguous way to work with a > given concept (i.c. fifos)... I don't know how this is solvable in > the RTL-RTAI world ;-) Through the ``common API'' initiative perhaps? > > - is the fifo created from user space (by default or not) fully > compatible with the real time space view on this same fifo? > I mean: can any real time task work with this fifo without having to > know how it was created? Same question for a user space task. > (Sorry, but I didn't look at the details of all the fifo code in all > different packages...) > > -- > [EMAIL PROTECTED] (Ph.D.)Fax: +32-(0)16-32 29 87 > Dept. Mechanical Eng., Div. PMA, Katholieke Universiteit Leuven, Belgium > > -- [rtl] --- > To unsubscribe: > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > echo "unsubscribe rtl " | mail [EMAIL PROTECTED] > --- > For more information on Real-Time Linux see: > http://www.rtlinux.org/rtlinux/ -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] fifo question user space create is OK
Phil Wilshire wrote: > > > The zentropix package ( Yes I do work for them ) allows you to create a > fifo from a user space program. > ( see ftp://www.zentropix.com/pub/downloads/rtai_rtl_fifos-05.tar.gz ) > > This may be of interest to you. > Hi Phil, Just so people are not misled, this package was derived from Paolo's newfifos. The difference is that it has some macros at the top to wrap the RT API's so it can be used from RTL or RTAI. BTW: We have added some better regression test, and a named fifos interface, this will be released soon. Regards, Stuart. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] contiguous shared memory
daniel sheltraw wrote: > > Hello realtimers > > My understanding of shared memory under RT Linux is that it uses > vmalloc to allocate memory and therefore this memory may not be > suitable for DMA (the memory is not guaranteed contiguous). > > (1) Is this the truth, the whole truth and nothing but the truth? Yes it is true, but I think there is a way to make it DMA safe in the upcomming 2.4 kernels. > (2) Is there someway to use the shared memory implementation in a > manner suitable for DMA? Use the old style method of append="mem=xxxm" in your lilo.conf to reserve some high memory and then use mmap in userland (using /dev/mem) and ioremap in the kernel giving both the fixed address of the reserved memory. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] strictly frank
Emeel wrote: > i have not yet worked out how the data is transfered from the fifos that > were written to in the thread code to the files /dev/rtfx... that were > printed out in the end. > can anyone please let me know? > > thanks in advance. > Hi Emeel, What is actually happing is that the rtf device driver stores a copy of the data written by the rtf_put in a buffer for the /dev/rtfx (minor node) actually. There is not real file involved, just the special device inode. Roughly, when the user code calls read, a trap to kernel space is made, and the driver associated with rtfx is called, at this point the data stored in the per-fifo buffer is copied to the user space programs buffer referenced by the read call, on return from the kernel the user buffer will have the fifo data available for printing. Take a look at Linux device drivers by Alessandro Rubini, this gives a clear picture of kernel drivers (although a bit out of date wrt current kernel versions, I think a second edition should be out 'real soon') Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Is RTLinux pre-emptable?
[EMAIL PROTECTED] wrote: > > > > > Hi Victor, > > > > Is there any way to make it do the following: > > > > lower priority tash runs: > > interrupt occurs and ISR wakes up higher priority task: > > ISR exits > > immediate rt schedule > > higher priority task runs > > higher priority task ends > > lower priority task resumes and completes > > > > > > What I'm after is the re-schedule is pended and set-up to run > > immediately after the iret of the ISR. > > We were just discussing that and it is possible to do, but it has > a disadvantage and is not strictly necessary. > First, it's not needed because any ISR can safely cause the same effect > simply by following the design >isr_entry: >finish all hardware related activities > >pthread_wakeup_np(highprioritythread); >return; > > This is highly efficient and I can't see any cases where it does not > act like your scenario -- except it is faster. > Hi Victor, Thanks for the reply, I agree that for most cases what you suggest would be fine. What I'm thinking about is down the line where it may be possible to have a more traditional (from the point of view of things like pSOS etc) model where the ISR runs in a priviledged state, and the tasks/threads run in a user priviledge state. I guess it's probably best to worry about it then. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] insrtl and rmrtl problem
cooldesi takore wrote: > > hi.. i installed rtlinux-2.3 and i tried the examples > and when do the make > test in the examples ... it says "permission denied" > for insrtl and rmrtl > i changed the permissions of both from -rw--x--x(611) > to -rwx--x--x(711)... > i wanted to know if this is correct or has there been > a some kind of mistake in > my installation.. after the change the examples are > running... > thanx Hi, You need to be root to run insrtl as it inserts modules, changing permissions is not enough, you need to run the su command and then try again as root. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Is RTLinux pre-emptable?
[EMAIL PROTECTED] wrote: > > > This depends on the interrupt and interrupt handler. If the handler > calls rtl_Schedule (directly or indirectly) there will be an immediate > switch, but if not the switch wil be delayed until the scheduler runs > again. So > my_isr: > pthread_kill(highestprioritythread,RTL_SIG_WAKEUP); > return > > will return to the theard that was running when the interrupt came in, > and the resched will happen only during the next run of the scheduler > (at the latest, during the next timer interrupt). > But > my_funny_isr: > rtl_wakeup_np(higestprioritythread); > > will switch at once (unless the thread is on another CPU). > > Threads are preemptable and RTkernel services are > either atomic or preemptable. > > Hope that answers your question. > Hi Victor, Is there any way to make it do the following: lower priority tash runs: interrupt occurs and ISR wakes up higher priority task: ISR exits immediate rt schedule higher priority task runs higher priority task ends lower priority task resumes and completes What I'm after is the re-schedule is pended and set-up to run immediately after the iret of the ISR. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] rtf_put nonblocking?
Tobias Klotz wrote: > > Hello, > > I have a problem concerning the use of rtf_put using it like this: > > my_mem=new whatever; > rtf_put (FIFO, my_mem, sizeof(whatever)) > delete whatever; > > if i leave out the delete line everything works fine, but it is not that > smart to allocate memory in a realtime loop called every 5 ms without > freeing it again... > > my question is wether the call of rtf_put is blocking or nonblocking (if > it is nonblocking i can understand why this call can crash, otherways i > am a little confused... > Hi Tobias, >From the RT side, the calls are non-blocking. When you do an rtf_put, your data is copied (upto the limit of the free space) to the fifo buffer before you are returned. If there is sufficient space, you should be okay. How is the delete function implemented ?? maybe this is the cause of your problems. Regards, Stuart. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] rtfifos out of rttasks?
Ivan Martinez wrote: > > Hello all > I'm programing Control Lib to use a rtfifo to start rttasks execution. > The rtfifo has a handler that wakes the rrtasks up when executed. So > actually no rttask uses the rtfifo. > I could use a character device, but I don't like their interface (that > thing of major numbers). Also I don't know if they can have handlers. > Is what I'm doing dirty programing?. Thank you. > Hi Ivan, IMHO these seems fine to me. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] FSCK and power up
Hi Adam, If your footprint is not too large (e.g no X etc), another possibility is to build a root filesystem compressed image (for your system) and then boot the system as an initrd and run out of ramdisk. You will be safe to pull power without shutting down. To do this, you need to put the kernel that matches your compressed rootfs modules in the usual place (e.g /boot/ramkernel) and then add similar to following to your lilo.conf and re-run lilo. image=/boot/ramkernel label=ramsystem ramdisk=8192# depending on size initrd=/boot/rootfs.gz root=/dev/ram0 read-only If your footprint is large, Cort's suggestion seems like the best option. Regards, Stuart Cort Dougan wrote: > > You could try reiserfs. Several people have had good luck with it. > > } I have a embedded linux machine using RTLinux that does not have a power > } switch. When ac is > } applied it boots up and to power it down just pull the plug. However since > } we cannot properly shut > } down linux, everytime we do this the system goes through the long fsck process. > } > } Is there anyway to get around this without just disabling fsck on boot > } up. It would be nice if somehow > } an abnormal shutdown (like pulling the power), did not screw up the filesystem. > } > } Has anyone come up with any solutions. > } > } Any pointers would be greatly appreciated. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] bug with rt_use_fp
cauffret wrote: > > Hello, > My name is Cyrille AUFFRET, I am a student and a newcomer to RT Linux. > I am trying to use the 0.6 version of the RT Linux, since I have the > 2.0.33 version of the Linux Kernel. > Using the example program that have been provided /testing/fp , I've > got a problem with rt_use_fp function. > While running the application I receive an error message : > > rt_use_fp undefined > Loading failed! The module symbols (from linux-2.0.33) don't match your > > linux-2.0.33 Hi Cyrille, You need to insert the RTL modules first, take a look at the example code that comes with the distribution. You may want to upgrade to a newer Linux kernel, and a newer RTL/RTAI distribution. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Soft Real Time
[EMAIL PROTECTED] wrote: > > On Mon, Jun 26, 2000 at 01:18:21PM -0500, Mike Cravens wrote: > > Could you encourage more participation in the porting process by others > > interested in keeping the source open? > > > > If you close the source, I might as well use VxWorks. > > I am not closing the source. Please note that there are new GPL releases > of RTLinux on our web site nearly every week. We have a long > track record of delivering GPL code. Longer than anyone else in this > area, by some years. > > > Many people are just arriving at the real-time and embedded party. > > > > Getting people to contribute commits them in ways beyond money and economics. > > > > There are some things that die if you hold them too tightly. > > Contributed source and ports are great. Please send 'em. > What we've found is that most RTLinux users want to work on their > own apps. RT kernel code is really specialized. > If you look at the credits file sent with RTLinux, you will > see that there are some exceptions -- and I, for one, really appreciate them. > Tomasz, Jerry, and others have been critical. What I have rejected, > and will continue to reject are changes that I think are technically > wrong, poorly done, or violate the base paradigm. An advantage of > open source is that others who disagree are free to pursue their own > path. And if their ideas turn out to be good, we may even change our > minds. A good example of how this works is the Linux fbcon component > that came after a conceptually similar but weak alternate method > was rejected. Hi Victor, If RTLinux is truly GPL, can you state clearly that the patent described in the RTLinux distribution will only be used defensively, and not as a means to: a) place restrictions on derivative works b) to force royalty payments from either RTLinux or derivatives. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] real-time function parameters and return value
Ivan Martinez wrote: > > Hello all: > Can the parameters of a function executed as a real time thread be > other than "void *"?. Can the returning value be other than "void *"?. > Thank you. Hi Ivan, You can use whatever you like as long as the size fits and you use the appropriate casts to keep the compiler quiet. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Chrash using network
npace wrote: > > After I insert modules for RTAI/LXRT (rtai, rtai_sched, lxrt), If I try to > download a file via ftp to my target, the system always crash with a kernel panic. >Crashes happen > for rather large file (> 500K), for small file transfers seem to work. > I am using RTAI1.3, Linux 2.2.14, and the upscheduler on a 486/100 embedded board >with 16M ram, no swap disk. > The network chipset is a PCI Realtek 8139. Note that I have no realtime user >process/tasks module active > (only the core module installed). If I don't install the realtime modules the system > works fine. > > What could I do ? > > Best regards > Eng. Nicola Pace > > Hi Nicolo, Do you have a hard drive in the system or is it loading to a RAM disk ?? Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts in another aspect
[EMAIL PROTECTED] wrote: > > > > I think there is a miscommunication here. If you mean the 'current' as > > in Linux terms (e.g current->pid) then yes of course that may refer to a > > low priory (Linux) task/process. > > No. 'current' means the actual version of RT-Linux (2.x). Ok, got it now :-) > > > > I think I understand ? What was being said is that if you are in an > > hard interrupt handler, and you use pthread_wakeup_np (or similar in > > RTAI) to call the scheduler, the new RT thread runs before you exit the > > ISR. > > Yes, this is the situation. > > > Victor was saying that depending an what you call, you can change the > > behavior to let the ISR finish and then have the RT task/thread run > > (pthread_mutex_unlock), this may be what you need. > > I use a "library function" that calls pthread_wakeup_np(). > I do not want to rewrite everything. Tricky, I'm not sure what your options are. > > > Sorry if I was confusing. It's all clear now. > I wrote my mail not for asking help to solve a given problem > but I suggested a possible improvement of RTLinux IRQ handling scheme. > Is this forum is not adequate for discussing principal issues? ;-) I think its a good forum for this. > > (My program works well since I realized what happens.) > Well I think by now most people will know what to expect after all these mails :-) Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts in another aspect
Hi Gabor, [EMAIL PROTECTED] wrote: > > > a *hardware* priority, this is unrelated to the concept of the priority > > of threads. Usually, when an interrupt occurs, it interrrupts whatever > > is running provided that a) interrupts are enabled, b) if currently in > > an ISR, the hardware priority of the new interrupt is higher than the > > current interrupt priority (implementation is architecture dependant). > > This is your wish or the reality? ;-) I think there is a miscommunication here. If you mean the 'current' as in Linux terms (e.g current->pid) then yes of course that may refer to a low priory (Linux) task/process. What I say above *is* reality, but I'm not referring to Linux in particular. I'm trying to point out that generally there is a marked difference in context between a true interrupt handler, and that which it interrupts (provided it is not already in an ISR). > > We were speaking so far, that ISRs run long because threads awaken > by them grabs the CPU. I think I understand ? What was being said is that if you are in an hard interrupt handler, and you use pthread_wakeup_np (or similar in RTAI) to call the scheduler, the new RT thread runs before you exit the ISR. Victor was saying that depending an what you call, you can change the behavior to let the ISR finish and then have the RT task/thread run (pthread_mutex_unlock), this may be what you need. > > Now I have such an ISR. There can be occur such a situation, > that it runs in two instances because the first one is delayed > by a high priority thread, meanwhile the hardware IRQ is delivered > again. You need to make sure that the thread is outside ISR context (I think ?). Fundamentally you need to make sure that you have time to complete the thread work before the next re-run request occurs (is that correct ?, I'm guessing you want to avoid reentrancy) Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts in another aspect
Hi Gabor, [EMAIL PROTECTED] wrote: > > > Personally I think the concept of "interrupt routines are pseudo-threads > with random priority" is not fortunate enough. > > Did I misunderstand something? AFAIK when an interrupt occurs > its handler is started as an implicit thread inheriting its priority > from the interrupted thread. The most possible interrupted thread is > the the Linux itself which has minus infinite priority. That means > that an ISR will run probably the lowest priority. > No, this is not a good assumption. Classically, an interrupt handler has a *hardware* priority, this is unrelated to the concept of the priority of threads. Usually, when an interrupt occurs, it interrrupts whatever is running provided that a) interrupts are enabled, b) if currently in an ISR, the hardware priority of the new interrupt is higher than the current interrupt priority (implementation is architecture dependant). This is why you should picture interrupts in a separate way to thread priority. Thread priority is implemented purely by the software scheduler (it decides which thread should run based on data in a per-thread structure). Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
[EMAIL PROTECTED] wrote: > > On Thu, Jun 22, 2000 at 11:49:52AM +0100, Stuart Hughes wrote: > > Victor Yodaiken wrote: > > Hi Victor, > > > > pthread_kill may be standard, but AFAIK the signal you use here is not. > > That is because having Linux run as a thread is unique to RTLinux. > > Our aim is not to pretend to be a standard nonrealtime POSIX, but to > make the api conform to POSIX standard as far as possible. POSIX permits > any number of signals and this extension is therefore within the standard > and seems to me to be a sensible extension. If you have a better idea > or even a good complaint, I'd be happy to hear it. What is a good complaint ??? doesn't the 'P' in POSIX stand for portable ? What you continually offer is non-portable extensions that make it impossible to run the same code on any environment other than RTLinux. A better idea might be to use what exists so that we all have a chance of running our code on a number of operating systems. May I suggest that a SIGHUP may be construed as a wakeup signal to a thread (it has been used context before), this may be bogus too, but you get the idea: try to use something that has a chance of being portable. Regards Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Memory needs
"Wayne E. Van Loon Sr." wrote:
>
> Hello rtl users.
> I am beginning a project where I would like to use a rtl process as both a rt
>process and a driver for 4 ea. bt848 devices. I need 12 buffers of 172,800 bytes ea.
>and each buffer needs to be DMA capable (consecutive physical addresses). I could
>live with the buffers being fragmented - meaning that each buffer might in turn be
>composed of smaller buffers - but it would make more sense (to me) if each buffer was
>the size that was really needed. I mention this because it is also my understanding
>that the maximum memory that can be allocated at any one time using get_free_page ()
>is 128KB.
>
> I wish to do all processing in a Linux process. So it would be real nice if I could
>also access the buffers from my Linux process rather than having rtl (or a driver)
>set up the bt848 DMA controllers and then have to copy the buffers to another set of
>12 buffers in user-land. Sounds like a candidate for shared memory, except that it is
>my understanding that memory allocated for shared memory is not physically
>consecutive and therefore not DMA capable.
>
> One way that I hear of to do this might be to use the mem = at boot time ,
>reserving the upper 2 MB of ram for my buffers and then hard code carve it up into
>the buffers that I need. I don't have any idea if these buffers could somehow be
>accessed from user-land or whether they would have to be copy_to_user()'d or similar.
>
> Any suggestions? Good places to look and learn? Also, any corrections of my
>(mis)understandings would be greatly appreciated.
>
Hi Wayne,
Your final suggestion is the one I would use (it is less efficient than
vremap, but doesn't suffer framentation). You can get at this memory
from the Linux kernel using ioremap, and from userspace using mmap.
To do this in lilo.conf, reserve some memory (run lilo afterwards)
append="mem=xxxm"
where xxx is 2 Megs less than you have (yuk!!)
In user space:
void *map_shared_mem(int mem_os_mb)
{
int mem_fd;
void *ptr = NULL;
if(( mem_fd = open("/dev/mem", O_RDWR)) < 0)
err_abort(errno,"Open /dev/mem");
ptr = (void *) mmap(0,
SHM_SIZE,
PROT_READ | PROT_WRITE, MAP_FILE |
MAP_SHARED,
mem_fd, mem_os_mb * 0x10 );
if( ptr == MAP_FAILED )
err_abort(errno, "mmap shared memory");
close(mem_fd);
return ptr;
}
In kernel space:
#if LINUX_VERSION_CODE < 0x020100
#include// vremap
#define ioremap vremap
#define iounmap vfree
#else
#include // ioremap
#endif
volatile void *ptr;
ptr = (void *)ioemap(mem_os * 0x10, SHM_SIZE);
Regards, Stuart
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
Victor Yodaiken wrote: > > On Tue, Jun 20, 2000 at 09:54:18AM -0700, Pascal Charest wrote: > > Hi, > > > > So, if I can't call Linux interrupt handler within an RTAI handler, can > > I use two independant handlers ; one from RTAI and the other from Linux? > > It is trivial to call a Linux interrupt handler from RTLinux. > But in RTLinux you do: >pthread_kill(rtl_get_linux_thread(cpunumber), RTL_LINUX_MIN_SIGNAL+irq) > > in pre 2.3 you need the simpler seeming, but nonstandard: > > rtl_global_pend_irq(irq); > Hi Victor, pthread_kill may be standard, but AFAIK the signal you use here is not. Is this just not a 'smoke and mirrors' approach to appear like you are following the POSIX standard ?? If I'm wrong, please accept my apologies, if I'm right then shouldn't we *all* try to come up with an existing standard way that can be implemented for RTLinux/RTAI ?? Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
Victor Yodaiken wrote: > > My opinion is that a multi-millisecond ISR is generally not a good idea. Agreed. Aside from all the other issues, one thing should be clear as a matter of general design philosophy: true interrupt handlers should be kept brief. Regards, Stuart. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
Victor Yodaiken wrote: > > > I think you're correct (RTL & RTAI). IMHO it should be changed so there > > is a way to pend a task to run only when an ISR has exited. > > That is exactly what pthread_kill WAKEUP is for. > We have designed pthread_kill to be extremely fast and lightweight and to > not call the scheduler. Is this signal (RTL_SIG_WAKEUP) portable ??? if not I prefer your other suggestion. > > But pthread_mutex_unlock also does not call the scheduler and for > exactly this reason. This seems like a better way to go. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI upgrade question and more
Hi Daniel, daniel sheltraw wrote: > > Hello RTAI world > > I am ready to upgrade from RTAI 0.7 to the latest stable version of RTAI. > Would someone please tell me which version that would be. Also rtai-1.3 from http://www.rtai.org/ > would you tell me how to best do an upgrade or point out any difficulties > they may have had upgrading. Does RTAI have a CD for a more recent version > yet? > You need to get a fresh 2.2.14, run the copyto and then build rtai. Move the modules to /lib/modules/2.2.14/misc and then run depmod -a. No CD just yet... > This has got to be the best linux related mailing list in existence. > I have dealt with a few others very recently and the smugness and > cockyness of the participants of those sites drove me away from > their product. Despite the heated exchanges sometimes, to me it resembles a health marriage :-) > > I have volunteered my services for any manual editing/writing that might be > needed for the RT effort. Please let me know if there is more I can do. > Thanks... Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
Arnaud Westenberg wrote: > > Stuart Hughes wrote: > > > One point I want to make is that there is a good reason why often people > > would choose to have an ISR wake up a real-time task to carry out the > > bulk of a set of processing. On most other real-time operating systems, > > the task that gets woken from the ISR runs at a lower privilege level > > than an ISR (in terms of machine state), also interrupts are normally > > enabled. This means that the task can be pre-empted by other real-time > > tasks and also interrupted. In the Linux (hard) real-time > > implementations (RTL/RTAI) this is not currently true, as I believe that > > the task/thread runs at the same machine privilege level as the ISR. > > This is not correct, I asked this question recently. Here's the question > and victor's reply: > > Q: Does a "hard" handler stop a RT thread? (I would say yes) How are the > Q: "priorities" between hard handlers and RT threads determined by > RTLinux? > > A: Hard handlers preempt anything that is not running with hard > interrupts > A: disabled. There is no other priority mechanism. > > So RT threads will be interrupted by the handler. > Hi Arnaud, The real question is if I have an ISR whos only task is to wake up a thead, what happens: a) enter ISR, wakeup thread, thread code runs, return to ISR, exit ISR or: b) enter ISR, wakeup thread, exit ISR, thead code runs. I'm saying that b) is more conventional, and I would like to have this facility available. Regards, Stuart. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
JunHyeok Heo wrote:
>
> Hi! pascal.
>
> First of all, I am sorry for missing your first letter and i had no experience of
>RTAI.
> I am going to explain what i am thinking as a solution in case of RTL.
> I hope you can use RTL instead of RTAI.
You can do this in either system in almost the same way
> But the following method is not verified.
>
> 1. Install your linux interrupt handler as a soft interrupt handler using
>'rtl_get_soft_irq()'
> 2. In real-time interrupt handler, use 'rtl_global_pend_irq()' to call your linux
>interrupt handler.
For RTAI (as Karim said)
rt_request_linux_irq()
rt_pend_linux_irq()
Regards, Stuart
>
> - Original Message -
> From: "Pascal Charest" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, June 21, 2000 1:54 AM
> Subject: Re: [rtl] Interrupts
>
> > Hi,
> >
> > So, if I can't call Linux interrupt handler within an RTAI handler, can
> > I use two independant handlers ; one from RTAI and the other from Linux?
> >
> > I've a driver that uses Linux interrupt handler. Then, I want a
> > realtime process that is calling by the same interrupt. When I'm using
> > rt_request_global_irq() and doing nothing in my handler, the system
> > restart or all is ok ; it depends of the Linux driver I use.
> >
> > How can I activate, if I can, Linux handler using the same irq? I've
> > used rt_pend_linux_irq() in my handler but it may crash too.
> >
> > Pascal
> > Charest
> >
> > Karim Yaghmour wrote:
> > >
> > > Hello Pascal,
> > >
> > > I beleive the problem comes from the fact that you are calling the
> > > Linux interrupt handler from within an RTAI handler. Since Linux
> > > interrupt handlers might call on lock mechanisms redirected by
> > > RTAI, this is where things get messy.
> > >
> > > Rather than using rt_request_global_irq(), try using rt_request_linux_irq().
> > > What this will do is add your handler to the list of handlers linux
> > > will call when the IRQ happens. Therefore, the normal handler gets
> > > called and so does yours. Your handler can then use RTAI locking
> > > mechanisms to do it's work.
> > >
> > > This is actually currently used from within the RTAI schedulers to
> > > try recovering lost jiffies (this is from start_rt_timer in the upscheduler):
> > > rt_request_linux_irq(TIMER_8254_IRQ, recover_jiffies, "rtai_sched",
>recover_jiffies);
> > >
> > > The recover_jiffies function now gets called every time a timer
> > > interrupt gets to Linux.
> > >
> > > J'espere que ca pourra vous aider ...
> > >
> > > Karim
> > >
> > > Pascal Charest wrote:
> > > >
> > > > Hi,
> > > >
> > > > I'm trying to catch interruptions with rtai and forcing the linux
> > > > interrupt handler, but I don't know how to do it correctly. In fact, I
> > > > want to use different drivers with my rt_process and to make them
> > > > realtime without changing their code. There is a example of what I want
> > > > to do :
> > > >
> > > > void handler(int irq)
> > > > {
> > > > ... forcing linux interrupt handler
> > > > ... doing my own work
> > > > }
> > > >
> > > > int init_module()
> > > > {
> > > > ...
> > > > rt_request_global_irq(IRQ, (void*)handler);
> > > > rt_startup_irq(IRQ);
> > > > ...
> > > > }
> > > >
> > > > When I try something, linux stops or the computer restarts when the
> > > > interrupt occurs ; it depends of the rt fonctions I use in my handler.
> > > > Do someone know how to do it?
> > > >
> > > > Thanks in advance,
> > > >
> > > > Pascal Charest
> > > > -- [rtl] ---
> > > > To unsubscribe:
> > > > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> > > > echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
> > > > ---
> > > > For more information on Real-Time Linux see:
> > > > http://www.rtlinux.org/rtlinux/
> > >
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl " | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
"Stephen D. Cohen" wrote: > > Stuart Et. Al., > > > I may be mistaken, but I think in RTAI/RTL, you can set a > > semaphore from > > within the ISR, exit and on exit the real-time task/thread > > will run its > > code. If it doesn't work this way, it would be nice to have this > > facility available as this is typical of the sort of thing I > > used to do > > with pSOS. > > That is exactly the same structure I used in VxWorks. I was under > the impression, from messages on the list, that this did not work in RTL. > > As far as semaphores go, I demand a stable base for RTL, so I am > still using RTL 2.2 on Linux 2.2-14. This version does not contain > semaphores as near as I can tell. I am also not certain that semaphores > work as expected in V3. Anybody want to fill us in (after answering my > original question)? > Have you looked at RTAI, this has semaphores, mailboxes etc ?? > It seems to me that the semaphore handling routines should simply > check to see if anyone is waiting for a semaphore (when it is given) and, if > so, call the scheduler. The scheduler should also be called on return from > every interrupt. Is this the case? > I think you're correct (RTL & RTAI). IMHO it should be changed so there is a way to pend a task to run only when an ISR has exited. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
eric keller wrote: > > I would like to point out that an interrupt based approach, where the most > important > stuff happens in the ISR is a perfectly viable approach. If a task _must_ get > done > before the next interrupt, then you may as well do it in the ISR. I cannot see > any > advantage in scheduling a thread to clean up after an ISR each time the ISR > runs, > unless that cleanup is not as critical as the interrupt. > > In my case i want my controller to run in an ISR, which means that I'm going to > use > fp in my ISR. I really don't see anything wrong with that on the processors i > am > using. If it becomes a problem with future processors, maybe i'll have to > switch > to a DSP or other processor where the fpu is not cobbled on like it is on the > i386. > > I think the idea that you shouldn't use fp in kernal mode makes a lot of sense > for > linux and no sense at all for a RTOS. > eric > Hi Erik, I agree with your points. Each design may have different constraints and so sometimes you may wish to do FP in an ISR. Nothing should be forbidden if one has sound reasons for making a particular design choice. One point I want to make is that there is a good reason why often people would choose to have an ISR wake up a real-time task to carry out the bulk of a set of processing. On most other real-time operating systems, the task that gets woken from the ISR runs at a lower privilege level than an ISR (in terms of machine state), also interrupts are normally enabled. This means that the task can be pre-empted by other real-time tasks and also interrupted. In the Linux (hard) real-time implementations (RTL/RTAI) this is not currently true, as I believe that the task/thread runs at the same machine privilege level as the ISR. So for real-time Linux it is currently less important than on other RTOS's to make the ISR/task distinction, but things may change in the future, so keeping this in mind may help to produce a design that will be more conventional: a) if real-time Linux changes b) if you port to other real-time operating systems Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Floating point in "restricted" code
"Stephen D. Cohen" wrote: > > Victor Et. Al., > > You recently wrote: > > > 1. Saving fp state is _slow_ so you don't need it in an ISR > > -- there is no performance loss > >in having the ISR hand over work to a thread. > > I have been trying to figure out how to do this for some time. > Would you please provide a code fragment or clear explanation of how to have > an ISR cause a thread to become computable? > > I thought it would be correct to simply have the thread sleep until > it gets woken up by the ISR, but I am told that this will cause the thread > to run in the ISR context. That is, obviously, not what we want. I want to > get in and out of ISR context just as quickly as possible, but cause another > thread to become computable (a high priority hardware handler responding to > the interrupt, for example). > > Any suggestions? > > Confusedly Yours, > Hi Stephen, I may be mistaken, but I think in RTAI/RTL, you can set a semaphore from within the ISR, exit and on exit the real-time task/thread will run its code. If it doesn't work this way, it would be nice to have this facility available as this is typical of the sort of thing I used to do with pSOS. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] fifo handlers
Daniel Krippner wrote: > > Greetings! > > Question: in the manpages it says that a handler installed with > rtf_create_handler is "executed when data is written to or read from a > real-time fifo" . Just what I need. > Problem is, the handler I installed in my module only gets called when I > write data to the fifo, not when I try to read from it (user space). > Am I being stupid, got the concept wrong, or is there a way to get the > handler executed also when reading from the fifo? > thanks > Daniel > Hi Daniel, One thing to be aware of, the handler will run only when there is data to read. If there is no data, the user space process will block until there is data (unless you set it non-blocking), only when there is data in the fifo to read will the driver wake up and then run your handler. Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] more RTAI and OSS
daniel sheltraw wrote: > > Hello RTAI world > > I am having difficulty with getting OSS (open sound system) installed > on my machine running RTAI version 0.7 (I know I should upgrade but > one problem at a time). The following is there most recent suggestion > for correcting what appears to be a versioning problem. Would someone > tell me whether RTAI will work after this proposed solution. > > Thanks everyone, > Daniel Sheltraw > > You should definitely try to remove the -rtai in the EXTRAVERSION field > of > /usr/src/linux/Makefile and then recompile the kernels as follows: Hi Daniel, I don't think RTAI 0.7 had the -rtai added to the Linux make file. The easiest way to tell is to do 'uname -r' (if you're running this kernel) and see if it has the suffix -rtai. If it does, the to get rid of it, do as suggested in the text you sent (edit the Linux makefile, and remove the -rtai from the EXTRAVERSION field. Warning: if you do this, and you have some other plain linux 2.2.14 kernel, you will overwrite your modules when you do a make modules_install after building the kernel/modules, if you don't want this to happen, make sure to move them to a safe name first (e.g mv /lib/modules/2.2.14 /lib/modules/2.2.14-june20) Regard, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
