Atmel vs others Tx and Rx pins placement

[VinzC]

Hi all.  This is no matter for a thesis rather than some questioning that occurred to me after two project in which I need communication ports. So far I have used Atmel micro-controllers (ATtiny 1634 and ATmega64M1) with USB (MCP2221) and CAN (ATA6560) transceivers. What I've noticed so far is that the Rx and Tx pins on both micro-controllers don't face their respective equivalent on transceivers.

For instance if you have the MCP2221 face an ATTiny, the RxD and TxD pin on the micro do not face their equivalent on the MCP2221: Rx is 20 or 2  and Tx is 19 or 1 on ATtiny 1634. (It's even worse on ATmega given that Tx and Rx are not adjacent pins.) Same goes between the CAN Rx and Tx pins... while both the transceiver and micro units are made by Atmel!

In my projects I placed my components on opposite sides of my PCB, I found it more convenient to do so. But I wonder. Why is it so?

I know it's impossible to account for the pin placement of every processor chip made by every company. However in the case of Atmel (micro and CAN transceiver, for instance) I wonder if they could have not opted for a more sensible (consistent) disposition.

Any thoughts on that?

[Rerouter]

It likely comes down to where the transceivers are located on the die, i would imagine its not as reliable to cross bond wires, so where the bond pad is sets the pinout,

As for the original silicon designer, it could have been easier to group the output transceivers and input in different locations, both to reduce cross-talk and reuse common parts,

[VinzC]

Thanks Rerouter. I guess there's nothing to do but cope with it, right ?

Saying that there's yet another trap (for young players) that I fell for today morning: it was just after I submitted my board to Eurocircuits.com that I had a feeling I swapped two of these signals. Indeed when I checked I had swapped Rx and Tx between the MCP2221 and the micro. It went «panelize» status right before I had time to upload a fixed board.

That one boils down to how the manufacturers name pins on their chips. In the case of MCP2221 Tx is an... output and Rx an input, just like the Atmel (or any other MCU or CPU). On the other hand Tx is an input and Rx an output on the CAN controller (ATA6560/61)! Whichever makes more sense, that reminds me of the good ol' tricky question «DCE or DTE»?... Even triple check didn't prevent me from spotting that.

Both the MCP2221 and ATA6560/61 are transceivers so why Rx input on one and output on the other...  I like consistency and such discrepancies are a pain in the neck as such mistakes could be easily avoided. But, yeah, have to get away with it as well.

[suicidaleggroll]

That one boils down to how the manufacturers name pins on their chips. In the case of MCP2221 Tx is an... output and Rx an input, just like the Atmel (or any other MCU or CPU). On the other hand Tx is an input and Rx an output on the CAN controller (ATA6560/61)! Whichever makes more sense, that reminds me of the good ol' tricky question «DCE or DTE»?... Even triple check didn't prevent me from spotting that.

I -HATE- the Tx/Rx naming convention.  Every manufacturer has their own interpretation of what "Tx" and "Rx" should mean...does "Tx" mean "I transmit on this pin", or does it mean "connect this pin to Tx on your device"?  The entire world would be a better place if they would just drop "Tx"/"Rx" entirely and replace them with arrows showing the direction of data transfer, arrow leaving the chip for an output, arrow entering the chip for an input.  Or at least write "input" and "output" next to "Rx" and "Tx" so end-users know what convention is being used by the manufacturer.

[Pinkus]

I -HATE- the Tx/Rx naming convention....

Me too. Thats why I always draw little arrows with the signal direction to the needed serial ports when I draw the schematics. Alternatively the part itself may be drawn with more information about the data direction. The attached example shows both, naturally here the arrows are redundant.

[ajb]

Take a very careful look at the datasheet, then label them RXI/TXO or RXO/TXI as you prefer.

It gets a little trickier with more complex MCUs that have flexible pin mapping.  I got bitten the first time I laid out a PCB for an atmel SAMD21, which allows you to assign UART/SPI functions to each of four pin groups in almost any arrangement--except the one I'd chosen.

[Hypernova]

This is why I love SPI's naming convention: Master OUT Slave IN and vice versa. You don't get more spoon fed then that.

[JPortici]

Many modern parts don't have preassigned pins anymore for digital peripheral.. all new pics for example have peripheral pin select, even pic12 and pic16.. so aside from some special reasons (like I2C which requires specific hardware on the port) and to different degree of complexity, pretty much anything digital can go everywhere

[linux-works]

this is why you do not just design projects 'on paper' and then send them out.

you always wire up a test, first.

it amazes me that people still trust printed or online docs.  there are 3 kinds of docs:

- what is printed or online
- what is inside the engineer's mind who designed it
- what the thing really does in real life

the last one is the only one that truly matters and you can't know how things work until you build a PROTO.

at my last job, I ran into people who did nothing BUT paper designs.  they saw nothing wrong with it.  and yes, it took them extra iterations to get things actually working, lol

[MT]

I -HATE- the Tx/Rx naming convention.  Every manufacturer has their own interpretation of what "Tx" and "Rx" should mean...does "Tx" mean "I transmit on this pin", or does it mean "connect this pin to Tx on your device"?  The entire world would be a better place if they would just drop "Tx"/"Rx" entirely and replace them with arrows showing the direction of data transfer, arrow leaving the chip for an output, arrow entering the chip for an input.  Or at least write "input" and "output" next to "Rx" and "Tx" so end-users know what convention is being used by the manufacturer.

Single wire bidirectional USART com's are on TX pin only.

[retrolefty]

That one boils down to how the manufacturers name pins on their chips. In the case of MCP2221 Tx is an... output and Rx an input, just like the Atmel (or any other MCU or CPU). On the other hand Tx is an input and Rx an output on the CAN controller (ATA6560/61)! Whichever makes more sense, that reminds me of the good ol' tricky question «DCE or DTE»?... Even triple check didn't prevent me from spotting that.

I -HATE- the Tx/Rx naming convention.  Every manufacturer has their own interpretation of what "Tx" and "Rx" should mean...does "Tx" mean "I transmit on this pin", or does it mean "connect this pin to Tx on your device"?  The entire world would be a better place if they would just drop "Tx"/"Rx" entirely and replace them with arrows showing the direction of data transfer, arrow leaving the chip for an output, arrow entering the chip for an input.  Or at least write "input" and "output" next to "Rx" and "Tx" so end-users know what convention is being used by the manufacturer.

 I hate it too. I spend decades wiring up serial links between different manufactures equipment and for a standard RS-232 certainly created a lot of troubleshooting and wasted time.

 I really like how the SPI interfaces uses signal names like MISO and MOSI. No confusion of what the signal direction is between the master and slave.

[VinzC]

it amazes me that people still trust printed or online docs.

Just for clarification: manufacturers datasheet fall into either or both of those two categories. Did you mean to include them as well?

I -HATE- the Tx/Rx naming convention.  Every manufacturer has their own interpretation of what "Tx" and "Rx" should mean...does "Tx" mean "I transmit on this pin", or does it mean "connect this pin to Tx on your device"?  The entire world would be a better place if they would just drop "Tx"/"Rx" entirely and replace them with arrows showing the direction of data transfer, arrow leaving the chip for an output, arrow entering the chip for an input.  Or at least write "input" and "output" next to "Rx" and "Tx" so end-users know what convention is being used by the manufacturer.

I hate it too. I spend decades wiring up serial links between different manufactures equipment and for a standard RS-232 certainly created a lot of troubleshooting and wasted time.

I really like how the SPI interfaces uses signal names like MISO and MOSI. No confusion of what the signal direction is between the master and slave.

I don't quite agree on that. Master In Slave Out is as confusing as Tx or Rx. Why?

• It does not give any information on what goes in or out....
• unless you know whether the chip acts as a slave or a master
• Master or Slave is a function unbound to the schematics: it is a logical, not electrical feature.

Some chips have serial data pins named DI or DO (Data In/Out, e.g. WS2812) or even SI or SO. Both conventions unambiguously identify the pin function and direction without having to look at the schematics.

Right, you might know you need to wire all MOSI nets together and all MISO nets together. But MOSI is an input on a slave and an output on the master, MISO is an output on a slave and an input on the master... Still ambiguous. If you can get what goes in or out of the chip by just reading the pin name then the pin is cleverly named. As to MOSI and MISO you either have to know whether the chip is a slave or a master hence resort to its context (i.e. the schematics), which is not as good.

Now if the manufacturer also uses a pin named DI to also send data *out* (e.g. Newhaven LCDs) that is a different story...

[timb]

it amazes me that people still trust printed or online docs.

Just for clarification: manufacturers datasheet fall into either or both of those two categories. Did you mean to include them as well?

I -HATE- the Tx/Rx naming convention.  Every manufacturer has their own interpretation of what "Tx" and "Rx" should mean...does "Tx" mean "I transmit on this pin", or does it mean "connect this pin to Tx on your device"?  The entire world would be a better place if they would just drop "Tx"/"Rx" entirely and replace them with arrows showing the direction of data transfer, arrow leaving the chip for an output, arrow entering the chip for an input.  Or at least write "input" and "output" next to "Rx" and "Tx" so end-users know what convention is being used by the manufacturer.

I hate it too. I spend decades wiring up serial links between different manufactures equipment and for a standard RS-232 certainly created a lot of troubleshooting and wasted time.

I really like how the SPI interfaces uses signal names like MISO and MOSI. No confusion of what the signal direction is between the master and slave.

I don't quite agree on that. Master In Slave Out is as confusing as Tx or Rx. Why?

• It does not give any information on what goes in or out....
• unless you know whether the chip acts as a slave or a master
• Master or Slave is a function unbound to the schematics: it is a logical, not electrical feature.

Some chips have serial data pins named DI or DO (Data In/Out, e.g. WS2812) or even SI or SO. Both conventions unambiguously identify the pin function and direction without having to look at the schematics.

Right, you might know you need to wire all MOSI nets together and all MISO nets together. But MOSI is an input on a slave and an output on the master, MISO is an output on a slave and an input on the master... Still ambiguous. If you can get what goes in or out of the chip by just reading the pin name then the pin is cleverly named. As to MOSI and MISO you either have to know whether the chip is a slave or a master hence resort to its context (i.e. the schematics), which is not as good.

Now if the manufacturer also uses a pin named DI to also send data *out* (e.g. Newhaven LCDs) that is a different story...

Uh, no... I'm not sure what you're on about, but Master Out Slave In is pretty damn unambiguous. You obviously need to know which device is the master and which is the slave, otherwise you wouldn't know how to route the clock or chip select lines.

In this case, the MCU would be Master and the device would be Slave.

[VinzC]

You obviously need to know which device is the master and which is the slave, otherwise you wouldn't know how to route the clock or chip select lines.

... which was precisely my point! If a pin is named SI or DI you don't need to know whether it's a slave or a master: it's an input. Period.

[timb]

You obviously need to know which device is the master and which is the slave, otherwise you wouldn't know how to route the clock or chip select lines.

... which was precisely my point! If a pin is named SI or DI you don't need to know whether it's a slave or a master: it's an input. Period.

Then how is DI any different from RX? The whole point behind MOSI/MISO is it's completely unambiguous. You connect MOSI to MOSI and MISO to MISO. It's that simple. You don't actually need to know which is master and which is slave. In fact, if you had two MCUs connected via SPI like this, they could swap master/slave roles all day long if they wanted to, without rewiring anything.

My point about needing to know which device is master is only relevant when you actually start programming the MCU. For example, some SPI slaves actually generate the clock, instead of the master. But like I said, that's only a software issue; you still connect the lines up the same way.

From a hardware perspective, master/slave is only relevant if you've got more than one slave on a SPI bus. Because then you need more than one CS/SS pin on the master. But everything still wires up the same:

Master
MOSI>________>MOSI (Slave 1)
                  \___>MOSI (Slave 2)

MISO<________<MISO (Slave 1)
                  \___<MISO (Slave 2)

SCLK<>_______>SCLK (Slave 1)
                  \___<SCLK (Slave 2)

CS1>__________>CS (Slave 1)

CS2>__________>CS (Slave 2)

As an aside, RS-232 actually has a convention for the RX/TX issue. TX from a DTE goes to the RX of a DCE and vice versa.

[westfw]

RS-232 actually has a convention for the RX/TX issue. TX from a DTE goes to the RX of a DCE and vice versa.

The problem with "RS232" is that it became VERY ambiguous as to who was "DTE" and who was "DCE."    It was swell when you had a data terminal and a modem, and not so much when you had a microcomputer and a printer.  At the chip level, there is no such thing, so it wouldn't help the OP.

[dmills]

On the MOSI/MISO thing, I got stuffed good and proper when one of our contractors connected an SDout pin to a net called SDOUT... Trouble was the pin was on a slave device, and the net was named for the pin on the master!

I amended our design standards to mandate MOSI and MISO as net names for SPI after that little screwup.

RS232 was always a mess, anyone else remember little in line boxes with two rows of LEDs and a handful of jumper wires that you could use to help you figure out which random set of wiring would make things work (It was usually the handshake signals that were really random)?

Regards, Dan.

[retrolefty]

On the MOSI/MISO thing, I got stuffed good and proper when one of our contractors connected an SDout pin to a net called SDOUT... Trouble was the pin was on a slave device, and the net was named for the pin on the master!

I amended our design standards to mandate MOSI and MISO as net names for SPI after that little screwup.

RS232 was always a mess, anyone else remember little in line boxes with two rows of LEDs and a handful of jumper wires that you could use to help you figure out which random set of wiring would make things work (It was usually the handshake signals that were really random)?

Regards, Dan.

 Sure do remember. We use to buy them from Black Box co. and we called them 'break-out boxes'. Then after getting the link to actually work we would figure out what kind of standard null-modem or straight through gender changer would make the cable actually work, or wire a new cable with all the proper jumpers and cross over connectors. Don't miss those days much, retirement is easier. 

[VinzC]

remember little in line boxes with two rows of LEDs and a handful of jumper wires that you could use to help you figure out which random set of wiring would make things work (It was usually the handshake signals that were really random)?

Regards, Dan.

Ah... still have two of those.