Re: [beagleboard] Weird Problem using GPIOs on BBB

[William Hermans]

You're welcome. If you have more questions just ask.

On Thu, Jul 14, 2016 at 9:11 PM, Raul Piper  wrote:

> Hello William,
> Thankyou very much for jotting down all the relevant example amidst your
> busy schedule.I am really grateful to you.I will check this.This example
> looks far simpler to me.
> Rgds,
> Rp
>
> On Friday, July 15, 2016 at 2:26:00 AM UTC+5:30, William Hermans wrote:
>>
>> By the way. I'm not familiar with the C++ fstream object. But this person
>> is not doing any error checking . . .
>>
>> On Thu, Jul 14, 2016 at 1:48 PM, William Hermans 
>> wrote:
>>
>>> Ok turns out I do not have to write an example. After a quick google
>>> search I found a very good simple example on stackoverflow:
>>> http://stackoverflow.com/questions/21198933/how-to-control-beaglebone-gpio-pins
>>>
>>> So. . .  this is a very good example that shows how one would, or could
>>> wrap the gpio sysfs files. This:
>>>
>>> fs.open("/sys/kernel/debug/omap_mux/gpmc_ad4");
fs << "7";

 May be incorrect for current kernel / file system structure, but I can
>>> tell you what this bit of code is going. It's simply muxing the pin he /
>>> she want to control in code. 0x7 == pin mux for GPIO mode. So you( we ) can
>>> either figure how do do this with modern debian images, or "we" could
>>> simply mu our pins with config-pin( universal IO ) or  device tree overlay.
>>>
>>> Personally, since I've been experimenting with Charles' universal-io
>>> overlays and config-pin recently, and in my spare time. I'm favoring that
>>> lately. Also, that script is very easily wrapped in code as well. Anyway,
>>> once the pin it muxed for the correct mode, the rest of that code would(
>>> should ) simply work.
>>>
>>>fs.open("/sys/class/gpio/export");
fs << "32";
fs.close();

>>>
>>>  This is exactly as if you echo "32" into /sys/class/gpio/export. Which
>>> exports the pin.
>>>
>>>fs.open("/sys/class/gpio/gpio32/direction");
fs << "out";
fs.close();
>>>
>>>
>>> Exactly like echoing "out" into /sys/class/gpio/gpio32/direction. Which
>>> configures the pin as output.
>>>
>>>fs.open("/sys/class/gpio/gpio32/value");
fs << "1";
fs.close();


>>> Exactly the same as echoing "1" into /sys/class/gpio/gpio32/value.
>>> Which makes the pin output, and high.
>>>
>>> Any further questions ?
>>>
>>> On Thu, Jul 14, 2016 at 11:20 AM, William Hermans 
>>> wrote:
>>>
 OK, I'm still a little busy, but I should have something example wise
 in a couple hours.

 On Thu, Jul 14, 2016 at 1:00 AM, William Hermans 
 wrote:

> You only need to toggle gpio ? How fast do you need it to be ? That
> code is far to complex, and uses threading, as well as callbacks for some
> odd reason. Threaded code can have performance overhead, and callbacks can
> cause problems on the stack if you're not careful.
>
> You would be better off writing your own wrapper code. You could
> either wrap the sysfs gpio files directly. Or if you wished you could wrap
> config-pin from universal io.
>
> Anyway, it's getting late here so perhaps tomorrow I'll write up a
> quick example, that is far less code than D.R. Molloy's  . . . uh .
> ..library ? The thing is, the sysfs directory / file structure is already
> there and functional. Why would anyone need to write so much code to
> encapsulate it ? *shrug*
>
> On Wed, Jul 13, 2016 at 10:02 PM, Raul Piper 
> wrote:
>
>> Attached.
>> One is the cpp code and other is the bash script.
>> cpp code uses the GPIO class from the attached GPIO.7z .
>>
>>
>> On Thursday, July 14, 2016 at 9:50:45 AM UTC+5:30, William Hermans
>> wrote:
>>>
>>> Let's put it this way. No code, no help . . .
>>>
>>> On Wed, Jul 13, 2016 at 9:19 PM, William Hermans 
>>> wrote:
>>>

 #code2
 //create an instance of gpio41
  //set direction as OUT
 //set value as 1
 usleep(10);
 //set value 0

 Output : Toggle doesnt happens

 Whats this ? This is not code. At best it's comments, and usleep().


 On Wed, Jul 13, 2016 at 9:02 PM, Raulp 
 wrote:

> OK let em explain a bit more :
> #code 1
> sudo echo 41 > export
> cd gpio41
> sudo chmod 666 direction
> sudo chmod 666 value
> sudo echo out > direction
> sudo echo 1 > value
> sleep 1
> sudo echo 0 > value
>
> Output : Toggle on the GPIO 41
>
>
> #code2
> //create an instance of gpio41
>  //set direction as OUT
> //set value as 1
> usleep(10);
> //set value 0
>
> Output : Toggle doesnt happens
>
>
> Now the output I am referring to is the functioning of the
> ha

Re: [beagleboard] Weird Problem using GPIOs on BBB

[Raul Piper]

Hello William,
Thankyou very much for jotting down all the relevant example amidst your 
busy schedule.I am really grateful to you.I will check this.This example 
looks far simpler to me.
Rgds,
Rp

On Friday, July 15, 2016 at 2:26:00 AM UTC+5:30, William Hermans wrote:
>
> By the way. I'm not familiar with the C++ fstream object. But this person 
> is not doing any error checking . . .
>
> On Thu, Jul 14, 2016 at 1:48 PM, William Hermans  > wrote:
>
>> Ok turns out I do not have to write an example. After a quick google 
>> search I found a very good simple example on stackoverflow: 
>> http://stackoverflow.com/questions/21198933/how-to-control-beaglebone-gpio-pins
>>
>> So. . .  this is a very good example that shows how one would, or could 
>> wrap the gpio sysfs files. This:
>>
>> fs.open("/sys/kernel/debug/omap_mux/gpmc_ad4");
>>>fs << "7";
>>>
>>> May be incorrect for current kernel / file system structure, but I can 
>> tell you what this bit of code is going. It's simply muxing the pin he / 
>> she want to control in code. 0x7 == pin mux for GPIO mode. So you( we ) can 
>> either figure how do do this with modern debian images, or "we" could 
>> simply mu our pins with config-pin( universal IO ) or  device tree overlay.
>>
>> Personally, since I've been experimenting with Charles' universal-io 
>> overlays and config-pin recently, and in my spare time. I'm favoring that 
>> lately. Also, that script is very easily wrapped in code as well. Anyway, 
>> once the pin it muxed for the correct mode, the rest of that code would( 
>> should ) simply work. 
>>
>>fs.open("/sys/class/gpio/export");
>>>fs << "32";
>>>fs.close();
>>>
>>
>>  This is exactly as if you echo "32" into /sys/class/gpio/export. Which 
>> exports the pin.
>>
>>fs.open("/sys/class/gpio/gpio32/direction");
>>>fs << "out";
>>>fs.close();
>>
>>
>> Exactly like echoing "out" into /sys/class/gpio/gpio32/direction. Which 
>> configures the pin as output.
>>
>>fs.open("/sys/class/gpio/gpio32/value");
>>>fs << "1"; 
>>>fs.close();
>>>
>>>
>> Exactly the same as echoing "1" into /sys/class/gpio/gpio32/value. Which 
>> makes the pin output, and high. 
>>
>> Any further questions ?
>>
>> On Thu, Jul 14, 2016 at 11:20 AM, William Hermans > > wrote:
>>
>>> OK, I'm still a little busy, but I should have something example wise in 
>>> a couple hours.
>>>
>>> On Thu, Jul 14, 2016 at 1:00 AM, William Hermans >> > wrote:
>>>
 You only need to toggle gpio ? How fast do you need it to be ? That 
 code is far to complex, and uses threading, as well as callbacks for some 
 odd reason. Threaded code can have performance overhead, and callbacks can 
 cause problems on the stack if you're not careful.

 You would be better off writing your own wrapper code. You could either 
 wrap the sysfs gpio files directly. Or if you wished you could wrap 
 config-pin from universal io.

 Anyway, it's getting late here so perhaps tomorrow I'll write up a 
 quick example, that is far less code than D.R. Molloy's  . . . uh . 
 ..library ? The thing is, the sysfs directory / file structure is already 
 there and functional. Why would anyone need to write so much code to 
 encapsulate it ? *shrug*

 On Wed, Jul 13, 2016 at 10:02 PM, Raul Piper >>> > wrote:

> Attached.
> One is the cpp code and other is the bash script.
> cpp code uses the GPIO class from the attached GPIO.7z .
>
>
> On Thursday, July 14, 2016 at 9:50:45 AM UTC+5:30, William Hermans 
> wrote:
>>
>> Let's put it this way. No code, no help . . .
>>
>> On Wed, Jul 13, 2016 at 9:19 PM, William Hermans  
>> wrote:
>>
>>>
>>> #code2
>>> //create an instance of gpio41
>>>  //set direction as OUT
>>> //set value as 1
>>> usleep(10);
>>> //set value 0
>>>
>>> Output : Toggle doesnt happens
>>>
>>> Whats this ? This is not code. At best it's comments, and usleep().
>>>
>>>
>>> On Wed, Jul 13, 2016 at 9:02 PM, Raulp  wrote:
>>>
 OK let em explain a bit more : 
 #code 1
 sudo echo 41 > export
 cd gpio41
 sudo chmod 666 direction
 sudo chmod 666 value
 sudo echo out > direction
 sudo echo 1 > value
 sleep 1
 sudo echo 0 > value 

 Output : Toggle on the GPIO 41


 #code2
 //create an instance of gpio41
  //set direction as OUT
 //set value as 1
 usleep(10);
 //set value 0

 Output : Toggle doesnt happens


 Now the output I am referring to is the functioning of the hardware 
 I have used.(ignore toggling , it happens anyway using the code#2)


  Or does your code simply open, and use  the file descriptors 
 without any error checking what so ever ?
 >> I don

Re: [beagleboard] How to Compile OpenCV 'Hello World'

[Ben Nguyen]

Interestingly, when I omit the filename,

g++ -O2 `pkg-config --cflags --libs opencv` 

I get warnings about lame! 
http://pastebin.com/dLWJaCed 
(ex. libmp3lame.so.0 needed by //usr/lib/arm-linux-gnueabihf/libavcodec.so 
not found )

Why would it be looking for lame/mp3 files to compile?   lame installed 
without errors (3.99.5),  so it must be something else right?
Ben







On Tuesday, July 12, 2016 at 12:51:40 PM UTC-7, Wally Bkg wrote:
>
> And if that doesn't work, make sure the development packages ( libxxx-dev) 
> for the open CV libraries are also installed.  Its one of my biggest 
> frustrations with Debian/Ubuntu that  installing the library doesn't 
> generally install the header files for that library.
>
>
> On Monday, July 11, 2016 at 11:19:03 PM UTC-5, jdawgaz wrote:
>>
>>
>> On Mon, Jul 11, 2016 at 8:32 PM, Ben Nguyen  wrote:
>>
>>> 'pkg-config --cflags --libs opencv'
>>
>>
>>
>> try backticks instead of single-quotes like you have
>>
>>
>> --
>> Extra Ham Operator: K7AZJ
>> Registered Linux User: 275424
>> Raspberry Pi and Arduino developer
>>
>>
>> *The most exciting phrase to hear in science - the one that heralds new 
>> discoveries - is not "Eureka!" but "That's funny...".*- Isaac. Asimov
>>
>

-- 
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/a2fadb15-523c-411f-83bd-554bf1785fd3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Microphone Bias Voltage Level

[John Syne]

You would be better off using an audio codec for this purpose. Unfortunately, 
the Audio Cape doesn’t bring out the microphone circuitry, but you could use a 
audio preamp and connect to the audio cape audio input. 

Regards,
John




> On Jul 14, 2016, at 3:26 PM, keerthana.manivan...@gmail.com wrote:
> 
> 
> Hi there, 
> 
> I'm looking to use an electret microphone with a beaglebone black for my 
> project. Can't I directly plug the mic into an analog pin and use the data?
> Do I need a pre amplifier circuit kind of thing to use the mic with a BBB?
> 
> 
> On Tuesday, March 10, 2015 at 11:49:16 PM UTC-5, sns wrote:
> Will USB headset with mic work for audio application that records sound and 
> playback on beaglebone with quality?Here is there is no need for separate 
> pre- amplifier or circuit that requires biasing mic voltage?
> 
> On Thu, Feb 26, 2015 at 2:53 PM, Zainab S.V > 
> wrote:
> What about using microphone input from a headphone for recording and using 
> the headset for playback? Does it need any extra circuitry?
> 
> On Tue, Feb 24, 2015 at 8:22 PM, Fredrik Olofsson  > wrote:
> all the usb soundcards i've tried so far can don't need biasing.  just solder 
> an electret mic directly to a minijack and connect it to the input of the usb 
> soundcard.  though note that sound quality varies.  some cards make a lot of 
> noise (one logilink model even was blinking a led when active and that 
> interfered and could be heard in the mic input signal.)
> terratec aureon dual usb is the best sounding card i've found so far.  though 
> i don't own an audio cape so i can't compare.
> 
> If i use usb audio interface instead of the cape, is there a need for biasing 
> ?
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/beagleboard/qBpwQ0UZcIM/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> 
> -- 
> 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/a441645a-2159-4a64-8be5-5ebab130f289%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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/1BD250D9-4E58-4B6E-81F7-464C7145B8F9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] GPIO problems on ubuntu 16.04

