Connecting UART0 RTS and CTS to J1 for new BBB

GoogleGroups
1

Hi,

This question is meant for Gerald Coley since he is the only one who can answer it.

Gerald, is there any reason (aside from cost) that you didn’t connect the UART0 RTS and CTS lines (balls E17 and E18) to the J1 header for the serial console?

In my project I need all the LCD lines which eliminates using the RTS/CTS lines on UART2 through UART5. I also need I2C1 and I2C2, so I can’t use UART1 at all. That leaves only UART0 with handshaking lines. Unfortunately, those lines have been left as no connects on the current BBB.

I see that you are planning to release a new revision of the BBB, so I was wondering if you might consider connecting these lines to the J1 header. I realize you will also need to add another SN74LVC2G241 buffer for power down isolation and its associated bypass capacitor, and another pulldown resistor for the CTS input signal, but they are all small parts and fairly low cost.

I believe E17, UART0 RTS, should be buffered and drive J1 pin 2, the FTDI CTS input. Similarly E18, UART0 CTS, should be connected to the buffered output from J1 pin 6, the FTDI RTS output.

Is this something you might consider doing on the next revision of the BBB, or perhaps a later rev if it is too late for the next revision?

Perhaps a little bit of the increased price can go towards this increased functionality (in addition to the larger eMMC), instead of going to increase the margins for the manufacturers (which I agree is very important if the BBB is to be successful in the long term).

Thanks for your consideration.

Dennis Cote

2

Well, I'm not Gerald, but I'll be surprised if anything is changing on
the PCB. The change to a 4G eMMC requires no changes to the PCB and are
being made to improve margin, so don't expect to see any new parts.

On the other hand, why don't you just use P9.21 and P9.22 for the uart0
rts/cts lines? I suspect Gerald didn't tie them on the main board
because they are available on the expansion headers.

3

Well, I’m not Gerald, but I’ll be surprised if anything is changing on
the PCB. The change to a 4G eMMC requires no changes to the PCB and are
being made to improve margin, so don’t expect to see any new parts.

The eMMC may not require a new PCB layout, but the PCB has been revised for other minor changes in the past. I simply thought it might make sense to do both at the same time.

On the other hand, why don’t you just use P9.21 and P9.22 for the uart0
rts/cts lines? I suspect Gerald didn’t tie them on the main board
because they are available on the expansion headers.

I also require SPI0 so those pins are already allocated.

BTW, I noticed that in the expansion header pinout tables in the SRM, some signals are prefixed with PR1_. what is the significance of this prefix? Is it related to the PRU processors?

Dennis Cote

4

Yes, those are PRU peripherals. The PRU has a local UART, timer,
Ethernet controllers, etc.

5

I have no plans to make any changes to the board. Only change for Rev C was to populate the 4G eMMC. The idea of scrapping 80,000 is definitely a cost issue.

The requirement for the BBB was to be compatible with the BeagleBone.

Gerald

6

Does that mean those pins would not be available to the main CPU even if they were available? Would I have to use PRU software to drive them?

Dennis Cote

7

No. If they were connected, they could be used. They do not require the PRU to drive them.

Gerald

8

I have no plans to make any changes to the board. Only change for Rev C was to populate the 4G eMMC. The idea of scrapping 80,000 is definitely a cost issue.

I would never suggest scrapping that many boards. If you already have boards then by all means use them.

I was suggesting a change before your next order. When you are ordering PCBs in 100K quantities, the NRE charges for a PCB revision get spread pretty thin.

The requirement for the BBB was to be compatible with the BeagleBone.

If you add optional features to the BBB it is still compatible with the Beaglebone.

The software would have to be changed to activate the RTS/CTS handshaking if this new feature is desired. Otherwise these lines would still effectively be ignored and operate just as they do now, where they are not connected.

Dennis Cote

9

I have no plans to make any changes to the board. Only change for Rev C was to populate the 4G eMMC. The idea of scrapping 80,000 is definitely a cost issue.

