5

I want use MC6850 ACIA for bidirectional communication, but I am not sure if I've understood it well.

I want use an IRQ to interrupt an MCU when the ACIA receives data or has transmitted it. The MCU is a 6309 for now but will be others later.

There are many examples on the web of how to collect data but not so many of how to manage the communication.

If I have data to send, I enable transmitter interrupts, check status for transmit register and if ready, put a byte there and return from interrupt.

Later, when the byte has been sent, the ACIA generates an interrupt. The MCU responds by checking that the transmit buffer is empty, writing the next byte to it and returning from the interrupt. This is repeated while I have some bytes to send. The MCU then disables the interrupt until I have another batch of data ready.

If the remote party cannot receive and handle data as fast as the MCU is sending it, that device can raise my CTS. That prevents the ACIA from generating any more transmitter interrupts or flagging the transmit buffer as empty, so the MCU does not try to send anything until the remote device is ready to receive again.

So far so good.

For other way, the MCU enables the receiver interrupt. When data arrives, it calls. The MCU checks status, reads the receive register, stores the byte and returns from the interrupt.

Still good.

But if the MCU has a high workload, or low on free memory, and is being sent more data that it can read and process, is there a way to stop the device sending while still allowing the MCU to transmit data to the device?

It seem to me, that if the MCU raises RTS it will also be stopping itself from being able to transmit to the device.


More backgroud added (I used chatGPT to help fix my english and reworked the result after it, so it says, what I really mean):

Question:

Which specific variant of the MC6850 are you using that supports a baud rate of up to 115200 bps? It can't be the MC6850, MC68A50, or MC68B50, correct?

Answer:

The I/O chip is plastic and marked with an 'M' in a circle, with inscription "MC68B50P OM9N 0LZDO740" (I am not sure which characters are a letter 'O' and which are a zero).

The datasheets from Motorola state, that Data Clock Frequency is up to 1.5 MHz for /16 and /64 modes. I'm using the /16 mode at 1.8 MHz, slightly off specs but functioning well. (Currently the chip is overclocked by 22.88% (I did not know it earlier), but transfers are without errors).

It is connected to "QinHeng Electronics CH340 serial converter" by short wires. And this is connected to AMD Ryzen 9 3900X as a "just terminal" :)

Question:

Why such HW? And what is the whole setup?

Answer:

I bought it couple years ago (and I did not understand anything else, other than that it is cool) and now I am trying to understand it and improve it :)

Here's what I acquired years ago and recently excavated: https://tindie.com/products/omenmicro/omen-kilo-kit You can find the documentation with the schema on GitHub https://github.com/omenmicro/kilo , and I have "issue 1" version of the kit.

Here are some my pages (in Czech) about my current project with it http://8bit.gilhad.cz//6809/Expanduino/Expanduino_I.html There are also some schematics and photographs (and a gallery) of the project.

I will also modify it to enable IRQ functionality and maybe add more features later.

Now I am discovering what I have and I want connect the MC6309 to Arduino to get easy access to modern gadgets. (Currently, I have an I2C-connected RTC module with Flash and a thermometer, and an SPI-connected SD card reader; both are operational.)