[William Hermans]

Denis,

Which kernel version are you using for your system ? Ah ok, you said it at
the beginning. a 4.4.x*bone* variant. Can you easily configure a test
system to test the pin with the universal-io config-pin tool ? How I
personally did this was . . .
*/boot/uEnv.txt*
. . .
##BeagleBone Black: HDMI (Audio/Video) disabled:
dtb=am335x-boneblack-emmc-overlay.dtb
. . .
##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
cape_enable=bone_capemgr.enable_partno=univ-all

*Then download the config-pin tool.*
$ wget
https://raw.githubusercontent.com/cdsteinkuehler/beaglebone-universal-io/master/config-pin
$ chmod +x config-pin

*check the pin configuration:*
$ sudo ./ config-pin -q P9.15 /* gpio48 */
P9_15 Mode: default Direction: in Value: 1

*Test gpio48:*
$ sudo ./config-pin P9.15 hi
$ sudo ./config-pin -q P9.15
P9_15 Mode: gpio Direction: out Value: 1
$ sudo ./config-pin P9.15 low
$ sudo ./config-pin -q P9.15
P9_15 Mode: gpio Direction: out Value: 0

So  if this works. You'll have some sort of software issue. If it does not
. . . you may have defective hardware.






On Thu, Jul 14, 2016 at 3:29 PM,  wrote:

> Hello,
> I have a beaglebone black, and I am having some serious problems with the
> GPIO configuration, trying to migrate our working ubuntu 14.04 installation
> to ubuntu 16.04. The beaglebone sits on a specifically constructed board,
> that needs some GPIOs and the CAN-bus working, to function properly. As a
> starting point, I took the preconfigured 16.04 image from
> http://elinux.org/BeagleBoardUbuntu#Ubuntu_.2816.04.29 and installed the
> modified 4.4 kernel (--bone-kernel --lts-4_4 as described here:
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Mainline_.284.4.x_lts.29).
>
>
> I modified a dts script for a CAN overlay and got it working. Then, using
> Adafruit with python3, I got the required GPIOs configured. However
> autostart of CAN and GPIOs works only, if I force the respective init.d
> script to start after $network, which could pose a problem later, as the
> power supply for our wlan rounter is powered on using GPIOs.
>
> Nonetheless, the resulting entries in /sys/class/gpio are:
> gpio115, gpio26, gpio38, gpio44, gpio46, gpio48, gpio63, gpio65
>
> With the respective device trees in:
> /sys/devices/platform/ocp/44e07000.gpio/gpio/
> gpio26 (LED)
>
> /sys/devices/platform/ocp/481ac000.gpio/gpio/
> gpio65 (LED)
>
> /sys/devices/platform/ocp/4804c000.gpio/gpio (wird in der BBB_Setup.py
> benutzt)
> gpio38 (scanner_running)
> gpio44 (LED)
> gpio46 (LED)
> gpio48 (scanner_pwr)
> gpio63 (LED)
>
> /sys/devices/platform/ocp/481ae000.gpio/gpio/
> gpio115 (motor_pwr)
>
> At this point, I am able to power up the motor with gpio115 and four of
> the LEDs (gpio44, gpio46, gpio26, gpio65) via python or writing to the
> value files in the device tree.
> Unfortunately gpio48 always stays at measured 0.9V, regardless of the
> values written to the value file or the output commands issued using python
> and gpio63 always outputs something similar to a HIGH signal. As I
> suspected some other conflicting capes, I copied the system from eMMC to
> uSD and disabled the eMMC and HDMI/HDMI-audio capes in /boot/uEnv.txt. The
> slots in /sys/bus/platform/devices/bone_capemgr/slots now show only the CAN
> and the Adafruit capes. pinmux-pins and pingroups in
> /sys/kernel/debug/pinctrl/44e10800.pinmux look, as if all required pins are
> configured as GPIO unclaimed. However gpio48 and gpio63 still do not react
> to any output commands. Then I tried to build a device tree overlay using
> the patched version of the dtc compiler and configuring the required pins
> to work as outputs in mode7. Loading this cape gives me a probably kernel
> related error(see cape-error.log) that does not occur, if w1-gpio and
> w1-term are loaded using modprobe in advance. Regardless of this cape being
> loaded, gpio48 and gpio63 are still not working.
>
> I made some logs, that may be helpful with the diagnosis of the problem:
> www.defi1.de/beaglebone/cape-slots.log (slots right after booting)
> www.defi1.de/beaglebone/dmesg.log (kernel message log right after booting)
> www.defi1.de/beaglebone/cape-error.log (error in kernel message log when
> trying to load my custom cape)
> www.defi1.de/beaglebone/overlays.log (the device tree overlays created
> with Adafruit)
> www.defi1.de/beaglebone/pinmux-pins.log
> www.defi1.de/beaglebone/piongroups.log
>
> Any help on this would be appreciated.
>
>
> --
> 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/26aa24b0-f201-43de-863d-f6961b679471%40googlegroups.com
> 

[beagleboard] GPIO problems on ubuntu 16.04

[denis . fisseler]

Hello,
I have a beaglebone black, and I am having some serious problems with the 
GPIO configuration, trying to migrate our working ubuntu 14.04 installation 
to ubuntu 16.04. The beaglebone sits on a specifically constructed board, 
that needs some GPIOs and the CAN-bus working, to function properly. As a 
starting point, I took the preconfigured 16.04 image from 
http://elinux.org/BeagleBoardUbuntu#Ubuntu_.2816.04.29 and installed the 
modified 4.4 kernel (--bone-kernel --lts-4_4 as described here: 
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Mainline_.284.4.x_lts.29). 


I modified a dts script for a CAN overlay and got it working. Then, using 
Adafruit with python3, I got the required GPIOs configured. However 
autostart of CAN and GPIOs works only, if I force the respective init.d 
script to start after $network, which could pose a problem later, as the 
power supply for our wlan rounter is powered on using GPIOs.

Nonetheless, the resulting entries in /sys/class/gpio are:
gpio115, gpio26, gpio38, gpio44, gpio46, gpio48, gpio63, gpio65

With the respective device trees in:
/sys/devices/platform/ocp/44e07000.gpio/gpio/
gpio26 (LED)

/sys/devices/platform/ocp/481ac000.gpio/gpio/
gpio65 (LED)

/sys/devices/platform/ocp/4804c000.gpio/gpio (wird in der BBB_Setup.py 
benutzt)
gpio38 (scanner_running)
gpio44 (LED)
gpio46 (LED)
gpio48 (scanner_pwr)
gpio63 (LED)

/sys/devices/platform/ocp/481ae000.gpio/gpio/
gpio115 (motor_pwr)

At this point, I am able to power up the motor with gpio115 and four of the 
LEDs (gpio44, gpio46, gpio26, gpio65) via python or writing to the value 
files in the device tree.
Unfortunately gpio48 always stays at measured 0.9V, regardless of the 
values written to the value file or the output commands issued using python 
and gpio63 always outputs something similar to a HIGH signal. As I 
suspected some other conflicting capes, I copied the system from eMMC to 
uSD and disabled the eMMC and HDMI/HDMI-audio capes in /boot/uEnv.txt. The 
slots in /sys/bus/platform/devices/bone_capemgr/slots now show only the CAN 
and the Adafruit capes. pinmux-pins and pingroups in 
/sys/kernel/debug/pinctrl/44e10800.pinmux look, as if all required pins are 
configured as GPIO unclaimed. However gpio48 and gpio63 still do not react 
to any output commands. Then I tried to build a device tree overlay using 
the patched version of the dtc compiler and configuring the required pins 
to work as outputs in mode7. Loading this cape gives me a probably kernel 
related error(see cape-error.log) that does not occur, if w1-gpio and 
w1-term are loaded using modprobe in advance. Regardless of this cape being 
loaded, gpio48 and gpio63 are still not working.

I made some logs, that may be helpful with the diagnosis of the problem:
www.defi1.de/beaglebone/cape-slots.log (slots right after booting)
www.defi1.de/beaglebone/dmesg.log (kernel message log right after booting)
www.defi1.de/beaglebone/cape-error.log (error in kernel message log when 
trying to load my custom cape)
www.defi1.de/beaglebone/overlays.log (the device tree overlays created with 
Adafruit)
www.defi1.de/beaglebone/pinmux-pins.log
www.defi1.de/beaglebone/piongroups.log

Any help on this would be appreciated.


-- 
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/26aa24b0-f201-43de-863d-f6961b679471%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Microphone Bias Voltage Level

[keerthana . manivannan]

Hi there, 

I'm looking to use an electret microphone with a beaglebone black for my 
project. Can't I directly plug the mic into an analog pin and use the data?
Do I need a pre amplifier circuit kind of thing to use the mic with a BBB?


On Tuesday, March 10, 2015 at 11:49:16 PM UTC-5, sns wrote:
>
> Will USB headset with mic work for audio application that records sound 
> and playback on beaglebone with quality?Here is there is no need for 
> separate pre- amplifier or circuit that requires biasing mic voltage?
>
> On Thu, Feb 26, 2015 at 2:53 PM, Zainab S.V  > wrote:
>
>> What about using microphone input from a headphone for recording and 
>> using the headset for playback? Does it need any extra circuitry?
>>
>> On Tue, Feb 24, 2015 at 8:22 PM, Fredrik Olofsson > > wrote:
>>
>>> all the usb soundcards i've tried so far can don't need biasing.  just 
>>> solder an electret mic directly to a minijack and connect it to the input 
>>> of the usb soundcard.  though note that sound quality varies.  some cards 
>>> make a lot of noise (one logilink model even was blinking a led when active 
>>> and that interfered and could be heard in the mic input signal.)
>>> terratec aureon dual usb is the best sounding card i've found so far. 
>>>  though i don't own an audio cape so i can't compare.
>>>
>>> If i use usb audio interface instead of the cape, is there a need for 
>>> biasing ?
>>>

> -- 
>>> For more options, visit http://beagleboard.org/discuss
>>> --- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "BeagleBoard" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/beagleboard/qBpwQ0UZcIM/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> beagleboard...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>

-- 
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/a441645a-2159-4a64-8be5-5ebab130f289%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] reliability issues with Beaglebone Blacks, various failures

[William Hermans]

>
>
> One is an element14 board that boots ok, but reproducibly gives a
> mysterious error on install from source of Python 2.7.11 (a requirement for
> us, long ugly story).
>

This more than likely is a software issue. So, it sounds like there is some
sort of software requirement, but I'd very serious consider changing this
requirement. At minimum, make a good case to management.

As to the rest of your questions. No one can really answer these questions
because you've not provided enough information. However with that said,
this is something you really need to pay someone for. Someone who knows the
whole situation, and someone who knows the hardware, and software very well.

On Thu, Jul 14, 2016 at 3:04 PM, Gerald Coley 
wrote:

