floobydust wrote:
BigDumbDinosaur wrote:
Alternative number three would be to not beat a lame horse and instead use a UART that works right...
Yes, I've sorta gotten the feeling that you don't like the 6551/65C51 chip.. and that you're fairly set on the 26C92 being the preferred UART going forward, albeit I wouldn't call it a third alternative, as it's a complete HW/SW replacement.
It's not a matter of liking or not liking. It's a matter of having a functioning part. While I have focused on the 26C92, there are other UARTs that perform as well and aren't too difficult to interface to the 65xx bus. Garth suggested a Maxim part that works very well, although it requires SPI on your board to talk to it.
One of my basic design goals from the onset was having two TIA-232 channels, one for the console and the other for a communications path to my UNIX server. During my "research period" before I started to formalize POC V1.0's design, I looked at the 2692, 16550D and 16650. The latter two are familiar to anyone who knows x86 hardware. Both have a 16-bit receive FIFO, which was a feature added to the older 16450 when it became apparent that x86 interrupt performance at the time couldn't stay with the higher transmission speeds (reliable 115.2Kbps CBAT with the 8250 and 16450 was essentially impossible with interrupt-driven code on an 8086 or 80286). The 2692, which was derived from an older UART that was 68K bus-compatible, has a smaller receive FIFO, but a more efficient programming model than the 16550D.
Aside from programming considerations, I was looking at the shortest path to a functioning system and the 2692 was easier to interface to the 65C816 than the 16550. I would have had to use two 16550s to achieve what could be achieved with a single 2692. Also, I had prior experience with the 2698 OCTART, which is four 2692s in a single package, so I was already familiar with how to talk to the 2692. That's how I arrived at my decision to use it. The switch to the 26C92 came later when I decided I wanted to reduce the IRQ load during console writes. Among other things, the 26C92 has an 8 byte transmit FIFO, which makes for more efficient utilization of each UART-generated interrupt
Quote:
I've been working on a small 65C02 project and hoped to use a reasonable set of WDC 65XX series chips for core functions, the 65C51 being the console. Unfortunately this hasn't worked out so well as the older chips I have can't handle the higher clock speeds I want and most unfortunately the latest new manufacture chips from WDC have some pretty significant errors which prevent them from being used with standard coding due to the nature of the hardware problem. So be it.... I did take your advice (sorta) and ordered some 2691 chips (single channel version) from Newark, but during shipment, the UPS tracking log shows: package damaged, contents missing, remainder of damage packaging discarded, shipper contacted. So it would seem somebody doesn't approve of me having these chips.
The driver that I developed for the 2692 will work with the 2691. You should consider that the PLCC version of the 2691 takes up almost as much board space as the 2692 and is only slightly cheaper. As both channels in the 2692 are identical in all respects to the single channel of the 2691, the driver is only slightly more complicated than for the 2691—mostly just code repetition and a little more analysis of the interrupt status register.
Quote:
However, I would like some clarification on what "battle-tested" IRQ-driven code for the 26C92 is? Exactly what are the specifications for this and exactly how was the certification carried out?
I was using "battle tested" tongue-in-cheek.
However, the driver has seen a lot of use on the POC units and due to that, I've been able to substantially tightened the code to maximize throughput, as well as reduce its footprint (that 8KB ROM that houses POC's firmware has a lot jammed into it). Last year, I had replaced the 2692 with the 26C92, due to the latter's quicker response to chip selects, enlarged receive FIFOs and 8-byte transmit FIFOs—the latter feature is not present in the 2691 and 2692.
I recently reworked the IRQ part of the driver to take advantage of the 26C92's improvements, and now can process up to 16 bytes coming and going on both channels in a single interrupt. Needless to say, the performance implications are considerable. For example, if 128 bytes arrive in rapid succession on one channel, only 16 interrupts are needed to get and store all of them in the receive buffer. With the 2692, the same data flow would require 32 interrupts. So there's a potential receive performance improvement of 2 to 1 to be had by using the 26C92 instead of the 2691 or 2692. I won't even mention using a 65C51, which has a one byte receive buffer and would generate a flood of 128 IRQs in the same data flow scenario.
The improvement on transmission is even more dramatic. If 128 bytes (the transmit buffer's capacity) are waiting to be sent through each channel, I can now potentially send all 256 bytes in just 16 interrupts ("potentially" means if both channels are running at the same effective speed). With the 2692, the same data flow would require 128 interrupts, as that device lack a transmit FIFO.
Quote:
And yes, I can appreciate the work you've done and the success you've had with your POC SBC.... nicely done.
Thanks. However, if you really want to see an accomplishment, you should check out André Fachat's GECKO system, which he designed many years ago with 74LS logic and a whole lot of imagination. He even engineered SCSI into it via bit-banging, an unimaginably huge amount of programming effort due to the complexity of the SCSI bus protocol. I cheated by using a 53C94 ASIC to run my SCSI interface, so I avoided the pain and agony of sequencing the bus "by hand." All I had to do (!) was tell the 'C94 what to do and handle the different bus phases as they occurred (via some tricky IRQ programming).
Quote:
So, I'm going to switch UARTs... but I won't be tempted to look at your code as I prefer to write device level stuff myself, hopefully I'm successful.
Well, I hope you're successful, as writing any device driver is no simple matter. Please don't feel inadequate if you get stymied and decide to ask for help. We're all here to help out each other with what we know. I've already done all the dirty work with getting the 2692 to play nice with the 65C816. Plus I've done the reading between the data sheet lines to find out the stuff that always seems to be hard to find. You should take advantage of that effort, just as I've borrowed ideas and asked for help from others around here.
Login
Register
FAQ
Search
