Re: [beagleboard] 120VAC load switching interrupting PRU loop?

[John Syne]

My bet is you haven’t connected the GNDs correctly. Good design practices 
dictates that you connect all the GNDS to a single common point so that it 
looks like a star configuration. Think of every supply line has to be matched 
with a return line that connects to a GND source. If the GND for your 120VAC 
relay connects across the BBB ground plane, then you will see all kinds of 
problems. You external circuitry should only connect to the GND of the 5V 
barrel pin and not any of the other connectors or on the other side of the 5V 
cable. The BBB layout is good so I don’t believe it will be a EMC/SI issue. 

Regards,
John




> On Mar 9, 2016, at 4:17 PM, cresselander...@gmail.com wrote:
> 
> 
> I am working on a project where I have made modifications to the 
> beaglebone_pru_adc package available on GitHub here: 
> https://github.com/pgmmpk/beaglebone_pru_adc 
> 
> 
> The code loads in firmware as a *.bin file to run on the pru. It is complied 
> PRU assembly from a *.p file. 
> 
> My modifications were to implement a circular buffer in DDR based on the 
> oscilloscope_data() function in the module. This code grabs samples from the 
> adc like in the original code and stick the samples in DDR, but it also 
> updates memory pointers to wrap around. It loops indefinitely and respects 
> the cap_delay attribute.
> 
> The board is connected to provide fine grain analog data logging via current 
> transformer and voltage transformer on demand courtesy of the PRU. For 
> instance enabling RMS waveform calculation. I have also written a python 
> class that drives a latching relay. For test purposes I hooked a heavy ~10A 
> load to the relay. The PRU loop runs fine indefinitely using the analog log 
> to display RMS in the python code space. However, the PRU loop continues 
> running after the load is switched on or off but the PRU continues looping 
> only intermittently. The load is resistive, yet clearly the interruption is 
> correlated with switching the load on or off. Sometimes the PRU continues 
> running and sometimes it stops running but only during a switching event.
> 
> I understand BeagleLogic.net may be a good lead to follow. In the meantime, I 
> watch for the PRU to stop loading new samples into the DDR. Then I restart 
> it. Very kludgy. My question is have you seen anyone with similar problems 
> switching heavy load and using the PRU? Is there maybe an interrupt you think 
> might be breaking the PRU out of its loop? I can post code if it helps.
> 
> I really like these PRUs. Very slick to get real-time capabilities plus the 
> convenience of linux and speed of python prototyping.
> 
> Thanks,
> Cressel Anderson
> 
> -- 
> 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] bbb Internal ADC configuration settings?

[John Syne]

> On Mar 9, 2016, at 2:17 PM, William Hermans  wrote:
> 
> William,
> 
> Rather you should not comment on my replies. If I say white, you say black 
> even when you know you are wrong.
> 
> That's funny I was thinking the same, except your answer is wrong. 
> 
> If you look at the DT overlay the OP referenced, the additional entries don’t 
> exist and that is why I posted an updated DT overlay. Reading in_voltagex_raw 
> like your beaglebone-black-adc example was never meant for high speed 
> capture. In fact you are just reading the same sample over and over again. 
> 
> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide#One-shot_Mode
>  
> 
>  No one said anything about high speed capture. But have you actually ever 
> used one shot mode ? It is *NOT* reading the same sample over and over again. 
> But you do have to open / close the file every time you do want a new 
> reading. That's how it's supposed to work.
> 
> Reading the buffer via /dev/iio:device0 is how you are supposed to read IIO 
> ADC samples. 
> 
> No one ask that question.
> 
> If you want to understand oversampling, open delay, sample delay, then read 
> the AM3358 TRM. 
> 
> So in other words, you do not know. But again, this is not a question i asked 
> for myself. It's the question I interpreted Audry asking to which you 
> completely blew off.
You have this amazing ability to read peoples minds; at least you think you do. 
You should reframe from guessing what people know or don’t know, but you do 
make me smile when I read what you say. If you read the section I referenced in 
the TRM, it is explained very clearly. Why would I cut and past that is already 
explained. The ADC uses a scan cycle and in that cycle, it has an open delay, a 
sample delay and then it oversamples a predefined number of time. The 
oversampling helps increase the bits of resolution:

https://www.silabs.com/Support%20Documents/TechnicalDocs/an118.pdf 


The open delay and sample delay are used accommodate the sample error that 
occurs when the source impedance is too high. What isn’t in the TRM, but is 
understood by EE who design ADC front ends, an analog buffer like an opamp or a 
instrumentation amplifier or a chopper amplifier is used to eliminate offset 
errors and present a low impedance to the ADC sample and hold. If you don’t do 
this, you will see bleedover from one channel to another. Now this probably 
doesn’t make any sense to you because this is all to EE specific, but you did 
ask. 

Regards,
John
> 
>  
> 
> On Wed, Mar 9, 2016 at 11:24 AM, John Syne  > wrote:
> Look at AM3358 TRM Figure 12-3 on Page 1497
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 9, 2016, at 1:04 AM, William Hermans > > wrote:
>> 
>> John, also Audry asked what the values of that device tree fragment mean, 
>> not what the code was. As in Audry wants and explanation of the values:
>> 
>>  ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 
>> 0x16 0x16>;
>>  ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 
>> 0x98 0x98 0x98>;
>>  ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 
>> 0x0 0x0>;
>> 
>> As far as I can tell. Quite honestly I could use that explanation myself. 
>> But step avg can be a value 0-16 if memory serves from reading the TRM, I'm 
>> just not clear exactly on what step avg actually does. . . . the explanation 
>> in the TRM is very jumbled / confusing.
>> 
>> 
>> On Wed, Mar 9, 2016 at 1:58 AM, William Hermans > > wrote:
>> Now if you want to convey more information that is actually *useful* to 
>> anyone reading this post. You can say that both voltageX_raw, and 
>> iio:deviceX are buffers. 
>> 
>> With voltageX_raw being a single value buffer that gets updated only once 
>> every open() call on it's file descriptor.
>> 
>> Where iio:deviceX is a buffer, defined in size by the value set in 
>> /sys/bus/iio/devices/iio\:device0/buffer/length
>> 
>> More *useful* information can be found here: 
>> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide 
>> . Then if 
>> you want even more information still, googling "iio" will produce a lot of 
>> information. Much of it not so useful. At least for our use case, the 
>> Beaglebone.
>> 
>> On Wed, Mar 9, 2016 at 1:47 AM, William Hermans > > wrote:
>> what the hell does what you've said there even mean John ? voltagex_raw is 
>> one shot mode, iio:deviceX is continuous mode.
>> 
>> What you said above only serves to confuse the situation.
>> 
>> On Wed, Mar 9, 2016 at 1:32 AM, John Syne 

[beagleboard] Re: Finger touch/mouse left click stopped working on LCD Touchscreen 4DCape-70T for BeagleBoneBlack

[Radovan Chovan]

Ok, it has nothing with property ABS_PRESSURE. We can replicate issue even 
when there is no pressed action.
We try to manipulate with register CTRL of AM335X processor, but it didn't 
help.
Could it be problem with EMI???
When I am electrically charged and sometimes when I touch the display, the 
touch function recovers and touch works. 


-- 
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] Error while doing a apt-get update

[cornelius lee]

Hi all,

I am quite new to the world of Beaglebone and networking so please bare 
with me.

I tried to do a apt-get update and tried to run ./update_kernel.sh but have 
encountered the following errors.
Err http://repos.rcn-ee.com wheezy Release.gpg 


  Cannot initiate the connection to repos.rcn-ee.com:80 
(2600:3c00::f03c:91ff:fe37:6ad5). - connect (101: Network is unreachable) 
[IP: 2600:3c00::f03c:91ff:fe37:6ad5 80]

Any suggestions, please?


Regards,
Cornelius


-- 
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] PRU c compiler

[lkijmj]

Is the PRU c compiler free now? Can you use it without purchasing CCS6? 

-- 
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] Beaglebone Black + Audio codec TLV320AIC3106

[Dileep D R]

Hi,

 Below is the dtb configuration for audio routing,


sound {
   compatible = "ti,da830-evm-audio";
   ti,model = "DA830 EVM";
   ti,audio-codec = <>;
   ti,mcasp-controller = <>;
   ti,codec-clock-rate = <1200>;
  ti,audio-routing =
"Headphone Jack", "HPLOUT",
"Headphone Jack", "HPROUT",
"Line Out", "LLOUT",
"Line Out", "RLOUT",
"LINE1L", "Line In",
"LINE1R", "Line In";
};

I am able to hear audio on headphone when I play a wav file with aplay. But 
I also want output on*Line out* how to achieve the routing?


Thanks,

Dileep

-- 
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] 120VAC load switching interrupting PRU loop?

[Chris]

Do you have diode protection across the coil to prevent a flyback 
transient on your relay drive line?


On 3/9/2016 5:17 PM, cresselander...@gmail.com wrote:


I am working on a project where I have made modifications to the 
beaglebone_pru_adc package available on GitHub here: 
https://github.com/pgmmpk/beaglebone_pru_adc 



The code loads in firmware as a *.bin file to run on the pru. It is 
complied PRU assembly from a *.p file.


My modifications were to implement a circular buffer in DDR based on 
the oscilloscope_data() function in the module. This code grabs 
samples from the adc like in the original code and stick the samples 
in DDR, but it also updates memory pointers to wrap around. It loops 
indefinitely and respects the cap_delay attribute.


The board is connected to provide fine grain analog data logging via 
current transformer and voltage transformer on demand courtesy of the 
PRU. For instance enabling RMS waveform calculation. I have also 
written a python class that drives a latching relay. For test purposes 
I hooked a heavy ~10A load to the relay. The PRU loop runs fine 
indefinitely using the analog log to display RMS in the python code 
space. However, the PRU loop continues running after the load is 
switched on or off but the PRU continues looping only intermittently. 
The load is resistive, yet clearly the interruption is correlated with 
switching the load on or off. Sometimes the PRU continues running and 
sometimes it stops running but only during a switching event.


I understand BeagleLogic.net may be a good lead to follow. In the 
meantime, I watch for the PRU to stop loading new samples into the 
DDR. Then I restart it. Very kludgy. My question is have you seen 
anyone with similar problems switching heavy load and using the PRU? 
Is there maybe an interrupt you think might be breaking the PRU out of 
its loop? I can post code if it helps.


I really like these PRUs. Very slick to get real-time capabilities 
plus the convenience of linux and speed of python prototyping.


Thanks,
Cressel Anderson
--
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] 120VAC load switching interrupting PRU loop?

[William Hermans]

>
> *The PRU loop runs fine indefinitely using the analog log to display RMS
> in the python code space. However, the PRU loop continues running after the
> load is switched on or off but the PRU continues looping only
> intermittently. *
>

Outside looking in, this initially seems like a program flow error in your
code. It would help to see the actual code, but a couple other things come
to mind when thinking of your problem.

#1 I seem to recall reading *somewhere* that the ADC can be configured to
fill a buffer, and then stop taking samples until a related bit is
"flipped". Not sure I'm remembering this correctly or if I am if it
actually applies to this ADC module, or one on another embedded platform
I've been toying with lately . . .

#2 How  is the beaglebone isolated from the electrical?

On Wed, Mar 9, 2016 at 5:17 PM,  wrote:

>
> I am working on a project where I have made modifications to the
> beaglebone_pru_adc package available on GitHub here:
> https://github.com/pgmmpk/beaglebone_pru_adc
>
> The code loads in firmware as a *.bin file to run on the pru. It is
> complied PRU assembly from a *.p file.
>
> My modifications were to implement a circular buffer in DDR based on the
> oscilloscope_data() function in the module. This code grabs samples from
> the adc like in the original code and stick the samples in DDR, but it also
> updates memory pointers to wrap around. It loops indefinitely and respects
> the cap_delay attribute.
>
> The board is connected to provide fine grain analog data logging via
> current transformer and voltage transformer on demand courtesy of the PRU.
> For instance enabling RMS waveform calculation. I have also written a
> python class that drives a latching relay. For test purposes I hooked a
> heavy ~10A load to the relay. The PRU loop runs fine indefinitely using the
> analog log to display RMS in the python code space. However, the PRU loop
> continues running after the load is switched on or off but the PRU
> continues looping only intermittently. The load is resistive, yet clearly
> the interruption is correlated with switching the load on or off. Sometimes
> the PRU continues running and sometimes it stops running but only during a
> switching event.
>
> I understand BeagleLogic.net may be a good lead to follow. In the
> meantime, I watch for the PRU to stop loading new samples into the DDR.
> Then I restart it. Very kludgy. My question is have you seen anyone with
> similar problems switching heavy load and using the PRU? Is there maybe an
> interrupt you think might be breaking the PRU out of its loop? I can post
> code if it helps.
>
> I really like these PRUs. Very slick to get real-time capabilities plus
> the convenience of linux and speed of python prototyping.
>
> Thanks,
> Cressel Anderson
>
> --
> 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] 120VAC load switching interrupting PRU loop?

[cresselanderson]

I am working on a project where I have made modifications to the 
beaglebone_pru_adc package available on GitHub here: 
https://github.com/pgmmpk/beaglebone_pru_adc

The code loads in firmware as a *.bin file to run on the pru. It is 
complied PRU assembly from a *.p file. 

My modifications were to implement a circular buffer in DDR based on the 
oscilloscope_data() function in the module. This code grabs samples from 
the adc like in the original code and stick the samples in DDR, but it also 
updates memory pointers to wrap around. It loops indefinitely and respects 
the cap_delay attribute.

The board is connected to provide fine grain analog data logging via 
current transformer and voltage transformer on demand courtesy of the PRU. 
For instance enabling RMS waveform calculation. I have also written a 
python class that drives a latching relay. For test purposes I hooked a 
heavy ~10A load to the relay. The PRU loop runs fine indefinitely using the 
analog log to display RMS in the python code space. However, the PRU loop 
continues running after the load is switched on or off but the PRU 
continues looping only intermittently. The load is resistive, yet clearly 
the interruption is correlated with switching the load on or off. Sometimes 
the PRU continues running and sometimes it stops running but only during a 
switching event.

I understand BeagleLogic.net may be a good lead to follow. In the meantime, 
I watch for the PRU to stop loading new samples into the DDR. Then I 
restart it. Very kludgy. My question is have you seen anyone with similar 
problems switching heavy load and using the PRU? Is there maybe an 
interrupt you think might be breaking the PRU out of its loop? I can post 
code if it helps.

I really like these PRUs. Very slick to get real-time capabilities plus the 
convenience of linux and speed of python prototyping.

Thanks,
Cressel Anderson

-- 
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] Waiting for root device

[printesoi]

Thank you Robert,

That indeed fixes the problem and the kernel is able to boot.

Kind regards,
Victor Dodon.

