Re: [beagleboard] Debugging with beaglebone black

[William Hermans]

That is, kgdb . . .

On Fri, Mar 18, 2016 at 1:50 AM, William Hermans  wrote:

> https://www.google.com/search?q=how+to+debug+linux+kernel+modules
>
> Just like you would on any platform.
>
> On Thu, Mar 17, 2016 at 8:46 PM, John Syne  wrote:
>
>> To debug kernel modules with JTAG, you have to have a debugger which is
>> kernel aware like Lauterbach. If you don’t want to use JTAG, then use
>> printk or dev-dbg, dev-err, etc. You can also use ftrace, which requires
>> you to build your own kernel and add support for the various ftrace
>> features. Read kernel docs under documentation/trace/ftrace.txt to learn
>> more.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Mar 17, 2016, at 7:49 PM, cmajor.merch...@gmail.com wrote:
>>
>> I have a question about the beaglebone black. How am suppose to debug
>> with it? I really would prefer not to have to solder a JTAG header. Also
>> the JTAG header would be under the board which is really inconvenient. The
>> case that came with my board also has no room for the JTAG header so it
>> would basically render the case useless. I know it has a serial debug
>> header but how could I debug with it? I want to debug kernel modules.
>>
>> --
>> 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.
>> 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.
>> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] How to interface dht11 sensor with BBB....

[Sumit Bhut]

How to interface dht11 sensor with BBB

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] How to interface dht11 with BBB......

[Sumit Bhut]

How to interface dht11 with BBB

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] KiwiSDR for BBB/G on Kickstarter

[John Seamons]

An SDR cape with 14-bit ADC, Artix-7 FPGA and software-defined GPS is on 
Kickstarter 

.
Designed in partnership with Valent F(x), makers of the LOGi-Bone FPGA cape.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Terminal Block Wiring Options

[Jacek Radzikowski]

It looks like the terminal blocks should be the least of your worries
at the moment. To have "industrial strength" system, you should never,
ever connect wires directly to the pins of the processor. For each
digital input and output you should add at least transistor driver
separating the outside circuit from the board, with optoisolation if
possible. Analog inputs and outputs should also be buffered. It would
be good to add voltage spike protections (diodes, transils) on each of
the lines.
Optoisolation and spike protection will add ruggedness to your system,
however without proper buffering of the signals, most likely you will
fry the board in no time.

Regards,
Jacek.


On Thu, Mar 17, 2016 at 8:07 PM,   wrote:
> Hey guys,
>
> I'm currently designing a greenhouse automation control unit utilizing the
> BBB as the brain.  In order to create industrial strength wiring I'd like to
> use terminal block connections to each connector on the P8 and P9 headers.
>
> To give you a visual of what I'd like to do check out a picture of the
> terminal block shield for the Arduino Mega.  It plugs into the board nicely
> and the terminal blocks lay along perimeter of the shield giving the user
> access to each input.
>
> I'm also open to other ideas regarding how to wire up a BBB in a reliable
> way suitable for industrial purposes.
>
> What do you think?
>
>
> The information contained in this transmission contains potentially
> privileged, export controlled and/or confidential information of Imageware
> Systems, Inc. or its customers or partners.  It is intended only to be read
> by the person(s) named above and for no other purpose.  You are hereby
> notified that any dissemination, distribution, duplication of this
> communication or use of its contents for any purpose not authorized
> expressly by Imageware Systems, Inc. is strictly prohibited and could lead
> to both civil and/or criminal penalties.  If you are not the intended
> recipient, you are prohibited to review the contents herein and please
> contact the sender by reply e-mail and destroy all copies of the original
> message.  To reply to our e-mail administrator directly, please send an
> e-mail to emailad...@iwsinc.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.
> For more options, visit https://groups.google.com/d/optout.



-- 
Given a choice between two theories, take the one which is funnier

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone Cloud9 Default User

[Paul Wolfson]

​Several months ago I posted a note asking how to prevent the Cloud9 IDE
running its shell as root.  The answer pointed out where the bash command
is launched.

if (options.terminal) {

args.push("export ISOUTPUTPANE=0;"
​​
+ (options.defaultEditor
​​
? " export EDITOR='`which c9` open --wait'; "
​​
: "")
​​
+ BASH + " -l");
}
​


​​
> Terminals in cloud9 run bash -l so they will be logged in as the same user
> which have launched the server.js.
>


> See
> https://github.com/c9/core/blob/6cc153e712c64ef8326c195d27a2c224f84429c6/node_modules/vfs-local/localfs.js#L1817
>


> You could either modify that file to run a different command, or modify
> the script that launches the server.js, to launch it from the user you want.
>


> ​
> ​  --
> Harutyun Amirjanyan ​



-
Paul Wolfson, Ph.D., TX LPI, #A17473
Editor, TALI "The Texas Investigator"
Dallas Legal Technology
3402 Oak Grove Avenue, Suite 300-A
Dallas, Texas 75204-2353


*214-257-0984 (Tel)214-838-7220 (Fax)Send me an email. *
-
The contents of this email are confidential to the sender and the ordinary
user of the email address to which it was addressed, and may also be
privileged.  If you are not the addressee of the email, you may not copy,
forward, disclose or otherwise use it or any part of it in any form
whatsoever.  If you have received this email in error, please advise the
sender at  214-257-0984.  Thank you.
-

On Fri, Feb 5, 2016 at 7:10 PM, William Hermans  wrote:

> I "get it" though. Like for me, I know very basic electronics "OK", but
> really do not have the time nor inclination to become a fully fledged E.E.
> Or my buddy here, who is an excellent E.E. but whom also does not want to
> learn how to program.
>
> I will say that the only real differences I can think of between GPIO, and
> PWM in any code should only be file path, and values sent to the file
> handle. So anyone willing to read through,and understand  the code for
> GPIO. Should theoretically be able to adapt that code for PWM as well.
>
> Unfortunately, in my own case. If I do not have the time to bother
> learning this "something". Obviously I do not have the time to refactor the
> existing code either . . .
>
>
>
> On Fri, Feb 5, 2016 at 4:15 PM, Wally Bkg  wrote:
>
>>
>>
>> On Friday, February 5, 2016 at 1:48:53 PM UTC-6, William Hermans wrote:
>>>
>>> *After giving him a configured BBG (he'd have been dead in the water
 with the image that came in the BBG eMMC, which really breaks the ideal for
 a newbie idea) and showing him how to install the Windows drivers and
 connect to the BBG with Chrome web browser, it clearly was a great starting
 point for him.*

