Re: [beagleboard] Driving a Multiplexed LED matrix directly from gpio

2016-03-20 Thread William Hermans
OK so yes, seeing your code would help us understand what you're bottleneck
but I've a pretty good idea why you're LCD matrix refresh is so slow. It
has to do with userspace communicating with kernel space, and you're either
invoking some system API calls ( which are notoriously slow ), or you're
copying data from userspace to kernel space, which again is slow.

The reason I said to show us some code above however is that I think it
*should* be possible to use /dev/mem/ + mmap() to access whatever you're
controlling. Using mmap() in this manner gives you no userspace to kernel
overheard . . . but again I need to see some relevant code to give you a
better idea how that might work.

On Sun, Mar 20, 2016 at 8:58 PM, William Hermans  wrote:

> Show us some code.
>
> On Sun, Mar 20, 2016 at 6:28 PM, David Good  wrote:
>
>> Hi All,
>>
>> I've been experimenting with embedded linux and matrixed LED displays.  I
>> started on a Raspberry pi user space program, but could see visual
>> artifacts on the display due to inconsistent timing of my sleep command.
>> So, I figured that moving the basic row scanning into the kernel would help
>> out.  After failing to get the right kernel headers for the pi, I switched
>> to a BeagleBone White.  I've now got a working character device LKM which
>> takes new images by writing ASCII formatted hex strings to the device in
>> /dev.  The performance is pretty good, but not great.  I still see visible
>> artifacts, but am playing with things.
>>
>> My basic question is this: I know that Linux is not a RTOS, so timing
>> will never be guaranteed, yet linux does a lot of things very quickly
>> (video, audio, i2c, etc).  My driver is bit-banging a spi like stream over
>> 8 rows at a rate of ~3ms per row (333Hz row scanning or ~41Hz per complete
>> frame) and is really struggling.  How does linux usually get large smooth
>> video at over 60FPS while doing other things???  Is it simply taking
>> advantage of special hardware resources?
>>
>> The obvious solution for this display is to use a little 8051 or M0
>> microcontroller (or PRU!) and let the Bone feed it over uart or something,
>> but I really thought I could do better with the LKM.
>>
>> Am I just doing something totally wrong?  Any other ideas?
>>
>> Thanks!
>>
>> --David
>>
>> --
>> 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] Driving a Multiplexed LED matrix directly from gpio

2016-03-20 Thread William Hermans
Show us some code.

On Sun, Mar 20, 2016 at 6:28 PM, David Good  wrote:

> Hi All,
>
> I've been experimenting with embedded linux and matrixed LED displays.  I
> started on a Raspberry pi user space program, but could see visual
> artifacts on the display due to inconsistent timing of my sleep command.
> So, I figured that moving the basic row scanning into the kernel would help
> out.  After failing to get the right kernel headers for the pi, I switched
> to a BeagleBone White.  I've now got a working character device LKM which
> takes new images by writing ASCII formatted hex strings to the device in
> /dev.  The performance is pretty good, but not great.  I still see visible
> artifacts, but am playing with things.
>
> My basic question is this: I know that Linux is not a RTOS, so timing will
> never be guaranteed, yet linux does a lot of things very quickly (video,
> audio, i2c, etc).  My driver is bit-banging a spi like stream over 8 rows
> at a rate of ~3ms per row (333Hz row scanning or ~41Hz per complete frame)
> and is really struggling.  How does linux usually get large smooth video at
> over 60FPS while doing other things???  Is it simply taking advantage of
> special hardware resources?
>
> The obvious solution for this display is to use a little 8051 or M0
> microcontroller (or PRU!) and let the Bone feed it over uart or something,
> but I really thought I could do better with the LKM.
>
> Am I just doing something totally wrong?  Any other ideas?
>
> Thanks!
>
> --David
>
> --
> 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] looks like the BeagleBone Black and this community is dead. Cannot even flash 8.3.

2016-03-20 Thread evilwulfie
Reading this made me laugh.



