AW: [Oberon] Re. How is ETHO with USB?

[Stauber Sven Philipp]

There are currently four major USB host controllers: UHCI & OHCI for low- and full-speed transfers  (1.5/12 Mbps), EHCI for high-speed transfers (480Mbps) and most recently xHCI (low-, full-, high- and super-speed transfers).

> I can't remember if N-O has USB?

Native Oberon supports some specific UHCI host controller only (although the driver would most likely work with all UHCI controllers). If your machine comes with a UHCI host controller and your wireless terminal can live with 12Mbps, this is not a problem, however. 
PCITools.Scan should reveal what type of host controller you have.

> But BlueBottle/A2 has; so that means A2 must have the low-level-layer?

A2 supports UCHI, OCHI and EHCI host controllers so it works on almost any machine.

> Since I've got the native-A2 CD, it would be great if native-A2s USB facility could handle it.
> Is it realistic to try?

Do you have some specification/programming guide for the wireless terminal? If yes and the implementation of that specification seems feasible within the time you're willing to spend, it is definitely realistic.
(some source code of an existing driver can also do the job, of course)

Best,
Sven


-----Ursprüngliche Nachricht-----
Von: oberon-bounces at lists.inf.ethz.ch [mailto:oberon-bounces at lists.inf.ethz.ch] Im Auftrag von Chris Glur
Gesendet: Mittwoch, 18. August 2010 02:00
An: oberon
Cc: crglur at gmail.com
Betreff: [Oberon] Re. How is ETHO with USB? + klux

> >Apparently USB is rather complex?
> 
> Not necessary. In USB, there is a layer between the actual USB device 
> and its device driver (I call this layer USB system software here). 
> This layer takes care about things as device topology, power budget 
> and management, bandwidth management, ...
> Instead of directly accessing the hardware, the USB driver uses a 
> software interface provided by this layer (USB driver interface).

Yes, but then the OS has to have that lower layer.
So if we had a 'native' [non-M$] system, we'd have to provide that layer?

> So instead of accessing the device's registers and buffers directly 
> (memory mapped I/O, I/O ports), the USB device driver tells this layer 
> to do so.
> Since this layer is aware about the USB topology, your driver won't 
> have to care about it - from the device driver's view point, it looks 
> as it would be directly talk to "its" device.
---
> USB devices are identified by either class/subclass/protocol (generic 
> drivers) or vendorID/productID/[deviceRevision]
> (device-specific drivers).

Yes, the device I need to connect [a fixed wireless terminal] gives a vendorID/productID pair under linux, and linux hopes
to load the corresponding driver -- AFAICS.   Which seems to
confirm my original suspicion that USB is 'complex like NetCards and video-drivers', compared to RS232 & parallel-port.

I can't remember if N-O has USB?
But BlueBottle/A2 has; so that means A2 must have the low-level-layer?

I HATE having to buy and use Win<something> just to use this device!! Besides I don't [want to] know how to make an ET.Do script in Win to auto-d/l  8 https.

Since I've got the native-A2 CD, it would be great if native-A2s USB facility could handle it.
Is it realistic to try?

 Thanks,

== Chris Glur.

 PS. 
> Just curious - "clux" is an abbreviation for what?
'clux' means 'click some mouse button/s, by just thinking of what you want to achieve and your fingers will do it, like [I guess] when a pianist sees the chord score, the chord sound just happens.


--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon