EDK OPB Uart 16550

We are using the trial version of the OPB Uart 16550 in one of our designs. We are running this at 19200,8,N,1, no flow control. We are using Hyperterminal- and we are able to access the UART ok for generic stuff. Print/scan.

We then run a test where we send a bunch of checksum frames (Srecords) to the UART and check them on the PPC. This is done via Hyperterm- send text file. The program makes it thru a couple of hundred of these checksumed Srecords and then reports an error. Seems a piece of one of the Srecords gets lost.

We then try the same test with the OPB UART lite and it works flawlessly. All the records are reported correctly.

We then tried the same test with another terminal program- Tera Term- and the problems go away for the 550. We are able to send the text file to both the Uart Lite and Uart 550 with no problems.

Has anyone seen anything similar to this? It seems the 550 and Hyperterminal do not jive well together. Very odd. We want to buy this core because our OS comes with a 16550 driver- and do not want to write our own.

Reply to
Loading thread data ...

IMHO Hyperterm is an absolute piece of garbage! I've had no end of troubles over the years with it on various different applications, usually involving flow control but also dropped chars etc.

For years, the 'standard' test I used for serial comms was the DOS-based Telix. These days I find Tera Term Pro does the job quite well. More recently I've used PuTTY, but haven't used it extensively.

If I were you, I'd try 1 or 2 *other* terminal programs (is a DOS-based one pratical just for the sake of piece-of-mind testing, or even Minicom on Linux?) and if none of those have problems, curse Micro$oft and vow never to touch Hyperterm again!


|              Mark McDougall                | "Electrical Engineers do it
|                    |   with less resistance!"
Reply to
Mark McDougall

Yikes! Everything else snipped.

Do your utmost to remove HyperTerminal as a variable. The vast majority of the time when I've thought I had a serial I/O problem, when boiling it all down to a low gravy, what was left as a problem source, was HyperTerminal.

Summary: If you observe a serial I/O problem and you a using HyperTerminal, the likely cause is HyperTerminal!

You've been warned!

-- Dan Henry

Reply to
Dan Henry

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.