On 3/20/2016 3:49 PM, William Hermans wrote:
>
> /Trying to update the flash to Debian 8.3 and initially I get the
> back and forth Knight Rider pattern. Then, after a bit I get just
> 4 double blink leds every half second or so. Looks like a few
> others have seen this, but no conversation around the issue or
> possible solutions./
> /
> /
> /My raspberry pi's work just fine, and when I do have a problem I
> can find answers fairly quickly./
> /
> /
> /It's clear that the BBB is a dead product. There is no meaningful
> resources for issues, and when the system simply won't 'reset from
> a new image from their site'... that's the last straw./
> /
> /
> /Mine are going in the trash and I will advise anyone everywhere
> to do the same./
>
>
> If that's the mentality you're going to take, then I say don't let the
> door hit you in the ass on your way out . . .But it is in no way the
> fault or responsibility of anyone in this community that *you* have
> problems with customizing your software. You had a working image on it
> when it shipped to you, you take responsibility when you attempt to
> customize the software.
>
> On Sun, Mar 20, 2016 at 1:34 PM, Peter Lawler  > wrote:
>
>
> On 21 Mar 2016 06:28, "Karl Easterly"  > wrote:
>
> > Mine are going in the trash
>
> Seriously?
>
> Don't trash em. Send em to me. Email me your details and I'll pay
> for shipping if you like.
>
> PO Box 195
> Lindisfarne
> Tasmania
> AUSTRALIA 7015
>
> P.
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to beagleboard+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[beagleboard] Driving a Multiplexed LED matrix directly from gpio

2016-03-20 Thread David Good
Hi All,

I've been experimenting with embedded linux and matrixed LED displays.  I
started on a Raspberry pi user space program, but could see visual
artifacts on the display due to inconsistent timing of my sleep command.
So, I figured that moving the basic row scanning into the kernel would help
out.  After failing to get the right kernel headers for the pi, I switched
to a BeagleBone White.  I've now got a working character device LKM which
takes new images by writing ASCII formatted hex strings to the device in
/dev.  The performance is pretty good, but not great.  I still see visible
artifacts, but am playing with things.

My basic question is this: I know that Linux is not a RTOS, so timing will
never be guaranteed, yet linux does a lot of things very quickly (video,
audio, i2c, etc).  My driver is bit-banging a spi like stream over 8 rows
at a rate of ~3ms per row (333Hz row scanning or ~41Hz per complete frame)
and is really struggling.  How does linux usually get large smooth video at
over 60FPS while doing other things???  Is it simply taking advantage of
special hardware resources?

The obvious solution for this display is to use a little 8051 or M0
microcontroller (or PRU!) and let the Bone feed it over uart or something,
but I really thought I could do better with the LKM.

Am I just doing something totally wrong?  Any other ideas?

Thanks!

--David

-- 
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] looks like the BeagleBone Black and this community is dead. Cannot even flash 8.3.

2016-03-20 Thread William Hermans
>
> *Trying to update the flash to Debian 8.3 and initially I get the back and
> forth Knight Rider pattern. Then, after a bit I get just 4 double blink
> leds every half second or so. Looks like a few others have seen this, but
> no conversation around the issue or possible solutions.*
>
> *My raspberry pi's work just fine, and when I do have a problem I can find
> answers fairly quickly.*
>
> *It's clear that the BBB is a dead product. There is no meaningful
> resources for issues, and when the system simply won't 'reset from a new
> image from their site'... that's the last straw.*
>
> *Mine are going in the trash and I will advise anyone everywhere to do the
> same.*
>

If that's the mentality you're going to take, then I say don't let the door
hit you in the ass on your way out . . .But it is in no way the fault or
responsibility of anyone in this community that *you* have problems with
customizing your software. You had a working image on it when it shipped to
you, you take responsibility when you attempt to customize the software.

On Sun, Mar 20, 2016 at 1:34 PM, Peter Lawler  wrote:

>
> On 21 Mar 2016 06:28, "Karl Easterly"  wrote:
>
> > Mine are going in the trash
>
> Seriously?
>
> Don't trash em. Send em to me. Email me your details and I'll pay for
> shipping if you like.
>
> PO Box 195
> Lindisfarne
> Tasmania
> AUSTRALIA 7015
>
> P.
>
> --
> 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] looks like the BeagleBone Black and this community is dead. Cannot even flash 8.3.

2016-03-20 Thread Peter Lawler
On 21 Mar 2016 06:28, "Karl Easterly"  wrote:

> Mine are going in the trash

Seriously?

Don't trash em. Send em to me. Email me your details and I'll pay for
shipping if you like.

PO Box 195
Lindisfarne
Tasmania
AUSTRALIA 7015

P.

-- 
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] looks like the BeagleBone Black and this community is dead. Cannot even flash 8.3.

2016-03-20 Thread Robert P. J. Day

Quoting Robert Nelson :


On Mar 20, 2016 2:28 PM, "Karl Easterly"  wrote:



It's clear that the BBB is a dead product. There is no meaningful

resources for issues, and when the system simply won't 'reset from a new
image from their site'... that's the last straw.


Mine are going in the trash and I will advise anyone everywhere to do the

same.

'Last straw', I've don't remember you ever posting on here.. If it's only
one and done for you, then there's no reason for me to waste time either..


  how *dare* everyone not drop what they're doing ***right now*** and
solve my problem during the first weekend of march madness?

rday


--
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] looks like the BeagleBone Black and this community is dead. Cannot even flash 8.3.

2016-03-20 Thread Robert Nelson
On Mar 20, 2016 2:28 PM, "Karl Easterly"  wrote:
>
> Trying to update the flash to Debian 8.3 and initially I get the back and
forth Knight Rider pattern. Then, after a bit I get just 4 double blink
leds every half second or so. Looks like a few others have seen this, but
no conversation around the issue or possible solutions.

That's a flashing failure, usually caused by a weak or bad 5v DC power
supply. (2a)...

If your powering via USB, well that's why..

Or if you did something obvious wrong.. 4gb image on a 2gb board.

>
> My raspberry pi's work just fine, and when I do have a problem I can find
answers fairly quickly.
>
> It's clear that the BBB is a dead product. There is no meaningful
resources for issues, and when the system simply won't 'reset from a new
image from their site'... that's the last straw.
>
> Mine are going in the trash and I will advise anyone everywhere to do the
same.

'Last straw', I've don't remember you ever posting on here.. If it's only
one and done for you, then there's no reason for me to waste time either..

Regards,

-- 
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] looks like the BeagleBone Black and this community is dead. Cannot even flash 8.3.

2016-03-20 Thread Karl Easterly
Trying to update the flash to Debian 8.3 and initially I get the back and 
forth Knight Rider pattern. Then, after a bit I get just 4 double blink 
leds every half second or so. Looks like a few others have seen this, but 
no conversation around the issue or possible solutions.

My raspberry pi's work just fine, and when I do have a problem I can find 
answers fairly quickly.

It's clear that the BBB is a dead product. There is no meaningful resources 
for issues, and when the system simply won't 'reset from a new image from 
their site'... that's the last straw.

Mine are going in the trash and I will advise anyone everywhere to do the 
same.


-- 
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 based board power-off

2016-03-20 Thread Nikos
Hello,

We have a custom, BBB based board, which, when all relevant patches and 
PMIC settings have been applied, will power-cycle when poweroff is issued 
(remains off for a couple of seconds, and powers on again. The strange 
thing is that if we have the UART0 Tx pin connected to a PC, when poweroff 
is issued, the board powers off normally. Apparently, connecting the Tx 
causes some bleed that drops the voltage levels, that otherwise do not fall 
off adequately fast. Would anyone have any ideas as to what could be done 
to resolve this?

Thank you.

BR,
Nikos

-- 
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] Debugging with beaglebone black

2016-03-20 Thread William Hermans
https://www.google.com/search?q=how+to+debug+linux+kernel+modules

Just like you would on any platform.

On Thu, Mar 17, 2016 at 8:46 PM, John Syne  wrote:

> To debug kernel modules with JTAG, you have to have a debugger which is
> kernel aware like Lauterbach. If you don’t want to use JTAG, then use
> printk or dev-dbg, dev-err, etc. You can also use ftrace, which requires
> you to build your own kernel and add support for the various ftrace
> features. Read kernel docs under documentation/trace/ftrace.txt to learn
> more.
>
> Regards,
> John
>
>
>
>
> On Mar 17, 2016, at 7:49 PM, cmajor.merch...@gmail.com wrote:
>
> I have a question about the beaglebone black. How am suppose to debug with
> it? I really would prefer not to have to solder a JTAG header. Also the
> JTAG header would be under the board which is really inconvenient. The case
> that came with my board also has no room for the JTAG header so it would
> basically render the case useless. I know it has a serial debug header but
> how could I debug with it? I want to debug kernel modules.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[beagleboard] Terminal Block Wiring Options

2016-03-20 Thread msaporito
Hey guys,

I'm currently designing a greenhouse automation control unit utilizing the 
BBB as the brain.  In order to create industrial strength wiring I'd like 
to use terminal block connections to each connector on the P8 and P9 
headers.

To give you a visual of what I'd like to do check out a picture of the 
terminal block shield for the Arduino Mega.  It plugs into the board nicely 
and the terminal blocks lay along perimeter of the shield giving the user 
access to each input.

I'm also open to other ideas regarding how to wire up a BBB in a reliable 
way suitable for industrial purposes.

What do you think?