On Wednesday, March 9, 2016 at 1:19:28 PM UTC-8, RobertCNelson wrote:
>
> On Wed, Mar 9, 2016 at 12:50 PM,   
> wrote: 
> > Hi Robert, 
> > 
> > On Tuesday, March 8, 2016 at 7:26:29 PM UTC-8, RobertCNelson wrote: 
> >> 
> >> On Tue, Mar 8, 2016 at 7:57 PM,   wrote: 
> >> > I'm trying to boot the 4.4.3 kernel from 
> >> > https://github.com/beagleboard/linux/tree/4.4 on a beaglebone white 
> and 
> >> > the 
> >> > kernel stops the boot after 'Waiting for root device' 
> >> 
> >> Here's that git checkout on a beaglebone black: 
> >> 
> >> https://paste.debian.net/413462/ 
> >> 
> >> I'll test it out on a white tomorrow.. 
> > 
> > 
> > I want to mention that I was able to boot the 4.1.18 kernel from the 
> same 
> > repo, but not the 4.4.3 kernel. The kernel 4.4 does not detect any 
> disks. 
> > 
> > I saw that in the kernel 4.4 the DT is a little changed and I tried to 
> > change the mmc1_pins configuration 
> > (
> https://github.com/beagleboard/linux/blob/4.4/arch/arm/boot/dts/am335x-bone-common.dtsi#L153
>  
> > ) to the configuration from the 4.1 kernel 
> > (
> https://github.com/beagleboard/linux/blob/4.1/arch/arm/boot/dts/am335x-bone-common.dtsi#L153
>  
> > ), but still no luck. 
>
> It's this change:  (i synced our 4.4.x dts tree with 4.5.x, and didn't 
> pull the revert in fast enough, i'll have a new push shortly) 
>
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot?id=e327b3f564031a8d0090a6b3e3562a8b59bafe0e
>  
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.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.

Re: [beagleboard] bbb Internal ADC configuration settings?

[William Hermans]

>
> *William,*
>
> *Rather you should not comment on my replies. If I say white, you say
> black even when you know you are wrong.*


That's funny I was thinking the same, except your answer is wrong.

*If you look at the DT overlay the OP referenced, the additional entries
> don’t exist and that is why I posted an updated DT overlay. Reading
> in_voltagex_raw like your beaglebone-black-adc example was never meant for
> high speed capture. In fact you are just reading the same sample over and
> over again. *
>

http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide#One-shot_Mode
No one said anything about high speed capture. But have you actually ever
used one shot mode ? It is *NOT* reading the same sample over and over
again. But you do have to open / close the file every time you do want a
new reading. That's how it's supposed to work.

*Reading the buffer via /dev/iio:device0 is how you are supposed to read
> IIO ADC samples.*
>

No one ask that question.

*If you want to understand oversampling, open delay, sample delay, then
> read the AM3358 TRM. *
>

So in other words, you do not know. But again, this is not a question i
asked for myself. It's the question I interpreted Audry asking to which you
completely blew off.



On Wed, Mar 9, 2016 at 11:24 AM, John Syne  wrote:

> Look at AM3358 TRM Figure 12-3 on Page 1497
>
> Regards,
> John
>
>
>
>
> On Mar 9, 2016, at 1:04 AM, William Hermans  wrote:
>
> John, also Audry asked what the values of that device tree fragment mean,
> not what the code was. As in Audry wants and explanation of the values:
>
> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
> ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 0x98 0x98 0x98>;
> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
>
> As far as I can tell. Quite honestly I could use that explanation myself.
> But step avg can be a value 0-16 if memory serves from reading the TRM, I'm
> just not clear exactly on what step avg actually does. . . . the
> explanation in the TRM is very jumbled / confusing.
>
>
> On Wed, Mar 9, 2016 at 1:58 AM, William Hermans  wrote:
>
>> Now if you want to convey more information that is actually *useful* to
>> anyone reading this post. You can say that both voltageX_raw, and
>> iio:deviceX are buffers.
>>
>> With voltageX_raw being a single value buffer that gets updated only
>> once every open() call on it's file descriptor.
>>
>> Where iio:deviceX is a buffer, defined in size by the value set in
>> /sys/bus/iio/devices/iio\:device0/buffer/length
>>
>> More *useful* information can be found here:
>> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide. Then
>> if you want even more information still, googling "iio" will produce a lot
>> of information. Much of it not so useful. At least for our use case, the
>> Beaglebone.
>>
>> On Wed, Mar 9, 2016 at 1:47 AM, William Hermans 
>> wrote:
>>
>>> what the hell does what you've said there even mean John ? voltagex_raw
>>> is one shot mode, iio:deviceX is continuous mode.
>>>
>>> What you said above only serves to confuse the situation.
>>>
>>> On Wed, Mar 9, 2016 at 1:32 AM, John Syne  wrote:
>>>
 /*
  * Copyright (C) 2012 Texas Instruments Incorporated -
 http://www.ti.com/
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
 /dts-v1/;
 /plugin/;

 / {
 compatible = "ti,beaglebone", "ti,beaglebone-black",
 "ti,beaglebone-green";

 /* identification */
 part-number = "BB-ADC";
 version = "00A0";

 /* state the resources this cape uses */
 exclusive-use =
 /* the pin header uses */
 "P9.31", /* AIN0 */
 "P9.40", /* AIN1 */
 "P9.37", /* AIN2 */
 "P9.38", /* AIN3 */
 "P9.33", /* AIN4 */
 "P9.36", /* AIN5 */
 "P9.35", /* AIN6 */
 /* the hardware ip uses */
 "tscadc";

 fragment@0 {
 target = <>;
 __overlay__ {

 status = "okay";
 adc {
 ti,adc-channels = <0 1 2 3 4 5 6>;
 ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
 ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 0x98 0x98 0x98>;
 ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
 };
 };
 };
 };

 Reading from /sys/bus/iio/devices/iio:device0/in_voltage0_raw is
 reading and attribute of the IIO driver. Reading from /dev/iio:device0 is
 reading from the same IIO driver, but in this case you are reading from the
 buffer which stores samples defined in the DT overlay above.

 Regards,
 John




 On Mar 8, 2016, at 9:51 PM, Audrey  wrote:

 Thanks for the reply John. Could you perhaps explain how to modify the
 oversample, open delay time, 

Re: [beagleboard] Waiting for root device

[William Hermans]

>
> *This is a Beaglebone White, so it does not have eMMC. *
>

Yeap, I knew that. But since I do not own a white, was not sure if
parttition was the same or not.

*The SD card has 12 partitions, because I'm trying to boot Chromium OS and
> the root partition it the 3rd partition.*
>

OK, I did not know that. I was just troubleshooting from where I know what
works on 4.1.x, but seem 4.4.x - 4.5.x have lots of issues. Not just this
one.

On Wed, Mar 9, 2016 at 2:18 PM, Robert Nelson 
wrote:

> On Wed, Mar 9, 2016 at 12:50 PM,   wrote:
> > Hi Robert,
> >
> > On Tuesday, March 8, 2016 at 7:26:29 PM UTC-8, RobertCNelson wrote:
> >>
> >> On Tue, Mar 8, 2016 at 7:57 PM,   wrote:
> >> > I'm trying to boot the 4.4.3 kernel from
> >> > https://github.com/beagleboard/linux/tree/4.4 on a beaglebone white
> and
> >> > the
> >> > kernel stops the boot after 'Waiting for root device'
> >>
> >> Here's that git checkout on a beaglebone black:
> >>
> >> https://paste.debian.net/413462/
> >>
> >> I'll test it out on a white tomorrow..
> >
> >
> > I want to mention that I was able to boot the 4.1.18 kernel from the same
> > repo, but not the 4.4.3 kernel. The kernel 4.4 does not detect any disks.
> >
> > I saw that in the kernel 4.4 the DT is a little changed and I tried to
> > change the mmc1_pins configuration
> > (
> https://github.com/beagleboard/linux/blob/4.4/arch/arm/boot/dts/am335x-bone-common.dtsi#L153
> > ) to the configuration from the 4.1 kernel
> > (
> https://github.com/beagleboard/linux/blob/4.1/arch/arm/boot/dts/am335x-bone-common.dtsi#L153
> > ), but still no luck.
>
> It's this change:  (i synced our 4.4.x dts tree with 4.5.x, and didn't
> pull the revert in fast enough, i'll have a new push shortly)
>
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot?id=e327b3f564031a8d0090a6b3e3562a8b59bafe0e
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.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.
>

-- 
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] BeagleBone Enhanced

[Jason Kridner]

On Mon, May 26, 2014 at 7:26 AM  wrote:

> Hi All
>
> We are looking at making a BeagleBone compatible board with some enhanced
> features. Rather than guess we would like your input as to what extra
> interfaces or devices would you want on the board?
>
> Either use the link to the form below or put your comments below as to
> what you would like.
>
> BeagleBone Enhanced Form
> 
>
> Personally I would want extra USB ports (with one on a header to connect
> to a cape) and maybe more RAM.
>
> David
> SanCloud
>

This has been a while coming, but they have now started an Indiegogo
campaign:

https://www.indiegogo.com/projects/sancloud-beaglebone-enhanced/x/7085817#/

Robert and I have gotten to play with the prototypes and they look good.
Just got the 1gigabit Ethernet version and will try that real soon now.


>
> --
> 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] Waiting for root device

[Robert Nelson]

On Wed, Mar 9, 2016 at 12:50 PM,   wrote:
> Hi Robert,
>
> On Tuesday, March 8, 2016 at 7:26:29 PM UTC-8, RobertCNelson wrote:
>>
>> On Tue, Mar 8, 2016 at 7:57 PM,   wrote:
>> > I'm trying to boot the 4.4.3 kernel from
>> > https://github.com/beagleboard/linux/tree/4.4 on a beaglebone white and
>> > the
>> > kernel stops the boot after 'Waiting for root device'
>>
>> Here's that git checkout on a beaglebone black:
>>
>> https://paste.debian.net/413462/
>>
>> I'll test it out on a white tomorrow..
>
>
> I want to mention that I was able to boot the 4.1.18 kernel from the same
> repo, but not the 4.4.3 kernel. The kernel 4.4 does not detect any disks.
>
> I saw that in the kernel 4.4 the DT is a little changed and I tried to
> change the mmc1_pins configuration
> (https://github.com/beagleboard/linux/blob/4.4/arch/arm/boot/dts/am335x-bone-common.dtsi#L153
> ) to the configuration from the 4.1 kernel
> (https://github.com/beagleboard/linux/blob/4.1/arch/arm/boot/dts/am335x-bone-common.dtsi#L153
> ), but still no luck.

It's this change:  (i synced our 4.4.x dts tree with 4.5.x, and didn't
pull the revert in fast enough, i'll have a new push shortly)

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot?id=e327b3f564031a8d0090a6b3e3562a8b59bafe0e

Regards,

-- 
Robert Nelson
https://rcn-ee.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.

[beagleboard] BBB doesn't boot after powering down when flashing a new image

[diego . rmsouza]

Hello,

I've got a new Beaglebone this week. 

I was trying to update it to the latest Debian image (Debian 8.3) found 
here: https://beagleboard.org/latest-images

I have downloaded the SD Card version and used the Win32 Disk Imager to 
write the image to the SD.. 

After succesfully testing it on the SD, I tried to turn the image into the 
eMMC doing what the website says:

"To turn these images into eMMC flasher images, edit the /boot/UEnv.txt 
file removing the "#" in the line 'cmdline=init=/opt/(...)"

I did that, put the SD Card in the slot, reseted the board holding the user 
button. It started to update.

However, after 2 hours, I though something went wrong, because the 4 LED's 
did not light togheter as the procedure says...

Then I removed the power from the board... That's were my problem begins. 
Now the board doesn't boot.

I have connected a Serial to USB module to the J1 connector to debug.

If I have the SD Card connected and hold the user button while reseting, 
this is the message I get in the debug:


U-Boot SPL 2016.01-1-g4eb802e (Jan 13 2016 - 11:14:31)
Trying to boot from MMC
bad magic
bad magic
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###


If I remove the SD Card and boot, this is what I get in the debug (do know 
how to copy the whole thing, I have just manage to copy the final message):


Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/mmcblk1p1 does not exist.  Dropping to a shell!
(initramfs)
**

I have tried several times to rewrite the SD Card and boot from it (holding 
the user button), whitout any success...

What can I do?

Thanks!

Diego

-- 
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] Using Connman for WiFi AP/tether...

[Jason Kridner]

On Wed, Mar 9, 2016 at 2:10 PM Brian Anderson  wrote:

>
>
>> Yeah, once we find a Windows "mDNS" discovery (like Bonjour but
>> distribtable) we can stick in that in the flash drive that pop's up,
>> and switch usb0 to connman..
>>
>
> Yes, thats a good idea.  Any while you are at it, maybe a "preconfigured"
> PuTTY or something like that so users can automagically and hassle free
> connect to their shiny new board via usb ethernet?
>

License is probably okay for that. Can you confirm, create the
customization, and send a pull request against
http://github.com/beagleboard/beaglebone-getting-started ?  :-D


>
>> >
>> > Also, this Wikipedia article on ".local" is enlightening.  The article
>> > suggests that counting on hostname.local resolution may not scale well
>> to
>> > Windoze environments.
>>
>> I think as long as it works on one, that's good enough for out of box. ;)
>>
>
> Yes, I guess that's correct!  External networks not involved!
>
> ba
>
> --
> 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] Using Connman for WiFi AP/tether...

[Brian Anderson]

>
> Yeah, once we find a Windows "mDNS" discovery (like Bonjour but 
> distribtable) we can stick in that in the flash drive that pop's up, 
> and switch usb0 to connman.. 
>

Yes, thats a good idea.  Any while you are at it, maybe a "preconfigured" 
PuTTY or something like that so users can automagically and hassle free 
connect to their shiny new board via usb ethernet?

>
> > 
> > Also, this Wikipedia article on ".local" is enlightening.  The article 
> > suggests that counting on hostname.local resolution may not scale well 
> to 
> > Windoze environments. 
>
> I think as long as it works on one, that's good enough for out of box. ;) 
>

Yes, I guess that's correct!  External networks not involved! 

ba

-- 
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] Debian Image Differences

[Robert Nelson]

On Wed, Mar 9, 2016 at 10:25 AM,   wrote:
>
> *What is the difference between the following Debian images :
> -console

"smallest"

> -iot,

lxqt image minus "lxqt/xserver"

> -lxqt

"biggest"

> for the BBB listed at the following URL
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_8:_jessie
>
> *And what is the difference between the Debian images at the following
> locations :
> https://rcn-ee.online/rootfs/bb.org/

My host for (rcn-ee.net/rcn-ee.com) (linode), disk space get's spendy
$.. "rcn-ee.online" is a mirror on dreamhost that's cheap, with
unlimited space, but slow ;)

> and
> https://rcn-ee.com/rootfs/eewiki

Simple rootfs for:

https://eewiki.net/display/linuxonarm/BeagleBone+Black

Regards,

-- 
Robert Nelson
https://rcn-ee.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.

Re: [beagleboard] Using Connman for WiFi AP/tether...

[Brian Anderson]

> >>> >> Drop dnsmasq/create_ap, add back udhcpd 
>

Just curious, why udhcpd rather than dnsmasq?  Isn't dnsmasq supposed to be 
"light weight"?  Err, lighter than udhcpd?  What is the difference between 
the two? 
 

