Header for data pins on micro USB connector


28 posts   Page 1 of 2   1, 2
by roelb » Fri Jan 11, 2013 1:12 am
PCB layout feature idea: Have the (unused) data pins on the micro-USB connector routed to a header on the board. In that way, it would be possible for add-on modules to use the base micro-USB connector to provide, for example, a combined power/serial console connection.

Roel.
Posts: 6
Joined: Fri Jan 04, 2013 4:05 pm
by W. H. Heydt » Fri Jan 11, 2013 2:24 am
Not really.... As I understand the situation, the BMC2835 has *one* USB connection and that is router to the USB/LAN chip in the Model B and to a single USB connector in the Model A.

Having header pins for the uUSB connector would give you another way to connect power, but the data pins have nothing to be connected to on the processor chip.

(cf "The Moon is a Harsh Mistress" with respect phone systems.)
Posts: 1379
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)
by mofosyne » Tue Jan 22, 2013 12:24 pm
I think he is wants the possibility of using the microusb power input as a serial monitor. He doesn't require that the microusb be connected to the SoC, we know the SoC only usb out is directed to the ethernet and the 2 USB port.

E.g. connecting the raspberry pi to the laptop, currently only supply power to the raspberry pi. By putting a 'd+/d-' USB data header for the microusb on the raspberry pi, it will be trivial to add a small 'USB to serial' header expansion to the GPIO port. This will make on board serial development a single cable affair.

microusb(power) ---(d+/d-)--->FTDI_Serial_to_usb_chip----(UART)--->GPIO

I would prefer the raspberry pi to already have a serial to usb chip hooked to the data pins of the microusb, but this is a good compromise.
Posts: 15
Joined: Fri May 18, 2012 1:04 am
by rurwin » Tue Jan 22, 2013 12:43 pm
You don't actually need an add-on module, if you can handle 3.3V TTL serial at the other end of the wire. depending on the scenario that might even be easier, albeit non-standard.

+1, good idea.
User avatar
Forum Moderator
Forum Moderator
Posts: 2903
Joined: Mon Jan 09, 2012 3:16 pm
by mofosyne » Wed Jan 23, 2013 12:03 pm
Could be an approach, however for flexibility let's just keep the 'd+/d-' pins exposed as a header, instead of directly connecting it to UART GPIO.

If i wanted the usb cable to carry nonstandard rx,tx UART signal, I could just wire wrap the 'd+/d-' pins to the 'tx,rx' GPIO pins.

If i wanted to install an FTDI module, i could plug it in as well.

I of course prefer the serial chip installed by default, much less hassle for me, and will encourage kids to use console commands more often.
Posts: 15
Joined: Fri May 18, 2012 1:04 am
by roelb » Sat Jan 26, 2013 2:00 am
@mofosyne: indeed, that's what I meant..

I would not opt for a non-standard signal on the USB connector, just a header to expose these unused pins. It would indeed open up the option to add a simple add-on board enabling the micro-usb to act as a connection to the uart, either directly (non-standard) or through an FT230/232 or similar USB->TTL converter.

Why this idea? Well, I found out that fitting a standard RJ45 or DB9 connector on to an expansion board /and/ having the Pi still fit into a one of the cases is actually quite a challenge :-).

By the way, I would love to see a connector-less Pi - headers only - using a future-proof and guaranteed backwards compatible header layout. It would enable the Pi to be easily used as an embedded controller for any kind of project, just as it is now, but much more robust and without dangling cables. In such a version it could power projects /beyond/ the prototype stage, anything from student robotics to in-vehicle systems, appliances and everything else you can imagine.

Just put down a Pi footprint on the board and off you go, at a price below that of an MPU with similar capabilities, and much easier to integrate - a choice of OS's already running, no need for any other components, etc. Hell, it might even set a standard for interchangeable host boards. I would vote for .1mil headers, keeping it simple and at a size that is accessible for everyone, using either ribbon cables or mounting it directly onto a PCB. Even though that would be a design challenge ;-).

Roel.
Posts: 6
Joined: Fri Jan 04, 2013 4:05 pm
by W. H. Heydt » Sat Jan 26, 2013 7:44 am
roelb wrote:@mofosyne: indeed, that's what I meant..

I would not opt for a non-standard signal on the USB connector, just a header to expose these unused pins. It would indeed open up the option to add a simple add-on board enabling the micro-usb to act as a connection to the uart, either directly (non-standard) or through an FT230/232 or similar USB->TTL converter.


Okay.... So you want to jumper the data connections from the uUSB to some other signal that is already connected elsewhere on the board. If so, it *will* be non-standard, since there is no source of USB signalling other than the existing USB ports. Unless, of course, you want to use data connections from one of *those* ports to the data connections of the uUSB.

I'm afraid that I utterly fail to see any utility in doing that...

By the way, I would love to see a connector-less Pi - headers only - using a future-proof and guaranteed backwards compatible header layout. It would enable the Pi to be easily used as an embedded controller for any kind of project, just as it is now, but much more robust and without dangling cables. In such a version it could power projects /beyond/ the prototype stage, anything from student robotics to in-vehicle systems, appliances and everything else you can imagine.

Just put down a Pi footprint on the board and off you go, at a price below that of an MPU with similar capabilities, and much easier to integrate - a choice of OS's already running, no need for any other components, etc. Hell, it might even set a standard for interchangeable host boards. I would vote for .1mil headers, keeping it simple and at a size that is accessible for everyone, using either ribbon cables or mounting it directly onto a PCB. Even though that would be a design challenge ;-).


A lot of people want a lot of different things from the Pi. Ask yourself this: In what way would a Pi set up the way your asking for benefit the *Foundation's* goals of educating a new generation of truly computer savvy kids? How would a school teacher use a header-only Pi? How would a school teacher use 20 or 30 of them?

That Pis can be used (as is) in applications other than that that is the goal of the Foundation is both nice and interesting. However, the Foundation isn't in the business of designing embedded systems for everyone who wants one or everyone who has unique needs or desires in how the Pi is configured.

I suppose the real challenge is this...How can you use the Pi as it actually exists to further whatever goals you have?
Posts: 1379
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)
by mofosyne » Sat Jan 26, 2013 12:42 pm
W. H. Heydt I agree with most of your points, and that we do not really need a 'header' only raspberry pi, since it is pretty small already (plus it will screw with the 'economy' of scales, having another model of the Rpi).

As for why expose the USB input power's data header, again it's so that we can add an optional 'usb to serial' module, for one cable operations. This has applications in allowing students to 'access' their embedded projects (e.g. a robot) in school in a single cable, keeping cable clutter to a minimum.

