65C22 serial interface

[greg]

Hello

I am working on an application that requires the serial data to and from the 65C22 to be reversed. In other words the 65C22 sends and expects to receive serial data MSB first.
I need to send and receive data LSB first. I was wondering if any of you have developed a neat fast way of doing that other than the typical shift and rotate routines?

Greg

[GARTHWILSON]

If you're connecting it to one or more shift registers like the 74HC165, 74HC595, 4094, 4021, etc., the fastest way is to reverse the pin hook-up on the parallel I/O of these ICs. (Although it seems obvious, it's amazing how easy it is to miss really simple things like that.) I've used the 4000-series ICs a lot when I needed to interface to circuits that were mostly 12V. Next-fastest executing would be a 256-byte look-up table.

Garth

[greg]

Hi Garthwilson,

No, nothing simple like that. I am connecting to a single chip modem and want to keep the parts count and size as small as possible.
After posting my last message concerning the serial interface problem, I decided to use a lookup table for the data bit field reversing. The data field to be reversed can be used as the lower byte address for indexed addressing to access the reversed data field and would be in a linear 255-byte location. This would probably consume roughly one and a half dozen clock cycles as compared to more than 112 cycles using the shift and rotate method.
For those who would have serious memory restrictions, the data to be reversed could be split into nibbles. The lower nibble would index address the upper reversed nibble. The upper nibble to be reversed can be shifted down and then index address the reversed lower nibbles. The reversed nibbles can then be AND together. The lookup table for this would be only 15 bytes and clock cycles would still be drastically reduced.

Greg

[GARTHWILSON]

> This would probably consume roughly one and a half dozen clock cycles
> as compared to more than 112 cycles using the shift and rotate
> method.

Just start with the byte to be reversed in X and do LDA table,X, taking only 4 clocks, 5 if you cross a page boundary. You could also use LDA table,Y or LDX table,Y or LDY table,X. If you have to save X or Y on the stack, that will add another 7 clocks (using PHX...PLX or PHY...PLY).

What modem are you using and what serial interface does it use (I2C, SPI, etc)?

Garth

[greg]

Hi Garth

I am planning to use the CMX868 by Consumer Microcircuits Ltd. It will handle most of my data modem needs. It's serial interface is what they call a C-Bus Interface. The C-Bus serial interface sends and receives eight bit fields like the 65C22 only LSB first lile most every thing else. My main concern though is trying not to add an external uart or senthizing uart serial requirements. The CMX868 has an internal uart when needed and will automaticly add or remove start and stop bits and such. It seems to be a very neat package. I have done quit a bit of searching for new up to date stuff. Of course I would prefer a parallel interface but with all things considered, the CMX868 is what I came up with.

Greg

[GARTHWILSON]

I went to Consumer Microcircuits Ltd's website to look into this C-bus interface, thinking that I might as well make sure my next workbench computer can accommodate it easily if I want it. Unfortunately, they want oodles of info on you before they show you any data or ap notes, so I decided I'm compatible with enough different serial buses already.

Have you found a distributor that will sell you small quantities? I looked at their list of rep.s and distributors and didn't see any I recognized as ones that would want to sell just a few parts at a time.

> sends and receives eight bit fields like the 65C22 only LSB first like
> most every thing else.

