I agree on the reliability of the DOS as a monolitic OS. In fact, I have two
PC104 Pentium boards working 24x7 without any incidence using MSDOS 6.22

What is the big limitation with DOS? Well, multitasking. If you want to run
several programs at a time, it is not different than dealing with a PIC: you
have to make resident programs (a nightmare to debug) and then have these
little programs running driven by interrupts. This is definitely not the
best way to program multitasking.

Furthermore, if you go beyond a x286 computer uC, then you are missing all
the native uC multitasking features, except you load a Protected DOS
enhancer to get a flat 32bit memory space, protected code, etc.

What is the other problem? Reliability of the whole OS is determined by the
reliability of the application you run. In other words, a simple glitch and
the whole OS gets broken. So you need to develop really robust apps to have
a stable DOS environment.

But it is useful for many single-thread things, like the one you expose.

TTYL


2007/11/30, Bob Axtell <engineer@cotse.net>:
>
> I have a situation at my client office where we must provide testers for
> some sophisticated
> PCBs. These PCB's have heavy relays, NiMH battery chargers, and
> sensor-detection circuits
> as well as one or more PICs.
>
> To provide diagnostic information, _one pin_ of the PIC is dedicated to
> performing a dump of
> PIC register memory, independent of its normal operation. The data is
> pumped out at a rate
> of one bit every 4mS, slow but very reliable; to pump out 512 registers
> it takes just over 2
> seconds, using a Manchester scheme, with a 100mS "dead band wait" for
> resyncing. I use
> just 35 words of PIC code and just ONE register for this valuable
> feature, which is
> interrupt-driven.
>
> The way I use the data is that I have the operator install a known
> sensor into the PCB then
> read the diagnostic information to see the internal results. If the
> results are within nominal
> range, I pronounce that board section good, then go to the next. It
> saves the technicians
> an immense amount of time, yet doesn't interfere with normal product
> function. It also allows
> the technician to monitor the PIC itself for internal problems (I have
> found a few PIC16F877A
> PICs with stuck port bits).
>
> In years past I first used DOS PCs to read the diagnostic information
> into the tester software,
> written almost always in Borland Pascal 5.5 for DOS. The data is slow
> enough that DOS can
> extract it without error. I then went to Delphi 5. Of late, Delphi is
> not well supported, so I
> find myself going back to old DOS machines. The data is read through the
> PC's Parallel Port,
> and it works on even the OLDEST parallel port (uses the ACK pin).
>
> I am astonished at how reliable old DOS machines are (and were)! Why did
> we EVER get
> caught up with windows? I needed 3 old DOS systems, and my old resources
> of the past
> (pawn shops) didn't have any, so to get them, I had to ask friends and
> relatives to search
> their storage lockers and closets for them. Out of 5 received, I cobbled
> together the 3
> I needed by shifting hard disks around, parallel port cards, etc,
> tossing the broken stuff.
>
> FWIW, FreeDOS is the operating system of choice.
>
> --Bob A
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>



-- 
Ariel Rocholl
Madrid, Spain
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist