On Friday 30 March 2007 12:53am, Mike Isely wrote: > Bill Marr <[EMAIL PROTECTED]> > I need to go find the datasheet and really look at this. I think I > did look at a datasheet last summer when I did all this - but you're > right. If it's the same USB serial converter then it certainly seems > as if this serial line settings check should still work!
I opened the outer case of my LT-20, hoping to possibly identify the chip visually. Unfortunately, as I half-expected, I'd have to de-solder the inner metal case in order to get to anything interesting. I might be prepared to do that at some point, but not just yet. :^) Lonnie Mendez's site clearly shows the Cypress CY7C64013 chip on the non-LT-20 unit and I'd hoped to confirm/deny on the LT-20. > > I was half-heartedly hoping that at least 1 other Earthmate GPS user > > would have some input by now, but I suppose I should have included the > > 'linux-usb-users' mailing list instead of just the '-devel' list. To > > remedy that, I've opened a new thread on the 'linux-usb-users' list to > > see if someone else might have extra input. > > I currently don't subscribe there. So if there's a reply that doesn't > cc me, I'd appreciate it if you forwarded that. Wilco. > > Incidentally, I don't know why the driver attempts to read 8 > > configuration bytes (referred to as the "Feature Report" in some Cypress > > docs) from the Cypress device when it only has 5 to offer. For a minute, > > I thought that might be causing the problem, but when I changed it from 8 > > to 5, it made no difference. > > You know now that you mention it, I think I remember noticing that as > well. But I didn't make any attempt to change / fix this since it > didn't appear to be causing any harm (at least not for me). I want to look into this a bit more. I seem to recall seeing an older version of the 'cypress_m8' driver (forgot where, though) which used 5. I'd like to find out if that's really true and, if it changed to 8, when/where it did so. My instinct is to change it from 8 back to 5, since it's well documented in the Cypress datasheet, especially since it causes no harm to you or me. But I'd like to hear what your search of the datasheets returns too. Also, I did a little searching, with the intent to buy a Cypress-based USB/RS-232 converter (USB VID/PID: 0x04b4/0x5500, which identifies itself as "HID->COM", apparently), just so I could test the driver and my changes on that device too. Unfortunately, I was unsuccessful at identifying any such device for purchase. As near as I could tell, the Cypress chips may have been used in some generic, no-name converters and it's virtually impossible to clearly identify one to buy with that chip. > > No matter what I do, I get '-EPIPE' (-32) on that call to > > 'usb_control_msg()' (the one with 'HID_REQ_GET_REPORT'). > > > > I was able to find some code at the Cypress site which seems to confirm > > the use of the values 0x01 and 0x09 for 'HID_REQ_GET_REPORT' and > > 'HID_REQ_SET_REPORT', respectively. So that's reassuring. > > > > However, I'm unable to discern a source for the "magic" 0x300 number (the > > 'wValue' field (as named in the USB spec) in the call to > > 'usb_control_msg()'. > > I will bang on some brain cells here and refresh my memories of this > from last summer. When I did these patches by the way, I first pulled > the driver into a local SVN repository, complete with diffs marked for > every change I could vacuum up. So I should have a good trail of the > changes here. Excellent. Looking forward to anything you might recall/uncover! > > I've resorted (for now) to the simple solution of just checking for the > > LT-20 device and bypassing the call to query the serial port settings > > under those conditions. > > > > In fact, I really don't know why the serial line settings are queried at > > all, given that it's done _after_ they're set, with the stated intention > > (in the code) of being able to check if the settings took hold. However, > > I see nowhere (might've missed it) where such data is ever used to make > > such a check! > > As I mentioned before, I was going for (hopefully) just surgical > changes. I wasn't trying to analyze and fix every strange thing I saw > - just the ones that were obviously causing problems. Maybe we should > do some refactoring on this thing. I wouldn't object, assuming we're proceeding with good data -- e.g. datasheet based and/or (especially) if someone comes up with a Cypress USB/RS-232 adapter to test with. I'd really hoped to hear from Lonnie by now. Lonnie -- where are you? :^) > > I'd still like to know how your pre-LT-20 GPS behaves on the call to get > > serial port settings. I know it works for you, but is it really returning > > the correct data settings? Can you add some debug code to confirm this, > > (especially since it appears to me as if this call could return garbage > > and we'd never know it)? > > I'm pretty sure it was returning reasonable results. If it wasn't I > think I would have noticed and then dug deeper. But I'll have to > retest to be sure. It's been too long. Understood. Looking forward to hearing your results. > > If I can come to no better conclusion, I plan to submit a simple patch, > > which I'll ask you to test first, assuming that's OK with you. Assuming > > no problems, I'll submit that patch for the next kernel release. > > I will refresh my memory on this driver hopefully this weekend. I got sidetracked doing a major hardware and O/S upgrade on my main PC this weekend, so it may be a few days before I can contribute anything intelligent to the conversation. Rest assured that I will be back at it ASAP, though. Bill ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