> >>  I presume you 
> >> have told Connman to ignore usbx  interfaces in /etc/connman/main.conf? 
> > 
> > Here's the configuration i'm using at the moment, i'll test adding an 
> > ignore for usbx 
> > 
> > 
> https://github.com/RobertCNelson/omap-image-builder/blob/master/target/chroot/beagleboard.org-jessie.sh#L190-L220


Hmm, I see you are ignoring usb0 rather than all usb interfaces.  I suppose 
that is the only possiblity on BBB.  Not sure about other boards.

BTW, does it work to put a USB hub between the host and gadget and thus 
connect multiple hosts (laptop, desktop, etc.) to the usb ethernet and thus 
serve up many IP addresses from usb0 gadget?

 

> Okay, that should solve a race: 
>

Cool. 

ba

-- 
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] Waiting for root device

[printesoi]

Hi William,

On Tuesday, March 8, 2016 at 7:21:27 PM UTC-8, William Hermans wrote:
>
> Additionally, are you sure you have 3 partitions on your MMC device ? 
> Typically on modern RCN releases there is only one.
>
> On Tue, Mar 8, 2016 at 8:18 PM, William Hermans  > wrote:
>
>> So here is a silly question. Are you sure /dev/mmcblk0p3 even exists ? 
>> because mmcblk0 on the beaglebone black would be the eMMC . . .
>>
>
This is a Beaglebone White, so it does not have eMMC. The SD card has 12 
partitions, because I'm trying to boot Chromium OS and the root partition 
it the 3rd partition.
 