Microwire, SPI, I2C, SMBus (I think-- I've never used it), and the 74- and 4000-family logic do MSB first. The first three are very popular for interfacing intelligent peripherals like modems, UARTs, A/D and D/A convertors, signal generators, serial memory, etc.. 1-Wire, IrDA, and RS-232 and its derivatives and variations do LSB first. So actually my earlier question should not have included I2C and SPI since I've used these and I should have remembered that they do MSB first.

Most of these protocols would be quite a challenge to implement with the 6522's synchronous serial port; but with a fast 65c02, you can bit-bang through parallel port pins faster than some of the interfaces can go anyway. I would encourage others not to shy away from them, as there are so many peripheral ICs available with these protocols that are pretty easy to implement.

Garth

[greg]

Garth

Actually, it's been so long sense I have looked at Microwire, SPI and I2C that I have forgotten some of their spicifics. My main concern now though is data modems. I feel confortable that the 65C22 can directly adapt through driver routines with most of the serial standards. Now I know who to talk to when the need comes up.
I haven't had any problems getting data from CML. If you would like, I can send you some pdf data sheets on the CMX868. As far as distributors are concerned, I expect to be able to get samples and will have to probrably buy minumim order dollar amounts.
The CML reps are good. Another company that offers new single chip data modems is TDK they have good rep too. Another is Conexant but they wouldn't even give me the time of day.

[GARTHWILSON]

I probably should have been more specific when I said many of the intelligent serial interfaces would be quite a challenge to implement with the 6522's serial port. One reason is the differing frame lengths.

I2C presents another situation where a "start" condition is generated by the master by pulling the data line low while the clock line is high. A "stop" condition is generated by letting the data line up while the clock is high. At no other time shall the data line transition while the clock line is high. After a byte is sent out with 8 rising clock edges, the receiver pulls the data line low during the 9th clock pulse to indicate an acknowledge.

Dallas Semiconductor's 1-Wire interface actually uses the same line for clock and data. For example, when the master is receiving data from a slave, the master pulls the line down for about a microsecond as the clock, and then looks for the next 15-60 microseconds to see if the sender is pulling the line down to send a "0". I personally have not used this particular interface yet, but it doesn't look as easy as I2C, Microwire, and SPI. You'd have to have microsecond resolution on the timing control.

These interfaces can all be bit-banged on a VIA's individual parallel port bits, and it's not very difficult. You can make the job easier by putting the clock line on bit 0 of a parallel port so you can pulse it by doing INC DEC on the port. This way you don't need to affect the accumulator and do the ORing and ANDing etc.. If you put the data line on bit 6 or 7 of the port, you can read it with the BIT instruction and then branch based on the V or N flag results. You can do this without regard to the accumulator's contents and without affecting the accumulator. If the I/O is in ZP, you can use the BBS, BBR, RMB, and SMB instructions to directly read or write any bit in 5 cycles (1 microsecond at 5MHz), including the branch-on-condition in the case of reading the bit.

Garth

[greg]

Garth

I'll look at the bit banging deeper. I was orignally going to emulate a uart with the 65C22 using bit banging for a modem connection but decided simplisity is better when possible.
What do you think is good for multiple off board common serial connections? I have been looking at the CAN interface. There are some new devices available now that does all of the protocols on chip. I understand that CAN is becoming more popular in industrial applications.

Greg

[GARTHWILSON]

> I'll look at the bit banging deeper. I was orignally going to emulate a
> uart with the 65C22 using bit banging for a modem connection but
> decided simplisity is better when possible.

Compared to asynchronous serial (especially receiving), synchronous serial is easy to bit-bang. The controller can control the shift clock both transmitting and receiving, and timing is not an issue with many of the major SS protocols.

I like things simple too, but at times when I couldn't get the desired parts in small quantities, I gave up and brute-forced it with more common parts, even though it took a lot of them. When I have to chose the least of the evils, I'll chose software complexity over hardware complexity. After all, it's easier to edit and keep perfecting code than it is to re-arrange things or connections on an already-built-up board.

> What do you think is good for multiple off board common serial connections?

A method I have in the plans accommodates several kinds of serial interfaces. The intelligent ones are bit-banged, whereas I'm using the VIA's serial port for the dumb shift registers that so easily give hundreds of plain-vanilla I/O bits. You can do a lot of doubling-up on VIA pin use. I2C can normally share the clock and data lines with SPI or Microwire if: A., you never transition the data line while the clock line is high except to produce I2C start and stop conditions, and B., you keep the SPI/Microwire select lines false while addressing I2C parts (which have no enable inputs).

[Edit: We came up with 65SIB here on the forum, which is basically SPI but extends it in several directions at once, without really adding any required complexity. See the spec linked. For I²C, we have recommended a connector standard, I2C-6.]

> I have been looking at the CAN interface. There are some new
> devices available now that does all of the protocols on chip. I
> understand that CAN is becoming more popular in industrial
> applications.

I'm not familiar with CAN. What does it stand for and what company does it? (like SPI was originally Motorola's, Microwire was National's, 1-wire was Dallas's, etc.)

Garth

[greg]

Sorry for the late reply

What I ment by off board is long distance communications like across a factory floor. RS232 for instance except you can't directly connect multiple devices to an RS232. CAN means "Controller Area Network". You can connect multiple devices directly to the common CAN bus. It is an international open source protocol commonly used in the automotive industry but is finding it's way in general industry.

[GARTHWILSON]

I'll try to find some info on it. I devised such an interface with the 6522 but ran into the bug all brands of 6522 have with sending and receiving data under control of external clock. When receiving, you'll miss shifting a bit in if the rising clock edge on CB1 occurs too close to the falling edge of phase 2. When transmitting, you'll miss shifting a bit out if the falling clock edge on CB1 occurs too close to the falling edge of phase 2.

Implementing such an interface with the 6522 could still be done if you add a flip-flop (74xx74) and a couple of tristate buffer bits (74xx125 or '126), and use an extra I/O pin to control whether the clock signal goes out directly or comes in through the flip-flop. The flip-flop would be clocked by the rising edge of phase 2 to to keep you out of trouble. [Edit: I did this, and called the interface SS22. It is shown at viewtopic.php?f=4&t=2175.] I also used CA2 as a handshake line. You'd probably want a few passives to slow the edges down so reflections from various far-away line discontinuities wouldn't cause extra clock edges to fowl things up. If you make it an interface loop so each device on the loop has one input port and one output (requiring two 6522's) and daisychain them, data and clock on any given cable would only have to go one direction and to only one load or destination (ie, whichever one is next on the loop), so you could terminate the cable with its characteristic impedance and go as fast as the 6522's are capable of. Even with software overhead, I suppose you could do a couple megabits per second with WDC's 65c22's running at 10MHz.

Garth

[John West]

>What do you think is good for multiple off board common serial
>connections?

On the electrical side, RS485 is a good one. Two wire (make sure your grounds are all within the common-mode range of the transceivers) 5V differential, supporting many transmitters and receivers on the same bus. It'll put up with a huge amount of noise, and very long distances. We had dozens of units on kilometres of cable.

The protocol depends on your needs. We used UARTs, with a simple packet format containing the destination address as the first few bytes (so other receivers could ignore packets not addressed to them). We had one controller, and slaves would only speak when spoken to, so we never needed to worry about collisions.

Unfortunately, the processor was a Z80-derivative :-(

[greg]

John West,

The RS485 sounds like what I'm looking for. I will seriously investigate it.

Garth,
Thank you for the valuable information that you have provided.

Greg

[GARTHWILSON]

Greg, I appologize for misunderstanding the question. I hope you feel, as I do, that rabbit trails can still be profitable!

John, do you have any experience with B&B Electronics' serial interfacing products? (like RS-232 to RS-485?) They've been sending me catalogs for years. The products look quite interesting but I've never jumped in.

Garth