I am developing my own EEPROM monitor, named Castor (http://8bit.gilhad.cz/6809/Castor.html), along with its Arduino counterpart, Pollux (http://8bit.gilhad.cz/6809/Pollux.html). Pollux operates on an Arduino Nano Every, linked to a custom board (http://8bit.gilhad.cz/6809/Expanduino/Expanduino_I.html), which provides 3 ACIA-like bi-directional channels to connect these two different computers.

It is all still in development, and I am learning through trial and error because I don't know what I don't know (and should know) to make such project work.

Castor is currently around 6kB and can run independently or in conjunction with Pollux, enabling file transfers from the SD card to be displayed, run, or burned into EEPROM. Pollux is approximately 29kB, managing access to its devices and evolving to provide improved I2C and SPI interfaces to Castor.

Expanduino is basically finished, but next version will include minor fixes, improved LED placement, and connector positioning.

15
  • Why do you need an interrupt to send anything? Usually we just stick something in a buffer and forget about it. Commented Dec 12, 2023 at 9:44
  • 1
    @OmarandLorraine What kind of UART you are thinking? The 6850 UART basically has no buffer so if you want to send a buffer of multiple bytes, you need to either poll when UART is ready for next byte, or let it notify you about it with an interrupt.
    – Justme
    Commented Dec 12, 2023 at 10:08
  • 1
    @OmarandLorraine That does not apply. Of course if you delay for several milliseconds per byte like in the useless Arduino code, at 9600 baud, the byte has been transmitted long ago when you write the next byte so there is no need to check. Double-buffered just means you can write a byte to Transmit Data Register when it is empty, and there can be another byte being transmitted out in the Transmit Shift Register. So yeah, it does have a buffer, and it's only two bytes. You need to poll or get interrupts to know whem to send the next byte of multi-byte data buffer from MCU to UART.
    – Justme
    Commented Dec 12, 2023 at 12:16
  • 2
    @gilhad If there is additional information - like the one about speed grade and chip type - it might be best to add them in an edit of the question, not comments. Comments are volatile.
    – Raffzahn
    Commented Dec 12, 2023 at 22:59
  • 2
    @Raffzahn You need to read the data sheet front page with marketing department filter glasses on for the real specs. Yes, it will go up to 1 Mbps. But only if you buy the fastest model, MC68B50, and use it in the 1x synchronous mode which requires a clock wire between devices. So you can't reach the promised 1 Mbps in the usual asynchronous mode, in which you would normally use UARTs for communicating with other devices without a clock wire. The real maximums in async mode are 50kbps, 62.5kbps, and 93.75kbps. Currently the chip is overclocked by 22.88%.
    – Justme
    Commented Dec 12, 2023 at 23:17

1 Answer 1

7

TL;DR: No. Also Use RTR (aka RTS)

With today's RTR/CTS there is no signalling that one want's to send, only if one is ready to receive.

One side's RTR (aka RTS) is the other side's CTS. Whenever RTR is deselected (high, as it's low active) the other side will (well should) not send any data.

  • If your system doesn't want to receive data
    • Deselect RTR, the other side sees it as inactive CTS
  • If the other side doesn't want more data
    • It deselects RTR, which is reported at your CTS input

If one side is still sending data, then the first word will be stored in the receive buffer, all subsequent will be lost - and reported as buffer overrun.

The 6850 implements the older RTS/CTS protocol for basic (dumb) modems, which automatically stops transmission when RTS is deseclected. Quite comfortable back then, not as great today.


Historical Naming with Changed Functionality

This seems to be rooted in mixup between historical naming and actual usage. Originally RTS/CTS was intended for direct control of modem hardware. This changed with the introduction of less dumb modems and it became a way of flow control.

RTS: How It Was

Originally RTS/CTS was used to handle a modem. Except those were not the modems of today with processors of their own, but rather simple (*1) circuits and RTS/CTS was used to directly control modem Hardware. By default such a modem (DCE) does not hold a connection, think of it like being in a sleep mode.

To wake it up, a DTE (Terminal or PC) would raise RTS - Ready To Send. In response the Modem would fire up amplifiers or whatever and establish a connection. When done it would activate (set to low) CTS - Clear To Send. In turn the DTE would start to send.

This was more of a session control than byte wise flow control. Most obvious with direction handling in half duplex modems which need to switch circuitry when changing direction. The same goes for DSR/DCD.

RTR: How It Is

With more 'intelligent' modems which often featured way faster hardware flow control became a thing. Sincs RTS/CTS was already a working mechanic to throttle a sender, those modems employed RTS/CTS in a new way:

  • CTS was activated (low) by the DCE whenever ready to receive (more) data.

In turn the DCE no longer needed to interpret RTS as signal to 'fire up' but could take it as ready to communicate or in other words receive data. Thus

  • RTS from DTE now meant that it could take more data from the DCE

And that's the whole beauty of the change. From two specific signals commanding switch some low level hardware and reporting that switch it became a pair of symmetric signals which each side used to signal it's readiness to receive (more) data.

They now showed the same symmetry as TxD and RxD essentially making the distinction between DCE and DTE superfluous (*2), allowing simple cross over (null modem) cables to connect and DTE to any other.

L'insoutenable légèreté de l'être

(Or less philosophical: It might look the same but life changes)

To reflect this ITU added in the late 1980s RFR (Ready For Receive) as new signal 133 to V.24 which is to be positioned on the same pin as RTS.

EIA reflected that change in Revision E of EIA/TIA 232 of 1991, by replacing Circuit CA with CJ on pin 4.

Bottom Line: It's still the same pin with similar handling but a new name reflecting what what modern equipment really does.

Old Habits Die Hard

Yes, one should not use the term RTS/CTS anymore when talking about flow control, but people don't like to change habit - and even less do pin diagrams and datasheets of old chips. To smooze he transfer a bit some came up with using RTR instead of RFR :)

Important for anyone new:

  • Write RTR with whatever new work (schematic, documentation) you create
  • Read RTR whenever there is an RTS.
  • And remember RTR (RTS) as direct counter part of CTS.

All problems solved?

Not really, as that quickhack of using RTS as flow control still relies on willingness of both sides to comply. Even if a DTE disables RTR (high), the other side may 'choose' to ignore this and continue to send data. This is why any receiver should still react to incoming data, even with RTR disabled.

When everything fails is where the overflow detection comes in :))