-- 
The information contained in this transmission contains potentially 
privileged, export controlled and/or confidential information of Imageware 
Systems, Inc. or its customers or partners.  It is intended only to be read 
by the person(s) named above and for no other purpose.  You are hereby 
notified that any dissemination, distribution, duplication of this 
communication 
or use of its contents for any purpose not authorized expressly by 
Imageware Systems, Inc. is strictly prohibited and could lead to both civil 
and/or criminal penalties.  If you are not the intended recipient, you are 
prohibited 
to review the contents herein and please contact the sender by reply e-mail 
and destroy all copies of the original message.  To reply to our e-mail 
administrator directly, please send an e-mail to emailad...@iwsinc.com

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[beagleboard] Re: All the Leds remain lit.

2016-03-20 Thread Karl Karpfen
Have you tried to boot it fro ma system that is located on external 
microSD-card? E.g. a Ubuntu-version?

Am Freitag, 11. März 2016 17:25:57 UTC+1 schrieb Anh Le Tuan:
>
> It is a BeagleBone Black which was successfully flashed. I tried to 
> upgrade the kernel. However failed. I reboot the device and it stop 
> working. 4 Leds remain lit. They are not blinking. 
>
> I tried to re-flash the board. However, when I hold the user boot button. 
> The Leds are not up. Is my board broken. Any suggestion to make it work 
> again?
>
> Anh. 
>

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

2016-03-20 Thread John Syne
What is your kernel version?

Regards,
John