I would never suggest scrapping that many boards. If you already have boards then by all means use them.

I was suggesting a change before your next order. When you are ordering PCBs in 100K quantities, the NRE charges for a PCB revision get spread pretty thin.

The requirement for the BBB was to be compatible with the BeagleBone.

If you add optional features to the BBB it is still compatible with the Beaglebone.

The software would have to be changed to activate the RTS/CTS handshaking if this new feature is desired. Otherwise these lines would still effectively be ignored and operate just as they do now, where they are not connected.

If you need something changed, you can always take the files and build your own. Everything is available.

10

Can you explain how the hardware is setup to assign these UART pins to either PRU or the CPU?

I have been looking through the TI TRM and AM335x datasheet, and at the TI Pin Mux Utility trying to figure this out. The TRM has very little to say about the PRU.

The fact that I can have the CPU drive UART0 on one set of I/O pins and the PRU driving PR1_UART0 on a different set of I/O pins seems to imply that UART0 is not the same peripheral as PR1_UART0. So how do I setup the PR1_UART0 pins to connect to the UART0 signals? The Pin Mux Utility shows them as separate peripheral interfaces.

It turns out that using the PRU might make sense in my application. To do this I would have to abandon using the AM335x I2C peripherals and add some SPI to I2C bridge parts to drive the I2C connected peripherals, but I suspect that would involve a lot of custom driver development to allow these bridged I2C buses to operate like the standard I2C buses. I would also have to develop some kind of IPC link between the CPU and PRU.

Dennis Cote

11

I will take it under consideration. Now is no the time to be changing PCBs. Maybe I can consider this in the November time frame once things settle down. You are the only person to ask for this change so I am not sure making a change and the expense for a couple of boards makes any sense. It is a bad precedent to set.

Gerald

12

The CPU can access the PRU resources, so you don't need to write PRU
code if you don't want. But access has to go through the PRU
interconnect fabric, and is likely to be slower than the more
traditional SoC UARTs and timers.

See section 3.2 'Global Memory Map' in the PRU Reference guide for
addresses to use from the host (ARM) side.

13

No. If they were connected, they could be used. They do not require the
PRU to drive them.

Can you explain how the hardware is setup to assign these UART pins to
either PRU or the CPU?

I have been looking through the TI TRM and AM335x datasheet, and at the TI
Pin Mux Utility trying to figure this out. The TRM has very little to say
about the PRU.

The fact that I can have the CPU drive UART0 on one set of I/O pins and the
PRU driving PR1_UART0 on a different set of I/O pins seems to imply that
UART0 is not the same peripheral as PR1_UART0. So how do I setup the
PR1_UART0 pins to connect to the UART0 signals? The Pin Mux Utility shows
them as separate peripheral interfaces.

UART0 and PR1_UART0 are totally different chunks of hardware. Do not
get confused by the fact that they both have "UART0" in the name, they
are *NOT* the same.

You control the selection of PR1_UART0 pin functions the same way you
control any other special functions: make a device-tree overlay and load
the appropriate settings into the pinmux registers.

It turns out that using the PRU might make sense in my application. To do
this I would have to abandon using the AM335x I2C peripherals and add some
SPI to I2C bridge parts to drive the I2C connected peripherals, but I
suspect that would involve a lot of custom driver development to allow
these bridged I2C buses to operate like the standard I2C buses. I would
also have to develop some kind of IPC link between the CPU and PRU.

There is an rproc interface for the PRU if that helps. See the example
BB-BONE-PRU-0[2-4] device tree overlays.

14

Thanks for the consideration.

I just want to clarify a couple of points. Others have also reported or asked about this issue. See the following postings.

https://groups.google.com/forum/#!searchin/beagleboard/UART0/beagleboard/eXUobUdLTsE/-TaIa1qQpAUJ
https://groups.google.com/forum/#!searchin/beagleboard/UART0$20RTS/beagleboard/TwAvj3Qy9Dg/E28GTz_mfA8J

Also, we are expecting to buy about 1K boards per year rather than a couple of boards. We will be buying directly from CircuitCo, but we would like them to be the same boards they build for distribution if at all possible.

Dennis Cote

15

I understand that. I was confused about why you suggested I could use the P9.21 and P9.22 pins as UART0 RTS and CTS, when they are connected to PR1_UART0 and not to UART0. My original question was about UART0 RTS/CTS and you said were not connected to J1 because they are available on the expansion header.

You wrote:
On the other hand, why don’t you just use P9.21 and P9.22 for the uart0
rts/cts lines? I suspect Gerald didn’t tie them on the main board
because they are available on the expansion headers.

So is there something I am missing? It seems to me these expansion header pins can’t be used for UART0 RTS/CTS.

Dennis Cote

16

I see. One of those commercial guys. I thought so.

Gerald

17

<Doh!>

All I can say is that's what happens when I answer email before coffee.

Sorry for the confusion, I was apparently mis-reading the pinmux chart.

:frowning:

18

You say that like it is a negative thing. I can almost hear the sigh afterwards.

I don’t understand your resentment of commercial users.

You have done a masterful job designing a board with lots of CPU power, and flexible I/O. You then decided to build the board in large volume to push the selling price as low as possible. The design is open and well documented so it is easy to work with. It is also well supported by both the community and TI. The same features that make it appealing to your hobbyist audience also make it appealing to potential commercial users.

I understand that some commercial users have put a strain on your production capacity, but you are selling through distributors like Avnet, Arrow, Digi-Key and Mouser that primarily deal with commercial customers. These customers expect to be able to buy products from them in volume. If you had only sold through the likes of Adafruit, Sprkfun, and Jameco I suspect you would not have had this problem, but the BBB also wouldn’t be the successful product it has become.

I suspect that you may resent commercial users for making profits off your design without paying you directly for it. This is the same issue faced by anyone doing open hardware or software development. IBM has made a lot of money selling Linux systems without paying the Linux developers for their software. On the other hand IBM has contributed a great deal of expert time and effort to Linux development. I think a similar thing is happening with the BBB. TI provides a lot of support to the Beaglebone community to encourage the adoption of their Sitara processors in commercial products. Given the good design, relatively low price, and direct support by TI, some of those commercial users will chose to use the BBB. They do so because they can’t build their own custom board for anywhere near the cost of the BBB, principally because of the volume production. But that production volume is, in large part, supported by those very same commercial users.

Perhaps the BBB is, or was, under priced as some have said. I think it will still be a good value at $55. I don’t think things would have been much different if the original price had been higher, unless it was so much higher that it was no longer attractive to the hobbyist users either. Hobbyist weren’t running out to buy the TI EVM boards before the BBB became available, because they simply cost too much.

I also think that you will get a lot of community support from commercial users in the long run. I try to answer questions on the forums when I can. I am still learning myself, so I try to refrain from answering unless I know the answer. Commercial use means there will be users who have HAD to get things to work, and they will be able to guide others through their struggles with the same issues.

I know this is getting somewhat off topic, but I thought it was worth saying. Commercial users aren’t inherently bad guys.

Dennis Cote

19

This could be a cool example of a hardware fork: what if you made the
change you need, and did a contract manufacturing run? Gerald
suggested that you wouldn't reach the economies of scale that allow
CircuitCo to sell the BBB for $45, but the price is going up anyway,
so maybe it'd work for you. If the changes you made are feasible, and
don't affect compatibility, since you're adding functionality, not
changing it, maybe it'd be easier to get your changes into the
'upstream'.

I am of course speaking out of turn as I never organized contract
manufacturing, but at your quantities I feel that I would consider it.

20

There is no resentment. We just don’t support commercial users of the boards with the BeagleBoard LOGO on it as we have stated.

http://www.elinux.org/Beagleboard:BeagleBoneBlack#Terms_of_Use

Everything is there for you to build it yourself. Go for it. No strings attached.

Gerald