[beagleboard] Re: Beaglebone Black Wireless SDHC / SDXC support?

[Bill Fleming]

Any SD, SDHC, or SDXC should work on any BBB. As long as you don't try to 
use any "funny" cards such as the old non-standard 4 GB SD models, you 
shouldn't have any issues.
Note that for programming and booting a full system image (with desktop 
interface) you really want an 8 GB or larger SDHC card.
Otherwise you can use any cards that you want and put any filesystem on 
them that you want that Linux supports.

Bill

On Tuesday, December 25, 2018 at 12:22:14 PM UTC-6, Dennis Lee Bieber wrote:
>
> On Tue, 25 Dec 2018 03:50:25 -0800 (PST), don_wrt 
> > declaimed 
> the following: 
>
> >Dear All, 
> > 
> >If I am not wrong, BBBWL 's SDIO interface supports SD and SDHC, and does 
> >not support SDXC, right?   
> >I am confusing about the this Kingston microSD 
> > (PN: SDCIT/16GB) card 
> >compatible with BBBWL, or not? 
> > 
>
> SD=>LESS than 4GB, native FAT file system 
> SDHC=>(high capacity) 4-32GB, native FAT file 
> system 
> SDXC=>(?eXtreme capacity) 64GB and larger, native 
> exFAT file 
> system 
>
> (though since the BBB reformats into one of the Linux ext# file systems, 
> knowing the native format doesn't mean much... More of a problem on R-Pi, 
> since their NOOBS releases start as FAT, and format the rest of the card 
> into ext# during install). 
>
> I know of NO cards in the 16GB range that use SDXC protocol. 
>
>
> -- 
> Wulfraed Dennis Lee Bieber AF6VN 
> wlf...@ix.netcom.com 
> HTTP://wlfraed.home.netcom.com/ 
>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/13e1b87a-fa9f-4e89-8a83-0dd7abdb4547%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Detect change on GPIO configured as OUT

[Bill Fleming]

I think your project is a prime candidate to use the PRU Cortex-M that is 
included in the BBB for this type of stuff. While I have worked on many 
Cortex-Ms over the years, I haven't yet tried to use the PRU so you will 
need to search this board for help setting that up.
They do have the new free toolchain option for it.

On Friday, October 12, 2018 at 7:38:45 PM UTC-5, Sergey Manucharian wrote:
>
> Thanks, Bill, that definitely works (see the loop below), however, I think 
> it's not really effective from the CPU resources consumption standpoint.
> Maybe it has to be done at the kernel level...
>
> char res[2];
> 
> // check for value 0 i.e. 0x30
> while (res[0] != 0x30) {
>   lseek(fd, 0, SEEK_SET);
>   read(fd, res, 2);
> }
>
> On Friday, October 12, 2018 at 4:37:52 PM UTC-6, Bill Fleming wrote:
>>
>> I'm pretty sure that you can just always read the "value" inside the GPIO 
>> tree using a file read command.
>> So for example if you try to set the pin a certain way and it didn't 
>> change (strong pull or short) the value read still reflects the actual 
>> state.
>>
>> So just write a C program using fopen and fread to read the value from 
>> the "file".
>> http://www.cplusplus.com/reference/cstdio/fread/
>>
>> Put the read function in its own separate thread in a loop with a task 
>> delay resolution to match the baud rate.
>>
>> Then you are done, assuming the output pin read does actually work that 
>> way.
>> If not you can try setting input mode, read the value, then set output 
>> mode right after you are done reading.
>>
>> Bill
>>
>> On Friday, October 12, 2018 at 11:06:36 AM UTC-5, Sergey Manucharian 
>> wrote:
>>>
>>> What's the best way to detect a change in value on a GPIO configured as 
>>> OUT?
>>> It may sound really weird why one may need that. I have a custom cape 
>>> and cannot make changes to its hardware, but I need to improve certain 
>>> functionality.
>>> poll(2) on /sys/class/gpio/gpioXY/value exits with timeout.
>>>
>>> To avoid any XY-problem I'll explain the actual situation:
>>> The BBB's native RS-485 mode works fine with omap_serial driver, 
>>> however, I cannot use actual hardware pins for RTS (RE/DE) because the 
>>> above mentioned cape consumes all possibilities.
>>> So, I assigned an unconnected GPIO to be the RTS and want to detect its 
>>> state changes in a timing-critical application (tcdrain() takes too long).
>>>
>>> Thanks for advises!
>>> Sergey
>>>
>>>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/bf0e9db1-cfc7-4d68-922d-1e4a21519124%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Detect change on GPIO configured as OUT

[Bill Fleming]

I'm pretty sure that you can just always read the "value" inside the GPIO 
tree using a file read command.
So for example if you try to set the pin a certain way and it didn't change 
(strong pull or short) the value read still reflects the actual state.

So just write a C program using fopen and fread to read the value from the 
"file".
http://www.cplusplus.com/reference/cstdio/fread/

Put the read function in its own separate thread in a loop with a task 
delay resolution to match the baud rate.

Then you are done, assuming the output pin read does actually work that way.
If not you can try setting input mode, read the value, then set output mode 
right after you are done reading.

Bill

On Friday, October 12, 2018 at 11:06:36 AM UTC-5, Sergey Manucharian wrote:
>
> What's the best way to detect a change in value on a GPIO configured as 
> OUT?
> It may sound really weird why one may need that. I have a custom cape and 
> cannot make changes to its hardware, but I need to improve certain 
> functionality.
> poll(2) on /sys/class/gpio/gpioXY/value exits with timeout.
>
> To avoid any XY-problem I'll explain the actual situation:
> The BBB's native RS-485 mode works fine with omap_serial driver, however, 
> I cannot use actual hardware pins for RTS (RE/DE) because the above 
> mentioned cape consumes all possibilities.
> So, I assigned an unconnected GPIO to be the RTS and want to detect its 
> state changes in a timing-critical application (tcdrain() takes too long).
>
> Thanks for advises!
> Sergey
>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a2cbb2e7-0193-4a1f-b985-6b2679b809c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Difficulties for manual time set in Beglebone black

[Bill Fleming]

Currently we use the following to set the timezone for when the BBB is 
connected to the internet, as the GUI tool doesn't work (or you don't have 
GUI anyway in some cases).
This sets the US Central timezone as an example.