6850 Specifics

The 6850 has a few remarkable features:

  • The 6850 will not send any data if it's CTS input (pin 24) is inactive (high). It will take one byte into the Transmit Data Register, but not transmit any data from the Transmit Shift Register. No Transmit Empty interrupt will be generated until CTS is active (again).

  • When interrupt based signalling of CTS is intended, CTS needs to be tied to DCD, otherwise DCD needs to be tied to ground.

  • RTS can only be disabled (high) by disabling transmission as well (CR6=1, CR5=0) - at least when done using interrupts - as those functions are intervened. A statement about how old the 6850 is :))

    Straight Out: Input throttling via RTR (RTS)-signalling can not be used independent of transmission.

All of them, but especially the last one is a sign about how old the 6850 design is. Motorola as a communication company did a quite good job to package as much of the classic RTS/CTS handling into hardware, creating safe transmissions. It's a bit 'too intelligent' for today's RTR/CTS handling.

Generic Caveats ...

... when using interrupts on slow 8-bit devices:

  • Interrupts aren't always the best way to solve a communication task
  • Interrupts may be slower than polling
  • Interrupt programs can involve extreme complex event handling.
  • Using interrupt may not only slow down transmission but also
    • add layers of overhead and
    • add complicated synchronisation issues.
  • There's a reason serial drivers for systems mailboxes tend to be quite complex endeavours

*1 - From today's PoV.

*2 - At least for simple cases - for all other there's still the whole V.24 signal bundle :))

*3 - Nicely compiled in the 1976 MC6800 Microcomputer System Design Data collection.

*4 - Like the1975 M6800 Microprocessor Applications Manual with detailed programming examples.

11
  • RTS means Ready To Send and is standard RS232 stuff. Care to address the 6850-specifics to do with interrupt setup and handling? Commented Dec 12, 2023 at 12:27
  • 2
    @OmarandLorraine There is no 6850 specific problem here. It'll work quite fine the way he describes, it's a problem of understanding what the signals mean. Also present in your comment - RTS is no longer the meaning of that signal 133. It's now RTR. TIA-232 reflects this change since revision E of 1991. Will add a paragraph about that historic change.
    – Raffzahn
    Commented Dec 12, 2023 at 12:37
  • 2
    @another-dave Well, yes, of course, that's whey the how-it-is describes the historic changes that happend some 30 +years ago :)) Beside that,it's exactly that historic change in meaning/handling (ad its implementation with the 6850) where the OP got stuck, is't it?
    – Raffzahn
    Commented Dec 12, 2023 at 22:33
  • 1
    @Raffzahn Thank you very much, now I understand it all (I hope, at least my confusion is solved).
    – gilhad
    Commented Dec 13, 2023 at 2:45
  • 1
    @gilhad You need to calculate maximum possible speed. The interrupt routine will need at very least 80 to 100 cycles (INT+RTI alone =31) , more if done right, thus a 1.8 MHz will at 115kbps already run around 15-20% interrupt load, minimum. with a third of that being overhead. Also important, you eed to raise RTR at least 2 bytes before the receive buffer is filled (usually I's go for 4-8 with a buffer of 16 byte). That's because the other side may need some time to react, depending on implementation. There's a good reason the PC soon used a 16550 :))
    – Raffzahn
    Commented Dec 13, 2023 at 10:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .