Hi Andras,

On Mon, 21 Jul 2003, Major A wrote:

> > Hi Andreas,
> 
> (Just nitpicking, my name is Andras, as in Andr\'as (TeX syntax).)

Oops, seems I mixed it up with the german forename due to visual 
similarity - Sorry!

> > As you discovered it, would you mind to explain? My understanding was the 
> > DISCON pin would float pretty long at H (maybe due to some similar 
> > soft-pullup like they have on the ports) so it is required to actively 
> > drive it L. However, I have never used the simple setup with the 1k5 
> > resistor on USBD+ directly connected to the pin - I've always added a 
> > transistor there like they did on the development board. So I have never 
> > seen any issue with disconnect not working.
> 
> 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.

> 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.

> > I cannot tell for the FX2 but I've never seen any problem with INT2CLR or 
> > INT4CLR. I'm running the FX with up to 100000 interrupts per second, 
> > mostly USB and GPIF, so I'm pretty sure I would have noticed. I'm sure you 
> > have it enabled in the USBBAV and INT4SETUP registers respectively?
> > And you still need the EXIF first with INTxCLR as well, it's only a 
> > replacement for the USBIRQ or IN/OUT07IRQ.
> 
> Oh, maybe it's worth another try? It's a long time ago that I last
> tried, but it caused me days of frustration, so I think I did
> everything as it was in the TRM...
> 
> > Patches welcome of course ;-)
> 
> I'll test it once I have some time.
> 
> > Yes it's really a shame they've killed the DMA engine in the FX2. I've 
> > complained to them and they said it was because the 8051 couldn't keep 
> > with HS bandwidth anyway. This is right of course but there are other
> > benefits f.e. when combining GPIF/FIFO transfer with XMEM buffering, which 
> > are lost without DMA. In fact this was the main reason not to use the FX2 
> > in some project recently.
> 
> Their idea is that the 8051 is too slow for hi-speed USB anyway, and
> how right they are! The FX2 is probably capable of doing everything
> the FX could do with DMA, but in a very different way. I think Cypress

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 
possible because one can drain the fifo concurrently using 48 MB/s
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...

> 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.

Martin



-------------------------------------------------------
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

Reply via email to