cd /etc/
sudo rm localtime
sudo ln -s /usr/share/zoneinfo/America/Chicago /etc/localtime
ls -al|grep localtime

Once you set that if the BBB is always online your time will automatically 
be correct, at least until there is some major change to DST or something 
that would require an update.

If you disconnect from the internet then you can use the following to set 
the time, we use separate time/date commands currently.

sudo -kS date --set year-MM-DD

sudo -kS date --set HH:MM:SS


Note that you have to run this on every reboot, as the BBB does not have a 
battery backed RTC.
If you need that functionality, the Andice labs power cape (now back in 
stock after parts shortage) has an RTC feature that can be used.
I have not tried to use the RTC battery backed feature on it myself, but I 
did test the time set/get commands and they appear to work correctly. 
(battery part tested and it works ok)
So then to use the battery RTC you would just need to add a time set on 
bootup service. (run once type service)

Note that to use this manual timeset when online, or use the battery backed 
RTC time set software from an I2C chip, you need to go on the command line 
and remove/disable the network time service. 
I haven't tried that myself but one of the following should work:

sudo timedatectl set-ntp off
sudo systemctl stop ntp.service


If you make a GUI tool like I did to set the time when offline, you need to 
add the corresponding NTP service enable (when online) for completeness.

Bill



On Tuesday, October 9, 2018 at 1:22:06 PM UTC-5, ard...@gmail.com wrote:
>
> So as long as Beaglebone is connected to internet, there is no way to 
> manually set time and date?
> By the way, i didn't see any cronjob sync time periodically, how is it 
> getting sync after boot (if any)?
>
> On Tuesday, October 9, 2018 at 10:06:05 AM UTC-6, Dennis Lee Bieber wrote:
>>
>> On Tue, 9 Oct 2018 05:48:22 -0700 (PDT), 
>> ard...@gmail.com declaimed the following: 
>>
>>
>> >now if I run a command it says that date is changed: 
>> > 
>> >root@beaglebone:/etc# date --set "2018/10/2 18:20:10" 
>> > 
>> >Tue Oct  2 18:20:10 UTC 2018 
>> > 
>> > 
>> >but if if run date command again, it still shows original time 
>> > 
>> >root@beaglebone:/etc# date 
>> > 
>> >Tue Oct  9 12:42:13 UTC 2018 
>> > 
>> > 
>> >is there any other process for setting up time date on beaglebone? 
>>
>> If you are connected to the Internet, the BBB runs an NTP 
>> synchronization. 
>>
>>
>> -- 
>> Wulfraed Dennis Lee Bieber AF6VN 
>> wlf...@ix.netcom.comHTTP://wlfraed.home.netcom.com/ 
>>
>>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7efbbffe-992e-47c7-82ee-40bb06cd2951%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Spam on the list