>>>
>>> Anything of this nature still has a learning curve. Personally, I think
>>> things of this nature are a waste of time. Not because they're not handy,
>>> or cool. But instead you have to spend a time investment to learn anything.
>>> So you may as well learn the "underlying basics" so you're better prepared
>>> in the future to deal with more complex problems.
>>>
>>> So a very quick example . . . Not knowing what Node-RED really is, I'd
>>> have to spend a considerable amount of time learning this new "software
>>> technology", when I could instead just write  my own code and be done with
>>> it. Now sure, because I'm an experienced developer, who *now* has a decent
>>> bit of javascript / Nodejs experience, this may be easier for me. However,
>>> I had to learn all of this, just like anyone else, and in fact I'm by far
>>> not a Nodejs "expert". And in fact, I knew very little of  Nodejs 3 years
>>> ago when we got our first BBB's . . .
>>>
>>>
>> What you say is true, but I'm afraid its been so long since you've
>> started with zero programming knowledge that you've forgotten how difficult
>> that first step is, its mind numbingly complex when you throw in all the
>> GPIO mux options and restrictions of the Beaglebone
>>
>> A GUI tool like node-red lets a rank beginner do something useful,
>> without spending weeks learning programming and languages.  Drag and drop,
>> wire, and deploy can result it a rather sophisticated program with
>> distributed processing -- a sensor in one building communicating with a
>> actuator in another building over a WiFi network using mqtt protocol and
>> mosquito broker running on one of the Beaglebones -- all done like drawing
>> a schematic diagram -- something people with a hardware background find
>> "intuitive".  To use a GPIO as input or output, you drag the node to the
>> "tab", double click it, and fill in the necessary "properties" to make the
>> function.  The choices are limited to what is available with the "default"
>> pin mux settings but for a beginner its feature, not a bug.  If only the
>> PWM worked, and there were UART nodes it could do most anything that needs
>> response

Re: [beagleboard] X15 Availability

[robgs17]

Any update on the availability?

On Saturday, March 12, 2016 at 8:34:36 AM UTC-5, Gerald wrote:
>
> For the most part, Rev A and B work about the same. Most changes are 
> layout related.
>
> Gerald
>
>
> On Sat, Mar 12, 2016 at 1:42 AM, > 
> wrote:
>
>> Hi
>>
>> I am very thankful if you update me about when Rev B can be ready for 
>> purchase, I want work with that in our new Year holidays, If it not very 
>> big change against Rev A, do you prefer me Rev A for my R&Ds and tests?
>> I'm from Iran and new year is near.
>>
>> On Tuesday, February 9, 2016 at 4:39:05 AM UTC+3:30, Gerald wrote:
>>>
>>> We are working to get about 150 of the current revision out in the next 
>>> few weeks to one distributor. We had some of the Rev A2 versions PCBs still 
>>> available so we are working to build those up. 
>>>
>>> If you look at http://elinux.org/Beagleboard:BeagleBoard-X15 you will 
>>> see the latest official update on the Rev B version.
>>>
>>> Gerald
>>>
>>>
>>> On Mon, Feb 8, 2016 at 6:33 PM,  wrote:
>>>
 Is there any update on the shipping date?
 Are you still expecting to start shipping this month?

 On Thursday, December 24, 2015 at 10:24:32 AM UTC-6, Gerald wrote:
>
> Yes. We hope to start shipping in February. We had to make some design 
> changes in order to pass FCC.
>
> Gerald
>
> On Thu, Dec 24, 2015 at 9:18 AM,  wrote:
>
>> Previously a shipping date of the middle of December was mentioned.  
>> Has this date changed?
>>
>> -- 
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Gerald
>  
> ger...@beagleboard.org
> http://beagleboard.org/
>
 -- 
 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.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> -- 
>>> Gerald
>>>  
>>> ger...@beagleboard.org
>>> http://beagleboard.org/
>>>
>> -- 
>> 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 .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Gerald
>  
> ger...@beagleboard.org 
> http://beagleboard.org/
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Question on Cortex A ARMS...

[William Hermans]

Read the other post you made for my answer.

On Thu, Mar 17, 2016 at 2:50 PM,  wrote:

> I have an extremely simple question:
>
> My company uses ARM Cortex M micro-controllers.  I would like to know if
> if the Cortex A can have their operating system put aside and the unit be
> used strictly as a micro-controller.  The 1 Ghz capability is very fast
> with plenty of memory, it would be awesome to tap into that and use it for
> VFD development.
>
> Any thoughts?
>
> Rick W
>
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] u-boot can't find uEnv.txt

[William Hermans]

Just to make things perhaps a little clearer . . .

william@beaglebone:~$ pwd
/home/william
william@beaglebone:~$ ls /
ID.txt  boot  etc   lib media  nfs-uEnv.txt  proc  run   selinux
sys  *uEnv.txt*   usr
bin dev   home  lost+found  mntopt   root  sbin  srv
tmp  uEnv.txt.save  var


On Fri, Mar 18, 2016 at 2:11 AM, William Hermans  wrote:

> Oh, and if you're using the eMMC only, you need to have uEnv,txt located
> in the first partition at root of the "drive". So in laymen terms . . .
>
> /uEnv.txt - Not /boot/uEnv.txt or anywhere else *unless* you modify uboots
> code before compiling.
>
> On Fri, Mar 18, 2016 at 2:08 AM, William Hermans 
> wrote:
>
>> *It also seems that u-boot will try to took for uEnv.txt in several
>>> partitions, and seeing some "** Unable to read file uEnv.txt **" messages
>>> are ok.  Is this correct?*
>>>
>>
>> No. If you have an sdcard inserted at boot it will always load the first
>> and second stage boot loaders from eMMC, but it will always look to the
>> first partition on the sdcard for uEnv.txt.
>>
>> The only exception is if S2 is depressed at boot time, then the first and
>> second stage boot loader will be "attempted" from the sdcard first, but
>> uEnv.txt will still be expected to exist on the sdcard.
>>
>> Many people ( yours truly included ) have in the past bemoaned this
>> behavior of uboot. When having a blank sdcard inserted at boot.
>>
>> On Thu, Mar 17, 2016 at 10:50 PM, David Hinkes 
>> wrote:
>>
>>> Thanks for the response, I appreciate it.
>>>
>>>
 > Questions:
 > (1) What are the requirements for the location of uEnv.txt?

 Look at the flow:


 http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;h=6ebe0b3866f9b137472cc080c9eb8f1e38233186;hb=df61a74e6845ec9bdcdd48d2aff5e9c2c6debeaa#l130

 /uEnv.txt in the first partition...

>>>
>>> I tried that and no luck.
>>>
>>> I realized that I configured u-boot with am335x_boneblack_defconfig and
>>> instead of am335x_evm_defconfig.
>>>
>>> It also seems that u-boot will try to took for uEnv.txt in several
>>> partitions, and seeing some "** Unable to read file uEnv.txt **" messages
>>> are ok.  Is this correct?
>>>
>>> --
>>> 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.
>>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PWM On Beaglebone black with Jessie