> On Mar 18, 2016, at 1:22 PM, Audrey  wrote:
> 
> It says:
> root@beaglebone:/# echo 1 > 
> /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en
> -bash: /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en: No such 
> file or directory
> 
> and I can't find scan_elements in sys/bus/iio/devices/iio:device0
> root@beaglebone:/sys/bus/iio/devices/iio:device0# ls -l
> total 0
> -r--r--r-- 1 root root 4096 Mar  1 21:13 dev
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage0_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage1_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage2_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage3_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage4_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage5_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage6_raw
> -rw-r--r-- 1 root root 4096 Mar  1 21:13 in_voltage7_raw
> -r--r--r-- 1 root root 4096 Mar  1 21:13 name
> drwxr-xr-x 2 root root0 Mar  1 21:13 power
> lrwxrwxrwx 1 root root0 Mar  1 20:47 subsystem -> ../../../../../bus/iio
> -rw-r--r-- 1 root root 4096 Mar  1 20:47 uevent
> 
> 
> On Friday, March 18, 2016 at 4:15:00 PM UTC-4, john3909 wrote:
> 
>> On Mar 18, 2016, at 1:06 PM, Audrey > wrote:
>> 
>> Hm. 
>> 
>> Sorry, but unfortunately I'm still quite a bit lost. What should I be doing 
>> to dev/iio:device0 (open?) in order to do the following:
>> echo 1 > in_voltage0_en
> From memory, 
> 
> echo 1 > /sys/bus/iio/devices/iio:device0/scan_element/in_voltage0_en
>> echo 1 > buffer/enable
> echo 1 > /sys/bus/iio/devices/iio:device0/buffer/enable
> 
> Regards,
> John
>> 
>> I'm assuming that I should be able to see in_voltage0_en and buffer in the 
>> folder /sys/bus/iio/devices/iio:device0 but I currently do not see those 
>> attributes/drivers/folders/buffers/whatever-you-want-to-call-them.
>> 
>> Typing 
>> root@beaglebone:/dev# open iio:device0
>> doesn't seem to do anything.
>> 
>> Do you think you could break your steps down even further?
>> 
>> Thanks.
>> 
>> On Friday, March 18, 2016 at 3:49:39 PM UTC-4, john3909 wrote:
>> It is a driver, so you can open, poll and read from /dev/iio:device0
>> 
>> For a quick test, do the following: After you enable the various 
>> scan_channels, start the buffer and then do the following:
>> 
>> dd if=/dev/iio:device0 of=~/test.txt
>> 
>> Press ctrl-C to stop capture.
>> 
>> Use hexdump to view the file. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Mar 18, 2016, at 12:37 PM, Audrey smith.edu 
>>> > wrote:
>>> 
>>> It says:
>>> root@beaglebone:/dev# cd iio:device0
>>> -bash: cd: iio:device0: Not a directory
>>> root@beaglebone:/dev# cat iio:device0
>>> cat: iio:device0: Invalid argument
>>> 
>>> 
>>> On Friday, March 18, 2016 at 3:25:13 PM UTC-4, john3909 wrote:
>>> The buffer is available here:
>>> 
>>> /dev/iio:device0
>>> 
>>> Because the driver uses interrupts, you won’t get the speed you want. The 
>>> driver has to be updated to use DMA if you want to use full speed. Reading 
>>> from the buffer will reduce your CPU load compared to using LDR_PATH 
>>> because this interface blocks until a sample is available, but not long 
>>> enough for the thread to sleep. To use DMA, IIO have introduced a DMA 
>>> framework and most of what you need is already available. However, IIO are 
>>> going to be updating the IIO DMA framework to do zero copy between the 
>>> kernel module and the socket interface, using MMU maps. 
>>> 
>>> Regards,
>>> John
>>> 
>>> 
>>> 
>>> 
 On Mar 18, 2016, at 11:21 AM, Audrey smith.edu 
 > wrote:
 
 Hi everyone,
 
 First of all, thank you everyone for trying to help me. I appreciate 
 everyone's input.
 
 I took everyone's advice, and have moved away from bash to C++. It's 
 clocking at about 2 milliseconds, but I would really like it to go down 
 into the microsecond range:
 /** Simple LDR Reading Application
 * Written by Derek Molloy for the book "Exploring BeagleBone: Tools and
 * Techniques for Building with Embedded Linux" by John Wiley & Sons, 2014
 * ISBN 9781118935125. Please see the file README.md in the repository root
 * directory for copyright and GNU GPLv3 license information.*/
  
 #include
 #include
 #include
 #include
 using namespace std;
  
 #define LDR_PATH "/sys/bus/iio/devices/iio:device0/in_voltage"
  
 int readAnalog(int number)
 {
stringstream ss;
ss << LDR_PATH << number << "_raw";
fstream fs;
fs.open(ss.str().c_str(), fstream::in);
fs >> number;
fs.close();
return number;
 }
  
 int main(int argc, char* argv[])
 {
cout << "Starting the readLDR program" << endl;
int value;
int i=1;
while (true)
{
  

[beagleboard] Cape Manager question- What installs config-pin command?

2016-03-20 Thread Greg
I've successfully ran Robert Nelson's scripts 
(https://eewiki.net/display/linuxonarm/BeagleBone) which compile a kernel 
image, u-boot, installed root file system etc. and installed on microSD 
card.
It boots perfectly, I can use the serial device or SSH into a Beagleboard 
Green and all looks good.

I cloned the bb.org-overlays into the Debian home directory, and ran the 
dtc-overlay and install scripts.
It appeared that all ran good and no errors.

However, I can't locate the config-pin executable.  One another machine 
using a pre-build image, it is located in /usr/local/bin.

I must be missing a step which installs config-pin.

Also, I ran 
zcat /proc/config.gz | grep CONFIG_BONE_CAPEMGR
CONFIG_BONE_CAPEMGR=y

What am I missing here?

Thanks,
Greg

-- 
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: PWM Pin Error on Boot

2016-03-20 Thread M House
I should clarify that it is every time I start my node.js server file that 
a has a required module that uses P9_14.  I can manually change the 
polarity to 0 but it resets every time I reboot.

On Saturday, March 19, 2016 at 11:30:58 PM UTC-7, M House wrote:
>
> I'm doing a project right now that involves using a micro servo.  One is 
> on port P8_13 and another on P9_14.  
>
> Everytime I boot the beaglebone it gives me - error: Error enabling PWM 
> controls: Error: ENOENT, no such file or directory 
> '/sys/devices/ocp.3/bs_pwm_test_P9_14.15/polarity'
>
> When I check this file it shows a value of '1' inside of it.  Where the 
> same file for P8_13 shows a zero.  When I change the P9_14 polarity file to 
> 0 the servo works as intended.  I'm really confused why the polarity is 
> being set to 1 every time I boot the beaglebone.  This also happens if I 
> move the servo to P9_16.
>
> I did just upgrade from Debian 7.8 to 7.9 but I don't see how that would 
> change the GPIO behavior.
>
>

-- 
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] PWM Pin Error on Boot

2016-03-20 Thread M House
I'm doing a project right now that involves using a micro servo.  One is on 
port P8_13 and another on P9_14.  

Everytime I boot the beaglebone it gives me - error: Error enabling PWM 
controls: Error: ENOENT, no such file or directory 
'/sys/devices/ocp.3/bs_pwm_test_P9_14.15/polarity'

When I check this file it shows a value of '1' inside of it.  Where the 
same file for P8_13 shows a zero.  When I change the P9_14 polarity file to 
0 the servo works as intended.  I'm really confused why the polarity is 
being set to 1 every time I boot the beaglebone.  This also happens if I 
move the servo to P9_16.

I did just upgrade from Debian 7.8 to 7.9 but I don't see how that would 
change the GPIO behavior.

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