[Bill Fleming]

Anyone tried calling his boss yet?

On Wednesday, September 19, 2018 at 1:51:33 PM UTC-5, Matt Bradley wrote:
>
> He claimed he wasn't doing it and asked for my resume (really!). Maybe if 
> more people called...
>
>
>
> On September 19, 2018 11:44:40 AM PDT, evilwulfie  > wrote:
>>
>> Did he give a shit?  I suspect not.
>>
>> On 9/19/2018 11:03 AM, Matt Bradley wrote:
>>
>> He puts his phone number in his email. Call him and tell him to stop. I 
>> did.
>>
>> On September 19, 2018 11:01:04 AM PDT, Jacek Radzikowski 
>>   wrote: 
>>>
>>> Dear group admins,
>>>
>>> because no one is willing to take any actions on the spammer who 
>>> regularly sends unwanted messages to the list, and who violated the law he 
>>> refers in his emails by ignoring requests from the list to be removed from 
>>> his mailing list, I'm starting to mark his messages in my Gmail inbox as 
>>> spam, and I recommend other readers to do the same.
>>> I'm fully aware that this will affect Gmail's global spam filters, and 
>>> may increase number of false positives, but at this point this is the only 
>>> viable way of dealing with unwanted messages.
>>>
>>> Jacek.
>>>
>>>
>> -- 
>> Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 
>> 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 beagleboard...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CB2D63C1-1D43-4877-8094-5280A63F0F28%40brad-tech.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/00abefe6-1716-48fc-87ad-26545b9beb6a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Getting "libEGL warning: DRI2: failed to authenticate" on all qt gui projects

[Bill Fleming]

On the Stretch LXQT Debian 9.4 image I am getting:

"libEGL warning: DRI2: failed to authenticate" not just on my own simple 
widget qt apps but also on the included apps with lxqt.

So after some searching it appears that mesa "updated" the libegl.so and 
libglesv2.so.
However the instructions in the old post about how to fix this don't work 
on the new images or are not complete instructions as the BBB is missing 
the other copies of these files.

What is this correct way to fix this warning now?

Bill

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7e83723b-cf47-487f-a962-03b8f8edee05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] How to force BBB to re-read EDID of new connected display?

[Bill Fleming]

On the Debian stretch images for BBB is there an easy way to force the EDID 
to update and/or the display to re-initialize such as if you change the 
connected display (while the BBB is still running)?
I have noticed that I can switch to a different monitor on the HDMI, 
but /sys/devices/platform/ocp/4830e000.lcdc/drm/card0/card0-HDMI-A-1/edid 
will continue to show the information for the display that was connected at 
bootup. (old EDID)

Bill

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/59134874-c21f-45ca-bcd9-a939eab8da72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] How to fix bootup issues with barcode scanners and factory test code

[Bill Fleming]

If you are using Debian stretch with BeagleBone Black at least some of the 
images include test code that will run automatically when a barcode scanner 
is plugged in. (this was interesting to troubleshoot, lol)
To my knowledge this was not present on any Debian 8.X LXQT images.
You will know this is happening when at bootup instead of LXQT desktop 
showing up you will see a test screen instead with various image test 
patterns on the screen.

The simple fix is to remove the beagle-tester app and the associated script 
that runs it. (note the sh script has some device tree examples that might 
be helpful to look at as examples)

#Remove beagle-tester so that barcode scanners can be used.
sudo rm /usr/sbin/beagle-tester
sudo rm /usr/sbin/beagle-tester-open.sh

There probably is a service or 2 that are related to this, but removing 
those 2 files is at least one way of solving the issue.

Bill

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/45b70423-52f5-4982-8fa4-37a8b8895285%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BeagleBoneBlack GPIO folder randomly disappearing from sys/class/gpio

[Bill Fleming]

I finally figured this out.

The service I had created was constantly calling the export on the pin, 
which I assume would cause the list to "refresh" or something like that.
Stopping the service while the pin was "there" would cause the pin to stay. 
But if I stop the service when the pin is missing it stays missing.
I still need to confirm in the application that the pin works correctly 
every time but this probably settles this issue.

Later I can post up my scripts/service for reference once I get a final 
version.

Bill

