rhys@batserver.cs.uq.oz.au (Rhys Weatherley) (10/30/90)
cs65x7@sdcc18.ucsd.edu (Trieu Vu) writes: >This is my first posting so I hope it comes out right. > [... lots of stuff on "help me, I want to do int-driven comms" ...] This is not so much a reply as a request to the serial comms gurus out there. This particular question could go on the "MOST frequently asked questions" list with no troubles. Since we are continually getting requests for this operation, maybe there should be discussion in comp.os.msdos.programmer or somewhere on a STANDARD set of interrupt driven routines, that will work with both Microsoft C and Turbo C (ever heard of #ifdef ?? :-). To date, most routines I've seen on the net and on ftp sites have holes big enough to push elephants through. e.g. turning on interrupts on the chips BEFORE the chip has been properly initialised for send/receive, and the handler installed - I've seen things like this. What happens if you get an interrupt "right here" when the chip isn't quite ready yet? BOOM! Murphy's law of interrupts: "An interrupt will ALWAYS occur where you DON'T want it to!" Turn them OFF, initialise the rest, and THEN turn them on. Another thing I find is many libraries assume that the chip is in a reasonably OK state when they initialise it (early attempts at a library of my own showed the chip would only respond the SECOND time the program was run: using similar code to something in a book! - the second time the chip was in an OK state). Who said it had to be like this! Murphy's law of hardware: "It is in a totally random state when you first see it, and it will also be the least desirable state". Program defensively, not so it works "most of the time"! I have written "reasonably" bullet-proof routines for Turbo C, to handle COM1 and COM2 (both at the same time too, which is "weird" elsewhere!), but I don't know enough for COM3-N, so there are shortcomings. Also, I can't guarantee that they'll work on anything except XT clones, cause that's all I have access to at present. This message is mainly a call for serial gurus to post their source code, to be inspected for holes, and shortcomings, so we can come up with a standard set of routines, and say to these people "You can get it on ftp site XXX, and it is TOTALLY bullet-proof, it will work everytime, and not cause you any trouble". Or it could even be posted bi-monthly or something, just as long as we can help curb this recurring question. Of course, you gurus must be "big-hearted" enough to take flames and criticisms about you code :-). Any ideas? Rhys. P.S. I'm replying separately to Trieu about some of his questions. +===============================+==============================+ || Rhys Weatherley | University of Queensland, || || rhys@batserver.cs.uq.oz.au | Australia. G'day!! || +===============================+==============================+