>
>>
>> On Tue, Mar 8, 2016 at 6:57 PM,  
>> wrote:
>>
>>> I'm trying to boot the 4.4.3 kernel from 
>>> https://github.com/beagleboard/linux/tree/4.4 on a beaglebone white and 
>>> the kernel stops the boot after 'Waiting for root device'
>>>
>>> The MMC* and REGULATOR* options are enabled:
>>> CONFIG_MMC=y
>>> CONFIG_MMC_BLOCK=y
>>> CONFIG_MMC_BLOCK_MINORS=16
>>> CONFIG_MMC_BLOCK_BOUNCE=y
>>> CONFIG_MMC_OMAP=y
>>> CONFIG_MMC_OMAP_HS=y
>>> CONFIG_REGULATOR=y
>>> CONFIG_REGULATOR_FIXED_VOLTAGE=y
>>> CONFIG_REGULATOR_USERSPACE_CONSUMER=y
>>> CONFIG_REGULATOR_ACT8865=m
>>> CONFIG_REGULATOR_ANATOP=y
>>> CONFIG_REGULATOR_AS3722=y
>>> CONFIG_REGULATOR_AXP20X=y
>>> CONFIG_REGULATOR_DA9052=y
>>> CONFIG_REGULATOR_DA9063=y
>>> CONFIG_REGULATOR_FAN53555=m
>>> CONFIG_REGULATOR_GPIO=y
>>> CONFIG_REGULATOR_MC13XXX_CORE=m
>>> CONFIG_REGULATOR_MC13783=m
>>> CONFIG_REGULATOR_MC13892=m
>>> CONFIG_REGULATOR_MT6311=y
>>> CONFIG_REGULATOR_PALMAS=y
>>> CONFIG_REGULATOR_PBIAS=y
>>> CONFIG_REGULATOR_PFUZE100=y
>>> CONFIG_REGULATOR_PWM=y
>>> CONFIG_REGULATOR_S2MPA01=m
>>> CONFIG_REGULATOR_S2MPS11=m
>>> CONFIG_REGULATOR_S5M8767=m
>>> CONFIG_REGULATOR_TI_ABB=y
>>> CONFIG_REGULATOR_TPS65023=y
>>> CONFIG_REGULATOR_TPS6507X=y
>>> CONFIG_REGULATOR_TPS65217=y
>>> CONFIG_REGULATOR_TPS65218=y
>>> CONFIG_REGULATOR_TPS65910=y
>>> CONFIG_REGULATOR_TWL4030=y
>>> CONFIG_REGULATOR_VEXPRESS=m
>>>
>>> The config is generated from bb.org_defconfig.
>>>
>>> The full boot log is:
>>> ## Booting kernel from Legacy Image at 8200 ...
>>>Image Name:   Linux-4.4.3+
>>>Image Type:   ARM Linux Kernel Image (no loading done) (uncompressed)
>>>Data Size:8112968 Bytes = 7.7 MiB
>>>Load Address: fff2
>>>Entry Point:  fff2
>>>Verifying Checksum ... OK
>>> ## Flattened Device Tree blob at 8800
>>>Booting using the fdt blob at 0x8800
>>>XIP Kernel Image (no loading done) ... OK
>>>Using Device Tree in place at 8800, end 88010cb3
>>>
>>> Starting kernel ...
>>>
>>> [0.00] Booting Linux on physical CPU 0x0
>>> [0.00] Initializing cgroup subsys cpuset
>>> [0.00] Initializing cgroup subsys cpu
>>> [0.00] Initializing cgroup subsys cpuacct
>>> [0.00] Linux version 4.4.3+ () (gcc version 4.9.x-google 
>>> 20150123 (prerelease) (4.9.2_cos_gg_21201ea_4.9.2-r116) ) #30 Tue Mar 8 
>>> 17:27:58 PST 2016
>>> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
>>> cr=10c5387d
>>> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
>>> instruction cache
>>> [0.00] Machine model: TI AM335x BeagleBone
>>> [0.00] cma: Reserved 24 MiB at 0x8e80
>>> [0.00] Memory policy: Data cache writeback
>>> [0.00] CPU: All CPU(s) started in SVC mode.
>>> [0.00] AM335X ES1.0 (sgx neon )
>>> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  
>>> Total pages: 64960
>>> [0.00] Kernel command line: console=ttyO0,115200n8 loglevel=7 
>>> init=/sbin/init cros_legacy cros_debug oops=panic panic=-1 noinitrd 
>>> vt.global_cursor_default=0 
>>> capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4,BB-UART5,bone-servo-gpios,bone-servo-spi1
>>>  
>>> root=/dev/mmcblk0p3 ro rootfstype=ext4 rootwait
>>> [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
>>> [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 
>>> bytes)
>>> [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 
>>> bytes)
>>> [0.00] Memory: 218028K/262144K available (10677K kernel code, 
>>> 836K rwdata, 3704K rodata, 592K init, 857K bss, 19540K reserved, 24576K 
>>> cma-reserved, 0K highmem)
>>> [0.00] Virtual kernel memory layout:
>>> [0.00] vector  : 0x - 0x1000   (   4 kB)
>>> [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
>>> [0.00] vmalloc : 0xd080 - 0xff80   ( 752 MB)
>>> [0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
>>> [0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
>>> [0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
>>> [0.00]   .text : 0xc0008000 - 0xc0e1370c   (14382 kB)
>>> [0.00]   .init : 0xc0e14000 - 0xc0ea8000   ( 592 kB)
>>> [0.00]   .data : 0xc0ea8000 - 0xc0f791c8   ( 837 kB)

Re: [beagleboard] Waiting for root device

[printesoi]

Hi Robert,

On Tuesday, March 8, 2016 at 7:26:29 PM UTC-8, RobertCNelson wrote:
>
> On Tue, Mar 8, 2016 at 7:57 PM,   
> wrote: 
> > I'm trying to boot the 4.4.3 kernel from 
> > https://github.com/beagleboard/linux/tree/4.4 on a beaglebone white and 
> the 
> > kernel stops the boot after 'Waiting for root device' 
>
> Here's that git checkout on a beaglebone black: 
>
> https://paste.debian.net/413462/ 
>
> I'll test it out on a white tomorrow.. 
>

I want to mention that I was able to boot the 4.1.18 kernel from the same 
repo, but not the 4.4.3 kernel. The kernel 4.4 does not detect any disks.

I saw that in the kernel 4.4 the DT is a little changed and I tried to 
change the mmc1_pins configuration 
(https://github.com/beagleboard/linux/blob/4.4/arch/arm/boot/dts/am335x-bone-common.dtsi#L153
 
) to the configuration from the 4.1 kernel 
(https://github.com/beagleboard/linux/blob/4.1/arch/arm/boot/dts/am335x-bone-common.dtsi#L153
 
), but still no luck.

Thank you,
Victor.
 

>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.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.

[beagleboard] Debian Image Differences

[ninjakernel]

*What is the difference between the following Debian images :
-console
-iot, 
-lxqt 
for the BBB listed at the following URL
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_8:_jessie

*And what is the difference between the Debian images at the following 
locations :
https://rcn-ee.online/rootfs/bb.org/
and
https://rcn-ee.com/rootfs/eewiki

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.

Re: [beagleboard] Using Connman for WiFi AP/tether...

[Robert Nelson]

On Wed, Mar 9, 2016 at 12:26 PM, Brian Anderson  wrote:
>
>> >> yeah, very racy, and a bad idea. ;)
>> >>
>> >> So i now have things working a littler closer to a connman only
>> >> solution..
>> >>
>> >> Drop dnsmasq/create_ap, add back udhcpd
>> >>
>> >> usb0 : udhcpd (192.168.7.2)
>> >> wlan0: connman ap (192.168.0.1)
>
>
> Assuming Connman manages wlanx (AP or STA) as well as ethx.

Correct

>  I presume you
> have told Connman to ignore usbx  interfaces in /etc/connman/main.conf?

Here's the configuration i'm using at the moment, i'll test adding an
ignore for usbx

https://github.com/RobertCNelson/omap-image-builder/blob/master/target/chroot/beagleboard.org-jessie.sh#L190-L220

>> >> Windows 10 (usb0, beaglebone.local doesn't work)
>
>
> Hmm.  So, if udhcpd is managing the _static_ address on usb0, then counting
> on mDNS hostname discovery in no longer a requirement, just a nice to have?
> For Windoze users, they call still access via static IP, other platforms can
> access via static IP via hostname.local.  With that said, if we do include
> mDNS for Windoze users, and start advertising hostname.local as the
> _preferred_ way of access, then _eventually_ we could rid ourselves of the
> static IP access method.

Yeah, once we find a Windows "mDNS" discovery (like Bonjour but
distribtable) we can stick in that in the flash drive that pop's up,
and switch usb0 to connman..

>
> Also, this Wikipedia article on ".local" is enlightening.  The article
> suggests that counting on hostname.local resolution may not scale well to
> Windoze environments.

I think as long as it works on one, that's good enough for out of box. ;)

Regards,

-- 
Robert Nelson
https://rcn-ee.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.

Re: [beagleboard] Using Connman for WiFi AP/tether...

[Brian Anderson]

> >> yeah, very racy, and a bad idea. ;) 
> >> 
> >> So i now have things working a littler closer to a connman only 
> solution.. 
> >> 
> >> Drop dnsmasq/create_ap, add back udhcpd 
> >> 
> >> usb0 : udhcpd (192.168.7.2) 
> >> wlan0: connman ap (192.168.0.1) 
>

Assuming Connman manages wlanx (AP or STA) as well as ethx.  I presume you 
have told Connman to ignore usbx  interfaces in /etc/connman/main.conf?

>> 
> >> Windows 10 (usb0, beaglebone.local doesn't work) 
>

Hmm.  So, if udhcpd is managing the _static_ address on usb0, then counting 
on mDNS hostname discovery in no longer a requirement, just a nice to 
have?  For Windoze users, they call still access via static IP, other 
platforms can access via static IP via hostname.local.  With that said, if 
we do include mDNS for Windoze users, and start advertising hostname.local 
as the _preferred_ way of access, then _eventually_ we could rid ourselves 
of the static IP access method.

Also, this  Wikipedia article on 
".local" is enlightening.  The article suggests that counting on 
hostname.local resolution may not scale well to Windoze environments.

>> 
> >> I wonder Jason's thought on "shipping" this installer? 
> >> 
> >> https://support.apple.com/kb/DL999?locale=en_US 
> > 
> > Does it work? 
>
> It does work on Windows 10, "http://beaglebone.local; comes up over 
> usb0 just fine.. 
>
> >Do they provide a redistribution license? 
>
> I haven't found a clear license on that, everyone seems to link to it. 
> Or users are too cut it out of the itunes.exe binary.. yuck. 
>
> (maybe we can just link in the documentation for windows users) 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.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.

Re: [beagleboard] bbb Internal ADC configuration settings?

[John Syne]

Look at AM3358 TRM Figure 12-3 on Page 1497

Regards,
John




> On Mar 9, 2016, at 1:04 AM, William Hermans  wrote:
> 
> John, also Audry asked what the values of that device tree fragment mean, not 
> what the code was. As in Audry wants and explanation of the values:
> 
>   ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 
> 0x16 0x16>;
>   ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 
> 0x98 0x98 0x98>;
>   ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 
> 0x0 0x0>;
> 
> As far as I can tell. Quite honestly I could use that explanation myself. But 
> step avg can be a value 0-16 if memory serves from reading the TRM, I'm just 
> not clear exactly on what step avg actually does. . . . the explanation in 
> the TRM is very jumbled / confusing.
> 
> 
> On Wed, Mar 9, 2016 at 1:58 AM, William Hermans  > wrote:
> Now if you want to convey more information that is actually *useful* to 
> anyone reading this post. You can say that both voltageX_raw, and iio:deviceX 
> are buffers. 
> 
> With voltageX_raw being a single value buffer that gets updated only once 
> every open() call on it's file descriptor.
> 
> Where iio:deviceX is a buffer, defined in size by the value set in 
> /sys/bus/iio/devices/iio\:device0/buffer/length
> 
> More *useful* information can be found here: 
> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide 
> . Then if 
> you want even more information still, googling "iio" will produce a lot of 
> information. Much of it not so useful. At least for our use case, the 
> Beaglebone.
> 
> On Wed, Mar 9, 2016 at 1:47 AM, William Hermans  > wrote:
> what the hell does what you've said there even mean John ? voltagex_raw is 
> one shot mode, iio:deviceX is continuous mode.
> 
> What you said above only serves to confuse the situation.
> 
> On Wed, Mar 9, 2016 at 1:32 AM, John Syne  > wrote:
> /*
>  * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ 
> 
>  *
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License version 2 as
>  * published by the Free Software Foundation.
>  */
> /dts-v1/;
> /plugin/;
> 
> / {
>   compatible = "ti,beaglebone", "ti,beaglebone-black", 
> "ti,beaglebone-green";
> 
>   /* identification */
>   part-number = "BB-ADC";
>   version = "00A0";
> 
>   /* state the resources this cape uses */
>   exclusive-use =
>   /* the pin header uses */
>   "P9.31",/* AIN0 */
>   "P9.40",/* AIN1 */
>   "P9.37",/* AIN2 */
>   "P9.38",/* AIN3 */
>   "P9.33",/* AIN4 */
>   "P9.36",/* AIN5 */
>   "P9.35",/* AIN6 */
>   /* the hardware ip uses */
>   "tscadc";
> 
>   fragment@0 {
>   target = <>;
>   __overlay__ {
> 
>   status = "okay";
>   adc {
>   ti,adc-channels = <0 1 2 3 4 5 6>;
>   ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 
> 0x16 0x16>;
>   ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 
> 0x98 0x98 0x98>;
>   ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 
> 0x0 0x0>;
>   };
>   };
>   };
> };
> 
> Reading from /sys/bus/iio/devices/iio:device0/in_voltage0_raw is reading and 
> attribute of the IIO driver. Reading from /dev/iio:device0 is reading from 
> the same IIO driver, but in this case you are reading from the buffer which 
> stores samples defined in the DT overlay above. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 8, 2016, at 9:51 PM, Audrey > 
>> wrote:
>> 
>> Thanks for the reply John. Could you perhaps explain how to modify the 
>> oversample, open delay time, and sample time in greater detail in the BB-ADC 
>> overlay? I do not see these variables in the dto in github 
>> (https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-ADC-00A0.dts
>>  
>> ).
>>  Also, what value can/should I change them to?
>> 
>> So just to clarify, reading from 
>> /sys/bus/iio/devices/iio:device0/in_voltage0_raw reads attributes using 
>> sysfs, while reading from /dev/iio:device0 reads the values using IIO? Also 
>> another conceptual question, can you explain what exactly is in_voltage0_raw 
>> and iio:device0? I know it's not a folder, and I interact with it by using 
>> cat. So 

Re: [beagleboard] bbb Internal ADC configuration settings?

[John Syne]

http://events.linuxfoundation.org/sites/events/files/slides/lceu15_baluta.pdf 


Regards,
John




> On Mar 9, 2016, at 12:58 AM, William Hermans  wrote:
> 
> Now if you want to convey more information that is actually *useful* to 
> anyone reading this post. You can say that both voltageX_raw, and iio:deviceX 
> are buffers. 
> 
> With voltageX_raw being a single value buffer that gets updated only once 
> every open() call on it's file descriptor.
> 
> Where iio:deviceX is a buffer, defined in size by the value set in 
> /sys/bus/iio/devices/iio\:device0/buffer/length
> 
> More *useful* information can be found here: 
> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide 
> . Then if 
> you want even more information still, googling "iio" will produce a lot of 
> information. Much of it not so useful. At least for our use case, the 
> Beaglebone.
> 
> On Wed, Mar 9, 2016 at 1:47 AM, William Hermans  > wrote:
> what the hell does what you've said there even mean John ? voltagex_raw is 
> one shot mode, iio:deviceX is continuous mode.
> 
> What you said above only serves to confuse the situation.
> 
> On Wed, Mar 9, 2016 at 1:32 AM, John Syne  > wrote:
> /*
>  * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ 
> 
>  *
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License version 2 as
>  * published by the Free Software Foundation.
>  */
> /dts-v1/;
> /plugin/;
> 
> / {
>   compatible = "ti,beaglebone", "ti,beaglebone-black", 
> "ti,beaglebone-green";
> 
>   /* identification */
>   part-number = "BB-ADC";
>   version = "00A0";
> 
>   /* state the resources this cape uses */
>   exclusive-use =
>   /* the pin header uses */
>   "P9.31",/* AIN0 */
>   "P9.40",/* AIN1 */
>   "P9.37",/* AIN2 */
>   "P9.38",/* AIN3 */
>   "P9.33",/* AIN4 */
>   "P9.36",/* AIN5 */
>   "P9.35",/* AIN6 */
>   /* the hardware ip uses */
>   "tscadc";
> 
>   fragment@0 {
>   target = <>;
>   __overlay__ {
> 
>   status = "okay";
>   adc {
>   ti,adc-channels = <0 1 2 3 4 5 6>;
>   ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 
> 0x16 0x16>;
>   ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 
> 0x98 0x98 0x98>;
>   ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 
> 0x0 0x0>;
>   };
>   };
>   };
> };
> 
> Reading from /sys/bus/iio/devices/iio:device0/in_voltage0_raw is reading and 
> attribute of the IIO driver. Reading from /dev/iio:device0 is reading from 
> the same IIO driver, but in this case you are reading from the buffer which 
> stores samples defined in the DT overlay above. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 8, 2016, at 9:51 PM, Audrey > 
>> wrote:
>> 
>> Thanks for the reply John. Could you perhaps explain how to modify the 
>> oversample, open delay time, and sample time in greater detail in the BB-ADC 
>> overlay? I do not see these variables in the dto in github 
>> (https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-ADC-00A0.dts
>>  
>> ).
>>  Also, what value can/should I change them to?
>> 
>> So just to clarify, reading from 
>> /sys/bus/iio/devices/iio:device0/in_voltage0_raw reads attributes using 
>> sysfs, while reading from /dev/iio:device0 reads the values using IIO? Also 
>> another conceptual question, can you explain what exactly is in_voltage0_raw 
>> and iio:device0? I know it's not a folder, and I interact with it by using 
>> cat. So is it just like a text file or something?
>> 
>> Thanks.
>> 
>> On Sunday, March 6, 2016 at 2:15:17 PM UTC-5, john3909 wrote:
>> That is because you are doing this wrong. Reading attributes via sysfs is 
>> slow and not meant for this purpose. With IIO, you enable a scan element 
>> (echo 1 > in_voltage0_en) and then you enable the buffer (echo 1 > 
>> buffer/enable)and then you read the values from /dev/iio:device0. In the 
>> BB-ADC overlay, you can modify the scan update time by modifying the 
>> Oversample (default is 16x), Open Delay time (default is 0x98) and sample 
>> time (default is 1). Now the IIO ADC driver captures samples using 
>> interrupts which isn’t ideal, but it will capture samples at 

Re: [beagleboard] Using Connman for WiFi AP/tether...

[Robert Nelson]

On Wed, Mar 9, 2016 at 10:52 AM, Jason Kridner  wrote:
>
>
> On Mar 9, 2016, at 11:09 AM, Robert Nelson  wrote:
>
 I think i figured out how to get the usb0 to start at 192.168.7.2

 https://paste.debian.net/413402/
>>>
>>>
>>> Err, couldn't figure out from the pastebin.  Looked at your repo, and it
>>> appears you are trying to have some control over what the starting IP
>>> address that DHCP will hand out for tethering?  If so, I don't think you can
>>> necessarily assume that the USB gadget will be the first thing needing an
>>> address can you? What if one tethers WiFi then USB?  What if there is an
>>> address conflict with the localhost or USB host?  I'm assuming that connman
>>> deals with these use cases when allocating a new IP address via its internal
>>> DHCP.  And you still won't get the "static" address you desire.
>>
>> yeah, very racy, and a bad idea. ;)
>>
>> So i now have things working a littler closer to a connman only solution..
>>
>> Drop dnsmasq/create_ap, add back udhcpd
>>
>> usb0 : udhcpd (192.168.7.2)
>> wlan0: connman ap (192.168.0.1)
>>
>> Windows 10 (usb0, beaglebone.local doesn't work)
>>
>> I wonder Jason's thought on "shipping" this installer?
>>
>> https://support.apple.com/kb/DL999?locale=en_US
>
> Does it work?

It does work on Windows 10, "http://beaglebone.local; comes up over
usb0 just fine..

>Do they provide a redistribution license?

I haven't found a clear license on that, everyone seems to link to it.
Or users are too cut it out of the itunes.exe binary.. yuck.

(maybe we can just link in the documentation for windows users)

Regards,

-- 
Robert Nelson
https://rcn-ee.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.

Re: [beagleboard] Using Connman for WiFi AP/tether...

[Jason Kridner]

On Mar 9, 2016, at 11:09 AM, Robert Nelson  wrote:

>>> I think i figured out how to get the usb0 to start at 192.168.7.2
>>> 
>>> https://paste.debian.net/413402/
>> 
>> 
>> Err, couldn't figure out from the pastebin.  Looked at your repo, and it
>> appears you are trying to have some control over what the starting IP
>> address that DHCP will hand out for tethering?  If so, I don't think you can
>> necessarily assume that the USB gadget will be the first thing needing an
>> address can you? What if one tethers WiFi then USB?  What if there is an
>> address conflict with the localhost or USB host?  I'm assuming that connman
>> deals with these use cases when allocating a new IP address via its internal
>> DHCP.  And you still won't get the "static" address you desire.
> 
> yeah, very racy, and a bad idea. ;)
> 
> So i now have things working a littler closer to a connman only solution..
> 
> Drop dnsmasq/create_ap, add back udhcpd
> 
> usb0 : udhcpd (192.168.7.2)
> wlan0: connman ap (192.168.0.1)
> 
> Windows 10 (usb0, beaglebone.local doesn't work)
> 
> I wonder Jason's thought on "shipping" this installer?
> 
> https://support.apple.com/kb/DL999?locale=en_US

Does it work? Do they provide a redistribution license? 

> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.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.

-- 
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: QNX on beaglebone black

[Jason Kridner]

I contacted the QNX folks. They asked for some info on the permissions and
how you were running the script, so it seems they were on the right track.
Guess you've got it all going now?

They also said they'd work with me on refreshing the info as it is a bit
stale.
On Wed, Mar 9, 2016 at 2:11 AM Karl Karpfen  wrote:

> This is a bit off-topic, but: what is the state of QNX at the moment? Last
> time I have seen it, it came with a very poor X-Server interface which
> caused strange crashes. And it was not possible to compile and use a
> platform-independent GUI-toolkit like wxWidgets with QNX. Has this changes
> meanwhile or is QNX still a closed universe where all the necessary
> standards do not work?
>
>
>
> Am Mittwoch, 9. März 2016 00:27:29 UTC+1 schrieb acheesehead:
>>
>> I just downloaded and built the latest 'experimental' QNX 6.6 BSP for
>> BBB. Got the same errors. Turns out that the permissions of files in
>> install/sbin and install/bin needed to change. Once I changed their
>> permissions, all goes well. The build script does not mount the SD card or
>> the eMMC, so that must be done manually.
>>
>> On Tuesday, March 1, 2016 at 3:00:18 PM UTC-7, Steven Hartmann wrote:
>>>
>>> I hope there is someone here successfully using QNX on the BBB.  I am
>>> currently doing a QNX evaluation and am having trouble with the BBB BSP.  I
>>> am using the BSP_ti-am335x-beaglebone_br-660_be-660_SVN797070_JBN574.zip
>>> BSP.  The package comes with a pre-built image, which boots up fine.  I
>>> have been able to do a few test programs with it, but now I need to modify
>>> the BSP to change which features are used.  The first step in doing this
>>> was to just recompile the BSP to make sure I can recreate the precompiled
>>> version.  The build goes fine and creates an image.  I can boot off the
>>> image, but it gives a lot of errors:
>>>
>>> U-Boot#  fatload mmc 0 8100 ifs-ti-am335x-beaglebone.bin
>>> reading ifs-ti-am335x-beaglebone.bin
>>> 5794620 bytes read in 657 ms (8.4 MiB/s)
>>> U-Boot# go 8100
>>> ## Starting application at 0x8100 ...
>>>
>>> __Board ID__
>>> header:  ee3355aa
>>> name:A335BNLT
>>> 
>>> BeagleBone Black detected
>>>
>>> VFPv3: fpsid=410330c3
>>> coproc_attach(10): attach fe08a3fc (fe08ad24)
>>> coproc_attach(11): attach fe08a3fc (fe08ad24)
>>> Welcome to QNX Neutrino 6.6.0 on the Texas Instruments AM335x BeagleBone
>>> (ARMv7 Cortex-A8 core) - Board
>>> Unable to start "devc-seromap" (2)
>>> Unable to access "/dev/ser1" (2)
>>> Unable to access "/dev/ser1" (2)
>>> Starting MMC/SD driver...
>>> Unable to start "devb-sdmmc-j5_generic" (2)
>>> Unable to start "devb-sdmmc-j5_generic" (2)
>>> starting I2C driver...
>>> Unable to start "i2c-omap35xx-j5" (2)
>>> Unable to access "/dev/i2c0" (2)
>>> starting WDT reset utility...
>>> Unable to start "dm814x-wdtkick" (2)
>>> starting Board ID driver...
>>> Unable to start "am335x-boardid" (2)
>>> Unable to access "/dev/bdid" (2)
>>> Setting OS Clock from on-board RTC
>>> Unable to start "rtc" (2)
>>> Sat Jan 01 00:00:15 GMT 2000
>>> Starting USB OTG Host driver...
>>> Starting SPI driver...
>>> Unable to start "spi-master" (2)
>>> Starting network driver...
>>> starting leds driver...
>>> Unable to start "am335x-leds" (2)
>>> Unable to access "/dev/leds" (2)
>>> Setting environment variables...
>>> done.
>>> Starting Screen Graphics...
>>> done.
>>> Starting HDMI Audio driver...
>>> Unable to access /dev/snd/pcmC0D1p
>>> ksh: No controlling tty (open /dev/tty: No such device or address)
>>> ksh: warning: won't have full job control
>>>
>>>
>>> All of the software that reports "unable to start" does not have execute
>>> permissions.  When I tried to add execute permissions by hand, it said the
>>> file did not exist.
>>>
>>> My build host is linux mint.
>>>
>>> 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.
>

-- 
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] Using Connman for WiFi AP/tether...

[Robert Nelson]

>> I think i figured out how to get the usb0 to start at 192.168.7.2
>>
>> https://paste.debian.net/413402/
>
>
> Err, couldn't figure out from the pastebin.  Looked at your repo, and it
> appears you are trying to have some control over what the starting IP
> address that DHCP will hand out for tethering?  If so, I don't think you can
> necessarily assume that the USB gadget will be the first thing needing an
> address can you? What if one tethers WiFi then USB?  What if there is an
> address conflict with the localhost or USB host?  I'm assuming that connman
> deals with these use cases when allocating a new IP address via its internal
> DHCP.  And you still won't get the "static" address you desire.

yeah, very racy, and a bad idea. ;)

So i now have things working a littler closer to a connman only solution..

Drop dnsmasq/create_ap, add back udhcpd

usb0 : udhcpd (192.168.7.2)
wlan0: connman ap (192.168.0.1)

Windows 10 (usb0, beaglebone.local doesn't work)

I wonder Jason's thought on "shipping" this installer?

https://support.apple.com/kb/DL999?locale=en_US

Regards,

-- 
Robert Nelson
https://rcn-ee.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.

[beagleboard] How to run Janus WebRTC Gateway on Beaglebone Black?

[Neo]

I installed successfully Janus WebRTC Gateway  ( 
https://github.com/meetecho/janus-gateway) on /usr/local/lib and I 
re-configure to start Janus. But when I do sudo janus, I get this error:


/*
debian@beaglebone:/usr/local/bin$ janus
---
  Starting Meetecho Janus (WebRTC Gateway) v0.1.0
---

Checking command line arguments...
Debug/log level is 4
Debug/log timestamps are disabled
Debug/log colors are enabled
Adding 'vmnet' to the ICE ignore list...
Using 10.92.200.16 as local IP...
[WARN] Token based authentication disabled
Initializing ICE stuff (Full mode, ICE-TCP candidates disabled, IPv6 support 
disabled)
ICE handles watchdog started
TURN REST API backend: (disabled)
[WARN] Janus is deployed on a private address (10.92.200.16) but you didn't 
specify any STUN server! Expect trouble if this is supposed to work over the 
internet and not just in a LAN...
BUNDLE is NOT going to be forced
rtcp-mux is NOT going to be forced
Fingerprint of our certificate: 
D2:B9:31:8F:DF:24:D8:0E:ED:D2:EF:25:9E:AF:6F:B8:34:AE:53:9C:E6:F3:8F:F2:64:15:FA:E8:7F:53:2D:38
[WARN] Data Channels support not compiled
Plugins folder: /usr/local/lib/janus/plugins
Loading plugin 'libjanus_voicemail.so'...
JANUS VoiceMail plugin initialized!
Loading plugin 'libjanus_recordplay.so'...
JANUS Record plugin initialized!
Loading plugin 'libjanus_echotest.so'...
VoiceMail watchdog started
EchoTest watchdog started
Record watchdog started
JANUS EchoTest plugin initialized!
Loading plugin 'libjanus_videocall.so'...
JANUS VideoCall plugin initialized!
Loading plugin 'libjanus_streaming.so'...
VideoCall watchdog started
JANUS Streaming plugin initialized!
Loading plugin 'libjanus_videoroom.so'...
JANUS VideoRoom plugin initialized!
Streaming watchdog started
Loading plugin 'libjanus_audiobridge.so'...
JANUS AudioBridge plugin initialized!
VideoRoom watchdog started
Loading plugin 'libjanus_sip.so'...
AudioBridge watchdog started
JANUS SIP plugin initialized!
Transport plugins folder: /usr/local/lib/janus/transports
Loading transport plugin 'libjanus_http.so'...
SIP watchdog started
[ERR] [janus.c:main:3684]   Couldn't load transport plugin 
'libjanus_http.so': libmicrohttpd.so.12: cannot open shared object file: No 
such file or directory
[FATAL] [janus.c:main:3741] No Janus API transport is available... enable at 
least one and restart Janus


libjanus_http.so and libmicrohttpd.so.12 are exist in 
usr/local/lib/janus/transport and /usr/local/lib

What does the error mean?

-- 
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: LCD touch screen is not saved after reboot

[iuo ioio]

You are welcome.

2016-03-09 15:39 GMT+01:00 Bremenpl :

> It does, thank you!
>
> W dniu 2016-03-09 o 15:35, iuo ioio pisze:
>
>
> ​I hope this helps
>
> 2016-03-09 14:36 GMT+01:00 Bremenpl :
>
>> But how can I know what values I entered?
>>
>> W dniu 2016-03-09 o 14:33, iuo ioio pisze:
>>
>> These values are not saved, you must save them to new file 
>> /usr/share/X11/xorg.conf.d
>> how I wrote in first answer.
>>
>> 2016-03-08 16:31 GMT+01:00 Bremenpl < 
>> breme...@gmail.com>:
>>
>>> Do you know where is this file saved?
>>>
>>> W dniu 2016-03-08 o 16:28, Radovan Chovan pisze:
>>>
>>> Hi,
>>> I have this values from "Calibrate Touchscreen" application on Debian
>>> found in "Start menu". When I finished this calibration test, then command
>>> window appeared and there were these values.
>>>
>>> --
>>> 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/nQPsVPl-S5o/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> 
>>> beagleboard+unsubscr...@googlegroups.com.
>>> For more options, visit 
>>> https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> Bremenpl
>>>
>>> --
>>> 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/nQPsVPl-S5o/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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 a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> 
>> https://groups.google.com/d/topic/beagleboard/nQPsVPl-S5o/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> Bremenpl
>>
>> --
>> 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/nQPsVPl-S5o/unsubscribe.
>> To unsubscribe from this group and all its topics, 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 a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/nQPsVPl-S5o/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Bremenpl
>
> --
> 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/nQPsVPl-S5o/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Re: LCD touch screen is not saved after reboot

[Bremenpl]

  
  
It does, thank you!

W dniu 2016-03-09 o 15:35, iuo ioio
  pisze:


  
​I hope this helps
  
  
2016-03-09 14:36 GMT+01:00 Bremenpl :
  
 But how can I know
  what values I entered?
  
  W dniu 2016-03-09 o 14:33, iuo ioio pisze:
  
  

  
These values are not saved, you must
  save them to new file /usr/share/X11/xorg.conf.d

how I wrote in first answer.

  2016-03-08 16:31
GMT+01:00 Bremenpl :

   Do you
know where is this file saved?

W dniu 2016-03-08 o 16:28, Radovan
  Chovan pisze:


  

  Hi,
I have this values from "Calibrate
Touchscreen" application on Debian
found in "Start menu". When I
finished this calibration test, then
command window appeared and there
were these values.

  
  -- 
  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/nQPsVPl-S5o/unsubscribe.
  To unsubscribe from this group and all
  its topics, send an email to beagleboard+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.


  


-- 
Bremenpl
  
  
 -- 
  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/nQPsVPl-S5o/unsubscribe.
  To unsubscribe from this group and all its
  topics, 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 a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/nQPsVPl-S5o/unsubscribe.
To unsubscribe from this group and all its topics,
send an email to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
  
  
  -- 
Bremenpl

  


  
-- 
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/nQPsVPl-S5o/unsubscribe.
To unsubscribe from this group and all its topics, send
an email to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
  

Re: [beagleboard] Re: LCD touch screen is not saved after reboot

[Bremenpl]

  
  
But how can I know what values I entered?

W dniu 2016-03-09 o 14:33, iuo ioio
  pisze:


  These values are not saved, you must save them to
new file /usr/share/X11/xorg.conf.d
  how I wrote in first answer.
  
2016-03-08 16:31 GMT+01:00 Bremenpl :
  
 Do you know where is
  this file saved?
  
  W dniu 2016-03-08 o 16:28, Radovan Chovan pisze:
  
  

  
Hi,
  I have this values from "Calibrate Touchscreen"
  application on Debian found in "Start menu". When
  I finished this calibration test, then command
  window appeared and there were these values.
  

-- 
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/nQPsVPl-S5o/unsubscribe.
To unsubscribe from this group and all its topics,
send an email to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
  
  

  
  
  -- 
Bremenpl


  
-- 
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/nQPsVPl-S5o/unsubscribe.
To unsubscribe from this group and all its topics, 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 a topic in
  the Google Groups "BeagleBoard" group.
  To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/nQPsVPl-S5o/unsubscribe.
  To unsubscribe from this group and all its topics, send an email
  to beagleboard+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.


-- 
Bremenpl
  




-- 
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: LCD touch screen is not saved after reboot

[iuo ioio]

These values are not saved, you must save them to new file
/usr/share/X11/xorg.conf.d
how I wrote in first answer.

2016-03-08 16:31 GMT+01:00 Bremenpl :

> Do you know where is this file saved?
>
> W dniu 2016-03-08 o 16:28, Radovan Chovan pisze:
>
> Hi,
> I have this values from "Calibrate Touchscreen" application on Debian
> found in "Start menu". When I finished this calibration test, then command
> window appeared and there were these values.
>
> --
> 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/nQPsVPl-S5o/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Bremenpl
>
> --
> 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/nQPsVPl-S5o/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Problem with enable SPI dev control in BeagleboneBlack.

[Micka]

look at the log ! dmesg | grep spi

do you see something ?

Le mer. 9 mars 2016 à 14:09,  a écrit :

> Hi,
>
> I am trying to enable SPI control in BBB refer:
> http://elinux.org/BeagleBone_Black_Enable_SPIDEV
>
> Here is my DTS:
>
>
> _pinmux {
> spi1_pins: pinmux_spi1_pins {
> pinctrl-single,pins = <
> 0x108 (PIN_OUTPUT_PULLUP | MUX_MODE2)  /* MII1_COL.spi1_sclk
> */
> 0x10C (PIN_INPUT_PULLUP | MUX_MODE2)  /* MII1_CRS.spi1_d0
> */
> 0x110 (PIN_INPUT_PULLUP | MUX_MODE2)  /*
> MII1_RX_ER.spi1_d1 */
> 0x144 (PIN_OUTPUT_PULLUP | MUX_MODE2)  /*
> RMII1_REF_CLK.spi1_cs0 */
> 0x164 (PIN_OUTPUT_PULLUP | MUX_MODE2)  /*
> ECAP0_IN_PWM0_OUT.spi1_cs1 */
> >;
> };
> };
>  {
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <_pins>;
> spi1_0 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0>;
> spi-max-frequency = <2400>;
> compatible = "spidev";
> };
> spi1_1 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <1>;
> spi-max-frequency = <2400>;
> compatible = "spidev";
> };
> };
>
> CONFIG_SPI_DEV was enabled.
>
> But I can't find any /dev/spi*. What did I do wrong? I am using kernel 3.14
>
>
> Thanks
>
> Tuan Nguyen
>
>
>
>
>
>
>
>
>
>
> --
> 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] Re: tilcdc FIFO underflow

