avoiding usb

There are several ways to approach this, it May be possible to get a PS2 keyboard to work using this UART, but you could also Make a serial keyboard too, in fact the Arduino is perfectly able to do this, an 8x8 matrix array using the keypad library and then output this as serial data directly to the UART would give you 64 keys.

or you you could use a PC and a terminal emulator, or even buy an old dedicated terminal, some are even handheld with an LCD screen for local echo.

I don`t really know much about the Pi, but i`m wondering if you Did need to use USB, if one of these 4 way HUB/Splitters would work on it?

This might well be the worst problem with the Pi.  This Broadcom SoC just wasn't made for networking.

It contrasts rather badly with the TI SoC on the BeagleBone which provides both Ethernet MAC and two USB ports on the chip directly.

I wonder if Broadcom has a better device in this range that might be used for a future version of Pi.

well yes, it is somwhat less than ideal, but that`s what there is to work with.

know any work-arounds?

YT2095 . wrote:

 

know any work-arounds?

Use a Model A (once available) in combination with the Ethernet-over-USB gadget driver.  The on-chip USB controller will then handle the network traffic in the usual interrupt-driven way (an assumption, but reasonable I think), and a downstream class-compliant USB hub will also be handled by the normal interrupt-driven USB driver.

It's only a partial solution since it requires something else to provide the actual Ethernet hardware, but at least it avoids the polling.

Interesting that you should mention polling, Esp since the Pi is open source (for the S/ware at least), it should be perfectly possible to Lower this 8KHz polling rate to something more reasonable surely?

or perhaps make it at least Semi-inteligent whereby it`s scanned at a rate suitable for that which is in use.

I guess you could poll less frequently for keyboard and mouse traffic since their data rate is somewhat low, but remember that the average response latency is half the polling interval, so it would become progressively worse as you decreased the polling rate.  And for Ethernet, that sounds extremely unlikely as a viable solution at all, since you could end up losing data in buffer overruns between polls.

Basically, "polling == bad", period.

My understanding, which might be wrong, is that the 20% CPU overhead from the 8k interrupts/sec is from the USB driver on the on-chip SoC USB port. So it would be just the same in the Model A.  It has been suggested that it might be possible to make a much more efficient USB driver, reducing the interrupt service routine overhead by up to 90%, but even though the code is open-source, not clear if there's enough good documentation to really do this (?)

The 8 kHz interrupt rate is actually mandated by the specific USB hardware they used in the SoC. 8 kHz is apparently the high-speed USB2 "micro-frame" rate, and any lower rate would not work correctly (at least with high-speed USB devices). You can think of it in analogy to a "winmodem" which offloads some of the processing to the CPU, to save complexity/cost in hardware.

jbeale wrote:

 

My understanding, which might be wrong, is that the 20% CPU overhead from the 8k interrupts/sec is from the USB driver on the on-chip SoC USB port.

It's a timer-driven poll of the external device, apparently.  On a Model A, it wouldn't need to poll anything, since the USB driver would just sit there quiescent and only become active when USB data arrives and the SoC's USB controller then generates an interrupt to process it.  Ie. event-driven, just like everything else in the standard *nix model.

Morgaine Dinova wrote:

 

YT2095 . wrote:

 

know any work-arounds?

 

Use a Model A (once available) in combination with the Ethernet-over-USB gadget driver.  The on-chip USB controller will then handle the network traffic in the usual interrupt-driven way (an assumption, but reasonable I think), and a downstream class-compliant USB hub will also be handled by the normal interrupt-driven USB driver.

I don't think going with a Model A with external USB hub and Ethernet device would buy you anything.  The LAN9512 is really just a USB hub plus Ethernet device in a single chip.  The performance problem with RasPi is entirely the host software which runs on the BCM2835 in either case.  It just sounds like it's non-optimized software and could be replaced with something efficient if someone wants to go to the trouble of learning all about writing kernel drivers and USB control structures.  The USB 2.0 standard goes into quite a bit of detail about what's needed.

My understanding of USB host software is that it needs to find out what devices are connected and use device driver information to determine how often it needs to poll each device.  Then it uses a clock interrupt to trigger the polling routine.  ARM actually has very efficient interrupts if you choose to use them properly: ARM uses a different set of processor registers for interrupts so you don't have to save and restore main thread registers in memory.  However, you may have to do this in assembly language level, and it's easier to throw together a C interrupt service routine and accept the overhead, figuring that someone else will optimize it "some day".

I don't know how much polling intelligence is built into USB host hardware.  It may be that it can do a certain amount of this by itself, if one writes the software to configure it properly.  At one place I worked, we had the acronym SAMP: "Simply A Matter of Programming".  It was used both for features that required a small amount of programming and -- with irony -- for those that required a huge amount of programming.

I don't think it can be so John, because if it were, then all machines would be suffering the same USB polling overhead whenever they have downstream hubs and other devices attached.

No sensible engineer designs polled systems like that.

The problem here seems to be compounded by a dreadful driver implementation, but even if the driver were perfect then it would still be appallingly bad if it has to poll a downstream device.  You can't overcome the response latency and the overhead of active polling by writing a perfect driver.  It's the polling model here that's inherently broken.