[Walter Schilling]

OK, so here is where I am at:
#1 I wrote the following script, and, well it worked great...  Until I had 
to reboot my machine:






*#!/bin/bash# SE3910 Real Time Systems# PWM Bash shell script.# Author: W. 
Schilling# This script will enable PWM on the beaglebone connected to 
ECAPPWM0.# It will set the duty cycle to the value passed in, which is a 
value between 1 and 1.*


*# Setup the pin as a PWM pin.config-pin P9.42 pwm*


*# Export the control for the device, creating the directory structure that 
we w$echo 0 > /sys/class/pwm/pwmchip0/export*


*# Setup the period for PWM to be 1 to make things nice and easy to 
work wit$echo  1 > /sys/class/pwm/pwmchip0/pwm0/period*


*# Setup the duty cycle to the value passed in as $1echo $1 > 
/sys/class/pwm/pwmchip0/pwm0/duty_cycle*


*# Enable pwm echo 1 > /sys/class/pwm/pwmchip0/pwm0/enable*

However, when I rebooted my machine, the pin failed to toggle.  I believe I 
inadvertently did something with capes that wasn't enabled when I first 
tried it.  I then tried this script on my home beaglebone, running Robert 
Nelson's image bone-debian-8.3-lxqt-4gb-armhf-2016-02-21-4gb.img.  This 
one, however, fails with the following:

root@beaglebone:~# ./pwm2.sh 1000
P9_42 pinmux file not found!
cape-universala overlay not found
run "config-pin overlay cape-universala" to load the cape
./pwm2.sh: line 12: echo: write error: Device or resource busy
./pwm2.sh: line 15: /sys/class/pwm/pwmchip0/pwm0/period: No such file or 
directory
./pwm2.sh: line 18: /sys/class/pwm/pwmchip0/pwm0/duty_cycle: No such file 
or directory
./pwm2.sh: line 21: /sys/class/pwm/pwmchip0/pwm0/enable: No such file or 
directory
root@beaglebone:~# 

I've tried the following, which results in different errors but still 
errors:
root@beaglebone:~# config-pin overlay cape-universaln
Loading cape-universaln overlay
bash: line 0: echo: write error: File exists
Error loading device tree overlay file: cape-universaln
root@beaglebone:~# ./pwm2.sh 1000
P9_42 pinmux file not found!
cape-universala overlay not found
run "config-pin overlay cape-universala" to load the cape
./pwm2.sh: line 12: echo: write error: Device or resource busy
./pwm2.sh: line 15: /sys/class/pwm/pwmchip0/pwm0/period: No such file or 
directory
./pwm2.sh: line 18: /sys/class/pwm/pwmchip0/pwm0/duty_cycle: No such file 
or directory
./pwm2.sh: line 21: /sys/class/pwm/pwmchip0/pwm0/enable: No such file or 
directory
root@beaglebone:~# 

Ideas to try next?

Walt
-- 
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 .
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Cannot Use BBB After Updating

[marc . lavoie777]

Hello, 

I have recently bought two BeagleBone Black, one from Element14 and one 
from Adafruit (not the Element14 one). Both are rev C. 