[dasty82]

> Anyway, I'm not sure how useful this "test code" really is. This is not 
> something any useful application would ever do . . .other than apparently 
> making a beaglebone in certain situations "flicker" . . .
>

This is exactly what ffmpeg does when decoding WMA. Not so harshly - it 
does a lot of computation in between, but harsh enough to cause beaglebone 
display to flicker.

Radek

-- 
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] Problem with enable SPI dev control in BeagleboneBlack.

[hoangtuan180991]

Hi,

I am trying to enable SPI control in BBB refer: 
http://elinux.org/BeagleBone_Black_Enable_SPIDEV

Here is my DTS:


_pinmux { 
spi1_pins: pinmux_spi1_pins { 
pinctrl-single,pins = < 
0x108 (PIN_OUTPUT_PULLUP | MUX_MODE2)  /* MII1_COL.spi1_sclk */ 
0x10C (PIN_INPUT_PULLUP | MUX_MODE2)  /* MII1_CRS.spi1_d0 */ 
0x110 (PIN_INPUT_PULLUP | MUX_MODE2)  /* MII1_RX_ER.spi1_d1 
*/ 
0x144 (PIN_OUTPUT_PULLUP | MUX_MODE2)  /* 
RMII1_REF_CLK.spi1_cs0 */ 
0x164 (PIN_OUTPUT_PULLUP | MUX_MODE2)  /* 
ECAP0_IN_PWM0_OUT.spi1_cs1 */ 
>; 
}; 
}; 
 { 
status = "okay"; 
pinctrl-names = "default"; 
pinctrl-0 = <_pins>; 
spi1_0 { 
#address-cells = <1>; 
#size-cells = <0>; 
reg = <0>; 
spi-max-frequency = <2400>; 
compatible = "spidev"; 
}; 
spi1_1 { 
#address-cells = <1>; 
#size-cells = <0>; 
reg = <1>; 
spi-max-frequency = <2400>; 
compatible = "spidev"; 
}; 
};

CONFIG_SPI_DEV was enabled.

But I can't find any /dev/spi*. What did I do wrong? I am using kernel 3.14


Thanks

Tuan Nguyen










-- 
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: tilcdc FIFO underflow

[William Hermans]

One last point. In the case of Debian. You do not really have to worry much
about how large your stack size for any application is. So complicating an
application by dynamically allocating memory( heap versus stack ) is not
necessarily needed.

Anyway, I'm not 100% sure all Linux distro's behave in this manner, but
know for a fact this is the case with Debian as I spent a good amount of
time reading / researching this for a project of mine.

Not only that, but it is of course possible to structure code in a way that
your stack stays small to begin with. Either way, Debian can if needed
allocate up to 100% system for a single applications stack if needed. Of
course the only way this will ever happen is if tested with specific code .
. .

On Wed, Mar 9, 2016 at 5:38 AM, William Hermans  wrote:

> However . . since *you* do not get to respond to something and then just
> tell me to stop talking . . .
>
> *In C variable[0] is essentially a pointer to the start of variable.*
> *No, that's plain wrong. *
>
> Bullshit.
>
> *Also to nickpick even more. memset() expects type unsigned character, and
>> uint8_t *, and unsigned char * are not really equivalent . . . which is a
>> source of even more errors ;) *This* I've had personal hands on with ;)*
>> *No, glibc, uclibc, eglibc, even avr-libc all have the same signature,
>> which is the following:*
>> *void *memset(void *s, int c, size_t n);*
>>
>
> Here I mispoke ( mis-wrote ) but I was not speaking to the function
> prototype. But instead the value that memset() "sets" is interpreted as
> unsigned char *. So, mixing uint8_t  *, and unsigned char * is bad mojo.
> It'll work, until you expect it to, and then your code will start randomly
> misbehaving. That is to say that such code may / may not work as expected,
> or in other words. undefined behavior. I am not however sure if there is in
> fact anything in the standard regarding that, but I do know from first hand
> experience that such code, that is not consistent in types, is not 100%
> reliable. Which is a good reason to use compiler options -Wall, and such.
>
> @Radek
>
> *It is just a good engineering practice, to write always free for every
>> malloc, in case somebody later on modifies/extends code later on to avoid
>> memory-leaks within the program.*
>>
>
> There would be no memory leak. knowing what your code does is in fact good
> engineering, so omitting useless code because you know it's useless is not
> bad form. It's known as knowing what you're doing ;)
>
> Anyway, I'm not sure how useful this "test code" really is. This is not
> something any useful application would ever do . . .other than apparently
> making a beaglebone in certain situations "flicker" . . .
>
>
> On Wed, Mar 9, 2016 at 1:56 AM,  wrote:
>
>> Hi William,
>>
>> I would like to point out, that free will never even be reached as there
>> is an ifinite loop before it :)
>>
>> It is just a good engineering practice, to write always free for every
>> malloc, in case somebody later on modifies/extends code later on to avoid
>> memory-leaks within the program.
>>
>> Thanks,
>> Radek
>>
>> On Wednesday, March 9, 2016 at 2:29:27 AM UTC+1, William Hermans wrote:
>>>
>>> I would also like to point out that the free() after the loop ( end of
>>> program ) is not necessary. Modern Linux versions deal with this
>>> automatically. I do not suppose it'll hurt, but figured I'd point that out.
>>>
>>> On Tue, Mar 8, 2016 at 6:23 PM, William Hermans 
>>> wrote:
>>>
 *Because it's not calling malloc() over and over...*
>

 Yeap, you're right it's calling memset() every loop. Not sure why I was
 thinking it was calling malloc() every loop. But the point is, it does not
 matter what is being called in the loop. any system / API call in the loop,
 without some form of a sleep() will eat up a lot of CPU cycles. Again, as
 much as the system will allow it to, which is usually in the mid to high
 90%'s . . .

 I'm surprised that code would compile at all without a compiler error.
> As [0] probably is not what you think it is.
>
 I see no issue here. Can you elaborate?

 So,  <- beginning of an array, equivalent to variable[0], but
 what is [0] ? A multi dimensional array ? that's not what was
 defined . . . to be 100% honest I'm not sure what it does, but the first
 thing that comes to mind is "undefined behavior".


 On Tue, Mar 8, 2016 at 5:39 PM,  wrote:

> I'm surprised that code would compile at all without a compiler error.
>> As [0] probably is not what you think it is.
>>
> I see no issue here. Can you elaborate?
>
>
>> Also, for the record, infinitely allocating an arbitrary amount of
>> dynamic memory, in a loop, without any kind of a pause is going to eat up
>> an incredible amount of CPU cycles. As in that code will very likely use 
>> 