On Monday, August 6, 2018 at 10:16:53 AM UTC-5, Bill Fleming wrote:
>
> I have finally been able to get back to working on this again.
> I have now seen the problem on 2 different BBBs (but not a third one yet) 
> so maybe this isn't a hardware problem?
>
> Here is an example of what I see. The GPIO will randomly appear and 
> disappear on certain BBBs.
> You can use the watch -n1 ls command to see it automatically update. This 
> can happen even with nothing physically connected to the pin.
>
> Has anybody else seen this problem before on any GPIO?
>
> debian@beaglebone:~$ cd /sys/class/gpio/
> debian@beaglebone:/sys/class/gpio$ ls
> export  gpio13  gpiochip0   gpiochip64  unexport
> gpio12  gpio50  gpiochip32  gpiochip96
> debian@beaglebone:/sys/class/gpio$ ls
> export  gpio13  gpiochip0   gpiochip64  unexport
> gpio12  gpio50  gpiochip32  gpiochip96
> debian@beaglebone:/sys/class/gpio$ ls
> export  gpio13  gpiochip0   gpiochip64  unexport
> gpio12  gpio50  gpiochip32  gpiochip96
> debian@beaglebone:/sys/class/gpio$ ls
> export  gpio13 gpiochip32  gpiochip96
> gpio12  gpiochip0  gpiochip64  unexport
> debian@beaglebone:/sys/class/gpio$ ls
> export  gpio13 gpiochip32  gpiochip96
> gpio12  gpiochip0  gpiochip64  unexport
> debian@beaglebone:/sys/class/gpio$ ls
> export  gpio13 gpiochip32  gpiochip96
> gpio12  gpiochip0  gpiochip64  unexport
> debian@beaglebone:/sys/class/gpio$ ls
> export  gpio13 gpiochip32  gpiochip96
> gpio12  gpiochip0  gpiochip64  unexport
> debian@beaglebone:/sys/class/gpio$ ls
> export  gpio13 gpiochip32  gpiochip96
> gpio12  gpiochip0  gpiochip64  unexport
> debian@beaglebone:/sys/class/gpio$ ls
> export  gpio13 gpiochip32  gpiochip96
> gpio12  gpiochip0  gpiochip64  unexport
> debian@beaglebone:/sys/class/gpio$ ls
> export  gpio13 gpiochip32  gpiochip96
> gpio12  gpiochip0  gpiochip64  unexport
> debian@beaglebone:/sys/class/gpio$ ls
> export  gpio13  gpiochip0   gpiochip64  unexport
> gpio12  gpio50  gpiochip32  gpiochip96
>
>
> Bill
>
>
> On Wednesday, July 18, 2018 at 6:46:23 PM UTC-5, Bill Fleming wrote:
>>
>> So we have been using GPIO 50 on the BBB with older releases such as 
>> Debian 8.3 for a while now with no issues.
>> We have updated to stretch Debian 9.4 in the past few days.
>>
>> I am setting the gpio export as follows: (in script on boot)
>>
>> sudo su
>>> echo 50 > /sys/class/gpio/export
>>
>>
>> Then I echo to these files to use the GPIO and it works as expected.
>> /sys/class/gpio/gpio50/value
>> /sys/class/gpio/gpio50/direction
>>
>> What I have noticed though is that on at least one of the boards the 
>> entire "/sys/class/gpio/gpio50/" folder will randomly go missing, then 
>> reappear a few seconds or minutes later.
>> This either started after a few reboots or it was like this the whole 
>> time on 9.4 but it took a while to notice the issue.
>> For example I can be in /sys/class/gpio/ then call the ls command. If I 
>> repeat this command over and over again sometimes the gpio50 will show up, 
>> and sometimes it won't. Most of the time it won't show up.
>> Sometimes I can navigate into the gpio50 folder, but then the various 
>> files and sub folders will be missing.
>>
>> When this folder disappears the application we are using fails to control 
>> the GPIO using fwrite, so it isn't just cosmetic.
>>
>> Does this mean the pin is fried and this is a hardware feature to disable 
>> a fried pin, or could the system be doing something else in the background 
>> where it tries to claim this pin for something else?
>> I have tried searching and I couldn't find any other case of the 
>> disappearing device tree folder like this.
>>
>> We had originally chosen this pin for PWM but never implemented it, so I 
>> am open to suggestions if there is a better GPIO I should be using for 
>> basic 3.3 level switching. (one that is guaranteed to work without having 
>> to disable a bunch of features in the system)
>>
>> Thanks in advance for any help.
>>
>> Bill
>>
&g