> At this point all I can say is that I did not design these boards for your
> application and therefore I cannot guarantee that it will do what you need
> it to do.
>
> From what little you have said about your application, it sounds like
> industrial versions would be preferable.
>
> I would need to see a detailed schematic of your design to see if there
> were any issues in your application and use of the board as designed..
>
> There can be a variance across different boards depending on what corner
> cases you might be hitting. It could be the ones that are working fine are
> working better than they should be as opposed to the ones that fail not
> working as good as they should be.
>
> Gerald
>
>
> On Thu, Jul 14, 2016 at 4:40 PM, John Stoner  wrote:
>
>> In our lab we have 8-9 Beaglebone Black units. We are using them to
>> control high intensity lights, with circuits in the 7A/9V neighborhood. The
>> circuits are simple, using mosfets to control the high power circuits.
>> There is water in our environment but we protect our electronics pretty
>> well, through both design and procedure. It's warm (~80F) but not
>> particularly humid. We haven't really measured the humidity but I'm
>> reasonably comfortable here.
>>
>> We've had three of our boards fail in different ways:
>>
>> One is an element14 board that boots ok, but reproducibly gives a
>> mysterious error on install from source of Python 2.7.11 (a requirement for
>> us, long ugly story). I've tried to reflash with an SD card and it seems
>> unresponsive whether I hold down the S2 button or not. Damaged SD card
>> socket? Linux does see the SD card's filesystem. It just refuses to boot
>> from it. Maybe a damaged S2 button?
>>
>> Another element14 one seems to overheat. With an IR camera, we've seen
>> the power regulator spike over 60C. It has frozen up on us a couple times
>> if we let it run--lights stop blinking, network goes unresponsive, but does
>> not appear to power off.
>>
>> Another has a Beaglebone logo with the text ''beagleboard.org'
>> silkscreened on it (CircuitCo? It's close but not identical to the logo I
>> see on their board on Adafruit). It shut down mysteriously. W have rebooted
>> a couple times since and seen diminishing uptimes. Most recently it didn't
>> finish rebooting at all.
>>
>> The rest seem to run OK. We have had other failures related to other
>> electronics. These ones seem hardware related, within the BBB. These have
>> all been bought in 2016, I think. We've bought them through Adafruit and
>> Amazon when they were out of stock.
>>
>> A few questions come to mind:
>>
>> 1. we are looking at scaling up at some point. 35%-ish failure rates for
>> microcontrollers over six months are not going to work for us in the long
>> term. *Is this normal for Beaglebone Blacks?* We already handle these
>> units pretty carefully. Maybe we could do more, though it's hard to say
>> what. If we can't get it under control we might want to find another board
>> to standardize on. The BBB has a lot of features we need--we'd prefer not
>> to leave it if possible.
>>
>> 2. The industrial BBBs seem to address higher temperature, though we
>> don't expose ours to extremes of temperature (that they don't generate on
>> their own anyway). *Might the higher quality parts provide higher
>> reliability in general?*
>>
>> 3. *Also, could we expect better customer service with industrial BBBs? *
>>
>> 4. *What could we expect in general with industrial units?*
>>
>>
>> --
>> 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/f8142c48-dc50-4ea9-9fab-2e3ea0ef10dd%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Gerald
>
> ger...@beagleboard.org
> http://beagleboard.org/
> gcol...@emprodesign

Re: [beagleboard] reliability issues with Beaglebone Blacks, various failures

[John Stoner]

I understand that. I'm just trying to work through the issues we're seeing,
and find a way forward for us. It's a trial-and-error process. I chose the
BBB initially because it's a great design that meets a lot of our needs,
known and potential. To go with another design would likely involve
compromises for us.

I could provide more details, though I'd prefer not to do so in a public
forum. I would also need to talk to my management about confidentiality and
stuff.  If you are open to a (hopefully brief) offline conversation, that
would be ideal.

I appreciate any help you can give.

On Thu, Jul 14, 2016 at 5:04 PM Gerald Coley  wrote:

> At this point all I can say is that I did not design these boards for your
> application and therefore I cannot guarantee that it will do what you need
> it to do.
>
> From what little you have said about your application, it sounds like
> industrial versions would be preferable.
>
> I would need to see a detailed schematic of your design to see if there
> were any issues in your application and use of the board as designed..
>
> There can be a variance across different boards depending on what corner
> cases you might be hitting. It could be the ones that are working fine are
> working better than they should be as opposed to the ones that fail not
> working as good as they should be.
>
> Gerald
>
>
> On Thu, Jul 14, 2016 at 4:40 PM, John Stoner  wrote:
>
>> In our lab we have 8-9 Beaglebone Black units. We are using them to
>> control high intensity lights, with circuits in the 7A/9V neighborhood. The
>> circuits are simple, using mosfets to control the high power circuits.
>> There is water in our environment but we protect our electronics pretty
>> well, through both design and procedure. It's warm (~80F) but not
>> particularly humid. We haven't really measured the humidity but I'm
>> reasonably comfortable here.
>>
>> We've had three of our boards fail in different ways:
>>
>> One is an element14 board that boots ok, but reproducibly gives a
>> mysterious error on install from source of Python 2.7.11 (a requirement for
>> us, long ugly story). I've tried to reflash with an SD card and it seems
>> unresponsive whether I hold down the S2 button or not. Damaged SD card
>> socket? Linux does see the SD card's filesystem. It just refuses to boot
>> from it. Maybe a damaged S2 button?
>>
>> Another element14 one seems to overheat. With an IR camera, we've seen
>> the power regulator spike over 60C. It has frozen up on us a couple times
>> if we let it run--lights stop blinking, network goes unresponsive, but does
>> not appear to power off.
>>
>> Another has a Beaglebone logo with the text ''beagleboard.org'
>> silkscreened on it (CircuitCo? It's close but not identical to the logo I
>> see on their board on Adafruit). It shut down mysteriously. W have rebooted
>> a couple times since and seen diminishing uptimes. Most recently it didn't
>> finish rebooting at all.
>>
>> The rest seem to run OK. We have had other failures related to other
>> electronics. These ones seem hardware related, within the BBB. These have
>> all been bought in 2016, I think. We've bought them through Adafruit and
>> Amazon when they were out of stock.
>>
>> A few questions come to mind:
>>
>> 1. we are looking at scaling up at some point. 35%-ish failure rates for
>> microcontrollers over six months are not going to work for us in the long
>> term. *Is this normal for Beaglebone Blacks?* We already handle these
>> units pretty carefully. Maybe we could do more, though it's hard to say
>> what. If we can't get it under control we might want to find another board
>> to standardize on. The BBB has a lot of features we need--we'd prefer not
>> to leave it if possible.
>>
>> 2. The industrial BBBs seem to address higher temperature, though we
>> don't expose ours to extremes of temperature (that they don't generate on
>> their own anyway). *Might the higher quality parts provide higher
>> reliability in general?*
>>
>> 3. *Also, could we expect better customer service with industrial BBBs? *
>>
>> 4. *What could we expect in general with industrial units?*
>>
>>
>> --
>> 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/f8142c48-dc50-4ea9-9fab-2e3ea0ef10dd%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Gerald
>
> ger...@beagleboard.org
> http://beagleboard.org/
> gcol...@emprodesign.com
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received t

Re: [beagleboard] reliability issues with Beaglebone Blacks, various failures

[Gerald Coley]

At this point all I can say is that I did not design these boards for your
application and therefore I cannot guarantee that it will do what you need
it to do.

>From what little you have said about your application, it sounds like
industrial versions would be preferable.

I would need to see a detailed schematic of your design to see if there
were any issues in your application and use of the board as designed..

There can be a variance across different boards depending on what corner
cases you might be hitting. It could be the ones that are working fine are
working better than they should be as opposed to the ones that fail not
working as good as they should be.

Gerald


On Thu, Jul 14, 2016 at 4:40 PM, John Stoner  wrote:

> In our lab we have 8-9 Beaglebone Black units. We are using them to
> control high intensity lights, with circuits in the 7A/9V neighborhood. The
> circuits are simple, using mosfets to control the high power circuits.
> There is water in our environment but we protect our electronics pretty
> well, through both design and procedure. It's warm (~80F) but not
> particularly humid. We haven't really measured the humidity but I'm
> reasonably comfortable here.
>
> We've had three of our boards fail in different ways:
>
> One is an element14 board that boots ok, but reproducibly gives a
> mysterious error on install from source of Python 2.7.11 (a requirement for
> us, long ugly story). I've tried to reflash with an SD card and it seems
> unresponsive whether I hold down the S2 button or not. Damaged SD card
> socket? Linux does see the SD card's filesystem. It just refuses to boot
> from it. Maybe a damaged S2 button?
>
> Another element14 one seems to overheat. With an IR camera, we've seen the
> power regulator spike over 60C. It has frozen up on us a couple times if we
> let it run--lights stop blinking, network goes unresponsive, but does not
> appear to power off.
>
> Another has a Beaglebone logo with the text ''beagleboard.org'
> silkscreened on it (CircuitCo? It's close but not identical to the logo I
> see on their board on Adafruit). It shut down mysteriously. W have rebooted
> a couple times since and seen diminishing uptimes. Most recently it didn't
> finish rebooting at all.
>
> The rest seem to run OK. We have had other failures related to other
> electronics. These ones seem hardware related, within the BBB. These have
> all been bought in 2016, I think. We've bought them through Adafruit and
> Amazon when they were out of stock.
>
> A few questions come to mind:
>
> 1. we are looking at scaling up at some point. 35%-ish failure rates for
> microcontrollers over six months are not going to work for us in the long
> term. *Is this normal for Beaglebone Blacks?* We already handle these
> units pretty carefully. Maybe we could do more, though it's hard to say
> what. If we can't get it under control we might want to find another board
> to standardize on. The BBB has a lot of features we need--we'd prefer not
> to leave it if possible.
>
> 2. The industrial BBBs seem to address higher temperature, though we don't
> expose ours to extremes of temperature (that they don't generate on their
> own anyway). *Might the higher quality parts provide higher reliability
> in general?*
>
> 3. *Also, could we expect better customer service with industrial BBBs? *
>
> 4. *What could we expect in general with industrial units?*
>
>
> --
> 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/f8142c48-dc50-4ea9-9fab-2e3ea0ef10dd%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
gcol...@emprodesign.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/CAHK_S%2BfJZC44PfPO9JLY4DHL_Sh_JoiiqMzzzwBOMqkYaMSnUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Extracting eMMC to image file on microSD card

[Kirk]

Regarding the instructions and the file "beagleboneblack-save-emmc.zip" 
file located here:

http://elinux.org/BeagleBone_Black_Extracting_eMMC_content

I've used it successfully in the past.
Now I tried it on an "Arrow BeagleBone Black Industrial" board and it 
doesn't work.

Should this work?  
Or do I need something new?

Thanks,
Kirk

-- 
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/f6906dcf-0ef7-4d7e-9f52-aa3b20fd599f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] reliability issues with Beaglebone Blacks, various failures

[John Stoner]

In our lab we have 8-9 Beaglebone Black units. We are using them to control 
high intensity lights, with circuits in the 7A/9V neighborhood. The 
circuits are simple, using mosfets to control the high power circuits. 
There is water in our environment but we protect our electronics pretty 
well, through both design and procedure. It's warm (~80F) but not 
particularly humid. We haven't really measured the humidity but I'm 
reasonably comfortable here. 

We've had three of our boards fail in different ways:

One is an element14 board that boots ok, but reproducibly gives a 
mysterious error on install from source of Python 2.7.11 (a requirement for 
us, long ugly story). I've tried to reflash with an SD card and it seems 
unresponsive whether I hold down the S2 button or not. Damaged SD card 
socket? Linux does see the SD card's filesystem. It just refuses to boot 
from it. Maybe a damaged S2 button?

Another element14 one seems to overheat. With an IR camera, we've seen the 
power regulator spike over 60C. It has frozen up on us a couple times if we 
let it run--lights stop blinking, network goes unresponsive, but does not 
appear to power off.

Another has a Beaglebone logo with the text ''beagleboard.org' silkscreened 
on it (CircuitCo? It's close but not identical to the logo I see on their 
board on Adafruit). It shut down mysteriously. W have rebooted a couple 
times since and seen diminishing uptimes. Most recently it didn't finish 
rebooting at all.

The rest seem to run OK. We have had other failures related to other 
electronics. These ones seem hardware related, within the BBB. These have 
all been bought in 2016, I think. We've bought them through Adafruit and 
Amazon when they were out of stock.

A few questions come to mind:

1. we are looking at scaling up at some point. 35%-ish failure rates for 
microcontrollers over six months are not going to work for us in the long 
term. *Is this normal for Beaglebone Blacks?* We already handle these units 
pretty carefully. Maybe we could do more, though it's hard to say what. If 
we can't get it under control we might want to find another board to 
standardize on. The BBB has a lot of features we need--we'd prefer not to 
leave it if possible.

2. The industrial BBBs seem to address higher temperature, though we don't 
expose ours to extremes of temperature (that they don't generate on their 
own anyway). *Might the higher quality parts provide higher reliability in 
general?* 

3. *Also, could we expect better customer service with industrial BBBs? *

4. *What could we expect in general with industrial units?*


-- 
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/f8142c48-dc50-4ea9-9fab-2e3ea0ef10dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Weird Problem using GPIOs on BBB

[William Hermans]

By the way. I'm not familiar with the C++ fstream object. But this person
is not doing any error checking . . .

On Thu, Jul 14, 2016 at 1:48 PM, William Hermans  wrote:

> Ok turns out I do not have to write an example. After a quick google
> search I found a very good simple example on stackoverflow:
> http://stackoverflow.com/questions/21198933/how-to-control-beaglebone-gpio-pins
>
> So. . .  this is a very good example that shows how one would, or could
> wrap the gpio sysfs files. This:
>
> fs.open("/sys/kernel/debug/omap_mux/gpmc_ad4");
>>fs << "7";
>>
>> May be incorrect for current kernel / file system structure, but I can
> tell you what this bit of code is going. It's simply muxing the pin he /
> she want to control in code. 0x7 == pin mux for GPIO mode. So you( we ) can
> either figure how do do this with modern debian images, or "we" could
> simply mu our pins with config-pin( universal IO ) or  device tree overlay.
>
> Personally, since I've been experimenting with Charles' universal-io
> overlays and config-pin recently, and in my spare time. I'm favoring that
> lately. Also, that script is very easily wrapped in code as well. Anyway,
> once the pin it muxed for the correct mode, the rest of that code would(
> should ) simply work.
>
>fs.open("/sys/class/gpio/export");
>>fs << "32";
>>fs.close();
>>
>
>  This is exactly as if you echo "32" into /sys/class/gpio/export. Which
> exports the pin.
>
>fs.open("/sys/class/gpio/gpio32/direction");
>>fs << "out";
>>fs.close();
>
>
> Exactly like echoing "out" into /sys/class/gpio/gpio32/direction. Which
> configures the pin as output.
>
>fs.open("/sys/class/gpio/gpio32/value");
>>fs << "1";
>>fs.close();
>>
>>
> Exactly the same as echoing "1" into /sys/class/gpio/gpio32/value. Which
> makes the pin output, and high.
>
> Any further questions ?
>
> On Thu, Jul 14, 2016 at 11:20 AM, William Hermans 
> wrote:
>
>> OK, I'm still a little busy, but I should have something example wise in
>> a couple hours.
>>
>> On Thu, Jul 14, 2016 at 1:00 AM, William Hermans 
>> wrote:
>>
>>> You only need to toggle gpio ? How fast do you need it to be ? That code
>>> is far to complex, and uses threading, as well as callbacks for some odd
>>> reason. Threaded code can have performance overhead, and callbacks can
>>> cause problems on the stack if you're not careful.
>>>
>>> You would be better off writing your own wrapper code. You could either
>>> wrap the sysfs gpio files directly. Or if you wished you could wrap
>>> config-pin from universal io.
>>>
>>> Anyway, it's getting late here so perhaps tomorrow I'll write up a quick
>>> example, that is far less code than D.R. Molloy's  . . . uh . ..library ?
>>> The thing is, the sysfs directory / file structure is already there and
>>> functional. Why would anyone need to write so much code to encapsulate it ?
>>> *shrug*
>>>
>>> On Wed, Jul 13, 2016 at 10:02 PM, Raul Piper 
>>> wrote:
>>>
 Attached.
 One is the cpp code and other is the bash script.
 cpp code uses the GPIO class from the attached GPIO.7z .


 On Thursday, July 14, 2016 at 9:50:45 AM UTC+5:30, William Hermans
 wrote:
