Oh, I think I forgot to mention: Despite the fact that it's mostly working with the new DTB stuff, I still can't set the mode on the pin:
# cat $PINS | grep 82c pin 11 (44e1082c.0) 00000027 pinctrl-single According to my .dts (http://pastebin.com/ksUU07u0), it should end in 0xf (PIN_OUTPUT | MUX_MODE7). > On Dec 28, 2014, at 23:23 , Rick Mann <[email protected]> wrote: > > Okay, with great thanks to Robert for all his help getting my DTB > up-and-running, I've now run into a new issue with GPIO and/or ADC access. It > seems that if I do it too rapidly, one of the operations never returns. > > I sit in a loop in the main thread, polling two ADC channels, and at the > start of the loop, and every 5 times through, I poll a GPIO and set a GPIO. > At the end of the loop, I sleep for 100 ms. > > This has worked very well under 3.8. Over the last few hours I upgraded to > 3.14.26-ti-r43 (with CONFIG_USB_TI_CPPI41_DMA disabled and > CONFIG_MUSB_PIO_ONLY enabled). I then customized the dtb with this: > http://pastebin.com/ksUU07u0 > > With all that, my GPIOs and ADC seemed to work fine. But then I removed some > logging statements from the main loop, and now the behavior seems to be that > the main thread loop hangs on some operation (I use sysfs to access the GPIOs > and ADCs). The secondary thread, which is decoding MP3s and playing audio, > continues to function. If I hit Control-C, that thread stops, but the process > doesn't exit. I can't kill the process at all, and I have to reboot the BBB. > > I inserted a 100 ms delay before each of my sysfs operations, and it seems to > function correctly. > > Note that at first I thought it might be a thread synchronization issue > between my two threads (the second thread can be paused by the main via a > binary semaphore implemented with C++11 mutex and condition variable). But > that code only gets executed if the state of one of the GPIOs changes, and > that's not happening. > > I also commented out all the GPIO-access code and only polled the ADCs, one > after the other, with a 100 ms pause after, and that, too locks up. > > I tried to attach to the process with GDB, but I can't seem to interrupt it > to see the state of things (similar to how I can't Control-C the process > itself). > > Any ideas? I can probably live with the pre-call delay, but that seems lame. > > Thanks! > > -- > Rick Mann > [email protected] > > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- Rick Mann [email protected] -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
