Hi, I have a big problem, please give me some help. I have a PCI card which read 16KB data from FIFO to the memory when an interrupt came out.And the interrupt is very fast, almost 16ms a time. I have written a driver based on windows for the card, but lost too many datas.
I want to change a embedded system, which OS should I chose? Please help me .thanks.
Could u furnish more info?
did you currently hook it to a PC and now are looking to hook it up with a embedded system?
Suresh M. Shenoy
Are you saying that you want to change to an embedded system BECAUSE your Windows driver is losing too much data? Your PCI card is generating 16KB every
16ms, which is 1000 KB/s or about 8 Mbps. This is very slow compared to other PCI cards that have Windows drivers like an old USB 1.1 card at 12 Mbps or a WiFi card at 54 Mbps or a USB 2.0 card at 480 Mbps. The 16 ms interrupt period shouldn't be a problem either since that's slower than Windows traditional 10 ms timesilce. If you're losing data, then it sounds like the problem is either on the card itself or in the way your driver is written. Changing to an embedded OS won't fix either problem.
... snip ...
Which u? As far as I know no u posts here, and I know of none other than u thant.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]:
Try the download section.
As you mention Windoze, I assume your embedded system is also x86 based. In which case you could take a look at
How big is the FIFO? Windows will stream video at several tens of megabytes/second with rare dropouts if you use it correctly. It _will_, however, go to sleep on you for extended periods of time, usually during screen redraws and/or disk accesses. With a deep enough data buffer you can significantly reduce the probability of this happening, although you can never eliminate it with Windows (or Linux, for that matter). With tightly controlled access to the OS (i.e. if you freeze everything except for your app) you may be able to get by, at least until someone pushes a button or you try to write to disk.
If you absolutely positively must respond to every single interrupt in some finite amount of time then you need a real-time operating system (RTOS). Which one is right for you depends heavily on what you're trying to do and the environment in which it needs to work.
If you just need to capture the data, do something with it, then move on, and you don't have any user look-and-feel requirements then just about any RTOS (or no RTOS at all, and a task loop running under DOS) will work for you.
If you need to put the data to disk, then you need a fancy RTOS that can do a disk write without interfering with other interrupt driven stuff. For this you'll have to shop around.
If you want all the features of Windows or a windowed Linux system then you're restricted to Windows with RTOS extensions, Linux with RTOS extensions (like RTAI), or one of the 'big' RTOSs like VxWorks. All of these will be big, require lots of knowledge to set up to avoid interfering with the real-time nature of your application, and will cost you either money or time to get working.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" gives you just what it says. See details at http://www.wescottdesign.com/actfes/actfes.html
I think, windows should be capable of handling it. There is some other problem with your system. PCI card interface is very common in Windows and Windows handles much higher data at much higher speed. So, that should not be a problem.
There can be a problem with FIFO size or the manner in which the interrupts are handled. Can you share some info regarding the FIFO and Interrupt details so that we can help you.
If you are very much interested to move to some kind of RTOS. Then, you can try VxWorks/Rtlinux. Lot of RTOS are available commercially and freely . Check out their specifications & support before starting with those.
Karthik Balaguru
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.