>
> Let's put it this way. No code, no help . . .
>
> On Wed, Jul 13, 2016 at 9:19 PM, William Hermans 
> wrote:
>
>>
>> #code2
>> //create an instance of gpio41
>>  //set direction as OUT
>> //set value as 1
>> usleep(10);
>> //set value 0
>>
>> Output : Toggle doesnt happens
>>
>> Whats this ? This is not code. At best it's comments, and usleep().
>>
>>
>> On Wed, Jul 13, 2016 at 9:02 PM, Raulp  wrote:
>>
>>> OK let em explain a bit more :
>>> #code 1
>>> sudo echo 41 > export
>>> cd gpio41
>>> sudo chmod 666 direction
>>> sudo chmod 666 value
>>> sudo echo out > direction
>>> sudo echo 1 > value
>>> sleep 1
>>> sudo echo 0 > value
>>>
>>> Output : Toggle on the GPIO 41
>>>
>>>
>>> #code2
>>> //create an instance of gpio41
>>>  //set direction as OUT
>>> //set value as 1
>>> usleep(10);
>>> //set value 0
>>>
>>> Output : Toggle doesnt happens
>>>
>>>
>>> Now the output I am referring to is the functioning of the hardware
>>> I have used.(ignore toggling , it happens anyway using the code#2)
>>>
>>>
>>>  Or does your code simply open, and use  the file descriptors
>>> without any error checking what so ever ?
>>> >> I dont use error codes to check , but I have seen in the
>>> oscilloscope that the signal transition is happening according to my 
>>> code.
>>>
>>> -Rp
>>>
>>>
>>> On Wednesday, July 13, 2016 at 8:52:30 PM UTC+5:30, William Hermans
>>> wrote:

 When I try to do the same using a user space C application I dont
> get the expected response.I am running this app as sudo'er and I have
> oscil

Re: [beagleboard] Weird Problem using GPIOs on BBB

[William Hermans]

Ok turns out I do not have to write an example. After a quick google search
I found a very good simple example on stackoverflow:
http://stackoverflow.com/questions/21198933/how-to-control-beaglebone-gpio-pins

So. . .  this is a very good example that shows how one would, or could
wrap the gpio sysfs files. This:

fs.open("/sys/kernel/debug/omap_mux/gpmc_ad4");
>fs << "7";
>
> May be incorrect for current kernel / file system structure, but I can
tell you what this bit of code is going. It's simply muxing the pin he /
she want to control in code. 0x7 == pin mux for GPIO mode. So you( we ) can
either figure how do do this with modern debian images, or "we" could
simply mu our pins with config-pin( universal IO ) or  device tree overlay.

Personally, since I've been experimenting with Charles' universal-io
overlays and config-pin recently, and in my spare time. I'm favoring that
lately. Also, that script is very easily wrapped in code as well. Anyway,
once the pin it muxed for the correct mode, the rest of that code would(
should ) simply work.

   fs.open("/sys/class/gpio/export");
>fs << "32";
>fs.close();
>

 This is exactly as if you echo "32" into /sys/class/gpio/export. Which
exports the pin.

   fs.open("/sys/class/gpio/gpio32/direction");
>fs << "out";
>fs.close();


Exactly like echoing "out" into /sys/class/gpio/gpio32/direction. Which
configures the pin as output.

   fs.open("/sys/class/gpio/gpio32/value");
>fs << "1";
>fs.close();
>
>
Exactly the same as echoing "1" into /sys/class/gpio/gpio32/value. Which
makes the pin output, and high.

Any further questions ?

On Thu, Jul 14, 2016 at 11:20 AM, William Hermans  wrote:

> OK, I'm still a little busy, but I should have something example wise in a
> couple hours.
>
> On Thu, Jul 14, 2016 at 1:00 AM, William Hermans 
> wrote:
>
>> You only need to toggle gpio ? How fast do you need it to be ? That code
>> is far to complex, and uses threading, as well as callbacks for some odd
>> reason. Threaded code can have performance overhead, and callbacks can
>> cause problems on the stack if you're not careful.
>>
>> You would be better off writing your own wrapper code. You could either
>> wrap the sysfs gpio files directly. Or if you wished you could wrap
>> config-pin from universal io.
>>
>> Anyway, it's getting late here so perhaps tomorrow I'll write up a quick
>> example, that is far less code than D.R. Molloy's  . . . uh . ..library ?
>> The thing is, the sysfs directory / file structure is already there and
>> functional. Why would anyone need to write so much code to encapsulate it ?
>> *shrug*
>>
>> On Wed, Jul 13, 2016 at 10:02 PM, Raul Piper 
>> wrote:
>>
>>> Attached.
>>> One is the cpp code and other is the bash script.
>>> cpp code uses the GPIO class from the attached GPIO.7z .
>>>
>>>
>>> On Thursday, July 14, 2016 at 9:50:45 AM UTC+5:30, William Hermans wrote:

 Let's put it this way. No code, no help . . .

 On Wed, Jul 13, 2016 at 9:19 PM, William Hermans 
 wrote:

>
> #code2
> //create an instance of gpio41
>  //set direction as OUT
> //set value as 1
> usleep(10);
> //set value 0
>
> Output : Toggle doesnt happens
>
> Whats this ? This is not code. At best it's comments, and usleep().
>
>
> On Wed, Jul 13, 2016 at 9:02 PM, Raulp  wrote:
>
>> OK let em explain a bit more :
>> #code 1
>> sudo echo 41 > export
>> cd gpio41
>> sudo chmod 666 direction
>> sudo chmod 666 value
>> sudo echo out > direction
>> sudo echo 1 > value
>> sleep 1
>> sudo echo 0 > value
>>
>> Output : Toggle on the GPIO 41
>>
>>
>> #code2
>> //create an instance of gpio41
>>  //set direction as OUT
>> //set value as 1
>> usleep(10);
>> //set value 0
>>
>> Output : Toggle doesnt happens
>>
>>
>> Now the output I am referring to is the functioning of the hardware I
>> have used.(ignore toggling , it happens anyway using the code#2)
>>
>>
>>  Or does your code simply open, and use  the file descriptors without
>> any error checking what so ever ?
>> >> I dont use error codes to check , but I have seen in the
>> oscilloscope that the signal transition is happening according to my 
>> code.
>>
>> -Rp
>>
>>
>> On Wednesday, July 13, 2016 at 8:52:30 PM UTC+5:30, William Hermans
>> wrote:
>>>
>>> When I try to do the same using a user space C application I dont
 get the expected response.I am running this app as sudo'er and I have
 oscilloscope'd the timings of HIGH/LOW levels of the GPIOs and 
 compared it
 with that of the manually writing procedure of GPIOS. The waveform and 
 the
 timing diagrams almost matches (95%)

>>>
>>> I'm not exactly sure what you saying here . . . However, in code are
>>> you actually checking for 

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[William Hermans]

>
> But, you mentioned something else, that got me thinking: after backing up
> the sd card and writing a new image to the sd-card, it failed first pass
> (no booting BBG whatsever I tried). Flashed the image again, and then my
> BBG booted. So now I start to suspect my sd card actually. Time for new sd
> card to make sure. I'll be watching the power supply as well; I'm using a
> 6600 mAh Lipoly with an Adafruit 500mA Power charge and adapter (if
> interested: first glimpse of my project page here). I'm not 100% convinced
> on the power supply as well with occasional drops during booting. So maybe
> I'l go for micro-usb power supply for "mission critical" changes to the
> image to ensure correct upgrades and only use the battery when testing the
> entire setup with stepper drivers and motors. T
> Thanks for your suggestions.
>

Ok, so here is one thing to consider. After writing a new image to sdcard,
and inserting into the beaglebone. Keep in mind that if it's been sitting a
while. You may have to press reset a time or two. I believe I remember
Gerald saying that sometimes if the board power supply caps are completely
without charge. There may be the occasional glitch. I've also experienced
this, and  what I do is completely disconnect the board from everything (
especially serial debug ), and then try again. A good indication that
you're having a power glitch is when the power LED either does not come on,
or come on then goes off again.

Also be aware that if you're using a battery, and you need USB for
anything. Once PWR_GOOD( 5v input ) goes away you're going to need to
shutdown until the power comes back, or reboot in case of a quick power
line glitch.
 The Debian package "acpid" will shut the board down immediately( but
cleanly ) from either a PWR_GOOD, or PWR_BTN press interrupt from the PMIC
. . . They both trigger the same irq.

On Thu, Jul 14, 2016 at 12:19 PM, Joseph Heller 
wrote:

>
>
> On Thursday, July 14, 2016 at 8:18:37 PM UTC+2, William Hermans wrote:
>>
>> Well, I used apt-get install. I traced back the command entered when
>>> examining .bash_history:
>>> *# sudo apt-get install linux-image-4.1.15-bone-rt-r18 *
>>
>>
>> So you say it just failed, and when you examined the second stage
>> uEnv.txt file the uname_r variable had not changed to reflect the upgrade ?
>> What kind of power supply are you using, and how  much do you have running
>> on the board ?
>>
>> Anyway, using APT is the correct way to install a kernel on Debian.
>> Period. Not just for this hardware, but in general. So I would say that you
>> just experienced a glitch that is not usually that happens when upgrading.
>> But when I tell you that I've not experienced this myself in 3.5 years of
>> using this board . . . that's not entirely accurate. I've experienced a few
>> glitches here, and there. I just never dug into what happened. Instead I
>> just tried again, and it worked . . . So maybe nothing is 100% perfect, but
>> it does work if you keep at it.
>>
>> Heres a tip though. Whenever flashing a new image, or doing anythign like
>> upgrading the kernel. Disconnect, and / or turn off everything non
>> essential. Peripheral wise. ethernet, and eMMC should be fine, but passed
>> that turn every thing else off.
>>
>
> Thanks William,
>
> I dod not expext a failre either doing apt upgrade / installs of kernels
> either. Not sure about the uEnv.txt. My /boot directory shows:
>
> bash-4.3$ ls -la
> total 33192
> drwxr-xr-x.  4 root root4096 Jul 11 18:04 .
> drwxr-xr-x. 21 root root4096 Jan 24 23:38 ..
> -rw-r--r--.  1 root root  134233 Jan 12  2016 config-4.1.15-bone-rt-r18
> -rw-r--r--.  1 root root  154972 Jan 21 21:22 config-4.1.15-ti-rt-r43
> drwxr-xr-x.  4 root root4096 Jul 11 18:03 dtbs
> -rw-r--r--.  1 root root 4245828 Jul 11 18:04 initrd.img-4.1.15-bone-rt-r18
> -rw-r--r--.  1 root root 4177318 Jun 20 12:12 initrd.img-4.1.15-ti-rt-r43
> -rw-r--r--.  1 root root 4096241 Jun 15 19:26
> initrd.img-4.1.15-ti-rt-r43.old-dkms
> -rw-r--r--.  1 root root 492 Jan 25 00:41 SOC.sh
> -rw-r--r--.  1 root root 3034732 Jan 12  2016 System.map-4.1.15-bone-rt-r18
> -rw-r--r--.  1 root root 3371694 Jan 21 21:22 System.map-4.1.15-ti-rt-r43
> drwxr-xr-x.  2 root root4096 Jan 24 23:38 uboot
> -rw-r--r--.  1 root root1652 Jul 11 18:04 uEnv.txt
> -rwxr-xr-x.  1 root root 6932296 Jan 12  2016 vmlinuz-4.1.15-bone-rt-r18
> -rwxr-xr-x.  1 root root 7800752 Jan 21 21:22 vmlinuz-4.1.15-ti-rt-r43
>
> So uEnv.txt seems to be updated at the time by the apt-get install, and
> both the old and new kernel are available. Start of uEnv.txt is:
>
> bash-4.3$ sudo head uEnv.txt
> #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
>
> uname_r=4.1.15-bone-rt-r18
> #uuid=
> #dtb=
>
> ##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..)
>
> ##BeagleBone Black: HDMI (Audio/Video) disabled:
> #dtb=am335x-boneblack-emmc-overlay.dtb
>
>
> But, you mentioned something else, that got me thinking: aft

Re: [beagleboard] beaglebone white doesn't work when powered from the barrel connector

[evilwulfie]

Time to grab a volt ohm meter and do some troubleshooting.


On 7/14/2016 10:31 AM, scma...@gmail.com wrote:
> hello everybody from a newbie,
>
> well, happily, my beaglebone white works just fine when connected to
> my pc via usb. The power led is on and everything is fine, therefore 
> i suppose that my bb board is still functional.
> The case is though that i am going to need to provide external power
> supply because i intend to connect my bb (through it's header pins)
> with an external circuit and thus power from usb is not enough. While
> trying to do so i face a power problem (i guess).
> Let me explain you in short what's going on. As i said before the
> board is working fine when powered from usb (and thus my pc). The
> problem is when i power it from external power supply.
> In specific when i supply 5V through a power supply the result is that
> the power led doesn't turn on and the board is not functional.
>
> So, do you have any suggestions about what is wrong? Let me emphasize
> that in the past my bb was working just fine when powered from ac.
>
> Thanks for any help in advance!
> -- 
> 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/3ad1b46b-4a15-4338-844f-ef688da62c85%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.


-- 
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/c788d4f2-e0ff-642e-31c6-eead28e56d85%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] beaglebone white doesn't work when powered from the barrel connector

[scmanop]

hello everybody from a newbie,

well, happily, my beaglebone white works just fine when connected to my pc 
via usb. The power led is on and everything is fine, therefore  i suppose 
that my bb board is still functional.
The case is though that i am going to need to provide external power supply 
because i intend to connect my bb (through it's header pins) with an 
external circuit and thus power from usb is not enough. While trying to do 
so i face a power problem (i guess).
Let me explain you in short what's going on. As i said before the board is 
working fine when powered from usb (and thus my pc). The problem is when i 
power it from external power supply.
In specific when i supply 5V through a power supply the result is that the 
power led doesn't turn on and the board is not functional.

So, do you have any suggestions about what is wrong? Let me emphasize that 
in the past my bb was working just fine when powered from ac.

Thanks for any help in advance!

-- 
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/3ad1b46b-4a15-4338-844f-ef688da62c85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BeagleBoard.org Latest Firmware Images - suggest pointing to 8.3 image rather than 8.4

[Stephane Charette]

On Wednesday, July 13, 2016 at 8:21:47 AM UTC-7, Jeff Albrecht wrote:

> ...
> In my thread "jessie moved my WiFi cheese" 
>  
> I document that 8.4 and 8.5 images don't work for wifi setup via connmanctl 
> and that 8.3 does.
>
>
I have a page I wrote up where I document how I got everything working with 
the Debian 8.5 image.  I'm not sure this is what you're asking about, but 
in case it is useful: 
 https://www.ccoderun.ca/programming/2016-06-29_BBGW/index.html

Stéphane

-- 
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/e755ab1b-02d6-4f0d-8261-785281a281e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

On Thursday, July 14, 2016 at 8:18:37 PM UTC+2, William Hermans wrote:
>
> Well, I used apt-get install. I traced back the command entered when 
>> examining .bash_history:
>> *# sudo apt-get install linux-image-4.1.15-bone-rt-r18 *
>
>
> So you say it just failed, and when you examined the second stage uEnv.txt 
> file the uname_r variable had not changed to reflect the upgrade ? What 
> kind of power supply are you using, and how  much do you have running on 
> the board ?
>
> Anyway, using APT is the correct way to install a kernel on Debian. 
> Period. Not just for this hardware, but in general. So I would say that you 
> just experienced a glitch that is not usually that happens when upgrading. 
> But when I tell you that I've not experienced this myself in 3.5 years of 
> using this board . . . that's not entirely accurate. I've experienced a few 
> glitches here, and there. I just never dug into what happened. Instead I 
> just tried again, and it worked . . . So maybe nothing is 100% perfect, but 
> it does work if you keep at it.
>
> Heres a tip though. Whenever flashing a new image, or doing anythign like 
> upgrading the kernel. Disconnect, and / or turn off everything non 
> essential. Peripheral wise. ethernet, and eMMC should be fine, but passed 
> that turn every thing else off.
>

Thanks William, 

I dod not expext a failre either doing apt upgrade / installs of kernels 
either. Not sure about the uEnv.txt. My /boot directory shows:

bash-4.3$ ls -la
total 33192
drwxr-xr-x.  4 root root4096 Jul 11 18:04 .
drwxr-xr-x. 21 root root4096 Jan 24 23:38 ..
-rw-r--r--.  1 root root  134233 Jan 12  2016 config-4.1.15-bone-rt-r18
-rw-r--r--.  1 root root  154972 Jan 21 21:22 config-4.1.15-ti-rt-r43
drwxr-xr-x.  4 root root4096 Jul 11 18:03 dtbs
-rw-r--r--.  1 root root 4245828 Jul 11 18:04 initrd.img-4.1.15-bone-rt-r18
-rw-r--r--.  1 root root 4177318 Jun 20 12:12 initrd.img-4.1.15-ti-rt-r43
-rw-r--r--.  1 root root 4096241 Jun 15 19:26 
initrd.img-4.1.15-ti-rt-r43.old-dkms
-rw-r--r--.  1 root root 492 Jan 25 00:41 SOC.sh
-rw-r--r--.  1 root root 3034732 Jan 12  2016 System.map-4.1.15-bone-rt-r18
-rw-r--r--.  1 root root 3371694 Jan 21 21:22 System.map-4.1.15-ti-rt-r43
drwxr-xr-x.  2 root root4096 Jan 24 23:38 uboot
-rw-r--r--.  1 root root1652 Jul 11 18:04 uEnv.txt
-rwxr-xr-x.  1 root root 6932296 Jan 12  2016 vmlinuz-4.1.15-bone-rt-r18
-rwxr-xr-x.  1 root root 7800752 Jan 21 21:22 vmlinuz-4.1.15-ti-rt-r43
 
So uEnv.txt seems to be updated at the time by the apt-get install, and 
both the old and new kernel are available. Start of uEnv.txt is:

bash-4.3$ sudo head uEnv.txt 
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.1.15-bone-rt-r18
#uuid=
#dtb=

##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..)

##BeagleBone Black: HDMI (Audio/Video) disabled:
#dtb=am335x-boneblack-emmc-overlay.dtb


But, you mentioned something else, that got me thinking: after backing up 
the sd card and writing a new image to the sd-card, it failed first pass 
(no booting BBG whatsever I tried). Flashed the image again, and then my 
BBG booted. So now I start to suspect my sd card actually. Time for new sd 
card to make sure. I'll be watching the power supply as well; I'm using a 
6600 mAh Lipoly with an Adafruit 500mA Power charge and adapter (if 
interested: first glimpse of my project page here 
). I'm not 100% 
convinced on the power supply as well with occasional drops during booting. 
So maybe I'l go for micro-usb power supply for "mission critical" changes 
to the image to ensure correct upgrades and only use the battery when 
testing the entire setup with stepper drivers and motors. T
Thanks for your suggestions. 

Will check john3909's remarks later as well and see if I get the PRU's 
working with uio/prussdrv.h and the selected kernel. 

-- 
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/03ba76ad-1d89-4c0d-877c-23f52b6dcdc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Weird Problem using GPIOs on BBB

[William Hermans]

OK, I'm still a little busy, but I should have something example wise in a
couple hours.

On Thu, Jul 14, 2016 at 1:00 AM, William Hermans  wrote:

> You only need to toggle gpio ? How fast do you need it to be ? That code
> is far to complex, and uses threading, as well as callbacks for some odd
> reason. Threaded code can have performance overhead, and callbacks can
> cause problems on the stack if you're not careful.
>
> You would be better off writing your own wrapper code. You could either
> wrap the sysfs gpio files directly. Or if you wished you could wrap
> config-pin from universal io.
>
> Anyway, it's getting late here so perhaps tomorrow I'll write up a quick
> example, that is far less code than D.R. Molloy's  . . . uh . ..library ?
> The thing is, the sysfs directory / file structure is already there and
> functional. Why would anyone need to write so much code to encapsulate it ?
> *shrug*
>
> On Wed, Jul 13, 2016 at 10:02 PM, Raul Piper 
> wrote:
>
>> Attached.
>> One is the cpp code and other is the bash script.
>> cpp code uses the GPIO class from the attached GPIO.7z .
>>
>>
>> On Thursday, July 14, 2016 at 9:50:45 AM UTC+5:30, William Hermans wrote:
>>>
>>> Let's put it this way. No code, no help . . .
>>>
>>> On Wed, Jul 13, 2016 at 9:19 PM, William Hermans 
>>> wrote:
>>>

 #code2
 //create an instance of gpio41
  //set direction as OUT
 //set value as 1
 usleep(10);
 //set value 0

 Output : Toggle doesnt happens

 Whats this ? This is not code. At best it's comments, and usleep().


 On Wed, Jul 13, 2016 at 9:02 PM, Raulp  wrote:

> OK let em explain a bit more :
> #code 1
> sudo echo 41 > export
> cd gpio41
> sudo chmod 666 direction
> sudo chmod 666 value
> sudo echo out > direction
> sudo echo 1 > value
> sleep 1
> sudo echo 0 > value
>
> Output : Toggle on the GPIO 41
>
>
> #code2
> //create an instance of gpio41
>  //set direction as OUT
> //set value as 1
> usleep(10);
> //set value 0
>
> Output : Toggle doesnt happens
>
>
> Now the output I am referring to is the functioning of the hardware I
> have used.(ignore toggling , it happens anyway using the code#2)
>
>
>  Or does your code simply open, and use  the file descriptors without
> any error checking what so ever ?
> >> I dont use error codes to check , but I have seen in the
> oscilloscope that the signal transition is happening according to my code.
>
> -Rp
>
>
> On Wednesday, July 13, 2016 at 8:52:30 PM UTC+5:30, William Hermans
> wrote:
>>
>> When I try to do the same using a user space C application I dont get
>>> the expected response.I am running this app as sudo'er and I have
>>> oscilloscope'd the timings of HIGH/LOW levels of the GPIOs and compared 
>>> it
>>> with that of the manually writing procedure of GPIOS. The waveform and 
>>> the
>>> timing diagrams almost matches (95%)
>>>
>>
>> I'm not exactly sure what you saying here . . . However, in code are
>> you actually checking for errors, and error codes. Or does your code 
>> simply
>> open, and use  the file descriptors without any error checking what so 
>> ever
>> ?
>>
>> Seeing the code would probably help a lot.
>>
>> On Wed, Jul 13, 2016 at 2:41 AM, Raulp  wrote:
>>
>>> I have interfaced a hardware using the 5 Gpios on BBB.I can talk to
>>> this device using GPIOs by manually (echoing 0 and 1 to the GPIOS) 
>>> writing
>>> to it in the sys/class/gpio directory by first exporting the Gpios and
>>> configuring their directions and value.It works perfectly fine.
>>> But,
>>> When I try to do the same using a user space C application I dont
>>> get the expected response.I am running this app as sudo'er and I have
>>> oscilloscope'd the timings of HIGH/LOW levels of the GPIOs and compared 
>>> it
>>> with that of the manually writing procedure of GPIOS. The waveform and 
>>> the
>>> timing diagrams almost matches (95%)
>>> So,
>>> What could mysteriously be missing here.?I can go deep into
>>> analyzing the wave-forms and timing diagrams as well if there is an 
>>> issue
>>> in the timings of the Signals.
>>> Please advice.Thanks in advance !
>>> -Rp
>>>
>>> --
>>> 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/cb65b710-203e-4579-8c08-e2b817dc7a03%40googlegroups.com
>>> 

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[William Hermans]

>
> Well, I used apt-get install. I traced back the command entered when
> examining .bash_history:
> *# sudo apt-get install linux-image-4.1.15-bone-rt-r18 *


So you say it just failed, and when you examined the second stage uEnv.txt
file the uname_r variable had not changed to reflect the upgrade ? What
kind of power supply are you using, and how  much do you have running on
the board ?

Anyway, using APT is the correct way to install a kernel on Debian. Period.
Not just for this hardware, but in general. So I would say that you just
experienced a glitch that is not usually that happens when upgrading. But
when I tell you that I've not experienced this myself in 3.5 years of using
this board . . . that's not entirely accurate. I've experienced a few
glitches here, and there. I just never dug into what happened. Instead I
just tried again, and it worked . . . So maybe nothing is 100% perfect, but
it does work if you keep at it.

Heres a tip though. Whenever flashing a new image, or doing anythign like
upgrading the kernel. Disconnect, and / or turn off everything non
essential. Peripheral wise. ethernet, and eMMC should be fine, but passed
that turn every thing else off.

-- 
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/CALHSORq-r6xLs5BKOc%3D7oniAG9R-OmPmKW-oChZUnmLN39FnGQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[John Syne]

Overlay for Remoteproc doesn’t work so you must follow Roberts instructions to 
select between rproc or uio:

You can swap between rproc and uio for the pruss...

while, uio can be loaded as an overlay, rproc was failing, so we need
to use the dtb-rebuilder...

Step 1:

upgrade to r34 and reboot:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#4.4.x-ti 


Step 2:

Install dtb-rebuilder:

git clone -b 4.4-ti https://github.com/RobertCNelson/dtb-rebuilder 

dtb-4.4-ti --depth=1
cd ./dtb-4.4-ti/

Step 3: (rproc)

Edit your device tree:

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-bonegreen.dts#L16-L22
 


nano src/arm/am335x-bonegreen.dts

Change:
/* #include "am33xx-pruss-rproc.dtsi" */ -> #include "am33xx-pruss-rproc.dtsi"
make ; sudo make install

set blacklist:

cat /etc/modprobe.d/pruss-blacklist.conf

blacklist uio_pruss

and reboot..

Regards,
John




> On Jul 13, 2016, at 1:18 PM, William Hermans  wrote:
> 
> By the way, TI's most recent kernels are purportedly supposed to use either 
> remoteproc, or uio_pruss. I say purportedly because I have not personally 
> experimented with that yet, but Robert made a post not long ago about this. 
> So it sounds like right off the bat, all you need to do is load the PRU 
> overlay file to get uio_pruss working. Or a slightly more involved process to 
> get remoteproc working.
> 
> 
> 
> On Wed, Jul 13, 2016 at 1:13 PM, William Hermans  > wrote:
> 2) The "ti" version seems to be dropped starting the 4.5.0 series kernel, so 
> I guess remoteproc was dropped in the end with newer kernels altogether?
> 
> No. That kernel is probably straight out of mainline. Which means it hasn't 
> had either the *bone* or *TI* patchset applied to it yet.
> 
> On Wed, Jul 13, 2016 at 1:10 PM, William Hermans  > wrote:
> 1) is it possible to install another kernel image, and how is this done 
> exactly? Unfortunately I managed to get my image on the sd-card unbootable 
> when installing another kernel (bone-kernel instead of ti-kernel). I guess 
> that uEnv.txt is not correctly updated when switching kernels. Actually I 
> forgot to install the kernel headers in the same pass, and this lead to a 
> series of upgrade errors maybe causing the booting issue. I might be able to 
> restore my image somehow if possible, although I still can use the data by 
> just inserting the SD card in my PC.
> 
> The traditional Debian way, you use APT. Something like . . .
> 
> william@beaglebone:~/dev$ apt-cache search linux-image | grep 4.1.15-bone
> linux-image-4.1.15-bone-rt-r17 - Linux kernel, version 4.1.15-bone-rt-r17
> linux-image-4.1.15-bone-rt-r18 - Linux kernel, version 4.1.15-bone-rt-r18
> linux-image-4.1.15-bone17 - Linux kernel, version 4.1.15-bone17
> linux-image-4.1.15-bone18 - Linux kernel, version 4.1.15-bone18
> 
> william@beaglebone:~/dev$ sudo apt-get install linux-image-4.1.15-bone-rt-r18
> Also keep in mind that you do not need to pipe the output to grep when 
> searching for a suitable linux-image. But if you do not you'll be in store 
> for a hell of a lot more 'noise'. ALso in the context of using grep, there 
> are many other kernels out there so perhaps you want to apt-cache search 
> linux-image |grep 4 (or something ) to get a broader idea of what all is out 
> there.
> 
> I guess that uEnv.txt is not correctly updated when switching kernels.
> 
> That's a false assumption. Using APT to upgrade kernels has always worked 
> great for me. Trust me also when I say I have literally tested every other 
> kernel version( at least ) in the last 3.5 years. For debian. So I do have 
> plenty of experience . . .
> 
> 
> On Wed, Jul 13, 2016 at 12:53 PM, Joseph Heller  > wrote:
> 
> Ok guys, here is my first question on how to change to another kernel 
> version. I'm using a BBG for my omni-robot project, and started opting for 
> using the PRU's to generate accurate variable frequency PWM signals for my 
> stepper motors (my c code was still showing the occasional delays in 
> frequency pulses due to the non-realtime nature of the kernel). At the time, 
> I was using linux-image-4.1.15-bone-rt-r18. I'm not yet convinced to use the 
> remoteproc driver to handle the PRU's, and would like to use the uio driver 
> instead. It boils down to two questions in the end: 
> 
> 1) is it possible to install another kernel image, and how is this done 
> exactly? Unfortunately I managed to get my image on the sd-card unbootable 
> when installing another kernel (bone-kernel instead of ti-kernel). I guess 
> that uEnv.txt is not correctly updated when switching kernels. Actually I 
> forgot to install the kernel headers in the same pass, and this lead to a 
> series o

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

On Wednesday, July 13, 2016 at 10:19:11 PM UTC+2, William Hermans wrote:
>
> By the way, TI's most recent kernels are purportedly supposed to use 
> either remoteproc, or uio_pruss. I say purportedly because I have not 
> personally experimented with that yet, but Robert made a post not long ago 
> about this. So it sounds like right off the bat, all you need to do is load 
> the PRU overlay file to get uio_pruss working. Or a slightly more involved 
> process to get remoteproc working.
>

Thanks for pointing that out! I think you are referring to this post I 
think: 
http://beagleboard.org/Community/Forums?place=msg%2Fbeagleboard%2Fl59Dx8ygxNg%2FGvIzOJSzDAAJ
 
? Need to check in detail what Robert mentioned in the post. I would have 
no problem reporting back if this leads to success, which might be 
something to materialize somewhere in the wiki and would be glad to help. I 
guess I was looking in the wrong spot trying to find info on the kernel 
(e.g. here  and the wiki and getting 
started guide referred in it), did not realize I had to search in the 
Forum. 

-- 
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/8d99efed-6eca-4689-bee4-3972df472c7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

On Wednesday, July 13, 2016 at 10:11:56 PM UTC+2, William Hermans wrote:
>
> The traditional Debian way, you use APT. Something like . . .
>
> *william@beaglebone:~/dev$ apt-cache search linux-image | grep 4.1.15-bone*
> linux-image-4.1.15-bone-rt-r17 - Linux kernel, version 4.1.15-bone-rt-r17
> linux-image-4.1.15-bone-rt-r18 - Linux kernel, version 4.1.15-bone-rt-r18
> linux-image-4.1.15-bone17 - Linux kernel, version 4.1.15-bone17
> linux-image-4.1.15-bone18 - Linux kernel, version 4.1.15-bone18
>
> *william@beaglebone:~/dev$ sudo apt-get install 
> linux-image-4.1.15-bone-rt-r18*
>

Well, I used apt-get install. I traced back the command entered when 
examining .bash_history:
*# sudo apt-get install linux-image-4.1.15-bone-rt-r18 *

-- 
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/c473954b-b97c-45ed-8a1d-a7347b23dc7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Cloud9 autocomplete broken in 8.4 images for Beaglebone Black

[mfaberm]

Hello,

I installed the latest images (8.4) for my Beaglebone Black and am 
programming javascript in Cloud9, but autocomplete and linting is not 
working. In an older image (8.3) this was working.

See also the tread at Cloud9 forum: 
https://community.c9.io/t/no-autocomplete-nor-input-menu/7312

At the Cloud9 forum they say it could be a bug in Beaglebone.

Thnks

-- 
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/93898e62-4481-437e-ac50-53bb3ff0af91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Python GPIO Error

[msriram1105]

I am using Beaglebone Black to run ultrasonic sensor. I am using the 
following code.

#!/usr/bin/env python 
 
import BBIO.GPIO as GPIO# Import GPIO library 
import time# Import time library 
GPIO.setmode(GPIO.BCM) # Set GPIO pin numbering  
 
TRIG = 23  # Associate pin 23 to TRIG 
ECHO = 24  # Associate pin 24 to ECHO 
 
print "Distance measurement in progress" 
 
GPIO.setup(TRIG, GPIO.OUT)  # Set pin as GPIO out 
GPIO.setup(ECHO, GPIO.IN)   # Set pin as GPIO in 
 
while True: 
 
GPIO.output(TRIG, False) # Set TRIG as LOW 
print "Waitng For Sensor To Settle" 
time.sleep(2)# Delay of 2 seconds 
 
GPIO.output(TRIG, True)  # Set TRIG as HIGH 
time.sleep(0.1)  # Delay of 0.1 seconds 
GPIO.output(TRIG, False) # Set TRIG as LOW 
 
while GPIO.input(ECHO) == 0:   # Check whether the ECHO is LOW 
pulse_start = time.time()  # Saves the last known time of 
LOW pulse 
 
while GPIO.input(ECHO) == 1:   # Check whether the ECHO is HIGH 
 
pulse_end = time.time()# Saves the last known time of 
HIGH pulse  
 
pulse_duration = pulse_end - pulse_start # Get pulse duration to a 
variable 
 
distance = pulse_duration * 17150# Multiply pulse duration by 
17150 to get distance 
distance = round(distance, 2)# Round to two decimal points 
 
if distance > 2 and distance < 400:  # Check whether the distance 
is within range 
print "Distance:",distance - 0.5,"cm"  # Print distance with 0.5 cm 
calibration 
else: 
print "Out Of Range"   # display out of range

While I try to implement it using the Beaglebone Black I am getting the 
following error.
"Traceback (most recent call last):
  File "ult.py", line 5, in 
import BBIO.GPIO as GPIO# Import GPIO library
ImportError: No module named BBIO.GPIO"

I need help.

-- 
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/a5ca191e-bcac-49c2-a45f-b847af24b2a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] RE: [Driver Installer Issue]Beagleboard Inquire from Keystone Taiwan