When I received my first BeagleBone Black, which was the Element14, I 
plugged it to the computer through usb to make sure it was working alright, 
which it was. Problem is, as soon as I updated to the last Debian version 
(Jessie for BBB, https://beagleboard.org/latest-images), it rendered the 
BBB unusable through the micro USB port. The device is not recognized by 
any of my Windows, Mac and Linux computers. I then tried to redo the 
installation of the latest Debian version (tried 10 times maybe), and at 
the end, even plugging the FTDI to USB cable in the BBB would output 
nothing at all. 

Then thinking the device was dead, I bought another one on Adafruit, a 4gb 
rev c, and about the same thing happened. I checked to see if it was 
working alright, then updated the distro on it, and now it can't be 
recognized by any of my computers. It is worth nothing that both my BBB 
still seem to try to do something when inserting my SD card. Both devices 
will have their LEDs moving the way you would expect them when updating the 
device, and then at some point, they will all flash at the same time which 
is when I figure the update is over. 

My latest BBB can still output something. Here's the log: 

U-Boot SPL 2016.01-1-g4eb802e (Jan 13 2016 - 11:14:31)
> Trying to boot from MMC
> bad magic
>
>
> U-Boot 2016.01-1-g4eb802e (Jan 13 2016 - 11:14:31 -0600), Build: 
> jenkins-github_Bootloader-Builder-313
>
>Watchdog enabled
> I2C:   ready
> DRAM:  512 MiB
> Reset Source: Power-on reset has occurred.
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Using default environment
>
> Net:not set. Validating first E-fuse MAC
> cpsw, usb_ether
> Press SPACE to abort autoboot in 2 seconds
> Card did not respond to voltage select!
> gpio: pin 56 (gpio 56) value is 0
> gpio: pin 55 (gpio 55) value is 0
> gpio: pin 54 (gpio 54) value is 0
> gpio: pin 53 (gpio 53) value is 1
> Card did not respond to voltage select!
> Card did not respond to voltage select!
> switch to partitions #0, OK
> mmc1(part 0) is current device
> Scanning mmc 1:1...
> gpio: pin 56 (gpio 56) value is 0
> gpio: pin 55 (gpio 55) value is 0
> gpio: pin 54 (gpio 54) value is 0
> gpio: pin 53 (gpio 53) value is 1
> switch to partitions #0, OK
> mmc1(part 0) is current device
> gpio: pin 54 (gpio 54) value is 1
> Checking for: /uEnv.txt ...
> Checking for: /boot.scr ...
> Checking for: /boot/boot.scr ...
> Checking for: /boot/uEnv.txt ...
> gpio: pin 55 (gpio 55) value is 1
> 1684 bytes read in 16 ms (102.5 KiB/s)
> Loaded environment from /boot/uEnv.txt
> Checking if uname_r is set in /boot/uEnv.txt...
> gpio: pin 56 (gpio 56) value is 1
> Running uname_boot ...
> loading /boot/vmlinuz-4.1.15-ti-rt-r43 ...
> 7800752 bytes read in 445 ms (16.7 MiB/s)
> loading /boot/dtbs/4.1.15-ti-rt-r43/am335x-boneblack.dtb ...
> 60524 bytes read in 40 ms (1.4 MiB/s)
> loading /boot/initrd.img-4.1.15-ti-rt-r43 ...
> 4096241 bytes read in 242 ms (16.1 MiB/s)
> debug: [console=ttyO0,115200n8 root=UUID=5e77d2fb-74c9-499b-b8a1-1a027bb43611 
> ro rootfstype=ext4 rootwait coherent_pool=1M quiet cape_universal=enable] 
> ...
> debug: [bootz 0x8200 0x8808:3e80f1 0x8800] ...
> Kernel image @ 0x8200 [ 0x00 - 0x7707b0 ]
> ## Flattened Device Tree blob at 8800
>Booting using the fdt blob at 0x8800
>Loading Ramdisk to 8fc17000, end 80f1 ... OK
>Loading Device Tree to 8fc05000, end 8fc16c6b ... OK
>
> Starting kernel ...
>
> [3.486358] wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle
> [3.797674] cpu cpu0: cpu0 clock notifier not ready, retry
> [3.943342] bone_capemgr bone_capemgr: slot #0: No cape found
> [4.003308] bone_capemgr bone_capemgr: slot #1: No cape found
> [4.063310] bone_capemgr bone_capemgr: slot #2: No cape found
> [4.123306] bone_capemgr bone_capemgr: slot #3: No cape found
> Loading, please wait...
> fsck from util-linux 2.25.2
> fsck: error 2 (No such file or directory) while executing fsck.ext4 for 
> /dev/mmcblk0p1
> fsck exited with status code 8
> [   11.881257] systemd-fsck[192]: BOOT: clean, 123277/233856 files, 
> 774023/933632 blocks
>
> 0* ttyUSB1  5:45PM  
> 17/Mar/2016 
> Scanning mmc 1:1...
> gpio: pin 56 (gpio 56) value is 0
> gpio: pin 55 (gpio 55) value is 0
> gpio: pin 54 (gpio 54) value is 0
> gpio: pin 53 (gpio 53) value is 1
> switch to partitions #0, OK
> mmc1(part 0) is current device
> gpio: pin 54 (gpio 54) value is 1
> Checking for: /uEnv.txt ...
> Checking for: /boot.scr ...
> Checking for: /boot/boot.scr ...
> Checking for: /boot/uEnv.txt ...
> gpio: pin 55 (gpio 55) value is 1
> 1684 bytes read in 16 ms (102.5 KiB/s)
> Loaded environment from /boot/uEnv.txt
> Checking if uname_r is set in /boot/uEnv.txt...
> gpio: pin 56 (gpio 56) value is 1
> Running uname_boot ...
>

[beagleboard] Re: Beaglebone Database Suggestions

[cl]

Ray Madigan  wrote:
> [-- multipart/alternative, encoding 7bit, 50 lines --]
> 
> [-- text/plain, encoding 7bit, charset: UTF-8, 18 lines --]
> 
> I have an app I want to write for home use that I need database access for. 
>  The dataset isn't extremely large but will eventually overflow the file 
> system on beaglebone.  I can't think of a way to add additional storage 
> that will work with a database like postgresql.  I have read many online 
> posts that suggest that most databases will not install on a fat file 
> system. 
> 
> At this point I am blocked.  I have thought of using a cloud database, for 
> the size of the database it is an expensive option.  Any suggestions would 
> be appreciated. 
> 
What about sqlite with the file on some sort of external storage?
Then there's no need for database servers or anything complicated like
that.  Backup is easy too, just copy the file.

-- 
Chris Green
·

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BeagleBoard Data transfer to SDR

[gopani . karan007]

Hi I am making a project on BeagleBoard which collects different data.
Now I want to interface a 433MHZ transmitter to the BeagleBoard and receive 
the transmitted data on a computer using SDR(Software defined Radio).
I don't want to use two BeagleBoard, it's OK if the Transmission speed is 
low with the SDR.
So If anyone can suggest me ways in which I can interface the transmitter 
to send data on RF and receive it on SDR.
Thanks


-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] RevB Expansion Headers

[wortlepj]

I've read in another post that the changes between the RevA and RevB are 
mostly layout related (HDMI and Power).
Does this mean that the expansion headers haven't changed or moved and the 
signals on these connectors are the same?

I ask because I would like to start work on a board that interfaces to the 
X-15, but the only information available at the moment seems to be for the 
RevA boards.

Thanks

Pete.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] bbb Internal ADC configuration settings?

[John Syne]

Where do you get the concept that there are two paths? From everything I know 
about IIO, there is only one path, /sys/bus/iio/devices/iio:deviceX, were X is 
the number assigned to each IIO driver loaded. There is no one-shot or 
continuous mode for this driver. I believe mode was removed from IIO. 


Regards,
John




> On Mar 18, 2016, at 2:56 PM, William Hermans  wrote:
> 
> Audrey,
> 
> Please read the link I gave you a couple weeks ago . . . 
> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide#Continuous_Mode
>  
> 
> 
> Everything you need to know to use the ADC is explained on this page. But 
> from your last post, and the paths you've shown us. You're in the wrong 
> directory. Essentially, you're still in the one-shot directories, which are 
> completely separate from the continuous mode directory structure.
> 
> On Fri, Mar 18, 2016 at 1:46 PM, John Syne  > wrote:
> What is your kernel version?
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 18, 2016, at 1:22 PM, Audrey mailto:a...@smith.edu>> 
>> wrote:
>> 
>> It says:
>> root@beaglebone:/# echo 1 > 
>> /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en
>> -bash: /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en: No such 
>> file or directory
>> 
>> and I can't find scan_elements in sys/bus/iio/devices/iio:device0
>> root@beaglebone:/sys/bus/iio/devices/iio:device0# ls -l
>> total 0
>> -r--r--r-- 1 root root 4096 Mar  1 21:13 dev
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage0_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage1_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage2_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage3_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage4_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage5_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage6_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage7_raw
>> -r--r--r-- 1 root root 4096 Mar  1 21:13 name
>> drwxr-xr-x 2 root root0 Mar  1 21:13 power
>> lrwxrwxrwx 1 root root0 Mar  1 20:47 subsystem -> ../../../../../bus/iio
>> -rw-r--r-- 1 root root 4096 Mar  1 20:47 uevent
>> 
>> 
>> On Friday, March 18, 2016 at 4:15:00 PM UTC-4, john3909 wrote:
>> 
>>> On Mar 18, 2016, at 1:06 PM, Audrey > wrote:
>>> 
>>> Hm. 
>>> 
>>> Sorry, but unfortunately I'm still quite a bit lost. What should I be doing 
>>> to dev/iio:device0 (open?) in order to do the following:
>>> echo 1 > in_voltage0_en
>> From memory, 
>> 
>> echo 1 > /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en
>>> echo 1 > buffer/enable
>> echo 1 > /sys/bus/iio/devices/iio:device0/buffer/enable
>> 
>> Regards,
>> John
>>> 
>>> I'm assuming that I should be able to see in_voltage0_en and buffer in the 
>>> folder /sys/bus/iio/devices/iio:device0 but I currently do not see those 
>>> attributes/drivers/folders/buffers/whatever-you-want-to-call-them.
>>> 
>>> Typing 
>>> root@beaglebone:/dev# open iio:device0
>>> doesn't seem to do anything.
>>> 
>>> Do you think you could break your steps down even further?
>>> 
>>> Thanks.
>>> 
>>> On Friday, March 18, 2016 at 3:49:39 PM UTC-4, john3909 wrote:
>>> It is a driver, so you can open, poll and read from /dev/iio:device0
>>> 
>>> For a quick test, do the following: After you enable the various 
>>> scan_channels, start the buffer and then do the following:
>>> 
>>> dd if=/dev/iio:device0 of=~/test.txt
>>> 
>>> Press ctrl-C to stop capture.
>>> 
>>> Use hexdump to view the file. 
>>> 
>>> Regards,
>>> John
>>> 
>>> 
>>> 
>>> 
 On Mar 18, 2016, at 12:37 PM, Audrey smith.edu 
 > wrote:
 
 It says:
 root@beaglebone:/dev# cd iio:device0
 -bash: cd: iio:device0: Not a directory
 root@beaglebone:/dev# cat iio:device0
 cat: iio:device0: Invalid argument
 
 
 On Friday, March 18, 2016 at 3:25:13 PM UTC-4, john3909 wrote:
 The buffer is available here:
 
 /dev/iio:device0
 
 Because the driver uses interrupts, you won’t get the speed you want. The 
 driver has to be updated to use DMA if you want to use full speed. Reading 
 from the buffer will reduce your CPU load compared to using LDR_PATH 
 because this interface blocks until a sample is available, but not long 
 enough for the thread to sleep. To use DMA, IIO have introduced a DMA 
 framework and most of what you need is already available. However, IIO are 
 going to be updating the IIO DMA framework to do zero copy between the 
 kernel module and the socket interface, using MMU maps. 
 
 Regards,
 John
 
 
 
 