Also not every student has easy access to a spare screen in the computer labs (most older computer lab's screens are VGA connector based, no composite), but any computer labs do have a USB port to view the raspberry pi as a serial interface.

This is a tradeoff between putting a 'FTDI' chip onboard the raspberry pi (compact but little more expensive), or permitting future installation of the FTDI chip later on via a header (cheap and easy, but more costly when needed).

p.s. Where is liz, for the final 'words from god', to help settle the debate lol?
Posts: 15
Joined: Fri May 18, 2012 1:04 am
by W. H. Heydt » Sat Jan 26, 2013 6:49 pm
mofosyne wrote:As for why expose the USB input power's data header, again it's so that we can add an optional 'usb to serial' module, for one cable operations. This has applications in allowing students to 'access' their embedded projects (e.g. a robot) in school in a single cable, keeping cable clutter to a minimum.


I'm sorry...this still reads as if you think the uUSB data pins are connected to some signal on the board. So far as I know they aren't. They'd have to be wired to *something*else* on the board in order to be functional for *anything*.

Also not every student has easy access to a spare screen in the computer labs (most older computer lab's screens are VGA connector based, no composite), but any computer labs do have a USB port to view the raspberry pi as a serial interface.


From what I know, you've got two choices. One is to use an existing USB port (either directly or through a USB hub) with a USB-to-serial adpapter. The other is to use some of the GPIO (or other header pins) to feed some addon that will provide a serial connection.
Posts: 1379
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)
by khulat » Sat Jan 26, 2013 7:34 pm
W. H. Heydt wrote:I'm sorry...this still reads as if you think the uUSB data pins are connected to some signal on the board. So far as I know they aren't. They'd have to be wired to *something*else* on the board in order to be functional for *anything*.


The proposed change was that the as of now unconnected data pins should be connected to a new header on the board. This new header could then be used to do all the stuff that people are talking about.
Posts: 104
Joined: Sun Feb 12, 2012 9:43 pm
by mofosyne » Sun Jan 27, 2013 2:54 am
W. H. Heydt ---> khulat says exactly what I was referring to.
Posts: 15
Joined: Fri May 18, 2012 1:04 am
by W. H. Heydt » Sun Jan 27, 2013 7:00 am
mofosyne wrote:W. H. Heydt ---> khulat says exactly what I was referring to.


Yabbut....what are you going to connect the pins TO, other than the connectors of the uUSB jack?

That's my point...there is nothing on the board to connect them TO. You are acting like they are connected--ultimately--to leads to the BCM2835 and--so far as I know--they are not only not connected, but there is no way to connect them. The ONLY USB connection on the BCM2835 is already connected to the LAN chip (Model B) or the sole USB port (Model A). Just ain't no other connection possible.
Posts: 1379
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)
by aTao » Sun Jan 27, 2013 7:05 am
W. H. Heydt wrote:
mofosyne wrote:W. H. Heydt ---> khulat says exactly what I was referring to.


Yabbut....what are you going to connect the pins TO, other than the connectors of the uUSB jack?

That's my point...there is nothing on the board to connect them TO. You are acting like they are connected--ultimately--to leads to the BCM2835 and--so far as I know--they are not only not connected, but there is no way to connect them. The ONLY USB connection on the BCM2835 is already connected to the LAN chip (Model B) or the sole USB port (Model A). Just ain't no other connection possible.


You could jumper them to GPIO pins, use a flying lead to the full size USB sockets, add a whole circuit board and jumper to that. There is plenty to connect them to.