Re: [beagleboard] Re: tilcdc FIFO underflow

[William Hermans]

However . . since *you* do not get to respond to something and then just
tell me to stop talking . . .

*In C variable[0] is essentially a pointer to the start of variable.*
*No, that's plain wrong. *

Bullshit.

*Also to nickpick even more. memset() expects type unsigned character, and
> uint8_t *, and unsigned char * are not really equivalent . . . which is a
> source of even more errors ;) *This* I've had personal hands on with ;)*
> *No, glibc, uclibc, eglibc, even avr-libc all have the same signature,
> which is the following:*
> *void *memset(void *s, int c, size_t n);*
>

Here I mispoke ( mis-wrote ) but I was not speaking to the function
prototype. But instead the value that memset() "sets" is interpreted as
unsigned char *. So, mixing uint8_t  *, and unsigned char * is bad mojo.
It'll work, until you expect it to, and then your code will start randomly
misbehaving. That is to say that such code may / may not work as expected,
or in other words. undefined behavior. I am not however sure if there is in
fact anything in the standard regarding that, but I do know from first hand
experience that such code, that is not consistent in types, is not 100%
reliable. Which is a good reason to use compiler options -Wall, and such.

@Radek

*It is just a good engineering practice, to write always free for every
> malloc, in case somebody later on modifies/extends code later on to avoid
> memory-leaks within the program.*
>

There would be no memory leak. knowing what your code does is in fact good
engineering, so omitting useless code because you know it's useless is not
bad form. It's known as knowing what you're doing ;)

Anyway, I'm not sure how useful this "test code" really is. This is not
something any useful application would ever do . . .other than apparently
making a beaglebone in certain situations "flicker" . . .


On Wed, Mar 9, 2016 at 1:56 AM,  wrote:

> Hi William,
>
> I would like to point out, that free will never even be reached as there
> is an ifinite loop before it :)
>
> It is just a good engineering practice, to write always free for every
> malloc, in case somebody later on modifies/extends code later on to avoid
> memory-leaks within the program.
>
> Thanks,
> Radek
>
> On Wednesday, March 9, 2016 at 2:29:27 AM UTC+1, William Hermans wrote:
>>
>> I would also like to point out that the free() after the loop ( end of
>> program ) is not necessary. Modern Linux versions deal with this
>> automatically. I do not suppose it'll hurt, but figured I'd point that out.
>>
>> On Tue, Mar 8, 2016 at 6:23 PM, William Hermans  wrote:
>>
>>> *Because it's not calling malloc() over and over...*

>>>
>>> Yeap, you're right it's calling memset() every loop. Not sure why I was
>>> thinking it was calling malloc() every loop. But the point is, it does not
>>> matter what is being called in the loop. any system / API call in the loop,
>>> without some form of a sleep() will eat up a lot of CPU cycles. Again, as
>>> much as the system will allow it to, which is usually in the mid to high
>>> 90%'s . . .
>>>
>>> I'm surprised that code would compile at all without a compiler error.
 As [0] probably is not what you think it is.

>>> I see no issue here. Can you elaborate?
>>>
>>> So,  <- beginning of an array, equivalent to variable[0], but
>>> what is [0] ? A multi dimensional array ? that's not what was
>>> defined . . . to be 100% honest I'm not sure what it does, but the first
>>> thing that comes to mind is "undefined behavior".
>>>
>>>
>>> On Tue, Mar 8, 2016 at 5:39 PM,  wrote:
>>>
 I'm surprised that code would compile at all without a compiler error.
> As [0] probably is not what you think it is.
>
 I see no issue here. Can you elaborate?


> Also, for the record, infinitely allocating an arbitrary amount of
> dynamic memory, in a loop, without any kind of a pause is going to eat up
> an incredible amount of CPU cycles. As in that code will very likely use 
> as
> close to 100% CPU as the system will allow it. Which again, is no wonder
> you're "flickering" . . .
>
 The code is not allocating anything in a loop.


> You lucky your program does not randomly crash for using malloc() on
> the same dynamic memory over, and over, without using free(), or instead
> using realloc() . . .
>
 Because it's not calling malloc() over and over...


 The issue here is that if you run memset() in a tight loop (which at
 least one gstreamer1.6 audio decoder plugins does), it seems to clog up the
 data bus enough for the DMA to fail.



> On Tue, Mar 8, 2016 at 10:16 AM, Radek Dostál 
> wrote:
>
>> Hi Michael,
>>
>> we had very similar issue, which we encountered when updating to
>> gstreamer 1.6. Using git bisect we were able to find a root cause and
>> prepare simple test program, 

[beagleboard] Re: bbb Internal ADC configuration settings?

[TJF]

Hi Audrey!

As mentioned above, a bash script is not feasible to handle ADC sampling at 
200 kHz. Instead use a fast compiler language like C, C++ or FreeBASIC. The 
mentioned iio solutions require file access, which is also slow. In order 
to get direct access to the values, use libpruio 
. This library provides

   - full control over all ADC configuration registers
   - at run-time (no device tree changes / reboots)
   - sampling at full speed (200 kHz)

and some further features ... Check out the examples. 


BR

-- 
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: Pinmuxing (Loadable) Kernel Module?

[TJF]

Hi John, please excuse my late reply. I haven't been in the office for a 
while.

I agree, it wouldn't be easy the implement this in a generic way to the 
gpiolib driver. And even if possible, we'll end up with a pinmux feature in 
a driver named gpiolib. Another stumbling stone in the big "find the right 
driver" game. Sure, that's not the way to go.

But what about adapting the driver pinctrl-single? This driver has all 
features we need. We just have to implement entries in sysfs to 
additionally control the pins after boot time. I see no reason why that 
shouldn't be possible in a generic way for all architectures.

Your statement is much appriciated.

BR

-- 
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] Re: Booting Android on the BeagleBone Black not working?

[allardiced]

Seems what worked for me was to NOT hold down the boot button prior to 
connecting power.  In fact, I had to plug in power, and then very quickly 
(before normal boot process begins, which is indicated by flashing of the 
indicator LEDs) I held down the boot button for several seconds, at which 
time the LEDs all came on solid for 2-3 seconds, then turned off; at which 
time I released the boot button, and the flashing process began (as 
indicated by LEDs flashing, but not in the heartbeat pattern).  Hope this 
helps!

-Darryl

 

On Thursday, June 20, 2013 at 5:22:47 PM UTC-4, a.jain wrote:
>
> I was able to put Android onto a microSD card (link here, not the TI link 
> ). However, when I attempted to 
> boot it, it would not work, as the BBB would run the eMMC. When I tried to 
> flash it onto the BeagleBone Black, none of the user LEDs were lighting up, 
> so I don't think that worked either. What can I do to fix this?

-- 
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: tilcdc FIFO underflow

[dasty82]

Hi William,

I would like to point out, that free will never even be reached as there is 
an ifinite loop before it :)

It is just a good engineering practice, to write always free for every 
malloc, in case somebody later on modifies/extends code later on to avoid 
memory-leaks within the program.

Thanks,
Radek

On Wednesday, March 9, 2016 at 2:29:27 AM UTC+1, William Hermans wrote:
>
> I would also like to point out that the free() after the loop ( end of 
> program ) is not necessary. Modern Linux versions deal with this 
> automatically. I do not suppose it'll hurt, but figured I'd point that out.
>
> On Tue, Mar 8, 2016 at 6:23 PM, William Hermans  > wrote:
>
>> *Because it's not calling malloc() over and over...*
>>>
>>
>> Yeap, you're right it's calling memset() every loop. Not sure why I was 
>> thinking it was calling malloc() every loop. But the point is, it does not 
>> matter what is being called in the loop. any system / API call in the loop, 
>> without some form of a sleep() will eat up a lot of CPU cycles. Again, as 
>> much as the system will allow it to, which is usually in the mid to high 
>> 90%'s . . .
>>
>> I'm surprised that code would compile at all without a compiler error. As 
>>> [0] probably is not what you think it is. 
>>>
>> I see no issue here. Can you elaborate?
>>
>> So,  <- beginning of an array, equivalent to variable[0], but 
>> what is [0] ? A multi dimensional array ? that's not what was 
>> defined . . . to be 100% honest I'm not sure what it does, but the first 
>> thing that comes to mind is "undefined behavior".
>>
>>
>> On Tue, Mar 8, 2016 at 5:39 PM,  wrote:
>>
>>> I'm surprised that code would compile at all without a compiler error. 
 As [0] probably is not what you think it is. 

>>> I see no issue here. Can you elaborate?
>>>  
>>>
 Also, for the record, infinitely allocating an arbitrary amount of 
 dynamic memory, in a loop, without any kind of a pause is going to eat up 
 an incredible amount of CPU cycles. As in that code will very likely use 
 as 
 close to 100% CPU as the system will allow it. Which again, is no wonder 
 you're "flickering" . . .

>>> The code is not allocating anything in a loop.
>>>  
>>>
 You lucky your program does not randomly crash for using malloc() on 
 the same dynamic memory over, and over, without using free(), or instead 
 using realloc() . . .

>>> Because it's not calling malloc() over and over...
>>>
>>>
>>> The issue here is that if you run memset() in a tight loop (which at 
>>> least one gstreamer1.6 audio decoder plugins does), it seems to clog up the 
>>> data bus enough for the DMA to fail.
>>>
>>>  
>>>
 On Tue, Mar 8, 2016 at 10:16 AM, Radek Dostál  wrote:

> Hi Michael,
>
> we had very similar issue, which we encountered when updating to 
> gstreamer 1.6. Using git bisect we were able to find a root cause and 
> prepare simple test program, which reliably reproduces the issue:
>
> #include 
> #include 
> #include 
>
> int main(int argc, char **argv)
> {
> int size;
> uint8_t *memblock;
>
> if (argc < 2)
> return -1;
>
> size = atoi(argv[1]);
>
> memblock = malloc(size);
>
> while (1)
> {
> memset([0], 0, size);
> }
>
> free(memblock);
>
> return 0;
> }
>
> starting this program will cause crazy flickering, ...
>
> We were able to reproduce the issue with
>
> 1) debian originally provided on beaglebone using memtest utility for 
> carlos. Kernel version was: 
>
> Linux version 3.8.13-bone70 (root@a5-imx6q-wandboard-2gb) (gcc version 
> 4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri Jan 23 02:15:42 UTC 2015 
>
> 2) latest version of debian from beaglebone website Kernel version 
> was: 
>
> Linux version 4.1.15-ti-rt-r43 (root@a4-imx6q-wandboard-2gb) (gcc 
> version 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT RT Thu Jan 21 20:13:58 
> UTC 
> 2016 
>
> so it seems to be existing for ages.
>
> Did you in the mean time managed to find a solution for your problem?
>
> Thanks,
> Radek
>
> On Monday, February 8, 2016 at 1:18:50 PM UTC+1, Michael Liesenberg 
> wrote:
>>
>> Hi there,
>>
>>
>> i was able to get my 10.1 custom Display to work with the RGB Pins on 
>> the beaglebone black.
>>
>> I am using the latest Debian Jessie image from beagleboard.org and 
>> the X11 Desktop has the right colors and the right size.
>>
>> So i assume that the Timings from my display are correct.
>>
>>
>> panel {
>>
>> status = "okay";
>>
>> compatible = 

Re: [beagleboard] Re: tilcdc FIFO underflow

[dasty82]

Hi William,

Let's not discuss the C of the program, as:

1) The mem-test program behaves the same even if it contains 
"memset(memblock, 0, size);"
2) The mem-test program behaves the same even if you run it using "nice" at 
very low priority
3) The mem-test program is not accessing directly any HW and runs as user 
nobody
4) The mem-test program does not cause any side-effects on x86 Ubuntu PC, 
Freescale iMX6 ARM or Broadcom BCM958305k dev kit
5) Same behavior is reproducible with gstreamer-1.6 and decoding WMA

I believe Linux kernel should never allow process running as nobody at very 
low priority without any access to HW to damage experience of other process 
(such as X server) running as root with much higher priority, ...

Thanks,
Radek

On Wednesday, March 9, 2016 at 4:13:42 AM UTC+1, William Hermans wrote:
>
> That's not what I've been taught over the last 20 years. In C variable[0] 
> is essentially a pointer to the start of variable. Which if you want to 
> get technical is not the "adddress of" variable. Regardless  
> should give the starting address of variable. So at minimum [0] 
> is a bit superfluous which makes the code harder to read through . . . and 
> is something I'd never do personally.
>
> Is that nick picky enough ? ;)
>
> Also to nickpick even more. memset() expects type unsigned character, and 
> uint8_t *, and unsigned char * are not really equivalent . . . which is a 
> source of even more errors ;) *This* I've had personal hands on with ;)
>
> On Tue, Mar 8, 2016 at 7:07 PM,  wrote:
>
>> *Because it's not calling malloc() over and over...*

>>>
>>> Yeap, you're right it's calling memset() every loop. Not sure why I was 
>>> thinking it was calling malloc() every loop. But the point is, it does not 
>>> matter what is being called in the loop. any system / API call in the loop, 
>>> without some form of a sleep() will eat up a lot of CPU cycles. Again, as 
>>> much as the system will allow it to, which is usually in the mid to high 
>>> 90%'s . . .
>>>
>>
>> Yes it's definitely not nice to call memset() in such a tight loop, but 
>> the program is just for demonstration purposes. As mentioned at least one 
>> gstreamer 1.6 audio decoder plugins will call memset() consecutively fast 
>> enough to cause issues with the lcdc dma. And thus screen flicker.
>>  
>>
>> So,  <- beginning of an array, equivalent to variable[0], but 
>>> what is [0] ? A multi dimensional array ? that's not what was 
>>> defined . . . to be 100% honest I'm not sure what it does, but the first 
>>> thing that comes to mind is "undefined behavior".
>>>
>> I won't go into details, but "" is not the same as "variable[0]". 
>> (You might be able construct some special/silly case tho where the content 
>> of variable[0] is equivalent to ).
>>
>> And "[0]" is equivalent to "variable". The latter might have 
>> been more readable in the context of the code, but both version are valid 
>> C. Basically you are getting the address of the first element of the memory 
>> block, which is the starting address of the memory block itself, which is 
>> what memset expects.
>>
>>
>>> On Tue, Mar 8, 2016 at 5:39 PM,  wrote:
>>>
 I'm surprised that code would compile at all without a compiler error. 
> As [0] probably is not what you think it is. 
>
 I see no issue here. Can you elaborate?
  

> Also, for the record, infinitely allocating an arbitrary amount of 
> dynamic memory, in a loop, without any kind of a pause is going to eat up 
> an incredible amount of CPU cycles. As in that code will very likely use 
> as 
> close to 100% CPU as the system will allow it. Which again, is no wonder 
> you're "flickering" . . .
>
 The code is not allocating anything in a loop.
  

> You lucky your program does not randomly crash for using malloc() on 
> the same dynamic memory over, and over, without using free(), or instead 
> using realloc() . . .
>
 Because it's not calling malloc() over and over...


 The issue here is that if you run memset() in a tight loop (which at 
 least one gstreamer1.6 audio decoder plugins does), it seems to clog up 
 the 
 data bus enough for the DMA to fail.

  