[william.chang]

Hi Both,

 

If there is any comment or new status for this issue?

Many Thanks.

Thanks and Best Regards,

William Chang(Chinese : 張世維)


===



KeyStone Semiconductor Corp. 

Chinese : 成一電子股份有限公司
Website：http://www.keystonesemi.com
http://www.keystonesemi.com/> 

2F, No. 62, Park Ave. 2, Science-Based Industrial Park, Hsinchu, Taiwan 300,
R.O.C

General Manager Office.

 TEL：+886-3-6662756 ext. 1017 

FAX：+886-3-6662758

Mobile：+886-933-201-891

Skype：ks_william.chang




From: william.chang [mailto:william.ch...@keystonesemi.com] 
Sent: Wednesday, July 06, 2016 8:08 AM
To: 'beagleboard@googlegroups.com' ; 'Jason
Kridner' 
Cc: 'Albert Tseng' ; 'Liz.Keng 耿瑞卿'
; 'Chengwei.Wu伍政緯'
; 'hsiu' ;
'ethan.huang' ; 'vincent.chen'

Subject: [Driver Installer Issue]Beagleboard Inquire from Keystone Taiwan

 

Hi All,

 

Hope the mail finds you well.

 

First, thanks for Jason's kindly help. Following your guide, our colleagues
had successfully changed the image within the driver installer of Beagle
Bone.

 

