Re: [rtl] rt display in usec
Wed, 09 Aug 2000 daniel sheltraw wrote: > Hello RTers > > This is a bit off the RTL and RTAI topic but I have a quetion similar to > Patricks regarding RT display. I am willing to accept the course > grained timing given by the reciprocol of the refresh rate but I would > like to be able to draw the image to screen with hard RT scheduling. There > exists a register in most cards that "resets" the sequencer. Standard VGA register? (Long time since I programmed VGA on the hardware level...) > I am not sure what reset means and can find no documentation to tell so. I > am wondering if anyone knows whether this resets the sequencer so that I can > start at a well defined spot in the sequencer cycle and therefore achieve > hard RT scheduling. Of course there may be latencies for the reset which > would have to be taken into account. Any video card registers (except for the one with the blanking bits, in case you have no VBL IRQ...) would generally be of interest only when dealing with hardware accelerated rendering. (If you're using mode-X or bitplane [16 color] modes, you're in trouble, though - these modes require register access all the time, which means you cannot share the card at the hardware level.) AFAIK, the only effect they could have on any normal card is that ongoing hardware accellerated operations could steal some VRAM bandwidth, which of course could be a problem if high bandwidth is required for the RT operations. As to standard VGA registers, I only know about the usual bitmap access "helper" logic and that stuff, and it is indeed slow on some modern cards, but I doubt it gets much worse than fiddling with ports in general. "Only" the usual hundreds of cycles wasted on waitstates... If you really need h/w acceleration for the RT stuff, the driver has to run in RT context, and on nearly all non-pro cards you also need to dedicate the card to the RT task, since consumer video cards in general cannot switch context in the middle of an operation. (Pro cards for CAD/CAM, real time 3D animation etc can do this kind of task switching, and it seems like the new generation of game cards are getting there too, as a result of game and pro cards beginning to use the same chipsets. Lower costs and higher performance for both classes.) David Olofson Programmer Reologica Instruments AB [EMAIL PROTECTED] ..- M u C o S . .- David Olofson --. | A Free/Open Multimedia | | Audio Hacker | | Plugin and Integration Standard | |Linux Advocate| `> http://www.linuxdj.com/mucos -' | Open Source Advocate | ..- A u d i a l i t y . |Singer| | Rock Solid Low Latency Signal Processing | | Songwriter | `---> http://www.angelfire.com/or/audiality -' `-> [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/
Re: [rtl] large memory block problem
all right . that's really work!
now i can get 50M memblock !
> On Fri, 11 Aug 2000, Wei Ren wrote:
>
> > > >#define MEM_SIZE 1000 // 10M
> > > >unsigned long memory_block[MEM_SIZE];
> > > >
> try:
> unsigned long *memory_block=NULL;
> > > >int init_module(void)
> > > >{
>
> memory_block=vmalloc(MEM_SIZE*sizeof(unsigned long));
> if(memory_block==NULL) {
> printk(KERN_ERROR "allocation failed\n")
> return -ENOMEM;
> }
>
> do not forget to deallocate it (vfree) in cleanup_module.
>
> If you would like to be able to have access to this memory from user space
> (convinient for debugging) use mbuff_alloc.
>
> --
> Tomek
>
> -- [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] Networking in realtime? Oh no, not again...
Hello RT community, I'm _not_ going to ask the question again: 'Is it possible to do TCP/IP from an RTL module?' though mine probably is a dummies one as well. I tried to follow the advice given many times: trigger a user space helper (I'm using /dev/rtf0). My helper thread blocks on reading a byte written by a RTAI module ervery 20ms and then sends some data. My aim is to send a udp broadcast as closely bound to that trigger as possible. Jitter would be well acceptable up to 1+ ms. I assumed to achieve that by setting the helper thread to SCHED_RR with a high priority (e.g. 99). But I find this construct working quite precise only most of the time: The reception of single triggers (as measured by timestamps from user space, with the RT activity known to be precise) is delayed by up to 15 ms. These runaways are not really constant but seem to happen in some repetitive patterns, the most obvious with a ~1.2sec period. There is no (obvious) load on system, disk or network and I'm not aware of any other high prio activities potentially delaying me. Please could somebody give a hint where to look, what to do better or (hopefully not) that my expectations are too high. Thanks a lot Wilken Boie -- [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] rtai_sched interferes with ppp ???
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 The kernel config is probably to lenghty to report here. So I would be very happy if somebody could give me a hint about what to try or look for. Thank you very much Wilken Boie -- [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] Data acquisition board & graphic card
Hello everyone, I am at the very beginning of a project. Currently, I am looking for Data Acquisition Boards. I need more than 64 analog channels with gains (at least one for all channels). I know that it is a bit off the RTL topic but, since I don't have much experience with that kind of hardware, I am wondering if some of you could give me suggestions or design caracteristics such a board must meet in order to be used efficiently in a real-time context. Don't hesitate to share bad experiences :-) ! Same kind of question regarding graphic cards. Thanx in advance. Cyrille Rustom IGB, École Polytechnique de Montréal -- [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] 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 " | 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
Thanks, Pavel I got some "No such file or directories" when I did the make. bits/stdio_lim.h /bits/mathinline.h bits/string.h bits/string2.h Did you forget 'um ? Thanks - Also, has anyone done a partial link with the libraries as you suggest Pavel?? ANYONE ?? Janet Estabridis Electrical Engineer NAWC Code 473E00D Building 31440 Room 1017 China Lake, CA 93555 [EMAIL PROTECTED] (760) 939-2896 FAX (760) 939 -3075 > -Original Message- > From: Pavel Andris [SMTP:[EMAIL PROTECTED]] > Sent: Friday, August 11, 2000 5:39 AM > To: Estabridis, Janet P > Cc: [EMAIL PROTECTED] > Subject: Re: [rtl] FW: sprintf for floating point numbers in rt > module > > On Thu, Aug 10, 2000 at 02:42:49PM -0700, Estabridis, Janet P wrote: > > > > > > > -Original Message- > > > From: Horacio and Janet Estabridis > [SMTP:[EMAIL PROTECTED]] > > > Sent: Thursday, August 10, 2000 1:59 PM > > > To: 'Janet Estabridis @ work' > > > Subject: sprintf for floating point numbers in rt module > > > > > > Hi, > > > > > > I'm using RTLV0.9J with kernel 2.0.36 if that matters. > > > > > > I've search the archives and found that sprintf doesn't work with > floating > > > > > > point numbers in a real-time modules, but that Pavel Andris had done > > > something "quick and dirty" and had agreed with Phil Wilshire to have > it > > > available. So, I looked and can't find it. Where can I get it and > > > instructions for using it? > > > > > 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. > > Regards, > > pa > -- > .. > Pavel Andris | tel: +421 7 5941 2167 > Institute of Control Theory and Robotics | fax: +421 7 5477 6045 > Slovak Academy of Sciences | > Dubravska cesta 9 | e-mail: [EMAIL PROTECTED] > SK - 842 37 Bratislava | > Slovakia | > .. > -- [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] pc-104 plus linux/rtlinux
On Fri, 11 Aug 2000, Gerald Przybylski, Lawrence Berkeley National Lab, [EMAIL PROTECTED] wrote: > We are hoping to run linux on a pc-104 single board computer. > > Anyone willing to offer encouragement? > Warnings? Hi Gerald - I run linux/rtlinux on several payloads that fly on the Space Shuttle and are manifested for the International Space Station. There should be no special considerations as PC-104 is just a form factor standard - it is just a small PC suitable for embedded applications. > Willing to suggest products? brands?? I've had very good fortune with Ampro (www.ampro.com) CPU's, ethernet modules and VGA controllers. For Analog and Digital I/O cards Diamond Systems (www.diamondsys.com) are very good; check the Diamond-MM-16, the ONYX-MM-16 and the Diamond-MM-32 I/O cards. For framegrabbers I like the Ajeco ANDI-FG (www.ajeco.com). By the way, I have an article due to appear in the September issue of Linux Journal that overviews these payloads and associated applications that may be of interest to you. Hope this helps. Feel free to contact me personally if you have any questions. Kevin ___ + Dr. Kevin K. Gifford + + http://rintintin.colorado.edu/~gifford + + Automation and Robotics Engineer + + BioServe - A NASA Center for Space Commercialization + + University of Colorado + + Engineering Center, Rm ECAE-1B08 + + Boulder, CO 80309-0429 + + Office: 303-492-0299 Fax: 303-492-5514 + ___ -- [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/
R: [rtl] pc-104 plus linux/rtlinux
Dear Gerald, I am running RT-Linux on a PC104. I have two different model, one is a AMD5x86 at 133Mhz, with 16MB of RAM and 16MB of flash disk, the second is a PMMX at 266Mhz with 16MB of RAM and 16 MB of flash disk. On the flash disk I have a linux system, my application, (which is a numerical control), a web server and there is a lot of room left on the flash. So you can be sure your application will work, go ahead! Ciao Giovanni -- [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] pc-104 plus linux/rtlinux
Gerald, I'm very happy with PC104+ CPUs (bigger form factor) with linux and rtlinux. I have been using AMPRO CPU boards. They also have nice development stations (small box with power supply, floppy, harddrive, connectors and ribbon cables so you can develop before you embedded your system). Janet Estabridis Electrical Engineer NAWC Code 473E00D Building 31440 Room 1017 China Lake, CA 93555 [EMAIL PROTECTED] (760) 939-2896 FAX (760) 939 -3075 > -Original Message- > From: Gerald Przybylski, Lawrence Berkeley National Lab, [EMAIL PROTECTED] > [SMTP:[EMAIL PROTECTED]] > Sent: Friday, August 11, 2000 8:27 AM > To: [EMAIL PROTECTED] > Subject: [rtl] pc-104 plus linux/rtlinux > > > We are hoping to run linux on a pc-104 single board computer. > > Anyone willing to offer encouragement? > Warnings? > > Willing to suggest products? brands?? > > Thank you for your time... > > Gerald Przybylski [EMAIL PROTECTED] http://rust.lbl.gov/~gtp > -- [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] pc-104 plus linux/rtlinux
gerald, you don't need to hope to run on a pc-104 system it is the same as installing and running linux/rtl on any other pc computer. there are a few little quarks at times but nothing major some, or most, i/o cards don't have much support but drivers can be written... we have rtl systems that are pc104 that we use in flight testing rpv's and gaa aircraft. most of the card are from real time devices usa. (www.rtdusa.com) their card are of good quality and all the times that i have called or emailed for info not in the manuals they have been very helpful. at this time they "don't support linux" but they've given good help on their products. chuck -- [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] pc-104 plus linux/rtlinux
We are hoping to run linux on a pc-104 single board computer. Anyone willing to offer encouragement? Warnings? Willing to suggest products? brands?? Thank you for your time... Gerald Przybylski [EMAIL PROTECTED] http://rust.lbl.gov/~gtp -- [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] generating random numbers
Adi Sudewa schrieb:
>
> 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.
>
Here is an extremely simple one (from
http://www.realtimelinux.org/CRAN/src/rtUtils-v0.1.0.h)
static unsigned long rtseed = 0;
unsigned long rtrand( void ) {
rtseed = rtseed * 0x41C64E6D + 0x3039;
return (rtseed>>16)&0x7FFF;
}
Have fun
Wilken
-- [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] Interrupt handling on PCI-DAS-1602
G'morning Everyone,
I am trying to write an RTLinux module that does interrupt driven
data acquisition with Computer Board's PCI-DAS-1602 card on a 233
Mhz Pentium running Red Hat Linux 6.1 Kernel 2.2.14-rtl2.2.
I have a DOS program that programs the DAS card at the register
level so I am very familiar with programming this card.
I have an RTL module that compiles & loads. The interrupt service
routine (ISR) does in fact gets control and on the first interrupt
then the machine crashes ("oops" kernel dump) and the computer is
dead.
Once set up properly, I want the ISR to run every 1 ms, with the
interrupts paced by counters on the DAS card (not by a CPU timer)
after it finishes its "burst" (collects data into an on-card FIFO).
On each interrupt, my ISR reads the data off of the DAS card and
processes it. I copied most of the code from my working DOS program
and the card appears to be setup properly to do this.
1. What do I have to do in my RTL module to indicate that the IRQ
is a "shared IRQ" when I install my ISR? (Both the PCI-DAS-1602
and the 3COM 10Mbit ethernet card share IRQ 10).
2. What is the meaning of the return value for the ISR (the
function specified in the rtl_request_irq() call)? I looked at
the RTL code and it appears to not be used.
3. When my ISR gets control, if it determines that the interrupt
was NOT generated by the DAS card, what is the correct RTL code
sequence (function calls) to exit my ISR so that the interrupt
will be "chained" to the next (shared) ISR?
4. When my ISR gets control, if it determines that the interrupt
WAS generated by the DAS card, what is the correct RTL code
sequence (function calls) to reset the 8259 PIC and exit my ISR
so that another interrupt can occur? (Of course before I exit my
ISR, I will make sure the DAS card has been correctly set up to
generate another interrupt).
5. (Unrelated question) What must I do to safely use floating
point inside an RTL FIFO handler call-back function (specified in
the rtf_create_handler()) (I understand that I must call
pthread_setfp_np() before I can use floating point in an RTL
thread.)
Here are the relevant code fragments (that don't work).
//---
// Called from an RTL FIFO handler in the RTL module
static short
install_isr(void)
{
short err = P16ERR_OK;// Return code (assume ok)
INTERRUPT_STATE interrupts; // (#defined as rtl_irqstate_t)
DisableInterrupts(&interrupts); // ==rtl_no_interrupts()
err = rtl_request_irq(mio.Irq1Lvl, piggy);
if (err)
{
//print_msg("p1600b Error %d requesting IRQ %d", err, mio.Irq1Lvl);
EnableInterrupts(&interrupts);
return(P16ERR_INSTALLISRERR);
}
PCI_EnableInts(pciDasInfo.badr0); // ENABLE PCI INTERRUPTS ON DAS CARD
rtl_hard_enable_irq(mio.Irq1Lvl); // Enable CPU interrupts for this IRQ
EnableInterrupts(&interrupts); // ==rtl_restore_interrupts()
return(P16ERR_OK);
}
//---
// Called from an RTL FIFO handler in the RTL module
static short
remove_isr(void)
{
// RESTORE ORIGINAL INTERRUPT
PCI_DisableInts(pciDasInfo.badr0); // Disable DAS card interrupts
rtl_free_irq(mio.Irq1Lvl); // Release IRQ
return(0);
}
//---
// The ACKNOWLEDGE_CARD macro clears interrupts on the card and
// preforms any other actions necessary to prepare the card for
// the next interrupt.
#define ACKNOWLEDGE_CARD ResetCardInterruptRequests() /* RESET DAS CARD
INTERRUPTS. */
// The ACKNOWLEDGE_PIC macro clears the PIC by sending EOI in DOS.
// For Linux, PIC management is done for us so we don't mess with the PIC.
// LINUX - We ACK PCI but not PIC (this is done by RTLinux when our ISR returns)
#define ACKNOWLEDGE_PICPCI_ResetIRQ(pciDasInfo.badr0) /* Acknowledge PCI
controller on DAS card */
//---
static unsigned int // ISR declaration for LINUX
piggy(unsigned int irq, struct pt_regs *regs)
{ // DYNAMIC LOCAL VARIABLES DONT WORK!!
mio.status = inpw(INTADCFIFO); // INTERRUPT & PACER CONTROL REGISTER
if (!(mio.status & 0x0080)) // DID DAS CAUSE INTERRUPT? (INT bit set?)
{
// THIS IS NOT OUR INTERRUPT!
return(0); // ??what is return value used for?
}
mio.isr_count++;// Count only our interrupts
// MOVE DATA OUT OF FIFO ON THE DAS CARD AND INTO OUR CPU MEMORY BUFFER
//c = mio.numChans; // # of words (Samples) to read from FIFO
//d = (int *) read_buffer + mio.numChans * nBursts; // destination CPU buffer
RE: [rtl] FW: sprintf for floating point numbers in rt module
Pavel, Yes, I'd like it. All I need is the sprintf command -- It preps my floating point numbers to write them out to a Video Insertion Generator card. So, if you say that I'm safe using the sprintf I'd like it. Then I don't have to figure out the "ld -r" stuff either (I'm not so good at that stuff and am always in a time crunch). Thanks - Janet > -Original Message- > From: Pavel Andris [SMTP:[EMAIL PROTECTED]] > Sent: Friday, August 11, 2000 5:39 AM > To: Estabridis, Janet P > Cc: [EMAIL PROTECTED] > Subject: Re: [rtl] FW: sprintf for floating point numbers in rt > module > > On Thu, Aug 10, 2000 at 02:42:49PM -0700, Estabridis, Janet P wrote: > > > > > > > -Original Message- > > > From: Horacio and Janet Estabridis > [SMTP:[EMAIL PROTECTED]] > > > Sent: Thursday, August 10, 2000 1:59 PM > > > To: 'Janet Estabridis @ work' > > > Subject: sprintf for floating point numbers in rt module > > > > > > Hi, > > > > > > I'm using RTLV0.9J with kernel 2.0.36 if that matters. > > > > > > I've search the archives and found that sprintf doesn't work with > floating > > > > > > point numbers in a real-time modules, but that Pavel Andris had done > > > something "quick and dirty" and had agreed with Phil Wilshire to have > it > > > available. So, I looked and can't find it. Where can I get it and > > > instructions for using it? > > > > > 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. > > Regards, > > pa > -- > .. > Pavel Andris | tel: +421 7 5941 2167 > Institute of Control Theory and Robotics | fax: +421 7 5477 6045 > Slovak Academy of Sciences | > Dubravska cesta 9 | e-mail: [EMAIL PROTECTED] > SK - 842 37 Bratislava | > Slovakia | > .. -- [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] generating random numbers (rtl-digest V1 #94)
> -- > > Date: Wed, 9 Aug 2000 00:55:40 -0700 > From: David Schleef <[EMAIL PROTECTED]> > Subject: 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 trivially 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. Unless there is a compelling reason to have this in the real time task, I'd calculate the random numbers in a user program and write them to the real-time task via a rtl FIFO. I've sent two channels of D/A data at 240 Hz with some really lame hardware (DT2801) using this method. Its clean, versatile and works well. You can get "real" random numbers by hooking a white noise generator to the sound card (or A/D if you have one) and reading it. --wally. -- [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] FW: sprintf for floating point numbers in rt module
On Thu, Aug 10, 2000 at 02:42:49PM -0700, Estabridis, Janet P wrote: > > > > -Original Message- > > From: Horacio and Janet Estabridis [SMTP:[EMAIL PROTECTED]] > > Sent: Thursday, August 10, 2000 1:59 PM > > To: 'Janet Estabridis @ work' > > Subject:sprintf for floating point numbers in rt module > > > > Hi, > > > > I'm using RTLV0.9J with kernel 2.0.36 if that matters. > > > > I've search the archives and found that sprintf doesn't work with floating > > > > point numbers in a real-time modules, but that Pavel Andris had done > > something "quick and dirty" and had agreed with Phil Wilshire to have it > > available. So, I looked and can't find it. Where can I get it and > > instructions for using it? > > 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. Regards, pa -- .. Pavel Andris | tel: +421 7 5941 2167 Institute of Control Theory and Robotics | fax: +421 7 5477 6045 Slovak Academy of Sciences | Dubravska cesta 9 | e-mail: [EMAIL PROTECTED] SK - 842 37 Bratislava | Slovakia | .. -- [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] Cheapest RTLinux platform ?
I want to eveluate RTlinux for small devices, but run into problem with expensive hardware. The CPU cards available for intel processors normally cost more than a new stripped PC, and I expect lower price than that. Can anyone give a hint of a cheap platform for this. The cpu does not matter as long as it can run a linux system. Even system designs that can easily be build "by hand" are of interest. If evaluation systems with serialport and perhaps IDE interface are available at a low cost that would be perfect. _ Want a new web-based email account ? ---> http://www.firstlinux.net -- [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] No Mail or system damage?(test, nil)
-- [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] large memory block problem
On Fri, 11 Aug 2000, Wei Ren wrote:
> > >#define MEM_SIZE 1000 // 10M
> > >unsigned long memory_block[MEM_SIZE];
> > >
try:
unsigned long *memory_block=NULL;
> > >int init_module(void)
> > >{
memory_block=vmalloc(MEM_SIZE*sizeof(unsigned long));
if(memory_block==NULL) {
printk(KERN_ERROR "allocation failed\n")
return -ENOMEM;
}
do not forget to deallocate it (vfree) in cleanup_module.
If you would like to be able to have access to this memory from user space
(convinient for debugging) use mbuff_alloc.
--
Tomek
-- [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 driver 0.7.2
On Thu, 10 Aug 2000, S.A. wrote: > I am using mbuff version 0.7.2 with RTL ver 2.2. > I would like to know the effect to change the max allocate number > (MBUFF_MAX_MMAPS). Just uses more memory. This is the maximum number of places where you can mmap single buffer. So, if you have more than 16 processes/threads where you attach to the same mbuff, increase it. > Is there an effect on real time behavior of the system ? > By default, the define is 16. Changing it to 1000 seems run well. Uses (1000-16)*4 bytes more per buffer. Makes mmap/unmap operations slower. > Why the limit of the count of allocation ? Because I did not wat to implement the list - too much levels of indirection is unhealthy. BTW. It rather makes no sence to allocate many small mbuff's. Each takes at least full page - 4096 B. It makes sence to mmap given mbuff in many processes, but as many as 1000 ??? Best regards, -- Tomek -- [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] large memory block problem
yes, of course.
but even it reports " Out of memory",
when i use lsmod, i can see the module app is in the list,
but it's size is 40002568(nearly 40M) unnitialized.
>
> Wei
>
> Are you doing a rmmod before doing the next insmod?
>
> Daniel
>
> >From: "Wei Ren" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Subject: [rtl] large memory block problem
> >Date: Fri, 11 Aug 2000 11:36:25 +0800
> >
> >hi,
> >
> > i want to use some large memory block in my module, so i does this:
> >in my app.c
> >
> >#define MEM_SIZE 1000 // 10M
> >unsigned long memory_block[MEM_SIZE];
> >
> >int init_module(void)
> >{
> > int i;
> > for(i = 0 ;i > {
> > memory_block[i] = 0x5f5f5f5f;
> > }
> >
> >}
> >
> > my box has 64M memory.
> > i compiled this module, then insmod it .
> > at the first time, it runs ok. i rmmod it.
> > the second time i insmod it, it reports : Out of memory.
> >
> > is this method SAFE to kernel ? or is there any other method
> > to get such large memory in my module?
> >
> >
> >
> >
> >
> >
> >
> >
> >-- [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/
> >
>
>
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.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/