> On Mar 18, 2016, at 11:21 AM, Audrey smith.edu 
> > wrote:
> 
> Hi everyone,
> 
> First of all, thank you everyone for trying to help me. I appreciate 
> everyone's input.
> 
> I took everyone's advi

Re: [beagleboard] Cannot Use BBB After Updating

[Wally Bkg]

Its clever, useful, and makes for great demos when it works, but  Its not 
useful enough to be worth hours of Googling and dicking around for what 
should work out of the box as its purported to be a major feature when you 
shop for a Beaglebone..   Reliability has been great on my BBW not so much 
on the BBB/BBG for whatever reason -- it goes beyond simply a kernel 
version or image issue as I've used the same SD card on all three at 
various times.


On Friday, March 18, 2016 at 3:55:10 AM UTC-5, William Hermans wrote:
>
> Wally, I'll give you a hint. In most cases g_ether does not come up, 
> because it was intended that way. But if you really *really* need it to 
> work, you should learn how to troubleshoot driver modules, and a thing or 
> two about USB gadget drivers. I've learned all this myself simply by 
> googling, from knowing nothing about the subject a few years ago( when I 
> started learning about it ).
>
> On Thu, Mar 17, 2016 at 10:34 PM, Wally Bkg  > wrote:
>
>> On Thursday, March 17, 2016 at 5:12:59 PM UTC-5, William Hermans wrote:
>>
>>> *Please retest with the latest:*

 * 
 http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots
  
 *

 * Which use the "4.1.18-ti-r52" kernel, some of the usb issues seem to*
 * be caused by the RT patchset, so with the "2016-03-13" snapshot we*
 * swapped back to the non-rt varient..*

 * I personally know "g_serial" now works out of the box again..*

 * Regards,*
>>>
>>>
>>> Looks like maybe I need to "whip up" a new guide for troubleshooting 
>>> basic Linux driver issues ? Plus perhaps how to work with the various 
>>> gadget drivers . . .
>>>
>>
>>  I think that would be awesome! especially if it finds its way to the 
>> elinux.org website.
>>  
>> I've been frustrated with the USB Ethernet gadget's flaky start-up, 
>> especially on Linux hosts.  But I haven't tried 2016-03-13 image yet, 
>> 2016-02-21 seemed a bit flakier in limited use before I had to take 
>> a hiatus for other things.  
>>
>> Although 2015-11-12 (with upgrades) has been solid on my BBW running 
>> pretty much 24/7 since I installed it, rebooting only for kernel upgrade 
>> and to test the cold start of my application.
>>
>> -- 
>> 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 .
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Help me.. BUG: soft lockup - CPU#0 stuck for 22s!

[lbohn]

-Original Message-
From: kim namic [mailto:namic...@gmail.com]
Sent: Thursday, March 17, 2016 08:39 AM
To: 'BeagleBoard'
Subject: [beagleboard] Help me.. BUG: soft lockup - CPU#0 stuck for 22s!

Hi, Everyone..


I'm study IEC 61850. and devloepment 61850 Gateway.


My application(gw61850) are running about 10 minutes, so, Freeze my BBB and 
screen error message.


I'm 2 BBB (Debian 7.5 and Debian 8.3)testing my application. but same error 
orrcur.


Please help me...


