From: "Dr Peter" Newsgroups: comp.realtime,comp.os.msdos.programmer,comp.os.linux.development.system,comp.os.linux.embedded,comp.os.msdos.djgpp Subject: Re: OS, tools selection Date: Sun, 11 Aug 2002 20:49:35 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <797576f5 DOT 0208091319 DOT 19be6ab6 AT posting DOT google DOT com> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Complaints-To: newsabuse AT supernews DOT com Lines: 68 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com For the xfer timing you suggest, DMA would be a goood choice.. this is a little tight for interrupt handling especially when you mention the nasty windoze word.. you could try RTOS-32 (http://www.on-time.com). this might help, but I suggest you rethink your hardware to reduce the bottleneck.. "Kel Tyree" wrote in message news:797576f5 DOT 0208091319 DOT 19be6ab6 AT posting DOT google DOT com... > I could use some good advice. > > I am a newbie to SW development in the current PC environment, though > I do have a strong background with assembler (and machine code) in > embedded applications, as well as some experience with QuickBasic and > (long ago) Fortran. I have also taken courses in C, C++, and Java, > though I don't have a lot of experience with them. > > I am about to dive into a semi-embedded project (it would be nice > if the system were available as a general purpose PC, though that is > not absolutely necessary) that is focused on a legacy *ISA* data > acquisition card. > > The interface to the board is fairly straightforward, with a few > mapped I/O ports and a single HW interrupt line. The stickiest part > is that about 1500 bytes must be transferred (to RAM from a fixed I/O > address) at each interrupt (they're about 200 microseconds apart). > > The rest of the application consists of a user interface (with a dozen > or so buttons, a few dialog boxes, etc.), a little file handling, and > some event-response logic. > > I was planning to attack this with Visual C++ (which I already have) > and run it on Win2K. I recently learned that W2K won't let me access > the hardware directly -- that I'll have to write a device driver. I > have downloaded the DDK, but I have the impression that I either have > to spend a great deal of time learning how to write and debug a device > driver or spend a lot ($4K?) to get "turnkey" driver generator. > > Since I have a good amount of learning to do anyway, it *could* make > sense for me to change horses now -- before I get to the middle of > the rapids. Though I'm fairly happy with W2K (it is everything that > Microsoft claimed Win 95 would be), I am not an ardent MS supporter > (would that make me an MS jock strap?) and do not relish a future that > involves an ever-increasing Microsoft Tax (conveniently deducted from > your paycheck?). I understand that the successor to Win XP won't even > boot unless it recognizes the chip implanted in your brain... > > Does anyone have specific suggestions about an OS, development tools, > and/or learning materials that would make this a not-too-unpleasant > and not-too-expensive experience? > > Any alternative (to W2K) OS environment must run on fairly modern > platforms (the latest mobos that have an ISA slot with the fastest > compatible CPUs, a few hundred MB of RAM, a few hundred GB of HD > capacity, etc.) and it must have plenty of drivers for modern > conveniences like CD and DVD recorders and NICs. > > I would appreciate any help. > > Thanks, > > Kel > > REMOVEkelteeTHIS AT attglobal DOT net