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.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.
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?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 .
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*.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.
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.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.
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.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*.
Yabbut....what are you going to connect the pins TO, other than the connectors of the uUSB jack?mofosyne wrote:W. H. Heydt ---> khulat says exactly what I was referring to.
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.W. H. Heydt wrote:Yabbut....what are you going to connect the pins TO, other than the connectors of the uUSB jack?mofosyne wrote:W. H. Heydt ---> khulat says exactly what I was referring to.
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 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.)aTao wrote: What is desired here is a RPi with only one cable connected. Neat and tidy like.
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.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.
USB 2 max 5 units @ 100mA could be pushing your luck there.W. H. Heydt wrote: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.)aTao wrote: What is desired here is a RPi with only one cable connected. Neat and tidy like.
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.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.
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!!)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.
Users browsing this forum: Baidu [Spider] and 28 guests