My error mesages
~~
[84918.845223] BUG: soft lockup - CPU#0 stuck for 22s! [gw61850:2388]
[84918.851545] Modules linked in: g_multi libcomposite ipv6 btrfs
[84918.857572]
[84918.859104] Pid: 2388, comm: gw61850
[84918.863909] CPU: 0 Not tainted (3.8.13 #5)
[84918.868470] PC is at ktime_get_ts+0x92/0xcc
[84918.872743] LR is at ktime_get_ts+0x61/0xcc
[84918.877020] pc : [] lr : [] psr: 8033
[84918.877020] sp : ddd15b10 ip : 0006 fp : b5e0a6a4
[84918.888708] r10:  r9 :  r8 : c4653600
[84918.894038] r7 : 1b788d90 r6 : ddd15b30 r5 :  r4 : 3b9ac9ff
[84918.900692] r3 : e4877270 r2 : db279f7e r1 : 00014c42 r0 : 75fc9559
[84918.907348] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user
[84918.914797] Control: 50c5387d Table: 9e5ec019 DAC: 0015
[84918.920715] [] (unwind_backtrace+0x1/0x8a) from [] 
(watchdog_timer_fn+0xb1/0xf8)
[84918.930047] [] (watchdog_timer_fn+0xb1/0xf8) from [] 
(__run_hrtimer.isra.20+0x4f/0x9c)
[84918.939899] [] (__run_hrtimer.isra.20+0x4f/0x9c) from [] 
(hrtimer_interrupt+0xd9/0x1d4)
[84918.949852] [] (hrtimer_interrupt+0xd9/0x1d4) from [] 
(omap2_gp_timer_interrupt+0x11/0x1c)
[84918.960063] [] (omap2_gp_timer_interrupt+0x11/0x1c) from 
[] (handle_irq_event_percpu+0x1f/0xe8)
[84918.970711] [] (handle_irq_event_percpu+0x1f/0xe8) from 
[] (handle_irq_event+0x29/0x3c)
[84918.980649] [] (handle_irq_event+0x29/0x3c) from [] 
(handle_level_irq+0x6f/0x84)
[84918.989968] [] (handle_level_irq+0x6f/0x84) from [] 
(generic_handle_irq+0x13/0x1c)
[84918.999478] [] (generic_handle_irq+0x13/0x1c) from [] 
(handle_IRQ+0x3b/0x5c)
[84919.008446] [] (handle_IRQ+0x3b/0x5c) from [] 
(omap3_intc_handle_irq+0x39/0x5c)
[84919.017676] [] (omap3_intc_handle_irq+0x39/0x5c) from [] 
(__irq_svc+0x3b/0x5c)
[84919.026800] Exception stack(0xddd15ac8 to 0xddd15b10)
[84919.031956] BUG: scheduling while atomic: gw61850/2388/0x4001
[84919.038159] Modules linked in: g_multi libcomposite ipv6 btrfs
[84919.044211] [] (unwind_backtrace+0x1/0x8a) from [] 
(__schedule_bug+0x33/0x48)
[84919.053278] [] (__schedule_bug+0x33/0x48) from [] 
(__schedule+0x49/0x498)
[84919.061983] [] (__schedule+0x49/0x498) from [] 
(__cond_resched+0x1b/0x24)
[84919.070689] [] (__cond_resched+0x1b/0x24) from [] 
(_cond_resched+0x21/0x28)
[84919.079575] [] (_cond_resched+0x21/0x28) from [] 
(dump_mem+0x53/0xc4)
[84919.087926] [] (dump_mem+0x53/0xc4) from [] 
(unwind_backtrace+0x7d/0x8a)
[84919.096542] [] (unwind_backtrace+0x7d/0x8a) from [] 
(watchdog_timer_fn+0xb1/0xf8)
[84919.105950] [] (watchdog_timer_fn+0xb1/0xf8) from [] 
(__run_hrtimer.isra.20+0x4f/0x9c)
[84919.115800] [] (__run_hrtimer.isra.20+0x4f/0x9c) from [] 
(hrtimer_interrupt+0xd9/0x1d4)
[84919.125740] [] (hrtimer_interrupt+0xd9/0x1d4) from [] 
(omap2_gp_timer_interrupt+0x11/0x1c)
[84919.135947] [] (omap2_gp_timer_interrupt+0x11/0x1c) from 
[] (handle_irq_event_percpu+0x1f/0xe8)
[84919.146593] [] (handle_irq_event_percpu+0x1f/0xe8) from 
[] (handle_irq_event+0x29/0x3c)
[84919.156529] [] (handle_irq_event+0x29/0x3c) from [] 
(handle_level_irq+0x6f/0x84)
[84919.165848] [] (handle_level_irq+0x6f/0x84) from [] 
(generic_handle_irq+0x13/0x1c)
[84919.175346] [] (generic_handle_irq+0x13/0x1c) from [] 
(handle_IRQ+0x3b/0x5c)
[84919.184312] [] (handle_IRQ+0x3b/0x5c) from [] 
(omap3_intc_handle_irq+0x39/0x5c)
[84919.193541] [] (omap3_intc_handle_irq+0x39/0x5c) from [] 
(__irq_svc+0x3b/0x5c)
[84919.202663] Exception stack(0xddd15ac8 to 0xddd15b10)
[84919.207829] 5ac0: 75fc9559 00014c42 db279f7e e4877270 3b9ac9ff 
[84919.216175] 5ae0: ddd15b30 1b788d90 c4653600   b5e0a6a4 
0006 ddd15b10
[84919.224510] 5b00: c0050939 c005096a 8033 
[84919.229685] [] (__irq_svc+0x3b/0x5c) from [] 
(ktime_get_ts+0x92/0xcc)
[84919.238041] [] (ktime_get_ts+0x92/0xcc) from [] 
(select_estimate_accuracy+0x83/0xac)
[84919.247715] [] (select_estimate_accuracy+0x83/0xac) from 
[] (do_select+0x281/0x28c)
[84919.257298] [] (do_select+0x281/0x28c) from [] 
(core_sys_select+0x14b/0x1cc)
[84919.266263] [] (core_sys_select+0x14b/0x1cc) from [] 
(sys_select+0x81/0xa4)
[84919.275140] [] (sys_select+0x81/0xa4) from [] 
(ret_fast_syscall+0x1/0x46)
[MBUS_HOLDING_RE[84919.286792] 5ac0: 75fc9559 00014c42 db279f7e e4877270 
3b9ac9ff 
AD] group=1 port[84919.295787] BUG: scheduling while atomic: 
gw61850/2388/0x4001
=2 addr=3 s[84919.303232] Modules linked in:ize=80 data=3da0 g_multi 3da0 
3

Re: [beagleboard] bbb Internal ADC configuration settings?

[William Hermans]

Audrey,

Also, if you need your samples to be taken precisely at 
apart. You'll have to use a PRU - Period. Linux is good for determinism at
around 200ms, which often times Linux *is* faster, but it's not guaranteed,
The PRU's on the other hand run outside of Linux( bare metal essentially ),
and can be very precise timing wise.

SO with using the PRUs, sometimes it's not about how fast you need
something, but how deterministic you need something.

On Fri, Mar 18, 2016 at 2:56 PM, William Hermans  wrote:

> Audrey,
>
> Please read the link I gave you a couple weeks ago . . .
> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide#Continuous_Mode
>
> Everything you need to know to use the ADC is explained on this page. But
> from your last post, and the paths you've shown us. You're in the wrong
> directory. Essentially, you're still in the one-shot directories, which are
> completely separate from the continuous mode directory structure.
>
> On Fri, Mar 18, 2016 at 1:46 PM, John Syne  wrote:
>
>> What is your kernel version?
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Mar 18, 2016, at 1:22 PM, Audrey  wrote:
>>
>> It says:
>> root@beaglebone:/# echo 1 >
>> /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en
>> -bash: /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en: No
>> such file or directory
>>
>> and I can't find scan_elements in sys/bus/iio/devices/iio:device0
>> root@beaglebone:/sys/bus/iio/devices/iio:device0# ls -l
>> total 0
>> -r--r--r-- 1 root root 4096 Mar  1 21:13 dev
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage0_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage1_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage2_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage3_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage4_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage5_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage6_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage7_raw
>> -r--r--r-- 1 root root 4096 Mar  1 21:13 name
>> drwxr-xr-x 2 root root0 Mar  1 21:13 power
>> lrwxrwxrwx 1 root root0 Mar  1 20:47 subsystem ->
>> ../../../../../bus/iio
>> -rw-r--r-- 1 root root 4096 Mar  1 20:47 uevent
>>
>>
>> On Friday, March 18, 2016 at 4:15:00 PM UTC-4, john3909 wrote:
>>>
>>>
>>> On Mar 18, 2016, at 1:06 PM, Audrey  wrote:
>>>
>>> Hm.
>>>
>>> Sorry, but unfortunately I'm still quite a bit lost. What should I be
>>> doing to dev/iio:device0 (open?) in order to do the following:
>>> echo 1 > in_voltage0_en
>>>
>>> From memory,
>>>
>>> echo 1 > /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en
>>>
>>> echo 1 > buffer/enable
>>>
>>> echo 1 > /sys/bus/iio/devices/iio:device0/buffer/enable
>>>
>>> Regards,
>>> John
>>>
>>>
>>> I'm assuming that I should be able to see in_voltage0_en and buffer in
>>> the folder /sys/bus/iio/devices/iio:device0 but I currently do not see
>>> those attributes/drivers/folders/buffers/whatever-you-want-to-call-them.
>>>
>>> Typing
>>> root@beaglebone:/dev# open iio:device0
>>> doesn't seem to do anything.
>>>
>>> Do you think you could break your steps down even further?
>>>
>>> Thanks.
>>>
>>> On Friday, March 18, 2016 at 3:49:39 PM UTC-4, john3909 wrote:

 It is a driver, so you can open, poll and read from /dev/iio:device0

 For a quick test, do the following: After you enable the various
 scan_channels, start the buffer and then do the following:

 dd if=/dev/iio:device0 of=~/test.txt

 Press ctrl-C to stop capture.

 Use hexdump to view the file.

 Regards,
 John




 On Mar 18, 2016, at 12:37 PM, Audrey  wrote:

 It says:
 root@beaglebone:/dev# cd iio:device0
 -bash: cd: iio:device0: Not a directory
 root@beaglebone:/dev# cat iio:device0
 cat: iio:device0: Invalid argument


 On Friday, March 18, 2016 at 3:25:13 PM UTC-4, john3909 wrote:
>
> The buffer is available here:
>
> /dev/iio:device0
>
> Because the driver uses interrupts, you won’t get the speed you want.
> The driver has to be updated to use DMA if you want to use full speed.
> Reading from the buffer will reduce your CPU load compared to using
> LDR_PATH because this interface blocks until a sample is available, but 
> not
> long enough for the thread to sleep. To use DMA, IIO have introduced a DMA
> framework and most of what you need is already available. However, IIO are
> going to be updating the IIO DMA framework to do zero copy between the
> kernel module and the socket interface, using MMU maps.
>
> Regards,
> John
>
>
>
>
> On Mar 18, 2016, at 11:21 AM, Audrey  wrote:
>
> Hi everyone,
>
> First of all, thank you everyone for trying to help me. I appreciate
> everyone's input.
>
> I took everyone's advice, and have moved away from bash to C++. It's
> clocking 

Re: [beagleboard] bbb Internal ADC configuration settings?

[John Syne]

Again this is wrong. The scan cycle determines the sampling rate and these 
samples are then fed to the fifo. As long as the interrupt services the 64 
sample fifo before it overflows, then no samples are lost. In essence, the 
driver can easily keep up. 

Regards,
John




> On Mar 18, 2016, at 3:07 PM, William Hermans  wrote:
> 
> Audrey, 
> 
> Also, if you need your samples to be taken precisely at  
> apart. You'll have to use a PRU - Period. Linux is good for determinism at 
> around 200ms, which often times Linux *is* faster, but it's not guaranteed, 
> The PRU's on the other hand run outside of Linux( bare metal essentially ), 
> and can be very precise timing wise.
> 
> SO with using the PRUs, sometimes it's not about how fast you need something, 
> but how deterministic you need something. 
> 
> On Fri, Mar 18, 2016 at 2:56 PM, William Hermans  > wrote:
> Audrey,
> 
> Please read the link I gave you a couple weeks ago . . . 
> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide#Continuous_Mode
>  
> 
> 
> Everything you need to know to use the ADC is explained on this page. But 
> from your last post, and the paths you've shown us. You're in the wrong 
> directory. Essentially, you're still in the one-shot directories, which are 
> completely separate from the continuous mode directory structure.
> 
> On Fri, Mar 18, 2016 at 1:46 PM, John Syne  > wrote:
> What is your kernel version?
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 18, 2016, at 1:22 PM, Audrey mailto:a...@smith.edu>> 
>> wrote:
>> 
>> It says:
>> root@beaglebone:/# echo 1 > 
>> /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en
>> -bash: /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en: No such 
>> file or directory
>> 
>> and I can't find scan_elements in sys/bus/iio/devices/iio:device0
>> root@beaglebone:/sys/bus/iio/devices/iio:device0# ls -l
>> total 0
>> -r--r--r-- 1 root root 4096 Mar  1 21:13 dev
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage0_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage1_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage2_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage3_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage4_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage5_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage6_raw
>> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage7_raw
>> -r--r--r-- 1 root root 4096 Mar  1 21:13 name
>> drwxr-xr-x 2 root root0 Mar  1 21:13 power
>> lrwxrwxrwx 1 root root0 Mar  1 20:47 subsystem -> ../../../../../bus/iio
>> -rw-r--r-- 1 root root 4096 Mar  1 20:47 uevent
>> 
>> 
>> On Friday, March 18, 2016 at 4:15:00 PM UTC-4, john3909 wrote:
>> 
>>> On Mar 18, 2016, at 1:06 PM, Audrey > wrote:
>>> 
>>> Hm. 
>>> 
>>> Sorry, but unfortunately I'm still quite a bit lost. What should I be doing 
>>> to dev/iio:device0 (open?) in order to do the following:
>>> echo 1 > in_voltage0_en
>> From memory, 
>> 
>> echo 1 > /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en
>>> echo 1 > buffer/enable
>> echo 1 > /sys/bus/iio/devices/iio:device0/buffer/enable
>> 
>> Regards,
>> John
>>> 
>>> I'm assuming that I should be able to see in_voltage0_en and buffer in the 
>>> folder /sys/bus/iio/devices/iio:device0 but I currently do not see those 
>>> attributes/drivers/folders/buffers/whatever-you-want-to-call-them.
>>> 
>>> Typing 
>>> root@beaglebone:/dev# open iio:device0
>>> doesn't seem to do anything.
>>> 
>>> Do you think you could break your steps down even further?
>>> 
>>> Thanks.
>>> 
>>> On Friday, March 18, 2016 at 3:49:39 PM UTC-4, john3909 wrote:
>>> It is a driver, so you can open, poll and read from /dev/iio:device0
>>> 
>>> For a quick test, do the following: After you enable the various 
>>> scan_channels, start the buffer and then do the following:
>>> 
>>> dd if=/dev/iio:device0 of=~/test.txt
>>> 
>>> Press ctrl-C to stop capture.
>>> 
>>> Use hexdump to view the file. 
>>> 
>>> Regards,
>>> John
>>> 
>>> 
>>> 
>>> 
 On Mar 18, 2016, at 12:37 PM, Audrey smith.edu 
 > wrote:
 
 It says:
 root@beaglebone:/dev# cd iio:device0
 -bash: cd: iio:device0: Not a directory
 root@beaglebone:/dev# cat iio:device0
 cat: iio:device0: Invalid argument
 
 
 On Friday, March 18, 2016 at 3:25:13 PM UTC-4, john3909 wrote:
 The buffer is available here:
 
 /dev/iio:device0
 
 Because the driver uses interrupts, you won’t get the speed you want. The 
 driver has to be updated to use DMA if you want to use full speed. Reading 
 from the buffer will reduce your CPU load compared to using LDR_PATH 
 because this interface blocks until a sample is available, but not long 
 enough for the thread to sleep. To use DMA, IIO have introduced a DMA 
 fram

Re: [beagleboard] Jessie debian lxqt

[danielbenevides]

Hello Robert and Everyone.

I'm a newbie with beaglebones black running debian...

I'm having a problem with connman and the interfaces file.

The problem arises with a beaglebone black rev c and the 
image BBB-eMMC-flasher-debian-8.3-iot-armhf-2016-03-13-4gb.img, but also 
happened with BBB-eMMC-flasher-debian-8.3-lxqt-4gb-armhf-2016-03-13-4gb.img.

The same beaglebone worked with a debian wheezy image installed...

Here is the problem: I cannot access the network through eth0.

I've found the instructions in this thread and removed connman, but the 
problem remains.

I have the following configuration on the beaglebone:

* /etc/network/interfaces file:*

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static
address 192.168.20.79
netmask 255.255.255.0
network 192.168.20.0
broadcast 192.168.20.255
gateway 192.168.20.1
dns-name-servers 192.168.20.200

iface usb0 inet static
address 192.168.7.2
netmask 255.255.255.252
network 192.168.7.0
gateway 192.168.7.1


* /etc/resolv.conf:*

nameserver 192.168.20.200
nameserver 8.8.8.8
nameserver 4.4.4.4

* ifconfig command returns:*

eth0  Link encap:Ethernet  HWaddr 54:4a:16:f0:f1:f0
  inet addr:192.168.20.79  Bcast:192.168.20.255  Mask:255.255.255.0
  inet6 addr: fe80::564a:16ff:fef0:f1f0/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:2652 errors:0 dropped:1 overruns:0 frame:0
  TX packets:2218 errors:16 dropped:63 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:272369 (265.9 KiB)  TX bytes:15461 (15.0 KiB)
  Interrupt:175

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:388 errors:0 dropped:0 overruns:0 frame:0
  TX packets:388 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:36764 (35.9 KiB)  TX bytes:36764 (35.9 KiB)

usb0  Link encap:Ethernet  HWaddr 54:4a:16:f0:f1:f1
  inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252
  inet6 addr: fe80::564a:16ff:fef0:f1f1/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:886 errors:0 dropped:5 overruns:0 frame:0
  TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:129397 (126.3 KiB)  TX bytes:9712 (9.4 KiB)

**  iptables -L command returns:*

Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

* route -n command returns:*

Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse 
Iface
0.0.0.0 192.168.20.10.0.0.0 UG0  00 eth0
192.168.7.0 0.0.0.0 255.255.255.252 U 0  00 usb0
192.168.20.00.0.0.0 255.255.255.0   U 0  00 eth0

REMARK: The first route I added manually - when the beaglebone boots, it 
was not configured, just the last two.

I cannot ping the beaglebone from another computer.
I cannot ping another computer from the beaglebone.

What am I missing?

Thanks in advance...

Regards,

Daniel.


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] X15 Availability

