> > Ah, OK. I used the 1.5k resistor, no external transistor. I don't know
> > what the actual cause was, but it looks like the DISCON pin never went
> > floating or didn't have sufficient impedance for a USB disconnect to
> > occur. The guys at Cypress recommended setting both DISCON and DISCOE
> > to 1, thus forcing the pin to go low. I don't think it hurts, so it
> > might be worth doing for the FX regardless of the version.
>
> Well, I think driving it low is not the usual way to SE0 on the wire. But
> it would probably work anyway, due to the 15k pulldown on the host side -
> no idea whether it behaves with all hubs (specified limits for T_DDIS).
> Maybe the best solution is to drive it low only for a very short period
> (to drain the charge from the pin and overrule whatever keeps it from
> floating) and then clear the DISCOE again. Do you have a Rev A setup for
> testing this? I would just make a modified firmware to try it.
That's probably a good idea. I do have some Rev A chips assembled
here, I'll have to dig one out, but testing should not be a problem.
> > How good that they got rid of that external 1.5k resistor in the FX2!
>
> I think this was a requirement due to the HS chirp negotiation.
Yes, but I can't understand why they didn't incorporate it in the FX
as well.
> Nope! How would you transfer some 8KiB chunk of data from the GPIF to XMEM
> with a *sustained* data rate of 5 or even 10 MB/s? With the FX this is
So you want to read in a larger amount of data than the endpoint
buffers will take, and then process it with the 8051?
> burst DMA. No chance with FX2. They are just assuming everything would go
> straight to the host. But if you need to accept say 8KiB chunks in one go
> the endpoint buffers are simply too small. Sure, one could add some
> external buffer but having only a few nanoseconds RT-tolerance this makes
> the GPIF design pretty challenging...
Why? Add an external FIFO, and all is well, unless your sample rate is
very close to the maximum GPIF speed, which is 48M words per second.
The FX and FX2 weren't designed to be real-time FIFOs at that kind of
speed anyway.
> > didn't make it very easy for FX users to transition to the FX2 because
> > you have to read at least three full chapters of the TRM to understand
> > its new philosophy.
>
> Right, this is another issue - too many unjustified (IMHO) changes...
> One good change OTOH is they have used a few of the reserved pins to give
> the UARTs dedicated pins, not multiplexed with GPIF.
I do miss, however, the multiplexed CTY and RDY pins of the FX. On the
FX, you could make up your mind as to which pins to handle with
waveforms and which to do manually when writing the firmware, now you
have to do it in hardware (unless you short GPIF pins to port pins,
which is ugly and requires attention when programming).
The biggest mistake Cypress (Anchor?) made was using an 8051 core. I
have yet to see another core that comes close to the 8051 in
stupidity. And I _have_ programmed DSPs, which can also be a pain.
Andras
===========================================================================
Major Andras
e-mail: [EMAIL PROTECTED]
www: http://andras.webhop.org/
===========================================================================
-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