> On Tue, Mar 8, 2016 at 10:16 AM, Radek Dostál  
> wrote:
>
>> Hi Michael,
>>
>> we had very similar issue, which we encountered when updating to 
>> gstreamer 1.6. Using git bisect we were able to find a root cause and 
>> prepare simple test program, which reliably reproduces the issue:
>>
>> #include 
>> #include 
>> #include 
>>
>> int main(int argc, char **argv)
>> {
>> int size;
>> uint8_t *memblock;
>>
>> if (argc < 2)
>> return -1;
>>
>> size = atoi(argv[1]);
>>
>> memblock = malloc(size);
>>
>>  

[beagleboard] network access to WD Mycloud Jessie Desktop works, but don't know how to command line access

[wellington . chun . sf]

My Beagle Bone Black running Jessie is able to access my WD MyCloud on the 
networks smb://GUMSAN and all files.


How do I access the same device using a console and command line?  If the 
desktop already capable of doing it, I should (I think) be able to access 
without loading any additional apts.  Is it some mount command? or some 
smbclient command?


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

Re: [beagleboard] Re: tilcdc FIFO underflow

[pietrmar]

>
> In C variable[0] is essentially a pointer to the start of variable.
>
No, that's plain wrong. 
 

> Also to nickpick even more. memset() expects type unsigned character, and 
> uint8_t *, and unsigned char * are not really equivalent . . . which is a 
> source of even more errors ;) *This* I've had personal hands on with ;)
>
No, glibc, uclibc, eglibc, even avr-libc all have the same signature, which 
is the following:
void *memset(void *s, int c, size_t n);

Also this is the last post from me regarding C stuff, since it's off topic.
 

> On Tue, Mar 8, 2016 at 7:07 PM,  wrote:
>
>> *Because it's not calling malloc() over and over...*

>>>
>>> Yeap, you're right it's calling memset() every loop. Not sure why I was 
>>> thinking it was calling malloc() every loop. But the point is, it does not 
>>> matter what is being called in the loop. any system / API call in the loop, 
>>> without some form of a sleep() will eat up a lot of CPU cycles. Again, as 
>>> much as the system will allow it to, which is usually in the mid to high 
>>> 90%'s . . .
>>>
>>
>> Yes it's definitely not nice to call memset() in such a tight loop, but 
>> the program is just for demonstration purposes. As mentioned at least one 
>> gstreamer 1.6 audio decoder plugins will call memset() consecutively fast 
>> enough to cause issues with the lcdc dma. And thus screen flicker.
>>  
>>
>> So,  <- beginning of an array, equivalent to variable[0], but 
>>> what is [0] ? A multi dimensional array ? that's not what was 
>>> defined . . . to be 100% honest I'm not sure what it does, but the first 
>>> thing that comes to mind is "undefined behavior".
>>>
>> I won't go into details, but "" is not the same as "variable[0]". 
>> (You might be able construct some special/silly case tho where the content 
>> of variable[0] is equivalent to ).
>>
>> And "[0]" is equivalent to "variable". The latter might have 
>> been more readable in the context of the code, but both version are valid 
>> C. Basically you are getting the address of the first element of the memory 
>> block, which is the starting address of the memory block itself, which is 
>> what memset expects.
>>
>>
>>> On Tue, Mar 8, 2016 at 5:39 PM,  wrote:
>>>
 I'm surprised that code would compile at all without a compiler error. 
> As [0] probably is not what you think it is. 
>
 I see no issue here. Can you elaborate?
  

> Also, for the record, infinitely allocating an arbitrary amount of 
> dynamic memory, in a loop, without any kind of a pause is going to eat up 
> an incredible amount of CPU cycles. As in that code will very likely use 
> as 
> close to 100% CPU as the system will allow it. Which again, is no wonder 
> you're "flickering" . . .
>
 The code is not allocating anything in a loop.
  

> You lucky your program does not randomly crash for using malloc() on 
> the same dynamic memory over, and over, without using free(), or instead 
> using realloc() . . .
>
 Because it's not calling malloc() over and over...


 The issue here is that if you run memset() in a tight loop (which at 
 least one gstreamer1.6 audio decoder plugins does), it seems to clog up 
 the 
 data bus enough for the DMA to fail.

  

> On Tue, Mar 8, 2016 at 10:16 AM, Radek Dostál  
> wrote:
>
>> Hi Michael,
>>
>> we had very similar issue, which we encountered when updating to 
>> gstreamer 1.6. Using git bisect we were able to find a root cause and 
>> prepare simple test program, which reliably reproduces the issue:
>>
>> #include 
>> #include 
>> #include 
>>
>> int main(int argc, char **argv)
>> {
>> int size;
>> uint8_t *memblock;
>>
>> if (argc < 2)
>> return -1;
>>
>> size = atoi(argv[1]);
>>
>> memblock = malloc(size);
>>
>> while (1)
>> {
>> memset([0], 0, size);
>> }
>>
>> free(memblock);
>>
>> return 0;
>> }
>>
>> starting this program will cause crazy flickering, ...
>>
>> We were able to reproduce the issue with
>>
>> 1) debian originally provided on beaglebone using memtest utility for 
>> carlos. Kernel version was: 
>>
>> Linux version 3.8.13-bone70 (root@a5-imx6q-wandboard-2gb) (gcc 
>> version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri Jan 23 02:15:42 UTC 2015 
>>
>> 2) latest version of debian from beaglebone website Kernel version 
>> was: 
>>
>> Linux version 4.1.15-ti-rt-r43 (root@a4-imx6q-wandboard-2gb) (gcc 
>> version 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT RT Thu Jan 21 20:13:58 
>> UTC 
>> 2016 
>>
>> so it seems to be existing for ages.
>>
>> Did you in the mean time 

[beagleboard] max310x & spi patch

[Micka]

Hi,

On my board we use pins of uart0 for the spi interface ( all others pins
are used ) .

To do so, we deactivate the max310x by default, but when the linux boot, it
has to move a gpio to enable the device. I modified the spi driver to
detect the parameter : enable-gpio = < 3 GPIO_ACTIVE_LOW>;

also we used the max310x with an external clock, so we don't need a clock
node. To do so, I modified the driver max310x to detect the parameter:
clock-frequency = <1843200>; .

And it works well !

the patch :

>From 50358ac2b1daad3850e57caca85390dc39186da5 Mon Sep 17 00:00:00 2001
From: michael musset 
Date: Wed, 9 Mar 2016 09:15:10 +0100
Subject: [PATCH] my patch

Signed-off-by: michael musset 
---
 drivers/spi/spi.c  | 26 +++-
 drivers/tty/serial/max310x.c   | 58 ++


diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index d35c1a1..91ebfc0 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1520,7 +1520,9 @@ int spi_register_master(struct spi_master *master)
  struct boardinfo *bi;
  int status = -ENODEV;
  int dynamic = 0;
-
+ int enable_gpio=0;
+ int ret=0;
+ enum of_gpio_flags  flags;
  if (!dev)
  return -ENODEV;

@@ -1576,6 +1578,28 @@ int spi_register_master(struct spi_master *master)
  }
  }

