>> >>> I don't like the fact that you're supposed to pay for an ID
>> >>> (and have thr device 'certified') if you want to make your
>> >>> own stuff. Never had this problem with RS232 :-)
>> You need to pay for and get certified if you are going to make a legitimate
>> network appliance also [MAC ID]. Of course most products purchase a
> You didn't need to pay for anything if you wanted to make an RS232 device.
Nor do you for USB. Just use one of the existing USB/Paralell
or USB/Serial modules, add a serial EEPROM with the needed
device strings, and you have your custom USB device. Then
take their generic driver, add whatever funcionality your device
should support and you get all the bonuses of USB (easy use,
plug and Pray, and so on) plus no USB specific development.
>> >>> And the fact that you seem to need special drivers for many
>> >>> devices which you can bet are not available for any of my machines.
>> Although I can not find the link at presend, there is source code for low
>> level drivers. Since your environment (by choice) is the use of equipment
> Ah, sop now if I buy a product the first thing I have to do is write
> special drivers for it..... And hope that I can get enough of a spec on
> the product to allow me to do this.
??? Isn't that the same for any device? I mean, if I get me a camera
with a RS232 interface (if such thing is still arround, but I can just
use my old Olympus as example :) I still have to write my own drivers
(unless useung Wn/Mac) ... that's nothing new to USB or whatever.
On a closer look, doing a USB driver is even a bit more simple than
for any older infervace, since not only the electrical parameters, but
also all basic messages are described.
>> >>> And the fact that it's very assymmetric (there are 'masters' and
>> >>> 'slaves') is something I don't like either. RS232 was much
>> >>> more symmetrical.
>> RS-232 is an ELECTRICAL Specification. The protocols that are run on
>> This are independand. Lets keep it apple and apples.....
> OK, Asynchronous bit-serial data, sent LSB first, using the RS232 voltage
> and connector specifications :-)
*G* and USB is the same, plus a well defined protocoll for messages,
which allows software development on specific levels with a great speed.
>> >>> More modern palmtops have USB ports. They're slaves,
>> >>> designed to hang off a PC. You can't link them directly to
>> >>> a printer. It's interesting that some of my older handhelds
>> >>> have HPIL ports, but by default the handheld is the loop
>> >>> controller ('master'), so you can link them straight to a
>> >>> printer. But they can be 'slaves' if you want to link them
>> >>> to a larger machine. We've gone backwards (as usual)
>> To be honest, I have not looked into the electricals on this. I am NOT sure
>> that they are *REQUIRED* to be slaves.
> There is, of course, nothing rreally to stop you making a handheld
> 'master' (althoguh the master has to supply power to all devices on the
> USB chain), but the fact remains that AFAIK all handheld machines
> currently on sale are 'slaves'
That's where on-the-go comes into the play, an extension of the electrical
spec (so the device can see if the other end is a host or a device and select
the oposite role) and a protocoll extension, for negotiation if both sides
are able to act as host/device. It even allows switching roles while running
(of course after closeing all open transactions).
OTG makes the low level driver a bit more complicated, but these have
only to be made once for any new machine (and adds a little hardware for
switching the power on and off).
OTG is ment that a camera can be a device to a PC, and a host for a
printer ... and so on.
>> >>> All my PCs have ISA slots only. Other machines have Unibus,
>> >>> Qbus, BBC 1MHz bus/Torch X-bus, various custom I/O slots
>> >>> (like on th HP9830), HPIL, PERQlink, etc. Just about all of
>> >>> those have RS232 (or compatible) ports, I've nver seen USB
>> >>> for any of them
>> Again, development boards ARE out their that give you everything you need to
>> interface to nearly any host...
> Most of the developemnt boards I've looked at assume you're making a
> slave device. This is not what I need.
Shure, most ICs sold are slave controlers ... If you realy want to look
into that, I recomend the Transdimension UHC 124 controler. It handles
already the most nasty parts of the low level protocoll, so even the basic
drivers are easy to do. also it features an 8 Bit Interface, so it's great for
every computer arround. The only feature missing is OTG. It's a host only
controller, but has already a 4 port hub integrated (oh, and it's only good
for low/full speed, but 1 MB/s is more than most old computers can handle
anyway).
Transdimension offers a real neat Evaluation board
http://www.transdimension.com/products/semiconductors/uhc124/evalboard/index.html
But more important is their 'Exerciser' Board
http://www.transdimension.com/products/semiconductors/uhc124/exerciserboard/index.html
a full figured USB training and Protocoll/Trafic analyzing tool.
All you need is a dumb terminal (or a PC) and you can dig deep into
USB.
My recomendation for anyone who realy wan't so know how USB ticks.
better than any Windows based tool I found (if you're able to handle a
classic text based UI - not necersarry true for everyone nowadays).
The TD243 is a nice upscale controler, but I haven't done anything with it.
Also it features a 32 Bit interface :( Theoreticaly the Atmel 370 (*G*) would
make an even better controller, since it freatures OTG and an even higer level
interface - just, I haven't had a chance to get the needed interface level decription,
and I don'T want to use their C libraries. they are worthless for the machines
I play with.
>> >>> > I also don't understand your statement that it is not a bus.....
>> >>> Electrically it's not a bus. If it was, I could just parallel up
>> >>> connectors and plug in several devices, there'd be no need
>> >>> to _always_
>> >>> have a hub (which, from what I've seen, contains a fair
>> >>> amount of logic).
>> By that argument (which has valid aspects), then ArcNet was not a bus
>> either, and RS-232 is DEFINITELY not a bus architecture (it is purely point
>> to point).
No argument there. But neither of those claim to be a bus.
Well, logicaly I considere USB a bus. from a host perspective all devices are
available in paralell, and you talk out of one port. that it'S bade up from point
to point connections is not realy a criteria - If you look arround, nowadays
Ethernet is also almost always a point to point with switches, still for each
connected computer it looks like a bus.
Hans
Received on Mon Sep 27 2004 - 11:24:04 BST