What is desired here is a RPi with only one cable connected. Neat and tidy like.
>)))'><'(((<
User avatar
Posts: 439
Joined: Wed Dec 12, 2012 10:41 am
Location: Swine Town UK
by khulat » Sun Jan 27, 2013 10:10 am
I'll try again this time with a picture, in the hope that i can express the idea better with this. Excuse the quality, it is only a 2 minute doodle.
P.S.: The Addon Board would contain a FTDI Chip.
Attachments
RPI.jpg
RPI.jpg (19.88 KiB) Viewed 1625 times
Posts: 104
Joined: Sun Feb 12, 2012 9:43 pm
by W. H. Heydt » Sun Jan 27, 2013 5:06 pm
aTao wrote:What is desired here is a RPi with only one cable connected. Neat and tidy like.


You can achieve that right now by powering a Pi through an existing USB port. (Just don't try it with a Rev. 1, Vers. 2 board...the ones with the 140mA polyfuses.)
Posts: 1379
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)
by W. H. Heydt » Sun Jan 27, 2013 5:11 pm
khulat wrote:I'll try again this time with a picture, in the hope that i can express the idea better with this. Excuse the quality, it is only a 2 minute doodle.
P.S.: The Addon Board would contain a FTDI Chip.


Okay...that's the alternative I thought you might be thinking of. It still wouldn't make those data pins connect to CPU and it wouldn't make the signaling you show be USB compliant. It also appears to be redundant, since you are *also* using the GPIO pins.

What data do you propose to carry on the *data* pins of a microUSB header and how do you propose to get that data to the CPU?
Posts: 1379
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)
by aTao » Sun Jan 27, 2013 5:21 pm
W. H. Heydt wrote:
aTao wrote:What is desired here is a RPi with only one cable connected. Neat and tidy like.


You can achieve that right now by powering a Pi through an existing USB port. (Just don't try it with a Rev. 1, Vers. 2 board...the ones with the 140mA polyfuses.)


USB 2 max 5 units @ 100mA could be pushing your luck there.
USB 3 max 6 units @150mA but RPi isnt USB 3

Also you lose FS 3 protection and D17 (over volt protection) is then a long long way from the power input making it void.


EDIT: C6 is also the wrong end of the board, a potential cause of instability.,
Last edited by aTao on Sun Jan 27, 2013 5:33 pm, edited 1 time in total.
>)))'><'(((<
User avatar
Posts: 439
Joined: Wed Dec 12, 2012 10:41 am
Location: Swine Town UK
by W. H. Heydt » Sun Jan 27, 2013 5:23 pm
Okay...after a little research, I *think* know what you are trying to do. Correct me if I'm wrong...

You want to do RS-232 serial communication on the GPIO pins and convert that (both ways) through an FTDI to the data pins on the microUSB power connector, so there is now data access (albeit pretty slow since RS-232 is spec'd to max out at 115Kbps as compared to USB 2.0 at 480Mbps) on the power connector.

This implies that you intend to put a device at the other end of the power cable that will transfer data to and from the Pi, in a rather roundabout way. Possibly a hub that will allow the Pi to draw 700mA on a hub port...
Posts: 1379
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)
by mofosyne » Mon Feb 04, 2013 12:05 am
You are almost correct. The access you get by connecting to the serial port of the GPIO (UART), is the 'debian' linux console. You get all the bootup messages (and the resulting error messages if it occurs during bootup, easy to debug). You also have direct access to the linux console and can use it as if you have sshed/telnetted to it over the network (But with the convenience of not needing to know it's IP address).

Its just a really good way to use the raspberry pi as an embedded debian development platform. The USB FTDI to Serial module for the raspberry pi, just make it more tidy.
Posts: 15
Joined: Fri May 18, 2012 1:04 am
by W. H. Heydt » Mon Feb 04, 2013 5:36 am
mofosyne wrote:You are almost correct. The access you get by connecting to the serial port of the GPIO (UART), is the 'debian' linux console. You get all the bootup messages (and the resulting error messages if it occurs during bootup, easy to debug). You also have direct access to the linux console and can use it as if you have sshed/telnetted to it over the network (But with the convenience of not needing to know it's IP address).

Its just a really good way to use the raspberry pi as an embedded debian development platform. The USB FTDI to Serial module for the raspberry pi, just make it more tidy.


And by using that "tidy" solution, you're transferring data over the Pi's *power* connection, which means that whatever is at the other end of that cable needs to supply 5v at 700mA in addition to handling data.

Sounds pretty messy to me...
Posts: 1379
Joined: Fri Mar 09, 2012 7:36 pm
Location: Vallejo, CA (US)
by mofosyne » Sun Feb 10, 2013 11:49 am
Not really if you think about it.

Many people run their raspberry pi off the USB port to their PC or laptop (e.g. I do). Why not have data as well. You do notice that you can charge and run your mobile phone off a PC/laptop USB port too? Same here.
Posts: 15
Joined: Fri May 18, 2012 1:04 am
by rurwin » Sun Feb 10, 2013 12:33 pm
The point is that we are not talking about using the RaspPi in education or in hobby projects. We are talking about using it as an OEM component in a bespoke industrial system. That probably dooms the concept as being too far from the thrust of the Foundation's aims, but as a talking point it is valid.

In such a bespoke environment, the device at the other end of the wire would be designed to provide power and whatever interface was required. That circuitry is required in any case, no matter how many wires are used. But the added complexity of wiring harness in having two wires where there need be only one, costs money.

The alternative solution is powering the Pi from the GPIO pins, but that bypasses the fuse and so another must be provided at extra cost.
User avatar
Forum Moderator
Forum Moderator
Posts: 2903
Joined: Mon Jan 09, 2012 3:16 pm
by WeUsePis » Sun Feb 10, 2013 1:17 pm
mofosyne wrote:Many people run their raspberry pi off the USB port to their PC or laptop (e.g. I do). Why not have data as well. You do notice that you can charge and run your mobile phone off a PC/laptop USB port too? Same here.

I'd call that luck or the clever use of special USB ports that are designed to carry a current way above the spec of USB2.0 which caps the current at 500 mA. Or are you talking about USB 3.0? There we get 900 mA assuming the implementation is done right. The 900 mA are sufficient for running a Pi, 500 mA is pushing it. And many new smartphones and especially tablets suck way more current than the 500 mA or even 900 mA (e.g., the iPad pulls 2.1 A!!)
Based on what I read about the design choices, the micro USB power port was chosen to make use of potentially already available power supplies for mobile devices. Same applies to the request to have a receptor for a barrel plug. Neither option does anything for data. If the Pi designers would have opted for a barrel plug receptor instead of the micro USB socket we would not have the discussion about what to do with the data pins because there wouldn't be any.
That said, the USB ports on the Pi have the 5V connected to the power in line. Some Pi users reported that they have USB hubs that backfeed the power and that it is sufficient to run the Pi. There are also data transfer cables based on USB, such as Dynex DX-C114200 (just an example, not an endorsement). That way you can connect to USB hosts together for data (file) exchange. I do not know if such a cable pulls the 5V power straight through, but if it does you could connect the Pi to a PC or Mac and power it over one cable...assuming the the OS on the Pi has drivers for the USB device. Alternatively, use shrink tubing and fuse two USB cables together, one special one for the data transfer and one that only carries power. The downside is that this will use up to USB ports. I also read that folks are running the Trendnet TU2-PCLINK successfully with Linux.
And why do I mention all this? If there is a need to get USB connection and power the Pi from USB ports on a PC or Mac you can most likely do that today with the applicable cables. No need for hardware changes on the Pi. I do not claim that it is a straightforward and guaranteed to work option, but it is an option.
Our Pi Blog - http://weusepis.wordpress.com/
Posts: 87
Joined: Mon Dec 31, 2012 4:02 pm
Location: Upstate New York
by rurwin » Sun Feb 10, 2013 2:04 pm
It's guaranteed to work in the target application, but it goes the wrong direction. The OP wants the Pi to be a USB slave. Your suggestion makes it a USB master.
User avatar
Forum Moderator
Forum Moderator
Posts: 2903
Joined: Mon Jan 09, 2012 3:16 pm
by roelb » Mon Feb 11, 2013 5:20 pm
I'm still amazed at how many people have no clue at all to the existance of a hosts' <em>serial console</em>, even though they are actively running a Unix OS on a development board :-).

But anyway, let's hope that this suggestion has landed with the right people. As far as the "header-only" suggestion and the remarks made by W. H. Heydt: sure, if you are looking /only/ at primary education and simple programming or system administration tasks, you're probably right.

But the Pi opens up a great opportunity to use it as an embedded controller for any project imaginable. Not just in primary schools, but all the way to universities. You've got a capable host, very low power consumption, a choice of hit-and-run OS packages (FreeBSD, Lynx, Linux) and easy control of other hardware through I2C, SMI or generic GPIO. I can see it become the de-facto standard at universities for use in robotics and similar projects.

However, if you were to use a Pi for such a project right now, you would probably have it dangling from a bunch of cables - or building a Lego chassis for it :-). Not a very reliable setup. The possibility to design your PCB to receive a Pi (or any other controller, RPi could set the standard here for a generic header layout!) without using any cables would be great. Such a development could also spawn other Pi-like hosts being developed by other parties, maybe even using the same header-specs if they are carefully thought out.
Posts: 6
Joined: Fri Jan 04, 2013 4:05 pm