However, we encounter an issue related to 64 bit Windows OS with some
computer, but not everyone. The installer will prompt the error message,
"dpinist.exe can not be correctly started(0xc07b)", and then the
isntaller will be terminated.

 

But, the same computer with the same Windows OS will not ecnouter such issue
if we use your default driver installer. Your default installer can be
installed successfully without any issue.

 

Would you please let us know what will casue such issue? Is there any
process needed to be handled when we rebuild the installer?

 

 

Many Thanks.

Thanks and Best Regards,

William Chang(Chinese : 張世維)


===

 

KeyStone Semiconductor Corp. 

Chinese : 成一電子股份有限公司
Website：http://www.keystonesemi.com
http://www.keystonesemi.com/> 

2F, No. 62, Park Ave. 2, Science-Based Industrial Park, Hsinchu, Taiwan 300,
R.O.C

General Manager Office.

 TEL：+886-3-6662756 ext. 1017 

FAX：+886-3-6662758

Mobile：+886-933-201-891

Skype：ks_william.chang




 

-- 
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/003d01d1dd90%24a06f1a80%24e14d4f80%24%40keystonesemi.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BeagleBoneBlack+mikrobus_cape+GSM2

[renzo . tomaselli]

Hi, since a few weeks I got my BBB plus a Mikrobus cape (4 slots) plus a 
MikroElektronika GSM2 modem.
I was able to run it using minicom only: getting phone calls ans sending 
sms.
I tried to manage it from java comm packages (jSSC, purejavacomm, etc.).
No way and no errors: I simply get back the command I just sent out, even a 
simple "AT".
No matter echo setting, it looks a kind of shortcut.
Thanks for any help, I'm running short of ideas.

Renzo

-- 
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/7ac8bbe1-3c8c-4a06-938f-0bcc449ed941%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Installing ARch Linux on BBB rev C. can't find boot/zImage

[Jelle Spijker]

Hi William,

I got it working. It seemed that I forgot that my e2fsprogs version was 
greater then 1.43.

