dcdeno@panisse.berkeley.edu (D. Curtis Deno) (05/16/91)
I am about to embark on a programming effort to permit background data collection on 286 and above MSDOS machines. My program should service a hardware timer interrupt every, say, 1-100 seconds and collect some data from an A/D board and a counter. The possibly tricky part comes when I wish to write this recent data to a disk file. The reason this can potentially cause trouble is that the main program, which runs in the foreground, can shell to DOS and the user must be able to run an editor, copy, and delete files at will. I am concerned DOS will get confused if it is in the middle of writing some sectors from the DOS shell application at the same time the interrupt service routine wishes to write some other sectors. I have experience writing hardware ISRs and have done hardware timer interrupt controlled data acquisition to RAM succesfully in the past. By saving the state of the numeric coprocessor at the top of the ISR I have even done floating point computations in both the ISR and main program/DOS shell application. A related issue is that of streaming data to disk with double/ring buffering. I am concerned that techniques that work here need not work under the conditions described above. Do I need to look into storing/saving copies of DOS's disk transfer area when I interrupt a procedure in progress? Tips and pointers to vocabulary, discussions, or example code are all welcome. Post replies to the newsgroup, if you feel appropriate, or email directly to me at dcdeno@united.berkeley.edu. I will summarize to the net a successful approach, when I understand it and have tested one. Thanks. -- Curt Deno dcdeno@united.berkeley.edu
ekalenda@cup.portal.com (Edward John Kalenda) (05/17/91)
(Lots of stuff about writing to disk from an ISR while DOS is doing other stuff). The Microsoft Encyclopedia has a nice example program called SNAP which sits in the background and does aa print-screen type of operation to a disk file. It can do it at any time, regardless of what is happening in the foreground. By any time I mean that it will remember the request and do it as soon as things are in a safe condition. Usually less under 1/20 of a second. I wrote a TSR program for a client which monitors the serial port in this way so the activity could be analyzed later. The trick is to have multiple buffers to fill and write so you never lose any data. Ed ekalenda@cup.portal.com