mfraser
19/7/06 6:53PM |
Good news, now all we need is the same for the Simtec USB stack which I'm hoping is still being developed. |
jamesp
19/7/06 9:45PM |
This is intresting stuff, I look forward to seeing what is possible. |
hzn (+1.5)
20/7/06 7:11AM |
In erply to mfraser:
What we need is just one USB stack for all - or at least one common interface for both so that there is no need to write apps etc. using USB to support both stacks. |
AMS (+1.0)
20/7/06 1:24PM |
In reply to hzn:
Support the USB stack that has the most applications then - that would the DeviceFS/Castle one. Besides the Castle one offers USB2 while the Simtec one doesn't (though to be fair this is a hardware limitation).
Isosynchronous support is one of those must have features (and full marks to John Ballance and associates on that). I would query though how practical it would be for (video) on the slow podule bus of the RiscPC - it should work better on the Iyonix. Should be the encouragement I need now is to upgrade beyond 5.03 and get the USB 2....... |
fylfot
20/7/06 2:20PM |
In reply to AMS:
In the "ROS must open up to survive says Wild" article you equated open sourcing RISC OS to "advocating an approach that would [...] lead to further fragmentation". hzn has suggested a solution which would mean that USB developments would benefit both Castle and Simtec users, yet you, instead, are effectively advocating abandoning all those users with Simtec podules and the increasing number of users with an A9home.
Are you sure you're interested in preventing "further fragmentation"? |
AMS (+1.0)
20/7/06 7:50PM |
In reply to fylfot:
Think about it logically for a sec. We currently have two USB stacks. One of those stacks (the DeviceFS/Castle one) is getting Isosynchronous transfer support added. Nothing else has changed - no extra fragmentation (isosync is part of the USB standard so should already have some representation in both stacks- even if the actual functionality was not implemented).
In response to hzn I was suggesting that we standardise on the stack that has the most capabilities (and I'd consider Isosync a *biggie*). That stack would be the Castle/DeviceFS one - if it were adopted by all vendors then we'd have less fragmentation. I am not sure how acchievable that is (are there commercial/business/licensing or technical issues that would prevent Castle's USB stack being deployed on an A9) but the suggestion I made is, I feel, more likely to yield the best overall results. Certainly more so than trying to implement an overarching abstraction layer that accomodates the existing two stacks - or going back to square one and coming up with a single unified (but different) third USB stack model.
|
Gulli (+3.5)
20/7/06 8:00PM |
In reply to fylfot:
How does dropping one USB stack and focus entirely on the other work against "preventing further fragmentation"? Wouldn't that do the exact opposite, help prevent the fragmentation? After all, dropping one stack and focusing on the other leaves one stack to work on instead of the current two!
That was not hzns exact words but would be a way of accomplishing what he pointed out when he wrote: "What we need is just one USB stack for all". Whether or not AMS' suggestion is the best way is a matter of opinion but surely not opposing this! |
jamesp (+2.0)
20/7/06 8:23PM |
An alternative may be to provide a module which implements the DeviceFS API but calls down to the Simtec stack. |
AMS (+1.0)
20/7/06 8:47PM |
In reply to jamesp:
That's quite true - an ingenious solution too.
I must complement you on your site discussing the USB API ([Link: homepage.ntlworld.com]) very informative it is too.
Making a module implement DeviceFS and calling down to the Simtec stack would definately provide the programmer with a coherent single API interface (at the the expense of some lost speed). Any USB device supported in that way would then have the virtue of running on Castle Iyonix/RPC USB Podule/A9Home/Simtec Podule. Probably as close to a single USB API as we're likely to get that can run on all platforms.
It would not however provide additional functionality not afforded by the Simtec stack itself (it wouldn't magically add Isosynchronous transfers or USB 2 if the underlying stack didn't know how to do this). But at least it might allow the task of supporting USB devices in a crossplatform manner that little bit easier.
|
jamesp
20/7/06 9:07PM |
The USB notes have moved to http://www.riscos.info now, so they can be maintained by anyone who's interested. I'm going to remove the ones from my site now.
I don't know how involved my suggestion would be, I'm not at all familiar with the Simtec API. |
mfraser
21/7/06 2:57PM |
In reply to hzn:
"What we need is just one USB stack for all - or at least one common interface for both so that there is no need to write apps etc. using USB to support both stacks."
That would be ideal, but unfortunately I can't see that happening any time soon, can you? |
JWCR
21/7/06 10:03PM |
In reply to mfraser:
Which brings us back to the $64K question of exactly what are RISC OS Open Limited planning. |
philpem
29/7/06 12:54AM |
Would be nice to see this sort of thing on the Simtec stack. I did ask STD about this (in the context of the Unipod) but their response was something to the effect of 'it's unlikely to happen, but it might - in any case, don't hold your breath'...
Having spent the money on a Unipod, I'm beginning to think I might have been better off buying a Castle USB card instead. That said, I've sold my spare IDE interface and Ethernet card, so there's no going back now... |
| |
Work is underway to add support for streaming data from webcams and radios over USB to 
