> > Hi, did you already try Linux, with your software running > as root so that it can access all I/O ports directly? > Or maybe RTLinux to get better "realtime" performance?
My concerns with Linux: 1) It has to have some sort of processing in the background to handle ethernet and serial ports - and I can't see what it is doing. If it adds a lot of overhead, I could end up with a performance problem I can't solve. 2) I'd need to write a driver to handle the interrupt I need to deal with directly. DOS will just let me hook it at runtime and won't make a fuss about it. 3) It's multitasking. I have one process, one thread, and it never sleeps; why do I need a scheduler? This is a bulldozer to move a teaspoon of sand. > > Fiddling with serial ports directly in DOS is as complicated > as doing the same without any OS at all, as you explicitly > do not want to use drivers for that... To be honest, I don't want an OS. Except for the fact that at power-on I want my app loaded from flash and started, and that I need a framework to run the TS5500's ethernet packet driver on, an OS is very much unwanted. I've seen the assembler for handling a serial port. It's not so bad. My real fear is that I will have trouble mating C++'s memory model assumptions with the assembler's. A fear of tools, not code. > Compiling 32bit DOS apps with GNU C++ (djgpp) is quite easy, > but you should not expect that hooking interrupts or using > the internet would be overly easy. In particular, the DOS > packet driver of your network card hooks interrupts, so it > will get in the way if you want to do real time stuff. Right, but that's true no matter what. I must handle TCP and UDP traffic. Whether it's DOS, Linux, or bare metal, something has to process the traffic. My realtime requirements aren't hideously demanding, though - there's a simple operation I *must* do 64 times a second, and some other processing that has to finish within a 64th of a second, and I don't think the serial or ethernet traffic will interfere with that enough to matter. Not with a 586 at 133Mhz, anyway. > What will be even worse is USB support. Even enabling BIOS > support for USB keyboards (just for an example) will already > make the system performance a lot more unsteady, as USB is > a complex networking protocol and not meant for realtime at > all... But it does mean I don't end up handling 8 serial ports someday, and running out of IRQs. I don't need this in the short term. I might never need it at all. I just need to make sure that it's possible. > As you said you only need 32bit INTS, you can even use a > 16bit compiler as long as you do not need data structures > which are more than 64k each. If you use 32bit addressing, > for example with DJGPP or OpenWatcom, I tried compiling my code with Watcom. I got extremely strange behaviour - the compiler planted stack checking calls, and the stack checks were *convinced* I needed vast amounts of stack space to proceed with even the first function call out of main(). (I make very little use of the stack.) I gave up and used the Digital Mars compiler, and things got a lot saner. > So... try 32bit DOS or 32bit Linux. I doubt that you will > have to write device drivers for the latter, there are > many drivers available. 64 times a second, I want to increment a 16 bit integer in my application's address space. It's about 2 instructions, and one of them dismisses the interrupt. Linux turns that simple procedure into a song and dance. 32bit DOS sounds right, but I read up on freeDOS-32 and it sounded like it was not ready for prime time. Does someone have a cheap/free 32 bit DOS with integrated TCP/UDP support? -- www.obsessionaudio.com Music matters. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