+/* activate child device before talking to them*/
+enable_gpio = of_get_named_gpio_flags( master->dev.of_node,
"enable-gpio", 0, );
+if (gpio_is_valid(enable_gpio)) {
+printk("spi found reset gpio, request gpio %d\n",
enable_gpio);
+
+ret = gpio_request( enable_gpio, "spi-gpio-reset");
+if (ret != 0){
+dev_warn(dev,"spi reset gpio : failed to request
gpio\n");
+return ret;
+}
+ret = gpio_direction_output(enable_gpio, 0);
+if (ret != 0){
+dev_warn(dev,"spi reset gpio : failed to put
direction\n");
+return ret;
+}
+dev_warn(dev,"spi reset gpio : set gpio to 1");
+gpio_set_value(enable_gpio, 1);
+mdelay(1000);
+}else{
+dev_warn(dev,"no reset gpio\n");
+}
+
  mutex_lock(_lock);
  list_add_tail(>list, _master_list);
  list_for_each_entry(bi, _list, list)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index 182549f..3542ca4 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -1081,7 +1081,7 @@ static int max310x_gpio_direction_output(struct
gpio_chip *chip,
 static int max310x_probe(struct device *dev, struct max310x_devtype
*devtype,
  struct regmap *regmap, int irq, unsigned long flags)
 {
- int i, ret, fmin, fmax, freq, uartclk;
+ int i, ret, fmin, fmax, freq=0, uartclk;
  struct clk *clk_osc, *clk_xtal;
  struct max310x_port *s;
  bool xtal = false;
@@ -1096,31 +1096,39 @@ static int max310x_probe(struct device *dev, struct
max310x_devtype *devtype,
  dev_err(dev, "Error allocating port structure\n");
  return -ENOMEM;
  }
-
- clk_osc = devm_clk_get(dev, "osc");
- clk_xtal = devm_clk_get(dev, "xtal");
- if (!IS_ERR(clk_osc)) {
- s->clk = clk_osc;
- fmin = 50;
- fmax = 3500;
- } else if (!IS_ERR(clk_xtal)) {
- s->clk = clk_xtal;
- fmin = 100;
- fmax = 400;
- xtal = true;
- } else if (PTR_ERR(clk_osc) == -EPROBE_DEFER ||
-   PTR_ERR(clk_xtal) == -EPROBE_DEFER) {
- return -EPROBE_DEFER;
- } else {
- dev_err(dev, "Cannot get clock\n");
- return -EINVAL;
+ if (of_find_property(dev->of_node, "clock-frequency", NULL)){
+of_property_read_u32(dev->of_node, "clock-frequency",
);
+printk("clock frequency detected %d\n", freq);
+}
+if(freq!=0){
+fmin = 100;
+fmax = 400;
+xtal = 0;
+}else{
+ clk_osc = devm_clk_get(dev, "osc");
+ clk_xtal = devm_clk_get(dev, "xtal");
+ if (!IS_ERR(clk_osc)) {
+ s->clk = clk_osc;
+ fmin = 50;
+ fmax = 3500;
+ } else if (!IS_ERR(clk_xtal)) {
+ s->clk = clk_xtal;
+ fmin = 100;
+ fmax = 400;
+ xtal = true;
+ } else if (PTR_ERR(clk_osc) == -EPROBE_DEFER ||
+   PTR_ERR(clk_xtal) == -EPROBE_DEFER) {
+ return -EPROBE_DEFER;
+ } else {
+ dev_err(dev, "Cannot get clock\n");
+ return -EINVAL;
+ }
+ ret = clk_prepare_enable(s->clk);
+ if (ret)
+ return ret;
+ freq = clk_get_rate(s->clk);
  }

- ret = clk_prepare_enable(s->clk);
- if (ret)
- return ret;
-
- freq = clk_get_rate(s->clk);
  /* Check frequency limits */
  if (freq < fmin || freq > fmax) {
  ret = -ERANGE;
@@ -1167,7 +1175,7 @@ static int max310x_probe(struct device *dev, struct
max310x_devtype *devtype,
  s->uart.nr = devtype->nr;
  ret = uart_register_driver(>uart);
  if (ret) {
- dev_err(dev, "Registering UART driver failed\n");
+ dev_err(dev, "Registering UART driver failed %d\n", ret);
  goto out_clk;
  }

-- 
1.9.1

-- 
For 

[beagleboard] Re: Kernel 4.1 activate module codec MAX98*

[Micka]

I'm looking at the list here :

Device Drivers > Sound card support > Advanced Linux Sound Architecture >
ALSA for SoC audio support > CODEC drivers


Le mer. 9 mars 2016 à 11:04, Micka  a écrit :

> Hi,
>
> In the configuration of the kernel compilation process, I can't see the
> list of MAX98** devices .
>
> in the file :
> KERNEL/sound/soc/codecs/Kconfig
>
> I have the line select SND_SOC_MAX98088 if I2C
>
> And I don't understand why I can't see it, the I2C is enabled ...
>
>
> Any idea ?
>

-- 
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] Kernel 4.1 activate module codec MAX98*

[Micka]

Hi,

In the configuration of the kernel compilation process, I can't see the
list of MAX98** devices .

in the file :
KERNEL/sound/soc/codecs/Kconfig

I have the line select SND_SOC_MAX98088 if I2C

And I don't understand why I can't see it, the I2C is enabled ...


Any idea ?

-- 
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?

[William Hermans]

John, also Audry asked what the values of that device tree fragment mean,
not what the code was. As in Audry wants and explanation of the values:

ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 0x98 0x98 0x98>;
ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;

As far as I can tell. Quite honestly I could use that explanation myself.
But step avg can be a value 0-16 if memory serves from reading the TRM, I'm
just not clear exactly on what step avg actually does. . . . the
explanation in the TRM is very jumbled / confusing.


On Wed, Mar 9, 2016 at 1:58 AM, William Hermans  wrote:

> Now if you want to convey more information that is actually *useful* to
> anyone reading this post. You can say that both voltageX_raw, and
> iio:deviceX are buffers.
>
> With voltageX_raw being a single value buffer that gets updated only once
> every open() call on it's file descriptor.
>
> Where iio:deviceX is a buffer, defined in size by the value set in
> /sys/bus/iio/devices/iio\:device0/buffer/length
>
> More *useful* information can be found here:
> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide. Then
> if you want even more information still, googling "iio" will produce a lot
> of information. Much of it not so useful. At least for our use case, the
> Beaglebone.
>
> On Wed, Mar 9, 2016 at 1:47 AM, William Hermans  wrote:
>
>> what the hell does what you've said there even mean John ? voltagex_raw
>> is one shot mode, iio:deviceX is continuous mode.
>>
>> What you said above only serves to confuse the situation.
>>
>> On Wed, Mar 9, 2016 at 1:32 AM, John Syne  wrote:
>>
>>> /*
>>>  * Copyright (C) 2012 Texas Instruments Incorporated -
>>> http://www.ti.com/
>>>  *
>>>  * This program is free software; you can redistribute it and/or modify
>>>  * it under the terms of the GNU General Public License version 2 as
>>>  * published by the Free Software Foundation.
>>>  */
>>> /dts-v1/;
>>> /plugin/;
>>>
>>> / {
>>> compatible = "ti,beaglebone", "ti,beaglebone-black",
>>> "ti,beaglebone-green";
>>>
>>> /* identification */
>>> part-number = "BB-ADC";
>>> version = "00A0";
>>>
>>> /* state the resources this cape uses */
>>> exclusive-use =
>>> /* the pin header uses */
>>> "P9.31", /* AIN0 */
>>> "P9.40", /* AIN1 */
>>> "P9.37", /* AIN2 */
>>> "P9.38", /* AIN3 */
>>> "P9.33", /* AIN4 */
>>> "P9.36", /* AIN5 */
>>> "P9.35", /* AIN6 */
>>> /* the hardware ip uses */
>>> "tscadc";
>>>
>>> fragment@0 {
>>> target = <>;
>>> __overlay__ {
>>>
>>> status = "okay";
>>> adc {
>>> ti,adc-channels = <0 1 2 3 4 5 6>;
>>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
>>> ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 0x98 0x98 0x98>;
>>> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
>>> };
>>> };
>>> };
>>> };
>>>
>>> Reading from /sys/bus/iio/devices/iio:device0/in_voltage0_raw is reading
>>> and attribute of the IIO driver. Reading from /dev/iio:device0 is reading
>>> from the same IIO driver, but in this case you are reading from the buffer
>>> which stores samples defined in the DT overlay above.
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Mar 8, 2016, at 9:51 PM, Audrey  wrote:
>>>
>>> Thanks for the reply John. Could you perhaps explain how to modify the
>>> oversample, open delay time, and sample time in greater detail in the
>>> BB-ADC overlay? I do not see these variables in the dto in github (
>>> https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-ADC-00A0.dts).
>>> Also, what value can/should I change them to?
>>>
>>> So just to clarify, reading from
>>> /sys/bus/iio/devices/iio:device0/in_voltage0_raw reads attributes using
>>> sysfs, while reading from /dev/iio:device0 reads the values using IIO? Also
>>> another conceptual question, can you explain what exactly is
>>> in_voltage0_raw and iio:device0? I know it's not a folder, and I interact
>>> with it by using cat. So is it just like a text file or something?
>>>
>>> Thanks.
>>>
>>> On Sunday, March 6, 2016 at 2:15:17 PM UTC-5, john3909 wrote:

 That is because you are doing this wrong. Reading attributes via sysfs
 is slow and not meant for this purpose. With IIO, you enable a scan element
 (echo 1 > in_voltage0_en) and then you enable the buffer (echo 1 >
 buffer/enable)and then you read the values from /dev/iio:device0. In the
 BB-ADC overlay, you can modify the scan update time by modifying the
 Oversample (default is 16x), Open Delay time (default is 0x98) and sample
 time (default is 1). Now the IIO ADC driver captures samples using
 interrupts which isn’t ideal, but it will capture samples at a much higher
 rate than can be read from sysfs. If you want to capture at full speed, the
 driver needs to be updated to use DMA.

 Regards,
 John




 On Mar 6, 2016, at 12:19 AM, Audrey 

Re: [beagleboard] bbb Internal ADC configuration settings?

[William Hermans]

Now if you want to convey more information that is actually *useful* to
anyone reading this post. You can say that both voltageX_raw, and
iio:deviceX are buffers.

With voltageX_raw being a single value buffer that gets updated only once
every open() call on it's file descriptor.

Where iio:deviceX is a buffer, defined in size by the value set in
/sys/bus/iio/devices/iio\:device0/buffer/length

More *useful* information can be found here:
http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide. Then if
you want even more information still, googling "iio" will produce a lot of
information. Much of it not so useful. At least for our use case, the
Beaglebone.

On Wed, Mar 9, 2016 at 1:47 AM, William Hermans  wrote:

> what the hell does what you've said there even mean John ? voltagex_raw is
> one shot mode, iio:deviceX is continuous mode.
>
> What you said above only serves to confuse the situation.
>
> On Wed, Mar 9, 2016 at 1:32 AM, John Syne  wrote:
>
>> /*
>>  * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>>  *
>>  * This program is free software; you can redistribute it and/or modify
>>  * it under the terms of the GNU General Public License version 2 as
>>  * published by the Free Software Foundation.
>>  */
>> /dts-v1/;
>> /plugin/;
>>
>> / {
>> compatible = "ti,beaglebone", "ti,beaglebone-black",
>> "ti,beaglebone-green";
>>
>> /* identification */
>> part-number = "BB-ADC";
>> version = "00A0";
>>
>> /* state the resources this cape uses */
>> exclusive-use =
>> /* the pin header uses */
>> "P9.31", /* AIN0 */
>> "P9.40", /* AIN1 */
>> "P9.37", /* AIN2 */
>> "P9.38", /* AIN3 */
>> "P9.33", /* AIN4 */
>> "P9.36", /* AIN5 */
>> "P9.35", /* AIN6 */
>> /* the hardware ip uses */
>> "tscadc";
>>
>> fragment@0 {
>> target = <>;
>> __overlay__ {
>>
>> status = "okay";
>> adc {
>> ti,adc-channels = <0 1 2 3 4 5 6>;
>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
>> ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 0x98 0x98 0x98>;
>> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
>> };
>> };
>> };
>> };
>>
>> Reading from /sys/bus/iio/devices/iio:device0/in_voltage0_raw is reading
>> and attribute of the IIO driver. Reading from /dev/iio:device0 is reading
>> from the same IIO driver, but in this case you are reading from the buffer
>> which stores samples defined in the DT overlay above.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Mar 8, 2016, at 9:51 PM, Audrey  wrote:
>>
>> Thanks for the reply John. Could you perhaps explain how to modify the
>> oversample, open delay time, and sample time in greater detail in the
>> BB-ADC overlay? I do not see these variables in the dto in github (
>> https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-ADC-00A0.dts).
>> Also, what value can/should I change them to?
>>
>> So just to clarify, reading from
>> /sys/bus/iio/devices/iio:device0/in_voltage0_raw reads attributes using
>> sysfs, while reading from /dev/iio:device0 reads the values using IIO? Also
>> another conceptual question, can you explain what exactly is
>> in_voltage0_raw and iio:device0? I know it's not a folder, and I interact
>> with it by using cat. So is it just like a text file or something?
>>
>> Thanks.
>>
>> On Sunday, March 6, 2016 at 2:15:17 PM UTC-5, john3909 wrote:
>>>
>>> That is because you are doing this wrong. Reading attributes via sysfs
>>> is slow and not meant for this purpose. With IIO, you enable a scan element
>>> (echo 1 > in_voltage0_en) and then you enable the buffer (echo 1 >
>>> buffer/enable)and then you read the values from /dev/iio:device0. In the
>>> BB-ADC overlay, you can modify the scan update time by modifying the
>>> Oversample (default is 16x), Open Delay time (default is 0x98) and sample
>>> time (default is 1). Now the IIO ADC driver captures samples using
>>> interrupts which isn’t ideal, but it will capture samples at a much higher
>>> rate than can be read from sysfs. If you want to capture at full speed, the
>>> driver needs to be updated to use DMA.
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Mar 6, 2016, at 12:19 AM, Audrey  wrote:
>>>
>>> Where can I find it (and set it)?
>>>
>>> I'm right now trying to collect voltage readings using beaglebone's
>>> internal adc using a bash script and a while loop. Right now the data
>>> collection is clocking at around 33 microseconds, but I know that the
>>> internal adc should be able to collect data as fast as 5 microseconds. What
>>> should I do to make that happen? Is the problem with making while loops
>>> move faster, or is it about setting the adc configurations?
>>>
>>> This is my bash script:
>>>
>>> #!/bin/bash
>>>
>>> #echo cape-bone-iio > /sys/devices/bone_capemgr.*/slots
>>>
>>> t0=$(date +%s%6N)
>>>
>>> while true; do
>>>t1=$(date +%s%6N)
>>>rawVal=$(cat /sys/bus/iio/devices/iio:device0/in_voltage0_raw)
>>>voltage=$(bc -l <<< 

Re: [beagleboard] bbb Internal ADC configuration settings?

[William Hermans]

what the hell does what you've said there even mean John ? voltagex_raw is
one shot mode, iio:deviceX is continuous mode.

What you said above only serves to confuse the situation.

On Wed, Mar 9, 2016 at 1:32 AM, John Syne  wrote:

> /*
>  * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>  *
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License version 2 as
>  * published by the Free Software Foundation.
>  */
> /dts-v1/;
> /plugin/;
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black", "ti,beaglebone-green";
>
> /* identification */
> part-number = "BB-ADC";
> version = "00A0";
>
> /* state the resources this cape uses */
> exclusive-use =
> /* the pin header uses */
> "P9.31", /* AIN0 */
> "P9.40", /* AIN1 */
> "P9.37", /* AIN2 */
> "P9.38", /* AIN3 */
> "P9.33", /* AIN4 */
> "P9.36", /* AIN5 */
> "P9.35", /* AIN6 */
> /* the hardware ip uses */
> "tscadc";
>
> fragment@0 {
> target = <>;
> __overlay__ {
>
> status = "okay";
> adc {
> ti,adc-channels = <0 1 2 3 4 5 6>;
> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
> ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 0x98 0x98 0x98>;
> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
> };
> };
> };
> };
>
> Reading from /sys/bus/iio/devices/iio:device0/in_voltage0_raw is reading
> and attribute of the IIO driver. Reading from /dev/iio:device0 is reading
> from the same IIO driver, but in this case you are reading from the buffer
> which stores samples defined in the DT overlay above.
>
> Regards,
> John
>
>
>
>
> On Mar 8, 2016, at 9:51 PM, Audrey  wrote:
>
> Thanks for the reply John. Could you perhaps explain how to modify the
> oversample, open delay time, and sample time in greater detail in the
> BB-ADC overlay? I do not see these variables in the dto in github (
> https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-ADC-00A0.dts).
> Also, what value can/should I change them to?
>
> So just to clarify, reading from
> /sys/bus/iio/devices/iio:device0/in_voltage0_raw reads attributes using
> sysfs, while reading from /dev/iio:device0 reads the values using IIO? Also
> another conceptual question, can you explain what exactly is
> in_voltage0_raw and iio:device0? I know it's not a folder, and I interact
> with it by using cat. So is it just like a text file or something?
>
> Thanks.
>
> On Sunday, March 6, 2016 at 2:15:17 PM UTC-5, john3909 wrote:
>>
>> That is because you are doing this wrong. Reading attributes via sysfs is
>> slow and not meant for this purpose. With IIO, you enable a scan element
>> (echo 1 > in_voltage0_en) and then you enable the buffer (echo 1 >
>> buffer/enable)and then you read the values from /dev/iio:device0. In the
>> BB-ADC overlay, you can modify the scan update time by modifying the
>> Oversample (default is 16x), Open Delay time (default is 0x98) and sample
>> time (default is 1). Now the IIO ADC driver captures samples using
>> interrupts which isn’t ideal, but it will capture samples at a much higher
>> rate than can be read from sysfs. If you want to capture at full speed, the
>> driver needs to be updated to use DMA.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Mar 6, 2016, at 12:19 AM, Audrey  wrote:
>>
>> Where can I find it (and set it)?
>>
>> I'm right now trying to collect voltage readings using beaglebone's
>> internal adc using a bash script and a while loop. Right now the data
>> collection is clocking at around 33 microseconds, but I know that the
>> internal adc should be able to collect data as fast as 5 microseconds. What
>> should I do to make that happen? Is the problem with making while loops
>> move faster, or is it about setting the adc configurations?
>>
>> This is my bash script:
>>
>> #!/bin/bash
>>
>> #echo cape-bone-iio > /sys/devices/bone_capemgr.*/slots
>>
>> t0=$(date +%s%6N)
>>
>> while true; do
>>t1=$(date +%s%6N)
>>rawVal=$(cat /sys/bus/iio/devices/iio:device0/in_voltage0_raw)
>>voltage=$(bc -l <<< $rawVal/4095*1.8)
>>time=$(expr $t1 - $t0)
>>echo $time $voltage
>> done
>>
>>
>> --
>> 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.
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You 

[beagleboard] Re: Debian img 8.3 lxqt boot indefinitely on some BBB

[mpsoft . ch]

Thanks PatM001,
This is a good direction to investigate, my external power supply is really 
3A@5V but it seemed I have some troubles when the Ethernet cable is 
connected.
Maybe a loss of power, I will look at this.

-- 
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]

/*
 * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 */
/dts-v1/;
/plugin/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black", 
"ti,beaglebone-green";

/* identification */
part-number = "BB-ADC";
version = "00A0";

/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
"P9.31",/* AIN0 */
"P9.40",/* AIN1 */
"P9.37",/* AIN2 */
"P9.38",/* AIN3 */
"P9.33",/* AIN4 */
"P9.36",/* AIN5 */
"P9.35",/* AIN6 */
/* the hardware ip uses */
"tscadc";

fragment@0 {
target = <>;
__overlay__ {

status = "okay";
adc {
ti,adc-channels = <0 1 2 3 4 5 6>;
ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 
0x16 0x16>;
ti,chan-step-opendelay = <0x98 0x98 0x98 0x98 
0x98 0x98 0x98>;
ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 
0x0 0x0>;
};
};
};
};

Reading from /sys/bus/iio/devices/iio:device0/in_voltage0_raw is reading and 
attribute of the IIO driver. Reading from /dev/iio:device0 is reading from the 
same IIO driver, but in this case you are reading from the buffer which stores 
samples defined in the DT overlay above. 

Regards,
John




> On Mar 8, 2016, at 9:51 PM, Audrey  wrote:
> 
> Thanks for the reply John. Could you perhaps explain how to modify the 
> oversample, open delay time, and sample time in greater detail in the BB-ADC 
> overlay? I do not see these variables in the dto in github 
> (https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-ADC-00A0.dts
>  
> ).
>  Also, what value can/should I change them to?
> 
> So just to clarify, reading from 
> /sys/bus/iio/devices/iio:device0/in_voltage0_raw reads attributes using 
> sysfs, while reading from /dev/iio:device0 reads the values using IIO? Also 
> another conceptual question, can you explain what exactly is in_voltage0_raw 
> and iio:device0? I know it's not a folder, and I interact with it by using 
> cat. So is it just like a text file or something?
> 
> Thanks.
> 
> On Sunday, March 6, 2016 at 2:15:17 PM UTC-5, john3909 wrote:
> That is because you are doing this wrong. Reading attributes via sysfs is 
> slow and not meant for this purpose. With IIO, you enable a scan element 
> (echo 1 > in_voltage0_en) and then you enable the buffer (echo 1 > 
> buffer/enable)and then you read the values from /dev/iio:device0. In the 
> BB-ADC overlay, you can modify the scan update time by modifying the 
> Oversample (default is 16x), Open Delay time (default is 0x98) and sample 
> time (default is 1). Now the IIO ADC driver captures samples using interrupts 
> which isn’t ideal, but it will capture samples at a much higher rate than can 
> be read from sysfs. If you want to capture at full speed, the driver needs to 
> be updated to use DMA. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 6, 2016, at 12:19 AM, Audrey smith.edu > 
>> wrote:
>> 
>> Where can I find it (and set it)?
>> 
>> I'm right now trying to collect voltage readings using beaglebone's internal 
>> adc using a bash script and a while loop. Right now the data collection is 
>> clocking at around 33 microseconds, but I know that the internal adc should 
>> be able to collect data as fast as 5 microseconds. What should I do to make 
>> that happen? Is the problem with making while loops move faster, or is it 
>> about setting the adc configurations?
>> 
>> This is my bash script:
>> 
>> #!/bin/bash
>> 
>> #echo cape-bone-iio > /sys/devices/bone_capemgr.*/slots
>> 
>> t0=$(date +%s%6N)
>> 
>> while true; do
>>t1=$(date +%s%6N)
>>rawVal=$(cat /sys/bus/iio/devices/iio:device0/in_voltage0_raw)
>>voltage=$(bc -l <<< $rawVal/4095*1.8)
>>time=$(expr $t1 - $t0)
>>echo $time $voltage
>> done
>> 
>> 
>> -- 
>> 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 
>> .
> 
> 
>