[Gerald Coley]

We expect to have the rev B1 boards in three weeks.
We will test the boards after they are assembled..
Then we will do the FCC testing.
*IF* it passes FCC, we should have boards out four four weeks after that.

So figure 8 weeks +/- from today.

Gerald


On Fri, Mar 18, 2016 at 5:30 AM,  wrote:

> Any update on the availability?
>
> On Saturday, March 12, 2016 at 8:34:36 AM UTC-5, Gerald wrote:
>>
>> For the most part, Rev A and B work about the same. Most changes are
>> layout related.
>>
>> Gerald
>>
>>
>> On Sat, Mar 12, 2016 at 1:42 AM,  wrote:
>>
>>> Hi
>>>
>>> I am very thankful if you update me about when Rev B can be ready for
>>> purchase, I want work with that in our new Year holidays, If it not very
>>> big change against Rev A, do you prefer me Rev A for my R&Ds and tests?
>>> I'm from Iran and new year is near.
>>>
>>> On Tuesday, February 9, 2016 at 4:39:05 AM UTC+3:30, Gerald wrote:

 We are working to get about 150 of the current revision out in the next
 few weeks to one distributor. We had some of the Rev A2 versions PCBs still
 available so we are working to build those up.

 If you look at http://elinux.org/Beagleboard:BeagleBoard-X15 you will
 see the latest official update on the Rev B version.

 Gerald


 On Mon, Feb 8, 2016 at 6:33 PM,  wrote:

> Is there any update on the shipping date?
> Are you still expecting to start shipping this month?
>
> On Thursday, December 24, 2015 at 10:24:32 AM UTC-6, Gerald wrote:
>>
>> Yes. We hope to start shipping in February. We had to make some
>> design changes in order to pass FCC.
>>
>> Gerald
>>
>> On Thu, Dec 24, 2015 at 9:18 AM,  wrote:
>>
>>> Previously a shipping date of the middle of December was mentioned.
>>> Has this date changed?
>>>
>>> --
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Gerald
>>
>> ger...@beagleboard.org
>> http://beagleboard.org/
>>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



 --
 Gerald

 ger...@beagleboard.org
 http://beagleboard.org/

>>> --
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Gerald
>>
>> ger...@beagleboard.org
>> http://beagleboard.org/
>>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/

-- 
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.
For more options, visit https://groups.google.com/d/optout.