[Robotgroup] USB to parallel problems

[Robo Al]

Ahhh, I see what you mean. The nice thing about the PICs is that they 
don't require you to use the serial interface and you can create your
own USB id and driver. The problem with that is that, as you stated,
it requires you to write a complete driver, which is outside of most
people's understanding.

Yep, USB is a result of a committee and has strict rules and overly
complicated standards. Heck, just to get your own vendor ID is too
expensive (although there is at least one inexpensive reseller for
device ids using their vendor id)

One of the bad things about USB is the host-device relationship. I
hope the USB OTO stuff will help, but I haven't followed it enough
to see if it will be good or bad. Gray was also looking and fighting
the USB host side of things and I think he was also unhappy with what
he came up with.

As computers get faster all IO interfaces are getting complicated and
outside the hobbyist realm. It is not just the parallel port that is
at a loss. Think about how easy ISA versus PCI and PCI-E was. Both,
parallel and serial ports are going away and we just need to figure
out where we want to go with our new devices.

I am afraid I have nothing to offer then, you've gone down the roads
that I was proposing, but I don't think they meet your needs.

Alberto

On Sun, 2008-04-20 at 00:57 -0500, Andre Lamothe wrote:
> No, I am not talking about USB to serial, that's trivial. I am talking about 
> the protocal itself. When you need to design a fully compliant windows 
> device driver and the endpoint drivers yourself, this is not trivial. If you 
> just want USB to serial, its trivial, I agree.
> 
> I am saying that if you want to "play" USB, say make a new peripheral that 
> is windows USB compliant that's not easy. Many chips Pic, Avr, cypress, 
> silicon labs, ftdi, have various solutions that do this and that, but in the 
> end many times you are going to have to code parts of the protocal if you 
> need "real" USB support and that's a lot of work.
> 
> USB is great, but it lacks a simple layer to the protocal to enable simple 
> interfaces, that's what I wish it had. An integrated mode where its more or 
> less a pure serial device, simplified protocal. Right now, there is so much 
> going on in the background with USB that's its nuts. A chip might hide it 
> from you if you get lucky and the chip does what you need. But, if you need 
> a host controller for example, that's not an easy find, and the solutions 
> out there are not cheap; nxp, etc.
> 
> For example, I used a USB to serial FTDI chip for the HYDRA with virtual 
> device drivers for the COM port, that's fine and dandy, but the hydra shows 
> up as a virtual COM port! Yuck. Then I talk serial to the FTDI then a layer 
> decodes this into HYDRA-SPEAK, I want to talk HYDRA-speak from the PC, as an 
> example, so if USB has built in simplified protocal models, it would 
> faciliate this natively.
> 
> To do it right, I would have to get a standard USB set of endpoints for the 
> HYDRA, and descriptors set up, use a removable media driver for it or 
> "something", so that there is some modicum of windows native compatibilty 
> (or write my own). The serial on top of USB is a "fix" a "hack", it gets us 
> BACK to what we once had, and that's my point. New interfaces should take 
> steps forward yes, but not alienate and make simple things hard.
> 
> Anyway, I have to design a lot for hobbiests, so USB is way out of the 
> technical grasp of 99% of hobbiests understanding, that's the rub. I have 
> written usb drivers from the electrical signals up all in software and the 
> device driver on the PC, to do this I have to know way too much. That's what 
> I don't like about any protocal, when you have to know so many things to get 
> it to work. With serial or parallel, its SOOO easy, and it promotes people 
> to make things. AND its a simple interface.
> 
> For example, I don't know if you are familiar with LVDS or fibre channel 
> protocals, but I love these since they are very low, you "can" put things on 
> top of them, but more or less they are within the grasp of mortals. USB is 
> much more complex than ethernet from the signaling, protocal level and it 
> doesn't need to be -- in my opinion :) Its the result of a committee more or 
> less and just overly complex.
> 
> USB reminds me of the windows registry -- need I say more :)
> 
> Andre'
> 
> ----- Original Message ----- 
> From: "Robo Al" <sp-18561884 at ggsys.net>
> To: "The Robot Group Mailing List" <robotgroup at puremagic.com>
> Sent: Sunday, April 20, 2008 12:34 AM
> Subject: Re: [Robotgroup] USB to parallel problems
> 
> 
> I do agree with you on the added level of complexity, there's
> no doubt that the parallel port is easier. But I think you
> may have had bad experiences in the past with USB that make
> you think it is hard. New offerings are easy to work with (or
> at least I think they are easy, and I am not a genius ;-)
> 
> The PIC18F2450 is $2.81 (qty. 25 from mouser). It comes with
> the standard CDC drivers that means it looks like a serial
> port.
> 
> It did take me a few days to figure out the basics for creating
> my own firmware. I can get a new interface developed within a
> single day that works both on windows and linux.
> 
> Seriously, buy a UBW from Sparkfun, give it a chance and look at
> the firmware (and how you can adapt it to your needs). From what I
> know from you, I can tell you that you'll get it to work in no time
> and within a day you'll be writing your own firmware to do anything
> you want.
> 
> Send me a reminder on Wednesday and I'll bring mine along and show
> you a simple example next meeting. I showed it while we were meeting
> at Poke's so it was before you joined the group.
> 
> Alberto
> 
> On Sun, 2008-04-20 at 00:10 -0500, Andre Lamothe wrote:
> > I agree on a practical level with you, but...
> >
> > The problem with USB though is that its not trivial to design, the 
> > protocal
> > is worst than ethernet, and the chips are VERY expensive. But, I agree on
> > new products you have to go USB. But, 99% of most dev tools in EDA, etc.
> > still have parallel programmer drivers, so you need parallel ports. You
> > "can" get a USB version, but they are closed protocals's usually and the
> > engineering time to develop a programmer based on the protocal is 
> > literally
> > 25-50x more than the parallel port. So I agree, everything should go USB,
> > but USB is overly complex at best for getting simple I/O to work. You have
> > to be a pretty sophisticated engineer to write a USB driver and implement
> > both sides of the hardware, that's all I am saying. With parallel, two 
> > mins
> > your done, with serials, 2 days you're done with USB 2 months you are done
> > :)
> >
> > Its just a bad situation that these legacy ports are slowly going bye bye,
> > because it REALLY does make a lot of things harder. for example, a simple
> > set of switches that I might want to interface to the PC, I can do that 
> > with
> > the parallel port, or at worst with a PIC and the serial port (which still
> > works thank god). But, if I have to interface to USB, it can be done with 
> > a
> > Pic in software for $2-3, but it's a LOT of work. So the problem I see is
> > that the ROI on your engineering effort is really low when you have to use
> > USB for simple interfaces.
> >
> > Andre'
> >
> > ----- Original Message ----- 
> > From: "Robo Al" <sp-18561884 at ggsys.net>
> > To: "The Robot Group Mailing List" <robotgroup at puremagic.com>
> > Sent: Saturday, April 19, 2008 11:42 PM
> > Subject: Re: [Robotgroup] USB to parallel problems
> >
> >
> > Actually for just bit banging I would no longer recommend the
> > parallel port (basically due to the problems you are encountering)
> >
> > I have been very happy with the UBW (usb bit wacker)
> > http://greta.dhs.org/UBW/ which is what I would use if I didn't
> > want to deal with electronics soldering (can be bought for $25
> > fully assembled) or programming (comes pre-configured and is controlled
> > with any terminal program).
> >
> > For advanced control, you can use the same hardware with your own
> > firmware (comes with a bootloader so you upgrade the firmware without
> > having any special programmer)
> >
> > All and all the parallel port is great and I've used it to do a
> > few things, but it is dying. Even if you find it in a motherboard
> > it is likely not using hefty drivers, but rather the cheap stuff
> > that can't drive some of the peripherals. I spent 2 weeks trying to
> > figure out why my brand new CNC motor controller wouldn't work and
> > it turned out that both systems I was using used too cheap parallel
> > port implementations not able to drive the logic chips in the
> > controller. Found an old computer and everything started to work
> > perfectly.
> >
> > I can understand your need for something that will talk to your
> > already existing products, which I thought is your current problem.
> > But if you are designing anything new I would stay away from parallel
> > port implementations, USB is cheap and easy to implement nowadays.
> >
> > My 2 cents,
> >
> > Alberto
> >
> >
> > On Sat, 2008-04-19 at 23:23 -0500, Andre Lamothe wrote:
> > > Right, this particular product is made by someone that is on the fench
> > > with
> > > if its commercial, etc. So I am concerned that he would change his mind 
> > > at
> > > some point, but the more pressing matter is the code base, etc. is the
> > > thing
> > > I don't want to deal with. But, if I don't find anything and it becomes 
> > > a
> > > problem then it might be my only short term solution.
> > >
> > > However, haven;t got a single complaint yet except from a MAC latop 
> > > user,
> > > so
> > > I am starting not to worry and it might work itself out, however, I, me,
> > > moi, would still like a USB to parallel from a real company that allows
> > > bit
> > > banging. I mean everyone in the robot group I am sure would like to hook
> > > things to the computer and turn on/off digital I/Os, the parallel port 
> > > is
> > > the only EASY way to do this. In 5 mins, I can be turning LEDs on with a
> > > parallel port, and 10 lines of C code.
> > >
> > > Andre'
> >
> >
> > _______________________________________________
> > Robotgroup mailing list
> > Robotgroup at puremagic.com
> > http://lists.puremagic.com/cgi-bin/mailman/listinfo/robotgroup
> >
> > _______________________________________________
> > Robotgroup mailing list
> > Robotgroup at puremagic.com
> > http://lists.puremagic.com/cgi-bin/mailman/listinfo/robotgroup
> 
> _______________________________________________
> Robotgroup mailing list
> Robotgroup at puremagic.com
> http://lists.puremagic.com/cgi-bin/mailman/listinfo/robotgroup 
> 
> _______________________________________________
> Robotgroup mailing list
> Robotgroup at puremagic.com
> http://lists.puremagic.com/cgi-bin/mailman/listinfo/robotgroup