Hi Thilo, I have to realize didn't have a look in to that code for a long time :) Consequently it's hard for me to judge the patch in the very detail. I couldn't see anything that triggered my suspicion and I ran a test against my 60SCx. It's still working. Let's assume it's working. I checked it into svn.
It would be nice if all the other driver maintainers would check against their USB devices, too. Just some thoughts about the hangups: To compile the GarminDev package you need the legacy version of libusb. There seems to be a totally new version of libusb now. So far I didn't dare to use it, because I didn't want to break anything. But maybe the new lib would work a bit more reliably with the device. And I noticed that SuSE 11.2 ships with a broken version of the old libusb. Exchange works except for maps. If you transfer a map it will stop right after the first block. Thus, make sure you use the legacy libusb from the sf.net server to avoid trouble. And you might want to give the new libusb a chance. Maybe it solves some of the problems. If the CUSB interface stays the same, all drivers would be able to use the new version. Oliver > > I started poking around with a new Garmin plugin for the Oregon (450 for > now). > > I'll publish it as soon as initialisation works cleanly, so you can join > the fun early if you're interested. > > However, while playing with the device I ran into communication problems > apparently caused by CUSB.c: > > Sometimes, data streams from the device, i.e. data over multiple > packets, would stop early. E.g. when I send "Product request" it is > supposed to respond with product data and protocol data. But I almost > ever only get the product data, if at all. Further reading on the bulk > pipe results in timeouts. > > If I send "Product request" again (which was my first workaround) I get > everything, _plus_ the missing data from the first run! > > So I tried something else and checked the interrupt pipe after the bulk > pipe reported it was empty. Turns out every time I "lose" data in the > middle of a response there was another "Data Available" packet in the > interrupt pipe. Which, when read, enables more data from the bulk pipe. > All that without sending a new command in between. > > I also noticed in the Garmin protocol spec that "Data Available" is a > transport level packet. I think it should be handled solely by CUSB, not > by the plugin. I.e. when "Data available" is read we should read the > application data from the bulk pipe and return that instead of the > transport level packet. > > As a Request for Comment I made some changes to the way read() works in > CUSB.cpp, plus some more, while I was at it. A patch containing the > changes is attached to this mail. Here's what I did: > - I separated all bulk handling from read() into (private) _bulk_read() > - "Data available" is solely handled by read() and _bulk_read() > - after a bulk pipe stops receiving data, _bulk_read() would check the > interrupt pipe for a "Data available" packet, and continue > reading the bulk pipe if such a paket was found > - I also added two comfort methods which make running device commands > easier with the Oregon plugin. They won't interfer with the rest of > CUSB, I just need them for the Oregon plugin. > - I had some trouble with protocolArraySize (segfaults), so I made > sure it is -1 if the array is empty (as protocolArraySize is used > for array indexing, and 0 is a valid index). > > Please tell me what you think. > > Regards, > Thilo > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > > > > _______________________________________________ > Qlandkartegt-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ QLandkarte-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qlandkarte-users
