Actually, I think it will get better than it is now. Once the FIQ stuff is released, Gordon's going to be working on the Isynchronous transfer stuff (I think that's what it's called, I'm no USB expert). But, as I said above, the timescales on all this stuff is pretty fluid. Note that M33P gave a very comprehensive summary (and very good) of the issues encountered above, so IMO there will always be some things that won't work as well as they do on a desktop USB controller (the one on the Raspi is designed for mobile devices, and has limitations). So although it will get better, there will always be some esoteric devices that probably won't work very well. I think they will be in the minority however, as even now the vast majority of devices work OK (once you have all the fixes). It's a shame there may well be these corner cases, but as the development has continued on this, the limitations of the device have become clearer, and expectations change with greater knowledge. The biggest issue I think will be the limit to the number of devices that can be successfully attached, rather than specific devices not working, but most people won't get near that limit anyway.obcd wrote:Jamesh made a point.
If the way usb works now doesn't work for you, don't complain but sell the board and move on to something else. After all, it's just 35 US$
This leads me to believe it won't get much better anymore than it is at the moment.
I don't blame the people working on it about that. If the hardware isn't up to the job, even clever programming can't totally fix it. They are doing a great job, lot has improved since the beginning.
I wouldn't be pi**ed about this if they had told me six months ago.
But then they said, it will be fixed, we just don't know when as we are a charity foundation etc. etc.
If you doubt questionning that you were a concern troll and freightend off with the banhammer.
And when I read the latest discussion here, I get a "déjà vu" feeling when suddendly the claim comes back that the Pi is a low cost computer for educational purpose...So don't expect....
The problem is how to make such a list, and equally importantly, keep it accurate. There is the Wiki which would seem to be the best if not only approach. There's no way the Foundation can test every item in existence (millions of them), so it's necessary for the people using those devices to update the list. Then a software release might fix a whole bunch of them and the list will then be out of date. It's a difficult problem.ausserirdischegesund wrote:I think a lot of the frustration around USB could be removed if there was more detailed and reliable documentation what works, and what not.
It really makes a difference if you have to buy three webcams or USB hubs to get a working one, or if you can look up known good setups in a table (with exact model designation, USB id and description of use scenario) and go shopping for that. The wiki is only half there. Too many "it works" where it does not (or only in some scenarios), not enough detail (e.g. do devices need extra power).
Most of this will work out eventually. I've got stuff that works exceptionally well (my USB hard disk works for months without a problem, and back-powers the pi too, the webcam I bought, well that is another story .
Look up ARM FIQ's for how gsh latest code fixes the interrupt speed issue.obcd wrote:As it's known what causes the problems, it should be possible to give a clue of when problems can be expected. It's perfectly possible to figure out what type of endpoints an usb device is using. Even if a wiki list isn't complete, it should be possible to create a list of known "good" working device. Which such a list, I can go shopping for devices on that list. Further on, usb devices can be divided in classes like the HID class, the Storage class, Serial device class, etc.
Maybe the accurate information isn't there because it's simply unknown. Maybe keyboard X will work perfectly on my Pi, and will loose keystrokes on yours. First of all, we will both need the same kernel and firmware to test in equal conditions. Next we will both need the same power supply as that also is a source of fustration, And finally, I shouldn't be typing slower than you do as obviously you will loose more keys/minute if you type faster. Finally, it might turn out that altough both our keyboards carry the same type number, mine might have another firmware rev. than yours. So I posted mine as working fine, and you are fustrated because it's inaccurate. Keeping track of the number of success/failure cases can help, but most people won't care posting that information unless there is a bonus for doing this.
If we look at it more technical, it seems that the needed real time response within a microframe can't be guaranteed. Such a response is needed to avoid the loose of split transactions. Pretty much every interrupt source going on can increase the real time response time (as one interrupt can't interrupt another ongoing interrupt handler) which makes predicting and fixing it very difficult.
The trouble with that is that the manufacturers change their devices without changing the part numbers, so what worked last time you bought one may not work this time.obcd wrote:... Even if a wiki list isn't complete, it should be possible to create a list of known "good" working device...
That is one of the biggest problems in USB country. Especially wireless USB keys can have different chipsets, but the same type numbers. Belkin and Dlink, for instance do this quite frequently. And some of these are on the "working" list.Burngate wrote:The trouble with that is that the manufacturers change their devices without changing the part numbers, so what worked last time you bought one may not work this time.
Ok, so the FIQ is comparable to the NMI that was present on some early day microcontrollers.Look up ARM FIQ's for how gsh latest code fixes the interrupt speed issue.
No worries, not going to advise sale - just patience. These sorts of things take a while to diagnose, determine a fix, and implement as you well know. That 'while' is quite often indeterminate. So patience is required.scrishton wrote:Hi Gordon,
Sorry to pester, and no pressure, but any idea how soon? I'm starting to think that my USB / keyboard / rs422 problem is actually related to the 'curses' getch command being upset by the microframe scheduler enable. I was trying to find time to try reading key presses a different way, but it seems far more difficult than expected to implement an 'INKEY$' type command in python. And I'm probably barking up the wrong tree anyway.
And jamesh, before you advise me to sell my wonderful Raspberry Pies and use something more powerful, I used to design quite sophisticated hardware and software around PIC processors running at 4MHz, less than 2k of program memory and 36 BYTES of RAM, so the Raspberry Pi is orders of magnitude more powerful than I'm used to.
See - this is why these bugs are immensely annoying to even replicate, let alone troubleshoot. Something that works "for a week now" but then randomly goes silent without a bang or even a whimper under normal usage conditions is a major headache - was it a power glitch? Nearby lightning strike upset it? Software (or even device firmware) bug unrelated to the driver?rspitz wrote:I should have known better
Within minutes after my "success!" posting, my Pi started acting up as before. The USB device is not accessible any more, nothing in dmesg. The command in the script setting the DVB-C frequency gives "/dev/dvb/adapter0/dvr0: No such device or address", even though it is there.
Ok, goodbye optimism, hello USB depression.
Oh snapgsh wrote:People who are having trouble with keyboards etc should try with the new fiq_split branch
http://www.raspberrypi.org/phpBB3/viewt ... 05#p345905
Thank you gsh!!!! This finally solved usb audio problems! I'm the dev behind RaspyFi, which uses usb as audio pathway for hi-fi music reproducion...gsh wrote:People who are having trouble with keyboards etc should try with the new fiq_split branch
http://www.raspberrypi.org/phpBB3/viewt ... 05#p345905