Re: [rtl] kernel memory limit
On Thu, Apr 19, 2001 at 05:41:27PM -0700, Basham, Richard R wrote: Hello all, I am trying to use mbuff to allocate several named shared memory buffers from a kernel module. I have 1 G of memory but I can't seem to allocate more than somewhere just below 64 M of named shared memory from a kernel module. If I use malloc from user space I can allocate nearly all of the 1 G. It appears that this has something to do with a kernel limit. Has anyone come across this? Have you found a way around the limit? Hmmm... I thought the minimum reserved for vmalloc was 128 MB. The Linux kernel uses addresses above 0xc000 for it's own use. Into this area, it needs to map PCI space, the kernel code and data, vmalloc()'d memory, etc. Some kernels also have a 1-1 mapping of RAM in this area. Naturally, since the area above 0xc000 is 1 GB large, and you have 1 GB of RAM, there's not going to much space for anything else. If you enable CONFIG_HIGHMEM, it will only map physical RAM that it needs, and more of the address range is available for vmalloc, but unfortunately, this option is not available on 2.2. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Re: [realtime] ESC attendence ... ?
On Fri, Apr 13, 2001 at 01:36:59AM -0400, Peter Cavender wrote: Because they are not a "real" company, just a couple of people hoping to reap dot-com profits from a patent based on ancient prior art. Do not confuse them with any of the for-profit RT Linux outfits with real products, or any of the GPL patriots that are working on real-time support. All they want is a royalty check in the mailbox. They couldn't care less about trade shows or such. My advice is to ugnire FSMLabs and use RTAI. It is better anyway. :-) Your abilities to write flaimbait have not gone unnoticed. You even got me to respond -- I usually just read flamewars in amusement. Please do not attempt to advocate RTAI at the same time as bashing RTLinux and/or FSMlabs. RTAI discussion holds a relatively amicable position on this RTLinux mailing list, which we would like to keep. Contrary to popular belief, many of the RTAI developers have no specific dislike for RTLinux, and much of the software associated with RTAI also works with RTLinux. dave... (one of the RTAI maintainers) -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Linux equivalents to pthread_make_periodic_np and pthread_suspend_np
On Fri, Apr 13, 2001 at 09:22:14PM +0200, Ivan Martinez wrote:
Hello all:
I'm trying to make DSLib v2 generate adecuated system calls depending on it being
Linux, RTLinux, or RTAI. I'm looking in the Linux threads functions and I don't see
any equivalent to pthread_make_periodic_np and pthread_suspend_np. Is there any?. If
not, how can I perform such operations?.
Thank you.
Ivan Martinez
It can be duplicated using something similar to the attached
file.
dave...
/* Example of a periodic task using straight POSIX calls. */
/* Copyright 2001 David Schleef [EMAIL PROTECTED] */
/* Use, distribution, and modification are allowed under the LGPL. */
#include stdio.h
#include stdlib.h
#include sys/time.h
#include sys/types.h
#include unistd.h
#define PERIOD 10 /* 100 ms */
void tv_add_usec(struct timeval *tv,unsigned int usec);
int tv_compare(struct timeval *a,struct timeval *b);
void tv_sub(struct timeval *a,struct timeval *b);
int main(int argc,char *argv[])
{
struct timeval now;
struct timeval next_tick;
gettimeofday(next_tick,NULL);
tv_add_usec(next_tick,PERIOD);
while(1){
printf("tick\n");
gettimeofday(now,NULL);
if(tv_compare(next_tick,now)0){
struct timeval timeout;
timeout = next_tick;
tv_sub(timeout,now);
select(0,NULL,NULL,NULL,timeout);
}
tv_add_usec(next_tick,PERIOD);
}
}
void tv_add_usec(struct timeval *tv,unsigned int usec)
{
tv-tv_usec += usec;
while(tv-tv_usec=100){
tv-tv_usec -= 100;
tv-tv_sec ++;
}
}
int tv_compare(struct timeval *a,struct timeval *b)
{
if(a-tv_sec==b-tv_sec)return b-tv_usec-a-tv_usec;
return b-tv_sec-a-tv_sec;
}
void tv_sub(struct timeval *a,struct timeval *b)
{
a-tv_sec -= b-tv_sec;
if(a-tv_usec b-tv_usec){
a-tv_usec += 100;
a-tv_sec --;
}
a-tv_usec -= b-tv_usec;
}
Re: [rtl] Virus emails
On Tue, Apr 03, 2001 at 07:39:23PM +0200, Erwin Rol wrote: Isn't it slowly getting time that the RTL mailing list admins take responsibility and disable attachments ? It should suffice to bounce messages containing application/* mime types. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] driver for computerboards das1200/jr
On Thu, Mar 22, 2001 at 04:19:51PM +, Willem Atsma wrote: Does anyone know of a driver for this card, or if one of the other DAS drivers can be used for it? The cb_pcidas driver that is part of Comedi should work with it. http://stm.lbl.gov/comedi dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] comedi from kernel
On Fri, Mar 09, 2001 at 12:19:06PM -0800, Basham, Richard R wrote: Hi all, Does anyone have a short example of how to use comedi from a kernel module. I was hoping to get a short comparable example with the correct header files etc. Have you looked at ftp://stm.lbl.gov/pub/comedi/realtime_comedi_examples.tgz? dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] comedi from kernel
On Fri, Mar 09, 2001 at 03:52:36PM -0800, Basham, Richard R wrote: David, I had not seen them. Thanks. I did get them and found that they were setup for use under RTAI. I made what I thought were the correct changes for RTLinux. When I compiled them I got: Did you edit the Makefile to tell it where to find the Comedi include files? /sbin/insmod it.o it.o: unresolved symbol comedi_cancel it.o: unresolved symbol comedi_lock it.o: unresolved symbol comedi_command it.o: unresolved symbol comedi_register_callback it.o: unresolved symbol comedi_unlock it.o: unresolved symbol comedi_command_test modprobe kcomedilib dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Real-time drivers for NI 6703 analog output card...
(CC'd to [EMAIL PROTECTED]) On Wed, Feb 28, 2001 at 12:04:56PM +0100, Herman Bruyninckx wrote: I need a driver for the National Instruments PCI-based analog output board 6703. Does this exist already somewhere? It's not in Comedi. Unless it's just a trivial extension to Comedi... The 66xx series is quite a bit different than the DAQ-STC-based devices (61xx series), and so it is a non-trivial excercise to write a driver. However, there's a developer at NI who is interested in writing one. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Discrete integration algorithms
On Fri, Feb 23, 2001 at 12:41:29PM +0100, Ivan Martinez wrote: Hello all, I want to add an integrator block to DSLib. Could anybody point me to documentation about discrete-time integration algorithms?. Has the simple integration x(t+1)=x(t)+dx*dt an special name or I should call it something like "SimpleIntegrator"?. Thank you. If you rewrite it in the form y(t) = y(t-1) + x(t), it looks like a trivial IIR filter. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] IRQ conflicts.
On Tue, Feb 06, 2001 at 07:58:00AM +0100, Bart Thissen wrote: "Daniel R. Schuette" wrote: My application is time critical so I would like to be able to use RTLinux's hard IRQ capabilities. However, since I have a large number of modules (six) on the CPCI bus there seems to always be a conflict between one of my modules and an IRQ line used by a Linux (non-RT) device. This creates a problem because my driver cannot service the Linux device's interrupt and RTLinux won't release the interrupt since my driver has registered a hard IRQ. The optimal sollution would to re-assign the IRQ lines so that there is no conflict. Unfortunately though the BIOS my system is using (AWARD) does not support this nor do I know of a way to do it in Linux. There are only 4 interrupt lines on the PCI bus, which are shared between the 6 slots and the AGP bridge. I think it's best if you register your irq's as hard-irq and check in the handler if the irq is caused by a non-rt linux device. In that case you can raise a software-interrupt to pass it to linux. In that case the non-rt handler should be installed on this soft-irq. The number of interrupts on the PCI bus depends on your motherboard design. There are 4 interrupts _per slot_, which on typical older motherboards are physically linked to 4 interrupt lines going into the bus controller. However, this is not true on my alpha, which links the 4 interrupts on 5 slots to 20 separate IRQs, nor on my Tyan Tomcat II SMP motherboard, which links interrupt A on each card to IRQs 16-20. To answer the first question, if you are lucky enough to have an IO-APIC on the motherboard, you can compile the Linux kernel in SMP mode (for 2.2) or 'APIC support on UP' (for 2.4), and then you can reassign IRQs as necessary at boot parameters. Otherwise, you have to deal with a broken BIOS. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL + Low Latency patch interference?
On Tue, Jan 16, 2001 at 10:26:36AM +0100, Bart Thissen wrote: Does any body has experience with the low latency kernel patch and RTL together? I did try this combination once, and found serious problems under heavy load, maybe related to bad memory. I do most of my RTAI hacking (and all of my regular activities) with a 2.4.0 kernel patched with a combo of RTAI, LTT, low-latency, timekeeper, and a few random patches. I've seen no difficulties so far, but if you're interested in attempting to crash it for me, you can find the patches at ftp://ftp.zentropix.com/pub/ds/patches. I tend to upload it only when people ask me, though. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Problems with RTNET (rtifconfig)
On Wed, Jan 10, 2001 at 05:38:00PM +0100, Janis wrote: I have problems with RTNET installation and usage. I use RedHat 6.2, RT Linux 2.3 (as well as RTAI 1.4, RTAI 1.6), RTNET-0.9.0 1. When I install RTNET the file /include/modbuild/config.h is not found. Therefore I create directory /include/modbuild/ , rename and copy file /home/rtnet-0.9.0/tmpconfig.h as file /home/rtnet-0.9.0/ /include/modbuild/config.h. I don't know is it right operation, but compilation process completed successfully and ping works with driver 3c59x_rt_old. This is ok. It's a known bug that is fixed in CVS, but there hasn't been a bugfix release. 2. The next problem is with rtifconfig, because device file " /dev/rtnet" is not found. It seems that device file "rtnet" is not registered. So I cannot configure network and work with RTNET in hard real time. run 'make dev'. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] NI_PCI_Driver
On Fri, Jan 05, 2001 at 04:47:37PM -0800, Basham, Richard R wrote: Hello, Does anyone know where I can find the latest National Instruments PCI device driver (NI_PCI_Driver) ? I want to use it with a PCI-6033 card. It's part of the Comedi package, http://stm.lbl.gov/comedi. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] SBC 8260
On Wed, Dec 20, 2000 at 08:49:03AM -0800, Rafeeq Ur Rehman wrote: Has anybody used SBC 8260 from EST (Now Wind River). I want to try it but need to know if anyone has tried this board earlier. I've been porting Linux and RTAI to the Motorola 8260 ADS board, and both run fine. Recent versions of Linux have run on the SBC 8260 board, but few-days-old versions have had a little bit of brokenness. Once this is fixed (I have patches), both Linux and RTAI should run on the EST SBC 8260 board, as well. If you already have Linux running on the board, tell me the version of the kernel that you are using, and I'll send you a patch for RTAI. Then, you can build RTAI out of CVS, and we'll see what happens. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] serial card drivers
On Thu, Dec 21, 2000 at 10:00:56PM +0800, A.Han wrote: Hi all, I am developing a CNC(Computer Numerical Control) system basing on rt-linux 2.2, and I am preparing to use some RS-232 serial card like moxa 104. I know there is linux device driver for serial card, but does it work in rt-linux?(to be honest,I know little about drivers) I want to do some output in rt threads,do I need a rt-driver for the serial card? If I do, how can I get it, and how to use it? I really hope to get your advise. Thanks for your help, and merry christmas to all. There is no real-time driver for the moxa 104 that anyone has announced. You have two choices a) port the moxa 104 driver to real-time or have someone else port it, or b) use one of the multiport boards based on standard PC UARTs (8250, 16450, 16550, etc.). It's been a few years since I've used multi-port serial boards, so I can't recommend one off-hand. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] rtnet
On Mon, Dec 04, 2000 at 05:05:38PM +0900, Randolph Lee wrote: Hello, Currently I'm working on a project using RT Linux for networking. I'm using Rtnet V0.9.0. I was wondering if there is an RT function that is similar to inet_addr or inet_aton (in arpa/inet.h). You can use the function in_aton(), which is declared in linux/inet.h. It is RT-safe. By the way, I'm working on a new home for RTnet, which currently is just a mailing list, but will soon be a CVS repository as well. Information can be found at: http://opensource.lineo.com/mailman/listinfo/rtnet The list address is [EMAIL PROTECTED]. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Patch available: use 8254 ch.1 instead of ch.2
On Tue, Nov 21, 2000 at 05:05:47PM -0500, jason sodergren wrote: Hi, all. I've made a small patch to schedulers/i386/rtl_time.c in rtlinux-3.0pre8 that allows use of the 8254's channel 1 instead of channel 2. Use of channel 1 is selected by means of a module parameter. This is useful to my project because I'm using a 486-class system that does not need channel 1 for DRAM refresh (it's based on the AMD Elan SC400). This frees up channel 2 for the usual role of driving the PC speaker. Note that timer 1 is used for other things, particularly APM. Using timer one on one of my machines works fine -- until I put it to sleep, at which point it blows up. And I haven't found a way to replace the original value. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] rtnet
On Wed, Nov 22, 2000 at 03:19:28PM +0100, [EMAIL PROTECTED] wrote: hi, I have to use an embedded Pc, a MOPSlcd4. I did the whole development (of a rtp sniffer) on a normal PC as well as the tests. Then, the precision of paquet arrival time is acccurate within the microseconds (on normal PC). after that i did the same (with exactly same application) on the embedded system and i got a time which is accurate within only 10 milliseconds!!! I resume: on a normal PC: 12:45:30.146589 on MOPSlcd4:12:45:30.14 Linux timestamps packets with get_fast_time() in the kernel. True to its name, get_fast_time() is implemented with a fast method of determining the current time. On a CPU with a TSC, it uses the TSC to get usec resolution, but otherwise it uses xtime, which is the time at the last 100 Hz clock tick, thus causing 10 msec resolution. If the kernel used do_gettimeofday() on a 486 for every packet, network speed would slow down a lot. This patch will cause a 486 to use do_gettimeofday() instead of xtime for timestamping packets: --- linux-2.2.17/kernel/time.c.orig Wed Nov 22 11:04:19 2000 +++ linux-2.2.17/kernel/time.c Wed Nov 22 11:17:53 2000 @@ -43,7 +43,7 @@ *tm=xtime; } -void (*do_get_fast_time)(struct timeval *) = do_normal_gettime; +void (*do_get_fast_time)(struct timeval *) = do_gettimeofday; /* * Generic way to access 'xtime' (the current time of day). dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI and RTLinux
On Tue, Sep 05, 2000 at 05:05:56PM +0200, David Olofson wrote: Tue, 05 Sep 2000 [EMAIL PROTECTED] wrote: Let's say I have N message buffers in a pool. What if there is no more free buffer? Then the design for your hard real time system was wrong :-) Or system reached its limits. Yep, and the only options are a) redesign and b) upgrading the hardware. It depends on your possibilities and intentions. What if amount of incoming data is unpredictable but you have to process at most as you can with a limited hardware? That's a kind of *soft* real time system, which is not really what RTL is intended for. (Although the input-"some kind of output" latency could have a hard RT requirement - but the memory allocation would still be soft RT.) You can't optimize a single API for both hard and soft RT, at least not without making it a major PITA to use if you want hard RT, so IMHO, it's a very good idea not to mix these two kinds of systems up when discussing APIs. 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. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Trouble upgrading to RT2.0
On Mon, Aug 28, 2000 at 11:31:41AM -0600, [EMAIL PROTECTED] wrote: First: /usr/src/linux/.config rtlinux-2.3-pre2: CONFIG_RTL=y rtlinux-2.3-pre3: CONFIG_RTLINUX=y Why was this changed? Why is this referenced in comedi? So that Comedi can autodetect RTLinux. This is the reason I gave when I convinced you to originally put it in. Not a problem, the autodetect script can be changed as necessary. Second: linux/rtl.h: No such file or directory Is there any way to detect (#ifdef) the change from linux/rtl.h to rtl.h It's easy to define #if LINUX_VERSION_CODE = KERNEL_VERSION(2,3,0) We probably need a RTLINUX_VERSION_CODE too. Wasn't this discussion about source compatibility? Requiring that the user modify the source code to upgrade != source compatibility. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Real Time in realtime ?
On Tue, Aug 22, 2000 at 03:03:25PM +0200, Klaus Keppler wrote: Hi, How can i get the Real Time ( seconds since 1970, time_t) in an rt-thread. I need this time as timestamp for my aquired data. Because the system-time on my rtlinux-box drifts away many seconds the day, i would like to get the time from the RealTimeClockChip on the processor board, converted to time_t. If you are only interested in seconds, you can use xtime.tv_sec, which is generally not going to be off more than 10 ms, is monotonic, and can be read atomically. I have a kernel patch that reimplements the way that Linux keeps time, making it completely dependent on the TSC instead of the TSC/timer-1 hybrid approach that is used now. One of the side effects (i.e., the main reason I wrote it) is that you should be able to call gettimeofday() from a real-time task. The real-time part isn't completely implemented yet, however, because I started working on other stuff. It will be at ftp://stm.lbl.gov/pub/realtime/patch-*-timekeeper whenever I upload it. You should also consider running NTP if your clock drifts badly. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] tcp-ip commands in rt modules
On Tue, Aug 22, 2000 at 04:13:03PM +0200, Wilken Boie wrote: If you _do_ need it from the RT side you could look at this package ftp://ftp.lineoisg.com/pub/rtnet/rtnet-0.9.0.tgz). It is restricted though in serveral ways (e.g. support for UDP only and currently only on type of NIC). ^^ two!?!?! (I worked very hard for the second NIC. =) ) Actually, the reason that there aren't more supported is because tulip devices are a) cheap, b) reliable, c) multi-vendor and d) available in many different configurations, including multiple- channel, PCMCIA, 100baseT, fiber, etc. I also don't have time. If anyone has other good chipset candidates, I'll put it on My List. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] FW: sprintf for floating point numbers in rt module
On Fri, Aug 11, 2000 at 02:39:08PM +0200, Pavel Andris wrote: Hi Janet and all, my quick and dirty packet is nothing but a collection of about 250 sources + includes from glibc. Only i586 architecture is covered. The sources were collected to cover sprintf() + sscanf() needs of my RT threads. I do lot of floating point operations and it is essential for my application. Actually the glibc sources were (almost) not modified and I declare I don't understand them. I wrote only a simple Makefile to get a lib that is partially linked (ld -r) with my RT modules. The lib contains e.g. unmodified malloc and friends that crash a computer very reliably when called from a RT thread, as expected. That's why I gave up publishing the lib. In spite of this sprintf and sscanf work fine. Anyway I should investigate if they call any dangereous function. I provided the lib to 2 or 3 people who asked me for a tarball but I received no feedback from them. Some time later I realized that the same result could be possibly reached by linking with standard libc (ld with right options), but I'm just too lazy to try it. If you want the tarball in spite of everything mentioned above, drop me a line, I'll upgrade README and send it to you. If you send me a copy, I'll put it into CVS so people can work on it. I'll also spend a little bit of time and make sure that it compiles with different distributions/kernels/RTs. This (libc functions for rt modules) is something that needs to happen, and you seem to have the best starting point. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] About size
On Thu, Aug 10, 2000 at 09:25:06AM -0400, Binu Balakrishnan wrote: Hi RTLinuxers, What is the size of the basic Linux kernel and what is that of RTLinux kernel? On i386, a compiled Linux kernel is about .5 to 2 MB, depending on which options are configured. My laptop, 2.4.0-test4-ds1, with a lot of options enabled, is at the higher end, my 486 running 2.0.37, is at the lower end. (This is the size of _uncompressed_ kernel images.) For 2.2.14-rtl2.3, the RTLinux module sizes on my laptop are: -rw-r--r--1 root root 122196 Jul 6 06:47 rtl_fifo.o -rw-r--r--1 root root 114864 Jul 6 06:47 rtl_posixio.o -rw-r--r--1 root root 329912 Jul 6 06:47 rtl_sched.o -rw-r--r--1 root root 320670 Jul 6 06:47 rtl_time.o 95% of the size is debigging symbols. After being stripped: -rw-r--r--1 root root 7708 Aug 10 11:31 rtl_fifo.o -rw-r--r--1 root root 6048 Aug 10 11:31 rtl_posixio.o -rw-r--r--1 root root 7952 Aug 10 11:31 rtl_sched.o -rw-r--r--1 root root10104 Aug 10 11:31 rtl_time.o dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] generating random numbers
On Wed, Aug 09, 2000 at 12:58:20PM +0700, Adi Sudewa wrote: Hi all, how to generate random integers from within real-time thread. I need to generate random numbers so my simulation can be unpredictable. It is not cool to have a train running with 20.00 m/s speed all the time so I'd like to have the speed fluctuate round 20.00 m/s. The GNU Scientific Library has one of the finest collections of PRNGs, from the trvially simple to ones capable of real work, and then some capable of Real Work (tm). I'd pick a relatively simple one and port it to RT. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Problem with Digital I/O board
On Fri, Aug 04, 2000 at 01:52:16PM -0400, Bin Lin wrote: Hello, I am writing a simple driver for National Instruments PCI-DIO-96 digital I/O board. You might consider using the PCI-DIO-96 driver in Comedi. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Programming sockets in RTL?
On Wed, Aug 02, 2000 at 08:44:30PM -0400, Tony Mouawad wrote: Is it possible to integrate a TCP/IP based server in an RTL module? I'm not sure how to do this using the RTL libraries. No. You can use a user-space helper task that acts as your server, which is probably the best solution if you don't need hard-real-time operation from your server. (Not likely.) If you actually need real-time networking, you can use RTnet, although it doesn't work with TCP. Only UDP. (ftp://ftp.lineoisg.com/pub/rtnet) dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] AD-card
On Tue, Aug 01, 2000 at 01:40:09PM +0200, Peter T. Drechsler wrote: Hi. Can anyone recommend me a decent AD-Card that runs under RTLinux. Kernel is 2.0.33 with appropriate RT-Patch. Runs. Could be PCI ot At. Should have at least 8 analog inputs with gains (12 Bit is ok). Should have 2 or more analog outputs, preferable 0-10V. Look at Comedi. http://stm.lbl.gov/comedi. Lots of boards supported. I want read out thermoelements type K. Since the voltages are micro-V I need gains in the order of 10, 100, 1000. Are you sure that you need real-time? Thermocouple leads make great antennas, and because of this are usually heavily filtered, sometimes using a 1 Hz low pass filter. The latency in the filter usually is greater than the latency of Linux. (This may be irrelevant if you have another need for real-time.) Also, it is usually recommended to use external amplification and filtering for thermocouple inputs. (And from personal experience: if possible, find a circuit that can detect disconnected thermocouples...) dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] rthal struct define
On Mon, Jul 31, 2000 at 10:36:43AM -0500, daniel sheltraw wrote:
Hello RTAIers
It looks like rthal is defined in the modified irq.c. When I try to
install a new SVAGlib I get a error that rthal is undefined which halts the
install. Why isn't rthal defined in a header file which
one could then #include in an include file of any new software
to be installed?
Daniel
You are running into a number of problems:
1. Your distribution uses symlinks from /usr/include/{linux|asm} to
/usr/src/linux/include/{linux|asm}. This is wrong. Keep in mind
that this has been wrong for about 5 years, but everyone *thinks*
it is right because Red Hat does it.
2. SVGAlib assumes that kernel header files are acceptable for
compiling a user-space program and/or library. This is also
wrong. Notably, compiling SVGAlib against an SMP kernel will
cause similar problems with undefined __global_cli and friends.
3. SVGAlib uses cli() in user-space. This is borderline stupid
on SVGAlib's part. Unfortunately, due to the design of SVGAlib,
this is required. (Borderline stupid == can cause lockups.)
Anyway, what is wrong with using the SVGAlib binary that is
packaged with your distribution? It will cause higher latency
for real-time interrupts (because of cli() in user-space), but
it works.
Also, there are options other than SVGAlib, including using GGI,
KGI, kernel framebuffer, or (my personal favorite) a stripped-down
X server.
dave...
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
On Tue, Jul 25, 2000 at 05:25:40PM -0600, [EMAIL PROTECTED] wrote: On Tue, Jul 25, 2000 at 02:07:20PM -0700, David Schleef wrote: Why don't you just use a Linux-like void *dev_id? Is it the migration difficulties in changing function prototypes, or is there some fundamental reason? The lack of a callback handle really makes writing correct drivers a pain. sigaction provides the irq# -- so if you want that information, use the sigaction interface. I'd rather make the RTLinux environment look like Posix threads than like the interior of the Linux kernel. The interior Linux kernel is much more complex, much less familiar, and guaranteed to be not stable. I think it is a fundamental error to use Linux internal operations as an API. I agree about the inherint long-term stability of Linux interfaces (except that the irq prototype hasn't been changed since 1.1.17.) But not having Linux-like interfaces available means that it is much more difficult to port drivers from Linux to RTLinux. But I don't see the problem even with the rtl_request_irq interface. After all, it is a one line function to provide the functionality you want. Am I missing something? Maybe you can give me an example. It takes about 30 lines to get dev_id functionality. The irq number has to be converted to a dev_id using a lookup table, which means that you have to have functions to add/remove entries to/from the lookup table as well as the ISR wrapper. Even with this, you can't share interrupts because the irq is not unique. If you want the full cruft, look at the comedi source. Note that the RTL V1 prototype (void isr(void)) makes it completely impossible to have multiple devices using the same driver. I don't really care whether or not RTLinux supports dev_id, since the code in Comedi works as it is. I just copy the same code to new projects as necessary. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
[rtl] Re: system frozen with comedi and higher freq
On Mon, Jul 10, 2000 at 09:48:57AM +0200, Olaf Petzold wrote: Hallo, some times ago I started this thread. Now some days later I had the time to verify some things (with new comedi-0.7.45, mbuff-6.6), e.g. the hint of using the right gcc: # cat /proc/version Linux version 2.2.14-rtl2.2 (root@rtreg) (gcc driver version 2.95.2 19991024 (release) executing gcc version 2.7.2.3) #10 Mit Jul 12 09:57:32 CEST 2000 So I recompiled the kernel, module, mbuff and comedi with the gcc 2.7.2.3 (without smp support). I insmoded the module from runlevel 1: About 4 kHz the systems slows down. About 4.5 kHz I will get into troubel, while rmmod the rtreg I got a lot of kernel oops (see attachement). Whats going on ? The first oops appears to be caused by some code in the kernel attempting to jump to a user-space address. This could either be due to memory corruption or dangling pointers. Could you send me your code, so I can crash my computer? dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Comedi and Minirtl...
On Wed, Jul 12, 2000 at 10:06:08AM -0700, Pete Buechler wrote: On Wed, 12 Jul 2000, Herman Bruyninckx wrote: We are trying to make MiniRtl floppies with Comedi drivers. But Comedi seems to need the libc, which is a couple of megabytes big. Is there another, much smaller ``embedded'' libc available? Is newlib from Cygnus such an alternative? Would it be possible to use it together with Comedi? 1) Try statically linking Comedi, it may be using only a small part of the library. libcomedi hits some rather sensitive areas of glibc, so statically linking anything causes binary sizes of about 300 kB. It shouldn't be too hard to knock this down in some cases, i.e., changing a sscanf() to strtol() dropped the average binary size of the demos to 240 kB. Think I'll keep that change. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] clock questions
On Wed, Jul 05, 2000 at 05:32:35PM -0500, daniel sheltraw wrote: Hello RTers A couple basic questions for yall, I have a PII machine. When I look in /proc/ioports I see "timer" listed once with associated port addresses 40h-5fh. Q: Is all this address space for one PIT only? No. It is a 8253-compatible chip, which has 3 timers. Ports 0x44-0x5f are aliased to 0x40-0x43. Timer 0 is used for the 100 Hz clock interrupt (Linux) , and one-shot or periodic clocking in RTAI and RTLinux. In some cases, the Local APIC timer on the Pentium may be used. Timer 1 was historically used to refresh DRAM. This is no longer the case, typically. Several of my machines work fine when you reprogram timer 1, but my laptop crashes any time the APM BIOS is entered if timer 1 has been modified. The output of timer 2 is connected to the PC internal speaker, and is responsible for the freqency of the console beeping. If you are willing to give up the console beep (who isn't? I find it annoying...) then you can use timer 2 for other purposes. Only timer 0 is connected to an interrupt. (IRQ 0) Q: Which counter (and PIT if more than one is available) is being used for RTLinux (or RTAI)? Both use Timer 0 for timing purposes, if a Local APIC is not available or not enabled. RTAI uses timer 2 to emulate a TSC. Q: By "time-stamp clock" does one mean system clock? No. Time stamp _counter_ refers to the Pentium-internal counter, which increments at the processor core frequency. It can be accessed much faster than the 8253 timers, is more accurate, and overflows less often. Q: How does any of the above differ for the 486? Most 486's don't have a TSC. (Some clones do.) dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Is it possible to perform network operations from RTLinux task?
On Thu, Jun 29, 2000 at 03:20:47PM -0400, Ajay Avasthi wrote: Is it possible to send out UDP packets on a network from an RTLinux task? If so, how? Ajay If you don't need real-time performance, use a user-space helper task. If you _do_ need real-time performance, Lineo ISG (a.k.a., the artist formerly known as Zentropix) will be releasing a real-time networking package "any day now." I know, we've been saying that for a long time now, but it is now possible to allocate some resources to clean it up and stabilize additional drivers. Since it is derived from Linux networking, it is, of course, GPL. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] hrtime_t - int
On Mon, Jun 26, 2000 at 09:22:44AM -0500, Cory Papenfuss wrote:
I've (sorta) figured it out. The int must first be cast as a long long
or the multiplication will overflow, but when I tried putting a division in a
rt-space function to return miliseconds since boot, I get
./init.o: unresolved symbol __divdi3
when I try to load up my init.o module. Is the access of the longlong division
forbidden within rt-space?
Long long division requires a function call to a function that is
part of libgcc. Do to 'executive decision' in the kernel, i.e.,
it's been that way forever, libgcc is not linked with the kernel.
(Libgcc _is_ linked with the kernel for most non-i386 architectures,
however.) You have the option of making a difference 'executive
decision', and link your module with libgcc.
dave...
BTW, getlrtime that produced that error is little more than
unsigned long int getlrtime(void){
return((unsigned long)((long long)gethrtime() / 100LL)
}
-Cory
On Mon, 26 Jun 2000, Michael Barabanov wrote:
Cory Papenfuss ([EMAIL PROTECTED]) wrote:
Hey all... I've got something that's been bugging me for awhile on this
project. I really only need millisecond resolution (since I'm logging data to
disk), but the hrtime_t doesn't like to be divided by 1000 (NS_PER_MS), as
it's a funky type. Any way I can get around that and get a millisecond
timestamp?
What do you mean it doesn't like to be divided? hrtime_t is just
an alias for long long.
On a related note, I've got a user-space app that can send new
pthread_make_period_np periods (again in [ms]). Problem is that if I try to
send a time greater than 2147 ms, the machine craps out. I suspect it's a
rollover on my
looptime = some_int_from_fifo * 100;
pthread_make_periodic_np(thread[0], genesis+OFFSET, looptime);
What's a good way to do arithmetic on these hrtime_t creatures?
looptime = some_int_from_fifo * (long long) 100;
Michael.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] RTAI upgrade question and more
On Wed, Jun 21, 2000 at 06:42:56PM +0100, Stuart Hughes wrote: 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. If you would prefer to use 2.2.16 (strongly recommended if you are connected to a network), you can use the rthal patch that I have made, which is functionally identical to the copyto script. It's at ftp://stm.lbl.gov/pub/realtime/patch-2.2.16-rthal3 dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] installation
On Sat, Jun 10, 2000 at 07:14:31PM +0100, Gordon Morison wrote: Hello there After having installed RTLinux 2.2 I attempted to install comedi-0.7.44, but when I do a make install depmod returns Unresolved symbols for each of the comedi modules. Can anyone give me a hint as to what I have missed or what I have done wrong as I have been wrestling with this all day, I have looked through all the documention I have and I can't find anything. Thanks in advance Gordon Morison What is the output of 'depmod -e comedi.o'? dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Many .O files to one loadable .O module with GCC?
On Tue, Jun 06, 2000 at 06:12:01PM -0500, Sheldon Hoffman wrote: To [EMAIL PROTECTED] We are using Red Hat 6.1 on a pentium 233 Mhz with Linux version 2.2.14-rtl2.2 (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #4 Sat May 20 08:52:04 CDT 2000 We are hoping to build a single loadable (INSMOD module compatible) object module for RTLinux. The project consists of many ( 50) .C files and associated .H files. We plan to use MAKE to compile each .C + .H file separately to a .O file then build the final .O loadable module from all the individual .O files. We can't figure out how to get GCC to accept a number of .O files and create a single .O file that can be loaded into RTLinux with INSMOD. Can anyone suggest how we can build a single .O loadable module from many .O files that were individually compiled using GCC? ld -r -o big.o small1.o small2.o It is important, however, to make sure that small1.o and small2.o are compiled with the correct flags and that the .c files include the correct header files. Looking at the output of 'make modules' while compiling a kernel and watching the details really helps. The sound drivers are especially useful. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] APM alert !!!!
On Mon, Jun 05, 2000 at 12:34:45PM +0400, Michael Barabanov wrote: Linux 2.3.xx kernels allow APM support to be built as a module. This feature solves the problem for at least RTL 3.0. Michael. How does compiling as a module help? dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] APM alert !!!!
On Thu, Jun 01, 2000 at 04:37:35PM +0100, Stuart Hughes wrote: Hi Victor, Tried it on RTLinux 2.3/Linux 2.2.14. Exactly the same effect. If you cat /proc/apm, the jitter jumps out to ~ 7 miliseconds. Regards, Stuart. Every so often, a thread comes up in the Linux kernel mailing list about modifying the kernel to run APM inside a virtual machine, since APM also causes problems with SMP. There is already other code doing this, such as (I think) the VESA framebuffer code and BIOS calls on other architectures. Usually, the thread erupts into a flamewar about the stupidities involved with running something inside a virtual machine _inside_ the kernel. Supposedly, ACPI will solve these problems, except that a) ACPI doesn't work on my machine, and b) the user-space ACPI code was developed independently from the APM code, and thus is incompatible. Go figure. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] driver for sound card
On Thu, May 25, 2000 at 08:16:41PM +0200, Thomas Gross wrote: Hello, does anybody know, are there any driver or applications for a standard sound card for rt-linux. I want it for data aquisition and noise analysis. Thomas Hmmm... bad idea. Sound cards have a few properties that make them good sound cards, but bad data acquisition cards. - input and output signals are currents, not voltages - input is generally heavily filtered, with unknown filters, but generally cut out anything below 20 Hz, around 50 or 60 Hz (depending on your local line frequency), and above 10 kHz. The 20 Hz filter is nasty, since it makes DC measurements impossible. - unknown absolute conversion between input current and sample value - dynamic input gain control - limited range of speeds - output generally has crappy electrical properties that do not cause audible noise, such as high frequency glitches. Having said this, I'm sure there is an application where this would be acceptible for measurement. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Driver
On Wed, May 17, 2000 at 11:06:40AM -0700, Matt Cheselka wrote: Dave, maybe I'm really missing something here. I'm referring to the drivers in comedi-0.7.xx/comedi/drivers/*.c. Nothing in this source code makes any mention of RTL or RTAI. The only things that do are actually in comedi-0.7.xx/comedi/rtl.c and comedi_fops.c. The problem here is that stuff like comedi_rtl_init() -- which to me sounds like a pretty important function -- doesn't DO anything (everything is commented out)!!! Im my opinion, a good driver should simply do what it needs to do, and get out of the way of the operating system. The individual drivers are also somewhat OS independent, in that anything that is different between OSs is moved into the comedi core, and properly #ifdef'd. What you're saying (and please please please excuse my stupidity if this is wrong) is that comedi is already 'wired' to run under RTL or RTAI and nothing has to be done to a particular driver except to modify it so it becomes incorportated into comedi (attach, detach, subdevices, etc). Meaning, I don't need to put any rt_task_init(), rt_task_wait() stuff into my driver. Yes. Drivers work automatically with RTAI and RTL, provided that they don't do anything "RT-stupid", that is, call kernel functions that are not real-time compatible, register interrupt correctly, don't have any unbounded waits, etc. Hardware drivers in comedi are actually _really_ simple -- just a collection of functions that are called by the Comedi core to do specific jobs. Ask yourself why the driver is running a task. Is this really a driver, or an application/driver combination? I prefer to make drivers as simple as possible, so starting a task seems too high level. I can think of reasons why you might want a task, but not in a data acquisition driver. I guess I have some confusion about what's going on in comedi/drivers and comedi/realtime. comedi/realtime contains two "virtual drivers" that are actually applications disguised as drivers. They use real-time tasks to emulate features that exist on higher-level data acquisition boards. It's kind of cool to use them every once and a while, but if you are doing serious work that requires such features, it is better to buy a real board. However, they make nice examples if you are writing applications that use Comedi. If the above paragraph is true, can you point me to where comedi decides that a driver is to be run in RTL or otherwise? The driver is not "run in RTLinux" as you say. The application calls comedi from RTLinux. Comedi calls the hardware driver. The driver doesn't do anything RT-stupid. Thus, the driver works in real-time. (I will readily admit that comedi drivers do many things RT-stupid, but it is not generally an issue. Writing real-time drivers is a continual learning process.) dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Labview
On Fri, May 12, 2000 at 08:27:17AM -0400, Crum, Bill W wrote: Hi, Is Labview RT available for Linux, or just Windows? For discussion sake, how would rtlinux/labview benefit over Labview RT? thanks, Bill RTLinux and/or RTAI allow you to use devices on the ISA and PCI busses. The NI RT boards are only capable of driving devices that are connected to them, specifically, the 60[34]0E and 6533E. The NI RT boards can probably give better latency and jitter, but only by a factor of 2 or 3. I'm not sure I'd be willing to pay USD 1500 for a 486/100 when I can buy a PIII/500 for significantly less than that. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: FW: [rtl] Labview
On Thu, May 11, 2000 at 09:19:33AM -0700, Dan Samber wrote: I have a naive question: How does Labview benefit from RTLinux? Alledgedly, the people at National Instruments have arranged things (via special drivers or some other mechanism) so that there are no ugly things like gaps in data acquisition etc. Can someone clear things up for me? A good data acquisition board these days have hardware fifos that allow them to sample at full speed (100 kS/s) without dropping samples. That being said, the operating system does have to guarantee _some_ maximum interrupt latency, in this case, at about 10 ms. Windows can handle this until you walk away and get a cup of coffee. I've never seen this failure under Linux (with my limited set of computers.) PCI cards using DMA allow you to increase this latency indefinitely, assuming you have enough RAM, and also assuming you have access to the driver source code... =) However, simple acquisition isn't very useful if your needs are more complicated than streaming input and output. Very quickly, it becomes necessary to record and generate synchronization events, accurate timestamps, etc. These things can be done trivially using an RTOS, but cannot be done accurately using LabView or any other user-space tool. Using RTLinux is essentially like using NI's plug-in real-time 486 boards, except that you can use existing ISA/PCI-based hardware. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTL PCMCIA ADC driver
On Mon, May 01, 2000 at 09:32:32AM -0700, Steve Rosenbluth wrote: By the way, if anyone is interested in helping write a driver for the National Instruments 200kHz 16 bit pcmcia ADC, there is someone starting a driver in Australia: [EMAIL PROTECTED] NI just recently sent me one of these cards (thanks, NI) and it will soon work with Comedi. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] RTLinux and RTimage processing
On Wed, Apr 26, 2000 at 12:51:56PM +0200, Cedric Hyppolite wrote: PCI CNA AT-MIO-16-XE-50 Is supported. See http://stm.lbl.gov/comedi dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] gcc and g++ mbuff confusion. __attribute__((packed))
On Thu, Apr 20, 2000 at 03:59:51PM +0200, Olaf Petzold wrote:
At first it's seems the compiler option -malign-double overides the
attributes, it's important to know. Secondly why is there a difference between
x1_t and x2_t ?? (it's interesting for me)
Because you made a typo.
typedef struct {
char c;
uint32 ui32;
struct s2 {
uint16 ui16[2];
- };
+ } s2_m;
} x2_t;
dave...
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] automating driver conversions
On Fri, Apr 07, 2000 at 02:03:24PM -0700, Willem Atsma wrote: Hi, I wrote a driver and now I want to addapt it for RTLinux. Can anyone think of reasons why I couldn't write a header file with macros to replace normal linux calls with the appropriate rtl ones? Has anyone done this? Willem Drivers are usually designed in a 2 or 3 layer model, with the bottom layer (closest to hardware) being mostly OS independent, and depending mostly on the middle layer for its functionality. Linux drivers usually follow this model, especially the network drivers. There are 2 approaches to converting such drivers to real-time. One is to make the low-level drivers _completely_ real-time and non-real-time safe, and have the middle layer take care of the details of how RTLinux/RTAI/Linux work differently. This is the approach I've taken with comedi, mainly because I control the middle layer. Another approach is to develop a second, compatible middle layer, especially for real-time. This way, you can easily #define low-level drivers to be real-time, non-real-time, or dual, simply by changing compilation flags. This usually involves changing the names of the important functions from func() to RT_func(), and then using #ifdef DRIVER_RT #define RT_func() rt_func() #endif #ifdef DRIVER_NON_RT #define RT_func() func() #endif #ifdef DRIVER_DUAL #define RT_func() (some_flag?rt_func():func()) #endif That version is readable/understandable, but the following is easier to maintain for many functions: #ifdef DRIVER_RT #define FLAG 1 #endif #ifdef DRIVER_NON_RT #define FLAG 0 #endif #ifdef DRIVER_DUAL #define FLAG some_flag #endif #define RT_func() (FLAG?rt_func():func()) Naturally, this approach requires that you have the same prototypes for both rt_func() and func(), which is not the case for most functions that you may want to use. One such example is request_irq() and its equivalents in RTLinux and RTAI. The main benefit of this approach is that you are able to use the same binary module for both real-time and non-real-time, makeing testing easier. I've had sucess with both approaches, although the latter is simpler for porting existing code. Since you wrote the driver, I'd suggest the first approach, since you are in charge of all the source. If you driver doesn't follow a layered model, now would be a good time to fix it. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] the performance of linux run on MPC860
On Wed, Mar 29, 2000 at 01:57:30PM -0700, Kulwinder Atwal wrote: Does not a lower time mean it runs faster? It sounds like linux is running faster than pSOS and VxWorks. Maybe I am mistaken by your test, but it sounds like Linux is faster. - Kal. Without knowing full details of the source code, it is impossible to tell what might be happening. There's no description about what happens inside the loop, what compilers are used, etc. It could simply be a matter of one compiler inserting an extra memory operation, in order to be more correct or to make debugging easier. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Date: Sat, 18 Mar 2000 20:32:35 +0800
On Sat, Mar 18, 2000 at 06:30:31AM -0800, Phil Wilshire wrote: dyd Good idea. This should be in the form of a HTML page perhaps.. Get started and realtimelinux.org will host it for you. If you maintain any upgrades from the group then we'll post your latest copy as and when.. Just make a stab at it and others will follow. I agree. If there were a well-written/well-maintained document about this, I would add my list of ok/not-ok kernel functions. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] DrDobbs
On Sat, Mar 18, 2000 at 11:43:35PM +0100, Tomasz Motylewski wrote: On Sat, 18 Mar 2000, Erwin Rol wrote: And nice to see a "windows" magazine to talk about something else. Of course they have to mention NT doing Real time in the same way. Did they recompile the NT kernel using soft-cli ? ;-) NT uses a hardware abstraction layer that replaces cli() (or the NT equivalent) with a virtual function call all the time, similar to RTAI. A HAL would be a nice way for Linux to make binary-only drivers work with RTLinux (and SMP, and various other patches that change inline functions and structure layout) -- that is, force binary-only drivers to use a HAL, but allow source drivers to use inline speedups. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] jiffies and udelay in rtl
On Thu, Mar 02, 2000 at 09:02:27AM +0100, Alain Rolle wrote: Hi there, I'm implementing a RT driver (RTL2.0 ,Kernel 2.2.13) and I'm not sure that I can use "jiffies" in it (I'm using these for detecting time outs). Should I not use some rtl specific call to do that? Same question concerning the linux "udelay" call. Can someone help me on this topic ? You may use jiffies, but remember that it will never be updated while you are running real-time code. (Because interrupts are disabled.) udelay() is completely real-time compatible. (Possibly untrue for 2.2.15pre10.) dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/~rtlinux/
Re: [rtl] timers
On Tue, Feb 29, 2000 at 06:34:50PM +0100, Jens Lauer wrote:
Hi folks,
[...]
What could be the reason for the misbehaviour of sleep, usleep and
select in a function?
This is slightly off your topic, but the following source code shows
some of the issues involved in using usleep() and select() functions
in Linux. Run the program and graph the results. Oviously, since
the Linux timer granularity is (typ) 10 ms, you see this effect show
up in the graph.
dave...
#include stdio.h
#include sys/time.h
#include unistd.h
void test1(void);
void test2(void);
int main(int argc,char *argv[])
{
test1();
return 0;
}
void test1(void)
{
struct timeval tv1;
struct timeval tv2;
int usec;
int actual;
for(usec=0;usec1;usec+=100){
gettimeofday(tv1,NULL);
usleep(usec);
gettimeofday(tv2,NULL);
actual=(tv2.tv_sec-tv1.tv_sec)*100+
(tv2.tv_usec-tv1.tv_usec);
//actual=tv2.tv_sec*100+tv2.tv_usec;
printf("%d %d\n",usec,actual);
}
}
void test2(void)
{
struct timeval now;
struct timeval targ,t;
int usec,sec;
int actual;
int i;
usec=(1.0e6/230.0);
sec=0;
gettimeofday(targ,NULL);
for(i=0;i1000;i++){
targ.tv_usec+=usec;
if(targ.tv_usec=100){
targ.tv_usec-=100;
targ.tv_sec++;
}
t=targ;
gettimeofday(now,NULL);
t.tv_sec-=now.tv_sec;
if(t.tv_usecnow.tv_usec){
t.tv_usec+=100;
t.tv_sec--;
}
t.tv_usec-=now.tv_usec;
select(0,NULL,NULL,NULL,t);
actual=(now.tv_sec-targ.tv_sec)*100+
(now.tv_usec-targ.tv_usec);
printf("%d %d\n",i*usec,actual);
}
}
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
Re: [rtl] Problem loading modules
On Wed, Feb 23, 2000 at 11:04:35AM +0100, Erwin Authried wrote: David Schleef[SMTP:[EMAIL PROTECTED]] wrote: Nope. gcc-2.7.2.3 outputs assembly instructions that perform the memcpy, even with very long strings. dave... Be careful. With *exactly* the statement above, compiled with -O2, memset is called. With some shorter or longer strings, memset is not used. -erwin You are correct. I somehow managed to completely ignore "memset" and focused instead on my incorrect interpretation of "memset" as "memcpy". I'm happy you corrected me, because this brings up gcc bugs/features (depending on perspective) on multiple levels. On one level, gcc optimization is _definiately_ wrong calling memset(ptr,0,3) instead of the trivial two or three instructions required to zero by hand. This appears to be the behavior in both gcc-2.7.2.3 and egcs-2.91.66. This deserves a bug report. Then, of course, it is not clear that gcc should be calling library functions instead of __builtin_memset or just inlining memset code, especially when the -fno-builtins flag is set. It is true that memset can have no other legitimate meaning. But clearly, for the purposes here, generating "call memset" is not useful, and in other circumstances, "call memset" is definately bad. Grepping the gcc source indicates that there are a number of function calls that gcc will emit in certain circumstances. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/~rtlinux/
Re: [rtl] RTL performance
On Thu, Feb 10, 2000 at 01:07:09PM -0700, [EMAIL PROTECTED] wrote: On Thu, Feb 10, 2000 at 10:45:35AM -0800, David Schleef wrote: And I hope you never do. What would I ever do with a VESA data acquisition board? Hang it up in my obsolete-hardware sculpture I have in my office, I guess. AGP has no future. I don't see a real need for 400 MB/sec from a card, when computers can't even currently handle 100 MB/sec from a PCI card. This comment was in reference to "why manufacturers don't make AGP boards", not why "AGP boards are bad". The "AGP has no future" comment should indicate that I'd be happy to go into a diatribe about why I dislike AGP, but I digress... dave... --- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] For more information on Real-Time Linux see: http://www.rtlinux.org/~rtlinux/
Re: [rtl] Memory Mapped ISA Video Frame Grabber Help
On Mon, Jan 10, 2000 at 01:52:11PM -0800, Estabridis, Janet P wrote: Dave, I am doing this from user space right now. I am using fd "/dev/mem" which is what Mr. Rubini's book example and he's advice via e-mail was. What is the difference between "/dev/mem" and "/dev/kmem" ? I'll try "/dev/kmem" and I'll try and look at the SVGAlib source. I truely did not think accessing a memory mapped card would be trouble from user space and I thought it would be easier until things are working (if you can map it). I'll also try it from kernel space if all else fails. Sorry, /dev/mem was correct. But mmap_kmem() is just defined to be mmap_mem(), which makes me suspicious. Have you tried plain, old read/write/fseek() on /dev/mem? Are you using a 2.2.x or 2.0.x kernel? dave... --- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] For more information on Real-Time Linux see: http://www.rtlinux.org/~rtlinux/
