On Tuesday 01 January 2008, steve birtles wrote: > >> The YL-9200 board switches a transistor to provide pullup > > > > Presumably driving through a pulldown, so that when the board resets > > it doesn't wrongly present itself as ready to respond to a USB host. > > > > I'm just the fire brigade called after the kiddies have been playing > with matches. ;-) > > Actually it's floating, PC4 directly drives a PNP transistor through > a 4.7k, one side of the PNP is connected to the 3v3 rail > the other side through a limiting resistor to the D+
Oh, right -- it'll "float" high because of the weak 100K pullup, which prevents the pullup from activating. Pretty much the same as the host's D+ pulldown would be doing without the transistor. Forget I said anything. :) > > Here's a replacement patch, addressing the critical issues I had > > mentioned to you before: (a) not breaking every existing at91rm9200 > > board, and (b) applying atop a previous patch [1]. > > > a.)That's why I added the code to initially set the flag to 1, but > I cannot see why my patch would break existing boards. Your original code changed from default == "active high". The newer code is just broken ... considering that "pullup_state" is boolean, and a misnomer, notice: -int pullup_state = 1; /*The 'normal case*/ - if (udc->board.pullup_active_level) - /* we pass in the state of the signal used to pullup the usb*/ - pullup_state = udc->pullup_active_level; - That pullup_state will always evaluate to true... > Just a couple of questions, > > 1. The way the patch is now: > int active = !udc->board.pullup_inverted; > > will that not force all existing code bases to implement a patch to > add 'pullup_inverted' > to their board code because an initial state of active is not set , > in any existing board code ? No, because it was clearly specified to be active-high. No inversion meant "active == true/high". Only boards that need to kick in signal inversion would set that flag, and thus get "active == false/low". > Also the name "pullup_inverted" suggests a negative situation > I.E > pullup_inverted = 0; (do not invert the signal) > pullup_inverted = 1; (do invert the signal) > Whereas the reverse is actually true. I don't follow. If "inverted == 0", then a driving the pullup signal high pulls the target signal high -- no inversion there, the sense of the pullup driver is not inverted. > 2. What happends if the user passes in a value that is not 1 or 0 , > will the call gpio_set_value , automatically mask it off? It's defined to be zero/false/low vs nonzero/true/high ... which FWIW is classic C for "boolean". - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
