Mail Archives: djgpp/2005/10/17/08:15:20
Nick Müller writes:
>> That's a very crude way of doing this. Consider using a proper serial
>> port communication library. There's about a handful available for
>> DJGPP on the ftp servers.
>
> The way is "crude", but it's the way the OS supports. I think that
> fiddling with hardware is not the right way to go. I have looked at the
> libs, and decided not to use them because of this. If my way is a
> failure, I still can fix it. It's just one of my libs to be changed and
> the serial lib to be added. No big pain.
From my years of MS-DOS serial programming, I never used the DOS support for
serial communications. Moreover, I have seen very few serious serial
comm program or library that used the OS "standard" way of doing serial
communications. Don't get me wrong, you can stay using it but it's just to
point out that in the MS-DOS case, not using the standard is "the
standard". :-) You will miss error checking, full duplex, and many other
things.
>> You get _what_? What's '16382 CHRO' supposed to be?
>
> 16382 times a "char = 0". Not a "O" as you quoted.
What were you expecting? 16384 bytes? 16382 exactly?
This is what you get when the speed doesn't match, if I'm not wrong, this
is exactly what happens when you have set your program at a lower speed
(i.e: 9600) and you get the data at higher speed. Do you get parity errors?
Frame errors? May be you're setting the speed right with the MODE command,
but you may need to check also the speed settings from the Windows
environment. Note that the XP DOS box is a fully virtual environment, the
DOS box isn't talking to the real UART. Maybe (I don't know for sure) the
Windows system is not setting the right speed, no matter what the MODE
command said.
>> That's about as hostile an environment as you could come up with.
>
> ACK. But that's what I have.
Does your program works from plain DOS? Try to isolate the problem, check if
your program works in plain DOS but not in Windows.
Cheers,
Jose Miguel.
- Raw text -