[beagleboard] Re: BeagleBoneBlack GPIO folder randomly disappearing from sys/class/gpio

[Bill Fleming]

I have finally been able to get back to working on this again.
I have now seen the problem on 2 different BBBs (but not a third one yet) 
so maybe this isn't a hardware problem?

Here is an example of what I see. The GPIO will randomly appear and 
disappear on certain BBBs.
You can use the watch -n1 ls command to see it automatically update. This 
can happen even with nothing physically connected to the pin.

Has anybody else seen this problem before on any GPIO?

debian@beaglebone:~$ cd /sys/class/gpio/
debian@beaglebone:/sys/class/gpio$ ls
export  gpio13  gpiochip0   gpiochip64  unexport
gpio12  gpio50  gpiochip32  gpiochip96
debian@beaglebone:/sys/class/gpio$ ls
export  gpio13  gpiochip0   gpiochip64  unexport
gpio12  gpio50  gpiochip32  gpiochip96
debian@beaglebone:/sys/class/gpio$ ls
export  gpio13  gpiochip0   gpiochip64  unexport
gpio12  gpio50  gpiochip32  gpiochip96
debian@beaglebone:/sys/class/gpio$ ls
export  gpio13 gpiochip32  gpiochip96
gpio12  gpiochip0  gpiochip64  unexport
debian@beaglebone:/sys/class/gpio$ ls
export  gpio13 gpiochip32  gpiochip96
gpio12  gpiochip0  gpiochip64  unexport
debian@beaglebone:/sys/class/gpio$ ls
export  gpio13 gpiochip32  gpiochip96
gpio12  gpiochip0  gpiochip64  unexport
debian@beaglebone:/sys/class/gpio$ ls
export  gpio13 gpiochip32  gpiochip96
gpio12  gpiochip0  gpiochip64  unexport
debian@beaglebone:/sys/class/gpio$ ls
export  gpio13 gpiochip32  gpiochip96
gpio12  gpiochip0  gpiochip64  unexport
debian@beaglebone:/sys/class/gpio$ ls
export  gpio13 gpiochip32  gpiochip96
gpio12  gpiochip0  gpiochip64  unexport
debian@beaglebone:/sys/class/gpio$ ls
export  gpio13 gpiochip32  gpiochip96
gpio12  gpiochip0  gpiochip64  unexport
debian@beaglebone:/sys/class/gpio$ ls
export  gpio13  gpiochip0   gpiochip64  unexport
gpio12  gpio50  gpiochip32  gpiochip96


Bill


On Wednesday, July 18, 2018 at 6:46:23 PM UTC-5, Bill Fleming wrote:
>
> So we have been using GPIO 50 on the BBB with older releases such as 
> Debian 8.3 for a while now with no issues.
> We have updated to stretch Debian 9.4 in the past few days.
>
> I am setting the gpio export as follows: (in script on boot)
>
> sudo su
>> echo 50 > /sys/class/gpio/export
>
>
> Then I echo to these files to use the GPIO and it works as expected.
> /sys/class/gpio/gpio50/value
> /sys/class/gpio/gpio50/direction
>
> What I have noticed though is that on at least one of the boards the 
> entire "/sys/class/gpio/gpio50/" folder will randomly go missing, then 
> reappear a few seconds or minutes later.
> This either started after a few reboots or it was like this the whole time 
> on 9.4 but it took a while to notice the issue.
> For example I can be in /sys/class/gpio/ then call the ls command. If I 
> repeat this command over and over again sometimes the gpio50 will show up, 
> and sometimes it won't. Most of the time it won't show up.
> Sometimes I can navigate into the gpio50 folder, but then the various 
> files and sub folders will be missing.
>
> When this folder disappears the application we are using fails to control 
> the GPIO using fwrite, so it isn't just cosmetic.
>
> Does this mean the pin is fried and this is a hardware feature to disable 
> a fried pin, or could the system be doing something else in the background 
> where it tries to claim this pin for something else?
> I have tried searching and I couldn't find any other case of the 
> disappearing device tree folder like this.
>
> We had originally chosen this pin for PWM but never implemented it, so I 
> am open to suggestions if there is a better GPIO I should be using for 
> basic 3.3 level switching. (one that is guaranteed to work without having 
> to disable a bunch of features in the system)
>
> Thanks in advance for any help.
>
> Bill
>
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/02d573a0-d3ca-47c0-9941-f9f0194da41d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.