Oh, I almost forgot - I'll give the BSD FUSE a try and let you know. Rob. On Sunday, July 23, 2006, at 10:18AM, Robert Nilsson <[EMAIL PROTECTED]> wrote:
>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 > > ------------------------------------------------------------------------- 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
