Paul, Since the queue is being filled for us in the background by the driver. There is no NULL data, as the USB dongle seems to return data quite frequently when polled, even if it hasn't changed. Basically, we get a queue that is just filled with status info...
So, I had two thoughts on how to fix it - one a bit more difficult that then other. Option 1: Start a thread that reads the queue whenever there is data, keeping a global status array up to date for the getstatus routine. I did this first, and it worked, althought I had to build in some smarts to keep it from starting as a pthread before LibStart() was complete. This guarantees the status values are always current. I used a pthread_wait in the getstatus loop which would be signalled any time the status data changed. This had no real impact on CPU, as it was keeping up with the USB interrupt polling and spent a lot of cycles waiting for data. Option 2: This morning it occurred to me that the real solution was to just flush the buffer every time we enter getstatus. All I have to do is read 1024 bytes from EP1 and it's clear. Then getstatus will run as it should, and while in its loop it's keeping up with the USB polling interval. There are still cases where a double return value occurs, so I put in a check: if 32 bytes were read and the first 6 bytes of the strings buffer and &buffer[16] match, copy &buffer[16] into buffer and set ret to 16. I'm sure this is an edge case, and although it could still be fooled, the chances are pretty small, and at that point you have so many error registers that your in bad shape anyway. Both of these work. Option 2 only required a couple of lines of code... And, it was your idea - thanks! Writing the thread version was fun. So: - No more read issues - I have a DS2409 hub, a DS2450 voltage reader, and a DS18B20 temperature sensor hooked up for testing - Binds to IPv4 - No core dump on exit I'll get this cleaned up and send you a diff. Next up is reading the FreeBSD Porters handbook and building this into a port. I did get a response from the FreeBSD USB group, and there is apparently a USB driver that would allow me to turn of the interrupt read/buffer process. This would require a kernel recompile, and I'd rather keep things as simple as possible. Rob. On Saturday, July 22, 2006, at 06:38PM, Paul Alfille <[EMAIL PROTECTED]> wrote: >Rob, I'm impressed by your perseverence. > >On 7/22/06, Robert Nilsson <[EMAIL PROTECTED]> wrote: >> Paul, >> >> I ran my code under debian, and it did what I expected - it never needs to >> loop through my inner loop more than once. >> >> As I dig deeper into the problem, they way ugen is implemented, when EP1 is >> opened an interrupt routine is started. This routine polls for new data >> from the USB device on a set schedule, and uses the q_to_b routine to store >> the data. This is a 1024 byte buffer. When you do a read, the b_to_q >> function is called, "popping" the data out of the queue. > >So "null" data is stored as well? >> >> If we were dealing with a mouse, this would probably be a great thing... >> >> As it stands, each read is thrown in the buffer, one after another. Even if >> the device wee to only give an update when there is something new, it only >> takes two updates to cause an issue. >> >> Ideally I could replace the callback function that handles the data >> correctly, only raising the flag for the read process when the data has >> changed. But, there are many layers in there that have to be traversed. >> Hopefully some smart FreeBSD USB person will have an answer. >> >> In the mean time, any brilliant ideas on how to work around this buffer >> issue without reinventing the wheel? >> >Well, despite your explanation, I'm a little hazy. If there is stale >data in the queue, we could "flush" it before the read. Other wise >read and parse the extra data, as you are doing. Really, the best >answer is to get it fixed. Is it a libusb or freeBSD kernel problem? > >One last, cheating, solution: NSLU2. Set up a dedicated device like >any of the lynsys routers or NSLU2 and let them run the USB, you can >run owserver on the device, and owhttpd etc on your BSD machine. > >One last question: have you tried FUSE for FreeBSD? http://fuse4bsd.creo.hu/ > >Paul Alfille > >> Rob. >> >> On Saturday, July 22, 2006, at 04:27PM, Paul Alfille <[EMAIL PROTECTED]> >> wrote: >> >> >This is great. >> >In the best of all worlds, your work will fix the libusb driver or OS >> >implementation and we won't need special case code in OWFS. (If we do, >> >that's fine, too.) >> > >> >As for the binding, in module/owlib/src/c/ow_net.c routine ServerAddr >> >uses getaddrinfo() with a hint of hint.ai_family=AF_UNSPEC seems to >> >bind to IP6. The man page of getaddrinfo seems to suggest adding: >> >hint.ai_flags = AI_PASSIVE | AI_ADDRCONFIG but you may want to check >> >the freebsd documentation. >> > >> >I'm at a bit of a loss concerning the seg fault. It is possible that >> >the thread handling is slightly different and the signals for closing >> >threads isn't happy. Probably a lower priority issue. (We can >> >instrument the cleanup code (in module/owlib/src/c/owlib.c) >> > >> >Paul Alfille >> > >> > >> >On 7/21/06, rnilsson <[EMAIL PROTECTED]> wrote: >> >> >> >> Paul, >> >> >> >> Progress! I actually have it working, although my current solution is a >> >> work around. >> >> >> >> Since the read in getstatus is returning 32 bytes (or more if I give it a >> >> bigger buffer) of all repeating data, I put in a loop that would read it >> >> until I got something less than 32 bytes. This isn't perfect, as an error >> >> condition could cause this to break. But, until I figure out why reading >> >> EP1 is providing so much data, it's all I can do. >> >> >> >> I've added quite a few debug messages. The snibbit below is an example of >> >> what's happening. The DS9490_reset issues a command, and then calls >> >> getstatus to wait for the ready. The Count is the number of times through >> >> my read loop - this line is printed each time the Command or Ready to read >> >> bytes change. On the first loop my comparison values are set (from 0), >> >> but >> >> the first read get me the results of the prior command. This will happen >> >> on >> >> every getstatus call. The second item at Count 1 is the new command that >> >> was issued. In this case we had to loop twice to get a < 32 byte read the >> >> first time, and then it ran throught the getstatus loop again and had to >> >> do >> >> 17 more reads. The longer the time between the command and the read, the >> >> more loops. If I turn on ugen USB debugging too aggressively, the added >> >> logging will cause enough delay that the loop will run until there is a >> >> crazy short read, which is at the end of the buffer. It seems like a >> >> lower >> >> level process is honoring the polling interval (10ms in alternative 3) and >> >> just going crazy filling the buffer, as opposed to waiting until I poll. >> >> After each getstatus there is either another command, or a close, which is >> >> probably why there is only one extra command buffered up once I catch up. >> >> >> >> The clear_halt from libusb is not implemented on the BSD side, which is >> >> why >> >> that didn't work. I added in the code, but haven't gotten it to work >> >> properly yet (I'm sure I'm sending some incorrect paramenter). >> >> >> >> The usb_interrupt_read function is irrelevant, since the ugen driver makes >> >> that decision based on the endpoint type. >> >> >> >> But - this does actually run now! I have a device on the bus, and can >> >> query >> >> it... >> >> >> >> While I wait for some response from the FreeBSD USB experts regarding the >> >> looping issue, do you have any idea where I can find the code that is >> >> binding to IPv6 instead of IPv4? >> >> >> >> Also, when I kill owhttpd, it core dumps. Any ideas on where to look for >> >> that issue? >> >> >> >> Jul 21 13:25:09 bsdtest OWFS[47728]: DS9490_reset >> >> Jul 21 13:25:09 bsdtest OWFS[47728]: DS9490_getstatus: readlen=0 >> >> Jul 21 13:25:09 bsdtest OWFS[47728]: DS9490_getstatus: Count: 0 Command: >> >> 0->117, 0-> 8 Ready to read: 0-> 1 >> >> Jul 21 13:25:09 bsdtest OWFS[47728]: DS9490_getstatus: Count: 1 Command: >> >> 117->75, 8-> 8 Ready to read: 1-> 0 >> >> Jul 21 13:25:09 bsdtest OWFS[47728]: DS9490_getstatus: Loops/Return: 2/16 >> >> Jul 21 13:25:09 bsdtest OWFS[47728]: DS9490_getstatus: Loops/Return: 17/16 >> >> Jul 21 13:25:09 bsdtest OWFS[47728]: DS9490_getstatus: readlen=0 >> >> >> >> -- >> >> View this message in context: >> >> http://www.nabble.com/FreeBSD-6.1-Troubles...-tf1969732.html#a5439566 >> >> Sent from the OWFS - Dev forum at Nabble.com. >> >> >> >> >> >> ------------------------------------------------------------------------- >> >> 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 >> >> _______________________________________________ >> >> Owfs-developers mailing list >> >> [email protected] >> >> https://lists.sourceforge.net/lists/listinfo/owfs-developers >> >> >> > >> >------------------------------------------------------------------------- >> >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 >> >_______________________________________________ >> >Owfs-developers mailing list >> >[email protected] >> >https://lists.sourceforge.net/lists/listinfo/owfs-developers >> > >> > >> >> ------------------------------------------------------------------------- >> 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 >> _______________________________________________ >> Owfs-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/owfs-developers >> > >------------------------------------------------------------------------- >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 >_______________________________________________ >Owfs-developers mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/owfs-developers > > ------------------------------------------------------------------------- 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 _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