As mentioned in the guide (do'h bangs head against table)
Create the ext4 filesystem:
   
   1. For e2fsprogs < 1.43:
   
   mkfs.ext4 /dev/sdX1
   
   2. For e2fsprogs >= 1.43:
   
   mkfs.ext4 -O ^metadata_csum,^64bit /dev/sdX1
   
   
by executing:

mkfs.ext4 -O ^metadata_csum,^64bit /dev/sdX1


I now got Arch linux up and running.
I wanted to thank you for your quick response. 

best regards,
Jelle

Op donderdag 14 juli 2016 09:48:37 UTC+2 schreef Jelle Spijker:
>
> Damn.. You have been busy whilst I was away.
>
> The uEnv mentioned in my previous post was one when I tried to mount the 
> boot as a fat 16 image, so in that setup there where two partitions. The 
> uEnv that I have currently and that is the default Arch Linux Uenv only has 
> one line:
>
> 
> 
> 
> 
> 
>
>
> optargs=coherent_pool=1M
>
>
>
> Thank you. I will try your suggestions.
>
> Op woensdag 13 juli 2016 23:12:28 UTC+2 schreef William Hermans:
>>
>> Correction:
>>
>> loaduimage=if ext4load mmc 0:2 ${loadaddr} /boot/zImage; then setenv 
>> mmcdev 0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv mmcroot 
>> /dev/mmcblk1p2 rw; fi; ext4load mmc 1:2 ${loadaddr} /boot/zImage; fi
>> *should be:*
>> loaduimage=if ext4load mmc 0:1 ${loadaddr} /boot/zImage; then setenv 
>> mmcdev 0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv mmcroot 
>> /dev/mmcblk1p*1* rw; fi; ext4load mmc 1:*1 *${loadaddr} /boot/zImage; fi
>>
>> On Wed, Jul 13, 2016 at 2:10 PM, William Hermans  
>> wrote:
>>
>>> So . . .
>>>
>>> mmcroot=/dev/mmcblk0p2 rw
>>> *should be:*
>>> mmcroot=/dev/mmcblk0p*1* rw
>>>
>>> loadfdt=ext4load mmc ${mmcdev}:2 ${fdtaddr} /boot/dtbs/${fdtfile}
>>> *should be:*
>>> loadfdt=ext4load mmc ${mmcdev}:*1* ${fdtaddr} /boot/dtbs/${fdtfile}
>>>
>>> loaduimage=if ext4load mmc 0:2 ${loadaddr} /boot/zImage; then setenv 
>>> mmcdev 0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv mmcroot 
>>> /dev/mmcblk1p2 rw; fi; ext4load mmc 1:2 ${loadaddr} /boot/zImage; fi
>>> *should be:*
>>> should be:loaduimage=if ext4load mmc 0:1 ${loadaddr} /boot/zImage; then 
>>> setenv mmcdev 0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv 
>>> mmcroot /dev/mmcblk1p*1* rw; fi; ext4load mmc 1:*1 *${loadaddr} 
>>> /boot/zImage; fi
>>>
>>> On Wed, Jul 13, 2016 at 1:56 PM, William Hermans  
>>> wrote:
>>>
 By the way, ${uname_r} is defined in the second stage uEnv.txt file 
 that comes with recent debian images. But It does not look as though the 
 people at ARCH uses this file structure. So while these paths should be 
 similar, they're going to be slightly different for you. But if you look 
 at 
 the uEnv,txt files closely, you should be able to figure out where your 
 file is wrong, and how to correct it. 

 On Wed, Jul 13, 2016 at 1:52 PM, William Hermans  
 wrote:

> Here, here is a stage one uEnv.txt file fro the latest official debian 
> image. Note the differences in disk / partition assingment. But otherwise 
> this uses the same layout for what I can tell as those ARCH instructions 
> imply.
>
> william@beaglebone:~/dev$ cat /uEnv.txt
> ##These are needed to be compliant with Angstrom's 2013.06.20 u-boot.
>
> loadaddr=0x8200
> fdtaddr=0x8800
> rdaddr=0x8808
>
> initrd_high=0x
> fdt_high=0x
>
> ##These are needed to be compliant with Debian 2014-05-14 u-boot.
>
> loadximage=echo debug: [/boot/vmlinuz-${uname_r}] ... ; load mmc 0:1 
> ${loadaddr} /boot/vmlinuz-${uname_r}
> loadxfdt=echo debug: [/boot/dtbs/${uname_r}/${fdtfile}] ... ;load mmc 
> 0:1 ${fdtaddr} /boot/dtbs/${uname_r}/${fdtfile}
> loadxrd=echo debug: [/boot/initrd.img-${uname_r}] ... ; load mmc 0:1 
> ${rdaddr} /boot/initrd.img-${uname_r}; setenv rdsize ${filesize}
> loaduEnvtxt=load mmc 0:1 ${loadaddr} /boot/uEnv.txt ; env import -t 
> ${loadaddr} ${filesize};
> check_dtb=if test -n ${dtb}; then setenv fdtfile ${dtb};fi;
> loadall=run loaduEnvtxt; run check_dtb; run loadximage; run loadxrd; 
> run loadxfdt;
>
> mmcargs=setenv bootargs console=tty0 console=${console} ${optargs} 
> ${cape_disable} ${cape_enable} root=/dev/mmcblk0p1 
> rootfstype=${mmcrootfstype} ${cmdline}
>
> uenvcmd=run loadall; run mmcargs; echo debug: [${bootargs}] ... ; echo 
> debug: [bootz ${loadaddr} ${rdaddr}:${rdsize} ${fdtaddr}] ... ; bootz 
> ${loadaddr} ${rdaddr}:${rdsize} ${fdtaddr};
>  
>
> On Wed, Jul 13, 2016 at 1:48 PM, William Hermans  
> wrote:
>
>> Ok, actually looking at those instructions. They're wrong for that 
>> uEnv.txt file you have.
>>
>> uenvcmd=run findfdt; if test $board_name = A335BNLT; then i2c mw 0x24 
>> 1 0x3e; setenv mmcdev 1; mmc dev ${mmcdev}; if mmc rescan; then setenv 
>> mm

[beagleboard] Bonescript simple examples not working

[Vincent lc]

Hi,

I just install Bonescript on my cloud9. Now I'm trying to use some simple 
examples. 
However, when I tried to use them I got some error, nevertheless, I didn't 
understand why, and how I can solve them.

First example : Toogle LED 
var b = require('bonescript');

var leds = ["USR0", "USR1", "USR2", "USR3","P8_07"];

for(var i in leds) {
b.pinMode(leds[i], b.OUTPUT);
}

var state = b.LOW;
for(var i in leds) {
b.digitalWrite(leds[i], state);
}

setInterval(toggle, 1000);

function toggle() {
if(state == b.LOW) state = b.HIGH;
else state = b.LOW;
for(var i in leds) {
b.digitalWrite(leds[i], state);
}
}

 The error that I got : 
 
/root/labs/cloud9_app/node_modules/bonescript/src/hw_mainline.js:84
if(!pinmux) { throw p + " was not found under " + my.is_ocp(); }
^
ocp:P8_07_pinmux was not found under /sys/devices/platform/ocp


Remark : if I change the line 
 var leds = ["USR0", "USR1", "USR2", "USR3","P8_07"];
by 
var leds = ["USR0", "USR1", "USR2", "USR3",];

My program is working because it didn't use a gpio pin which request a 
configuration.


Second example : set a PWM signal and change the duty cycle of it :
source : http://beagleboard.org/support/BoneScript/ServoMotor/

var b = require('bonescript');
var SERVO = 'P9_14';
var duty_min = 0.03;
var position = 0;
var increment = 0.1;

//b.pinMode(SERVO, b.OUTPUT);
updateDuty();

function updateDuty() {
// compute and adjust duty_cycle based on
// desired position in range 0..1
var duty_cycle = (position*0.115) + duty_min;
b.analogWrite(SERVO, duty_cycle, 60, scheduleNextUpdate);
console.log("Duty Cycle: " + 
parseFloat(duty_cycle*100).toFixed(1) + " %");   
}

function scheduleNextUpdate() {
// adjust position by increment and 
// reverse if it exceeds range of 0..1
position = position + increment;
if(position < 0) {
position = 0;
increment = -increment;
} else if(position > 1) {
position = 1;
increment = -increment;
}

// call updateDuty after 200ms
setTimeout(updateDuty, 200);
}



Error : 
  /root/labs/cloud9_app/node_modules/bonescript/src/hw_mainline.js:84
if(!pinmux) { throw p + " was not found under " + my.is_ocp(); }
^
ocp:P9_14_pinmux was not found under /sys/devices/platform/ocp


To confirm that my code was working I have tested it on the original kernel 
install on the beaglebone.
Both were working on it. So, I was wondering if it didn't come from the 
dts/dtbo file. 
To test that I copy the one form the original kernel in my own one. It 
didn't succeed either.

Here are my current configuration : 
# node --version
v0.12.7

# npm --version
2.11.3

# node -pe "require('bonescript').getPlatform().bonescript"
0.5.0

# uname -a
Linux beagle09 4.1.21-bone-rt-r20 #3 Wed May 25 13:55:22 CEST 2016 armv7l 
GNU/Linux


Did someone have an Idea on what's wrong ? Am I missing something ? 
If you have any questions do not hesitate.
Thanks by advance for your help

Regards
Vincent 
" Enjoy life no matter what ! " 



-- 
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/dbe67376-26a1-492e-b130-a9e0d210f5d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Weird Problem using GPIOs on BBB

[William Hermans]

You only need to toggle gpio ? How fast do you need it to be ? That code is
far to complex, and uses threading, as well as callbacks for some odd
reason. Threaded code can have performance overhead, and callbacks can
cause problems on the stack if you're not careful.

You would be better off writing your own wrapper code. You could either
wrap the sysfs gpio files directly. Or if you wished you could wrap
config-pin from universal io.

Anyway, it's getting late here so perhaps tomorrow I'll write up a quick
example, that is far less code than D.R. Molloy's  . . . uh . ..library ?
The thing is, the sysfs directory / file structure is already there and
functional. Why would anyone need to write so much code to encapsulate it ?
*shrug*

On Wed, Jul 13, 2016 at 10:02 PM, Raul Piper  wrote:

> Attached.
> One is the cpp code and other is the bash script.
> cpp code uses the GPIO class from the attached GPIO.7z .
>
>
> On Thursday, July 14, 2016 at 9:50:45 AM UTC+5:30, William Hermans wrote:
>>
>> Let's put it this way. No code, no help . . .
>>
>> On Wed, Jul 13, 2016 at 9:19 PM, William Hermans 
>> wrote:
>>
>>>
>>> #code2
>>> //create an instance of gpio41
>>>  //set direction as OUT
>>> //set value as 1
>>> usleep(10);
>>> //set value 0
>>>
>>> Output : Toggle doesnt happens
>>>
>>> Whats this ? This is not code. At best it's comments, and usleep().
>>>
>>>
>>> On Wed, Jul 13, 2016 at 9:02 PM, Raulp  wrote:
>>>
 OK let em explain a bit more :
 #code 1
 sudo echo 41 > export
 cd gpio41
 sudo chmod 666 direction
 sudo chmod 666 value
 sudo echo out > direction
 sudo echo 1 > value
 sleep 1
 sudo echo 0 > value

 Output : Toggle on the GPIO 41


 #code2
 //create an instance of gpio41
  //set direction as OUT
 //set value as 1
 usleep(10);
 //set value 0

 Output : Toggle doesnt happens


 Now the output I am referring to is the functioning of the hardware I
 have used.(ignore toggling , it happens anyway using the code#2)


  Or does your code simply open, and use  the file descriptors without
 any error checking what so ever ?
 >> I dont use error codes to check , but I have seen in the
 oscilloscope that the signal transition is happening according to my code.

 -Rp


 On Wednesday, July 13, 2016 at 8:52:30 PM UTC+5:30, William Hermans
 wrote:
>
> When I try to do the same using a user space C application I dont get
>> the expected response.I am running this app as sudo'er and I have
>> oscilloscope'd the timings of HIGH/LOW levels of the GPIOs and compared 
>> it
>> with that of the manually writing procedure of GPIOS. The waveform and 
>> the
>> timing diagrams almost matches (95%)
>>
>
> I'm not exactly sure what you saying here . . . However, in code are
> you actually checking for errors, and error codes. Or does your code 
> simply
> open, and use  the file descriptors without any error checking what so 
> ever
> ?
>
> Seeing the code would probably help a lot.
>
> On Wed, Jul 13, 2016 at 2:41 AM, Raulp  wrote:
>
>> I have interfaced a hardware using the 5 Gpios on BBB.I can talk to
>> this device using GPIOs by manually (echoing 0 and 1 to the GPIOS) 
>> writing
>> to it in the sys/class/gpio directory by first exporting the Gpios and
>> configuring their directions and value.It works perfectly fine.
>> But,
>> When I try to do the same using a user space C application I dont get
>> the expected response.I am running this app as sudo'er and I have
>> oscilloscope'd the timings of HIGH/LOW levels of the GPIOs and compared 
>> it
>> with that of the manually writing procedure of GPIOS. The waveform and 
>> the
>> timing diagrams almost matches (95%)
>> So,
>> What could mysteriously be missing here.?I can go deep into analyzing
>> the wave-forms and timing diagrams as well if there is an issue in the
>> timings of the Signals.
>> Please advice.Thanks in advance !
>> -Rp
>>
>> --
>> 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/cb65b710-203e-4579-8c08-e2b817dc7a03%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message becau

Re: [beagleboard] Installing ARch Linux on BBB rev C. can't find boot/zImage

[Jelle Spijker]

Damn.. You have been busy whilst I was away.

The uEnv mentioned in my previous post was one when I tried to mount the 
boot as a fat 16 image, so in that setup there where two partitions. The 
uEnv that I have currently and that is the default Arch Linux Uenv only has 
one line:








optargs=coherent_pool=1M



Thank you. I will try your suggestions.

Op woensdag 13 juli 2016 23:12:28 UTC+2 schreef William Hermans:
>
> Correction:
>
> loaduimage=if ext4load mmc 0:2 ${loadaddr} /boot/zImage; then setenv 
> mmcdev 0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv mmcroot 
> /dev/mmcblk1p2 rw; fi; ext4load mmc 1:2 ${loadaddr} /boot/zImage; fi
> *should be:*
> loaduimage=if ext4load mmc 0:1 ${loadaddr} /boot/zImage; then setenv 
> mmcdev 0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv mmcroot 
> /dev/mmcblk1p*1* rw; fi; ext4load mmc 1:*1 *${loadaddr} /boot/zImage; fi
>
> On Wed, Jul 13, 2016 at 2:10 PM, William Hermans  > wrote:
>
>> So . . .
>>
>> mmcroot=/dev/mmcblk0p2 rw
>> *should be:*
>> mmcroot=/dev/mmcblk0p*1* rw
>>
>> loadfdt=ext4load mmc ${mmcdev}:2 ${fdtaddr} /boot/dtbs/${fdtfile}
>> *should be:*
>> loadfdt=ext4load mmc ${mmcdev}:*1* ${fdtaddr} /boot/dtbs/${fdtfile}
>>
>> loaduimage=if ext4load mmc 0:2 ${loadaddr} /boot/zImage; then setenv 
>> mmcdev 0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv mmcroot 
>> /dev/mmcblk1p2 rw; fi; ext4load mmc 1:2 ${loadaddr} /boot/zImage; fi
>> *should be:*
>> should be:loaduimage=if ext4load mmc 0:1 ${loadaddr} /boot/zImage; then 
>> setenv mmcdev 0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv 
>> mmcroot /dev/mmcblk1p*1* rw; fi; ext4load mmc 1:*1 *${loadaddr} 
>> /boot/zImage; fi
>>
>> On Wed, Jul 13, 2016 at 1:56 PM, William Hermans > > wrote:
>>
>>> By the way, ${uname_r} is defined in the second stage uEnv.txt file that 
>>> comes with recent debian images. But It does not look as though the people 
>>> at ARCH uses this file structure. So while these paths should be similar, 
>>> they're going to be slightly different for you. But if you look at the 
>>> uEnv,txt files closely, you should be able to figure out where your file is 
>>> wrong, and how to correct it. 
>>>
>>> On Wed, Jul 13, 2016 at 1:52 PM, William Hermans >> > wrote:
>>>
 Here, here is a stage one uEnv.txt file fro the latest official debian 
 image. Note the differences in disk / partition assingment. But otherwise 
 this uses the same layout for what I can tell as those ARCH instructions 
 imply.

 william@beaglebone:~/dev$ cat /uEnv.txt
 ##These are needed to be compliant with Angstrom's 2013.06.20 u-boot.

 loadaddr=0x8200
 fdtaddr=0x8800
 rdaddr=0x8808

 initrd_high=0x
 fdt_high=0x

 ##These are needed to be compliant with Debian 2014-05-14 u-boot.

 loadximage=echo debug: [/boot/vmlinuz-${uname_r}] ... ; load mmc 0:1 
 ${loadaddr} /boot/vmlinuz-${uname_r}
 loadxfdt=echo debug: [/boot/dtbs/${uname_r}/${fdtfile}] ... ;load mmc 
 0:1 ${fdtaddr} /boot/dtbs/${uname_r}/${fdtfile}
 loadxrd=echo debug: [/boot/initrd.img-${uname_r}] ... ; load mmc 0:1 
 ${rdaddr} /boot/initrd.img-${uname_r}; setenv rdsize ${filesize}
 loaduEnvtxt=load mmc 0:1 ${loadaddr} /boot/uEnv.txt ; env import -t 
 ${loadaddr} ${filesize};
 check_dtb=if test -n ${dtb}; then setenv fdtfile ${dtb};fi;
 loadall=run loaduEnvtxt; run check_dtb; run loadximage; run loadxrd; 
 run loadxfdt;

 mmcargs=setenv bootargs console=tty0 console=${console} ${optargs} 
 ${cape_disable} ${cape_enable} root=/dev/mmcblk0p1 
 rootfstype=${mmcrootfstype} ${cmdline}

 uenvcmd=run loadall; run mmcargs; echo debug: [${bootargs}] ... ; echo 
 debug: [bootz ${loadaddr} ${rdaddr}:${rdsize} ${fdtaddr}] ... ; bootz 
 ${loadaddr} ${rdaddr}:${rdsize} ${fdtaddr};
  

 On Wed, Jul 13, 2016 at 1:48 PM, William Hermans >>> > wrote:

> Ok, actually looking at those instructions. They're wrong for that 
> uEnv.txt file you have.
>
> uenvcmd=run findfdt; if test $board_name = A335BNLT; then i2c mw 0x24 
> 1 0x3e; setenv mmcdev 1; mmc dev ${mmcdev}; if mmc rescan; then setenv 
> mmc1 
> 1;else setenv mmc1 0;fi;fi;setenv mmcdev 0; mmc dev ${mmcdev}; if mmc 
> rescan; then setenv mmc0 1;else setenv mmc0 0;fi;if run loaduimage; then 
> run loadfdt;run mmcboot;fi;
> *mmcroot=/dev/mmcblk0p2* rw
> *loadfdt=ext4load mmc ${mmcdev}:2 ${fdtaddr} /boot/dtbs/${fdtfile}*
> l*oaduimage=if ext4load mmc 0:2 ${loadaddr} /boot/zImage; then setenv 
> mmcdev 0; else setenv mmcdev 1; if test $mmc0 = 1; then setenv mmcroot 
> /dev/mmcblk1p2 rw; fi; ext4load mmc 1:2 ${loadaddr} /boot/zImage; fi*
> mmcboot=echo Booting from mmc ...; run mmcargs; bootz ${loadaddr} - 
> ${fdtaddr}
>
> But looks at these lines I've highlighted. I'm seeing a lot of 
> partitio