[beagleboard] Re: Connecting a flow sensor directly to BBB

[Brandon I]

Looks like there's a 1 wire driver that you can 
use: http://webshed.org/wiki/RaspberryPI_DS1820#Software


On Thursday, April 2, 2015 at 7:13:51 PM UTC-7, Geoffrey Carson wrote:
>
> I am trying to connect a flow sensor directly to my BBB revC running 
> Ubuntu trusty. I Have Strangebrew Elsinore up and running with 8 DS18B20 
> i-wire sensors. I want to utilize a hall sensor based flow sensor without 
> having to get Arduino involved if possible. I am suffering sensory overload 
> with this simple, I hope, task. Any help would be appreciated or even 
> pointing me in the general direction.
>
>

-- 
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: Seriously Confused

[Brandon I]

I'm not sure the kernel source would be beneficial. If you want to
understand how the ADC works or get it going manually, with all the clock
domain setup and whatnot, then read the reference manual. The kernel source
will be doing all of this, in an abstracted and not so easy to understand
way.

The driver/sysfs interface wont load up until the device tree overlay (that
describes the ADC) is loaded. Is the BB-ADC overlay loaded?
http://analogdigitallab.org/articles/using-adc-beaglebone-black




On Thu, Nov 6, 2014 at 7:41 AM, Curt Carpenter <1cjcarpen...@att.net> wrote:

> Thanks Brandon.  Alas, the path used in the c_adc.c software just doesn't
> seem to exist in the Debian I'm using -- one of the big sources of
> confusion for me.  I'm starting to think the only solution is to try to dig
> into the kernel source as Joshua suggests -- but that sounds like it might
> take more years than I have left :-)
>
>
> On Wednesday, November 5, 2014 4:24:01 PM UTC-6, Brandon I wrote:
>>
>> https://github.com/adafruit/adafruit-beaglebone-io-python/
>> blob/master/source/c_adc.c
>>
>> The adc source for bbio should be useful.
>>
>> Keep in mind that these sysfs interfaces are incredibly slow compared to
>> memory poking since each operation requires opening, reading/writing and
>> closing the file. For example, with GPIO, you're limited to a few hundred
>> khz (regardless of language since it's just file operations). With mmap and
>> python, you can toggle at > 3Mhz. C a bit faster. Kernel, 12Mhz. There are
>> python and closing libraries that handle all of the memory poking.
>>
>> Also, check out libpruio. It will setup the pin muxing, and provides
>> quick adc and GPIO support.
>>
>>  --
> 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/9IRWOZ8b2n4/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.

[beagleboard] Re: Seriously Confused

[Brandon I]

https://github.com/adafruit/adafruit-beaglebone-io-python/blob/master/source/c_adc.c

The adc source for bbio should be useful. 

Keep in mind that these sysfs interfaces are incredibly slow compared to memory 
poking since each operation requires opening, reading/writing and closing the 
file. For example, with GPIO, you're limited to a few hundred khz (regardless 
of language since it's just file operations). With mmap and python, you can 
toggle at > 3Mhz. C a bit faster. Kernel, 12Mhz. There are python and closing 
libraries that handle all of the memory poking. 

Also, check out libpruio. It will setup the pin muxing, and provides quick adc 
and GPIO support. 

-- 
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: color ball tracking with opencv on BBB

[Brandon I]

Seems like a lot of work! Use an indirect internet connection to your
beaglebone using the USB to your computer, then set up a bridge between
your internet and the USB connection.

On Wed, Oct 29, 2014 at 11:47 PM, Lingesh Waran 
wrote:

> Hi all...I want to perform Image processing tasks in BBB which runs Debian
> Linux... so I need to install *OpenCV* on BBB.. It seems i should install
> *cmake * in prior... I dont have direct internet connection to my BBB.. I
> tried to download OpenCV from github.com
> 
>  as
> a ZIP file and i copied it to BBB using pendriveCan anyone please guide
> me how to install cmake on BBB?? i tried to download cmake and ended up in
> incomplete build please help me  your ideas will be really
> appreciated
>
> Thanks in advance :)
>
> --
> 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/fTan4VKv1no/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.

[beagleboard] how to gate input GPIO during powerup? also BBB SRM problems

[Brandon I]

For the external source, if your
BB loses power, then you'll be powering it up through the esd does in the pin 
connected to that external power source. It probably won't survive.

A general rule is to never apply voltage to a devices pin unless that device is 
powered up, unless it is in the devices design (rare).

(typing with phone sucks)

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

[Brandon I]

All pru GPIO are accessible via a single register, so it's one tick,just like 
any other register (two for loading a 32 bit immediate value). 

Arm GPIO are never accessible in a single tick since there way outside the Pru 
and have to go over the OCP bus. See 
http://nomel.tumblr.com/post/30006622413/beaglebone-tutorial-accessing-main-memory-from-the-pru

-- 
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] Running Python on PC to simulate Beaglebone Python

[Brandon I]

Use one of the many remote python libraries. Rpyc could do it. Have the code 
accessible from a shared drive, use module reload, and run the functions and 
play with the objects as if they were local. 

-- 
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: Read register or memory location

[Brandon I]

If you just want to poke around, you can compile 
devmem2: http://free-electrons.com/pub/mirror/devmem2.c

If you want proper high speed access, see the devmem2 source, or do the 
equivalent 
in python 
, 
or any other language that supports mmap.

On Wednesday, October 1, 2014 1:49:19 PM UTC-7, vescov...@gmail.com wrote:
>
> Is there an easy way to just read a memory location (or AM335x register) 
> under Debian?
>
> Not from u-boot but after fully booted?
>

-- 
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: BBB & MultiCast

[Brandon I]

>debian@beaglebone:/Distrib/Scripts$ sudo tcpdump -p -i eth0 host 224.0.0.1 
-n

What does the -p do?

On Wednesday, September 17, 2014 12:45:27 AM UTC-7, Mickae1 wrote:
>
> Well .
>
> I know google too, and I know this link . Thx for the answer .
>
>
> My problem is that the beagle still receive the multicast packet (yes it 
> ignore all multicast packet), which is a problem for me when you are in a 
> network full of camera That love to send multicast packet !
>
> I tried to disable multicast in the kernel, but it still receive multicast 
> packet. Do you know a solution to prevent this ?
>
>
> Micka,
>
> On Tue, Sep 16, 2014 at 9:43 PM, Brandon I  > wrote:
>
>> First google result seems useful:
>>
>>
>> http://stackoverflow.com/questions/16374670/why-i-can-not-disable-multicast-request
>>
>>
>> On Tuesday, September 16, 2014 7:14:10 AM UTC-7, Mickae1 wrote:
>>>
>>> I've tried to deactivate the Multicast with :
>>>
>>> ifconfig eth0 -multicast
>>>
>>> But when i check with this command, I can still see :
>>>
>>> ip maddr show
>>>
>>> 2:  eth0
>>> link  33:33:00:00:00:01
>>> link  01:00:5e:00:00:01
>>> link  33:33:ff:9a:05:07
>>> *inet  224.0.0.1*
>>> inet6 ff02::1:ff9a:507
>>> inet6 ff02::1
>>>
>>>
>>> Which is not good for me !
>>>
>>>
>>> i've tried :
>>>
>>> debian@beaglebone:/Distrib/Scripts$ sudo ip -r maddr delete 224.0.0.1 
>>> dev eth0
>>>
>>> ioctl: No such file or directory
>>>
>>>
>>> I also tried to ping 224.0.0.1 from an another device . 
>>>
>>> And with the command tcpdump I can see that I'm receiving multicast 
>>> packet :
>>>
>>> debian@beaglebone:/Distrib/Scripts$ sudo tcpdump -p -i eth0 host 
>>> 224.0.0.1 -n
>>>
>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol 
>>> decode
>>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
>>> 16:09:28.679257 IP *190.190.167.1 > 224.0.0.1*: ICMP echo request, id 
>>> 1, seq 1913, length 40
>>>
>>>
>>>
>>>
>>>
>>> Why ? I really don't know what to do about it, My idea is to deactivate 
>>> multicast in the kernel build config . Does it sounds good for you ?
>>>
>>>
>>>
>>> Thank you,
>>>
>>>
>>> Micka.
>>>
>>  -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[beagleboard] Re: BBB & MultiCast

[Brandon I]

First google result seems useful:

http://stackoverflow.com/questions/16374670/why-i-can-not-disable-multicast-request

On Tuesday, September 16, 2014 7:14:10 AM UTC-7, Mickae1 wrote:
>
> I've tried to deactivate the Multicast with :
>
> ifconfig eth0 -multicast
>
> But when i check with this command, I can still see :
>
> ip maddr show
>
> 2:  eth0
> link  33:33:00:00:00:01
> link  01:00:5e:00:00:01
> link  33:33:ff:9a:05:07
> *inet  224.0.0.1*
> inet6 ff02::1:ff9a:507
> inet6 ff02::1
>
>
> Which is not good for me !
>
>
> i've tried :
>
> debian@beaglebone:/Distrib/Scripts$ sudo ip -r maddr delete 224.0.0.1 dev 
> eth0
>
> ioctl: No such file or directory
>
>
> I also tried to ping 224.0.0.1 from an another device . 
>
> And with the command tcpdump I can see that I'm receiving multicast packet 
> :
>
> debian@beaglebone:/Distrib/Scripts$ sudo tcpdump -p -i eth0 host 224.0.0.1 
> -n
>
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 16:09:28.679257 IP *190.190.167.1 > 224.0.0.1*: ICMP echo request, id 1, 
> seq 1913, length 40
>
>
>
>
>
> Why ? I really don't know what to do about it, My idea is to deactivate 
> multicast in the kernel build config . Does it sounds good for you ?
>
>
>
> Thank you,
>
>
> Micka.
>

-- 
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: color ball tracking with opencv on BBB

[Brandon I]

Or, cpufreq-set -f 1GHz

On Thu, Sep 11, 2014 at 4:39 PM, William Hermans  wrote:

> Oh, and for the uninitiated . . . setting your governor to performance /
> 1Ghz _all_the_time_ may not be a very good idea. For instance it has been
> in the mid to upper 80's F outdoor ambient here, and I've noticed my BBB
> getting pretty warm.
>
> On Thu, Sep 11, 2014 at 4:34 PM, William Hermans 
> wrote:
>
>> From memory setting profile limits would be like this
>>
>> You change to a profile via
>> $ sudo cpufreq-set -g 
>> Check profile limits
>> $ sudo cpufreq-info -p
>> Change minimum profile range
>> $ cpufreq-set -d 100 /*set minimum processor freq for active profile
>> to 1 GHz */
>>
>> I do not know if these setting persist across reboots, but I think not.
>> At least it did not see that was for me. Also settings seem to be a bit
>> quirky. On one of my Linux support system for instance, manually changing
>> anything did not work as expected. I could change profiles, governors etc,
>> but actual frequency always stayed the same. Then with BBB when you set
>> minimum ondemand profile to 1Ghz, it does not take. But when changing to
>> performance profile, minimum freq is 300Mhz, but when you check actual
>> processor freq it is 1Ghz . . .
>>
>> So yeah, anyhow the program is quirky.
>>
>> On Thu, Sep 11, 2014 at 4:26 PM, William Hermans 
>> wrote:
>>
>>> $ cpufreq-set --help. You may need to set you profile limits/
>>> performance is default 300MHz to 1Ghz just like ondemand, but for some
>>> reason it is always 1GHz whenever I look.
>>>
>>> On Thu, Sep 11, 2014 at 3:47 PM, John Syn  wrote:
>>>
>>>>
>>>> From: 
>>>> Reply-To: "beagleboard@googlegroups.com" 
>>>> Date: Thursday, September 11, 2014 at 3:35 PM
>>>> To: "beagleboard@googlegroups.com" 
>>>> Subject: Re: [beagleboard] Re: color ball tracking with opencv on BBB
>>>>
>>>> I was able to build and install the same version of openCV (2.4.9) on
>>>> BBB debian as on my desktop Ubuntu by using an external USB memory stick.
>>>> Now I have a problem with changing CPU frequency (as I would like to
>>>> increase it from 300MHz to 1GHz)
>>>>
>>>> debian@beaglebone:~$ cpufreq-info
>>>> cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
>>>> Report errors and bugs to cpuf...@vger.kernel.org, please.
>>>> analyzing CPU 0:
>>>>   driver: generic_cpu0
>>>>   CPUs which run at the same hardware frequency: 0
>>>>   CPUs which need to have their frequency coordinated by software: 0
>>>>   maximum transition latency: 300 us.
>>>>   hardware limits: 300 MHz - 1000 MHz
>>>>   available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz
>>>>   available cpufreq governors: conservative, ondemand, userspace,
>>>> powersave, performance
>>>>   current policy: frequency should be within 300 MHz and 1000 MHz.
>>>>   The governor "ondemand" may decide which speed to use
>>>>   within this range.
>>>> *  current CPU frequency is 300 MHz.*
>>>>   cpufreq stats: 300 MHz:97.20%, 600 MHz:0.20%, 800 MHz:0.06%, 1000
>>>> MHz:2.55%  (35)
>>>>
>>>> debian@beaglebone:~$ sudo cpufreq-set -g GOV
>>>> *Error setting new values*. Common errors:
>>>> - Do you have proper administration rights? (super-user?)
>>>> - Is the governor you requested available and modprobed?
>>>> - Trying to set an invalid policy?
>>>> - Trying to set a specific frequency, but userspace governor is not
>>>> available,
>>>>for example because of hardware which cannot be set to a specific
>>>> frequency
>>>>or because the userspace governor isn't loaded?
>>>> debian@beaglebone:~$
>>>>
>>>> William just explained how to do this earlier today:
>>>>
>>>> *sudo cpufreq-set -g performance*
>>>>
>>>> Regards,
>>>> John
>>>>
>>>>
>>>>
>>>> What am I doing wrong?
>>>>
>>>> Jan
>>>>
>>>> On Wednesday, 10 September 2014 12:52:11 UTC+10, Brandon I wrote:
>>>>>
>>>>> And, here are some compile flags you'll want to include/force:
>>>>> http://www.eliteraspberries.com/blog/2013/09/cflags-for-n

Re: [beagleboard] Re: registering asynchronous events on kernel thread in user space

[Brandon I]

OK, one more time. All userspace interrupts work the same, pru, network
driver, *anything*. The process blocks until the interrupt handler unblocks
the process with a semaphore or completion in the kernel. For example, when
you read data for a socket connection, it blocks. When data comes in, the
data is copied to userspace, the read function unblocks. Again, this is all
explained in that LDD3 chapter I linked. There's no other way to do it,
except going around the kernel and polling memory.

1. This isn't a realtime kernel. You will always have jitter. Does it
matter? I don't know what you're doing. You don't need to use polling. UIO
and select doesn't use polling.

2. Using select (and even poll() since it's just a wrapper for select()) on
the gpio doesn't poll. It's interrupt driven. Same method as described.

3. Same method as described.

If you use the PRU, it will be the same method to notify your userspace
application with the same shortcomings, unless you put all of your code
into the pru. If you want deterministic timing, you either need a realtime
kernel, or put all your code on the pru. But, I can guarantee you don't
need deterministic timing, and I can guess that you're worrying about
nothing Seriously, do some benchmarks with sysfs. It's only a few lines of
code. And, there are all sorts of userspace hardware drivers that use
userspace interrupts out there including graphics and network.

If you only need to know when a gpio event happened, and process it later
(it will always be later since this isn't a realtime kernel or in the pru),
you can timestamp the event. I believe you can do this with the enhanced
timers, and I know you can do this in the pru. So it would go, event
happens, pru/etimer hardware timestamps the event, sends interrupt,
userspace gets interupt using "the only way possible", userspace reads
timestamp from hardware, pretends that the event happened at the timestamp
for any calculations.

If you explained what you were doing, we could advise you better.

Good luck!

On Thursday, September 11, 2014, neo  wrote:

> Hi Brandon
>
>1. I agree with jitter involved with processing interrupts and 100%
>cpu usage during polling for the same, so is there no way to let the
>user-space know that interrupt has occurred apart from polling ?
>2. The reason why i said pseudo-interrupt is because we are polling
>and waiting there which is same as watching a flag in a UART register for
>RX flag to set.
>3. I am curious as to how interrupts for Ethernet and usb are written.
>I am guessing that the ISR will use the DMA to transfer bytes to
>user-space. But even in that case the userspace should know that a new data
>has arrived. Then hoe to synchronize the kernel space and user-space if
>there are to share a data ?
>
> Thanks...
>
> On Thursday, September 11, 2014 2:26:15 AM UTC+5:30, Brandon I wrote:
>>
>> > pseudo-interrupt from user space
>>
>> There's nothing pseudo about it. Again, any usual way to have a userspace
>> application respond to an interrupt will be the exact same. The kernel will
>> block the userspace process until the interrupt is seen. The only real
>> alternative is burning up the cpu with memory polling, which appears to be
>> what the BBIOlib method uses. So, your latency is limited to your poll
>> speed (which can be faster than interrupts). But, if you have a constant
>> poll for minimum latency, lets hope you're not trying to do something
>> important elsewhere since your cpu usage will be at 100%, and you'll be
>> maximizing process to process context switching!
>>
>> For 4, The only difference between a userspace and kernel space interrupt
>> handler is where the code is that responds to the interrupt. You will only
>> benefit from writing your own interrupt handler if you put all of your code
>> that does something with that interrupt in the kernel. Otherwise, you're
>> back to process blocked by kernel, interrupt occurs, kernel unblocks
>> process, process does something after seeing the interruptback to the
>> sysfs/UIO method.
>>
>> I would try some benchmarks. See if the regular UIO/sysfs interrupt
>> method gives you sufficient performance. And definitely keep in mind John's
>> statement. You're going to see a massive amount of jitter for anything in
>> userspace or kernel space (better jitter since you can disable interrupts
>> and whatnot, but if you don't finish quickly in kernel space, you'll crash
>> the kernel).
>>
>> If something like a precise timestamp is needed for an async event, then
>> there are other ways to approach this. If you're looking for fi

Re: [beagleboard] Re: registering asynchronous events on kernel thread in user space

[Brandon I]

> pseudo-interrupt from user space

There's nothing pseudo about it. Again, any usual way to have a userspace
application respond to an interrupt will be the exact same. The kernel will
block the userspace process until the interrupt is seen. The only real
alternative is burning up the cpu with memory polling, which appears to be
what the BBIOlib method uses. So, your latency is limited to your poll
speed (which can be faster than interrupts). But, if you have a constant
poll for minimum latency, lets hope you're not trying to do something
important elsewhere since your cpu usage will be at 100%, and you'll be
maximizing process to process context switching!

For 4, The only difference between a userspace and kernel space interrupt
handler is where the code is that responds to the interrupt. You will only
benefit from writing your own interrupt handler if you put all of your code
that does something with that interrupt in the kernel. Otherwise, you're
back to process blocked by kernel, interrupt occurs, kernel unblocks
process, process does something after seeing the interruptback to the
sysfs/UIO method.

I would try some benchmarks. See if the regular UIO/sysfs interrupt method
gives you sufficient performance. And definitely keep in mind John's
statement. You're going to see a massive amount of jitter for anything in
userspace or kernel space (better jitter since you can disable interrupts
and whatnot, but if you don't finish quickly in kernel space, you'll crash
the kernel).

If something like a precise timestamp is needed for an async event, then
there are other ways to approach this. If you're looking for fixed low
latency, you're doomed.

On Wed, Sep 10, 2014 at 5:13 AM, neo  wrote:

> pseudo-interrupt from user space

-- 
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: color ball tracking with opencv on BBB

[Brandon I]

And, here are some compile flags you'll want to include/force:
http://www.eliteraspberries.com/blog/2013/09/cflags-for-numerical-computing-on-the-beaglebone-black.html


On Tue, Sep 9, 2014 at 7:16 PM, Brandon I  wrote:

> I'm not sure that newer open cv can be compiled on the raspberry or
> beaglebone due to the limited ram. You'll probably have to cross compile.
>
> On Tue, Sep 9, 2014 at 5:56 PM,  wrote:
>
>> Thanks for that link, it is very usefull.
>> In a meantime my attempt to install a newer version of opencv (following
>> the instructions from here
>> http://robertcastle.com/2014/02/installing-opencv-on-a-raspberry-pi/0)
>> has failed firstly with cmake-curses-gui not working (empty database?)  and
>> after that (using command line cmake) the building stopped with a error
>> message of not enough memory.
>> Jan
>>
>> On Tuesday, September 9, 2014 11:03:58 AM UTC+10, janszyma...@gmail.com
>> wrote:
>>>
>>> Hi,
>>>
>>>  I need to implement tracking of color ball with opencv on BBB.
>>> I have a rev.C BBB with latest (default Debian) including opencv 2.3.1
>>> On my desktop Ubuntu I have installed opencv 2.4.9
>>> To check the initial performance I used the example webcam program from
>>> the book "Practical OpenCV" listing 4-4 p.34 playing
>>> the video from USB camera (Logitech C920)
>>> I need a resolution of 640x480.
>>> The problem is with a speed on BBB, having a significant delay. It's
>>> good on a desktop PC.
>>>
>>> I would like to ask for advice how to improve the performance on BBB if
>>> possible.
>>>
>>> Jan
>>>
>>>  --
>> 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/fTan4VKv1no/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: registering asynchronous events on kernel thread in user space

[Brandon I]

Before you jump into the kernel hole, is there a reason that you're not
using the existing sysfs gpio interface (
https://www.kernel.org/doc/Documentation/gpio/sysfs.txt) for the interrupts?

Using this, if you set the gpio up as an interrupt with the sysfs
interface, you poll() the value file and it will block until there's an
interrupt. When it unblocks, you can read the current value.

Or, you can make the gpio look like an event/button:
http://bec-systems.com/site/281/how-to-implement-an-interrupt-driven-gpio-input-in-linux

Any sane way you do it will be the same at the low level. You'll have a
read or ioctl function on the kernel device file that blocks in the kernel
using a completion/semaphore, putting your process/thread to sleep. When
the interrupt fires, the interrupt handler function is called to release
the completion/semaphore, unblocking your process/thread and allowing it to
continue executing. This unblocking is how the userspace program is
signaled.

So, if you *want* to reinvent the wheel, for understanding, then that's
fine. But, there's an existing interface that exists, only a few lines of
code away.

--Brandon

On Tue, Sep 9, 2014 at 7:10 PM, neo star  wrote:

> Hi Brandon
>
> I read through the link, very informative thanks.I can create a thread to
> do the polling and signal me when its ready.
> But how to really write an ISR in arm. I see a lot of guides but they say
> that it will work in Intel processors but they are not sure about ARM.
> For sure from my readings i see that i need a kernel object to handle an
> ISR, But how to really do that.
> One example about how to handle interrupts is in
> http://stackoverflow.com/questions/15245626/simple-interrupt-handler-request-irq-returns-error-code-22
> The other one is request_threaded_irq() as mentioned by Kavita in the
> above post.
> Is there any How to and guide to writing one. Any links.
> Thanks.
>
>
> On Wednesday, September 10, 2014 12:59:08 AM UTC+5:30, Brandon I wrote:
>>
>> See UIO: https://www.kernel.org/doc/htmldocs/uio-howto/
>>
>> The uio_pruss.c driver that comes with the pru package is a good example.
>>
>> > I have written a kernel module that registers interrupts on the rising
>> edge on a GPIO pin and want to relay this message to user space.
>>
>> The sysfs gpio interface already does this. Check out the code.
>>
>> On Thursday, August 28, 2014 2:44:12 AM UTC-7, sid...@gmail.com wrote:
>>>
>>> I have read online that we can't handle interrupts from user
>>> space. Instead -
>>> 1) We can write a kernel thread and have that thread wait on an event.
>>> 2) Once the interrupt occurs, send one asynchronous event from the
>>> kernel module/driver to user space where we will have one signal handler
>>> with FASYNC to tackle this
>>>
>>> I have written a kernel module that registers interrupts on the rising
>>> edge on a GPIO pin and want to relay this message to user space. How do I
>>> go about implementing the above?
>>>
>>> Thanks!
>>>
>>  --
> 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/eNX0CU7-noE/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: color ball tracking with opencv on BBB

[Brandon I]

I'm not sure that newer open cv can be compiled on the raspberry or
beaglebone due to the limited ram. You'll probably have to cross compile.

On Tue, Sep 9, 2014 at 5:56 PM,  wrote:

> Thanks for that link, it is very usefull.
> In a meantime my attempt to install a newer version of opencv (following
> the instructions from here
> http://robertcastle.com/2014/02/installing-opencv-on-a-raspberry-pi/0)
> has failed firstly with cmake-curses-gui not working (empty database?)  and
> after that (using command line cmake) the building stopped with a error
> message of not enough memory.
> Jan
>
> On Tuesday, September 9, 2014 11:03:58 AM UTC+10, janszyma...@gmail.com
> wrote:
>>
>> Hi,
>>
>>  I need to implement tracking of color ball with opencv on BBB.
>> I have a rev.C BBB with latest (default Debian) including opencv 2.3.1
>> On my desktop Ubuntu I have installed opencv 2.4.9
>> To check the initial performance I used the example webcam program from
>> the book "Practical OpenCV" listing 4-4 p.34 playing
>> the video from USB camera (Logitech C920)
>> I need a resolution of 640x480.
>> The problem is with a speed on BBB, having a significant delay. It's good
>> on a desktop PC.
>>
>> I would like to ask for advice how to improve the performance on BBB if
>> possible.
>>
>> Jan
>>
>>  --
> 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/fTan4VKv1no/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] Is it possible to command a beaglebone black over Ethernet.

[Brandon I]

I saw the link to the reference, but I didn't see an answer to his question.

On Tue, Sep 9, 2014 at 2:47 PM, William Hermans  wrote:

> Brandon, I guess you did not look at the link I gave. It covers every
> aspect of configuring an eth device on Debian. That is when using
> /etc/network/interfaces
>
> On Tue, Sep 9, 2014 at 1:21 PM, Brandon I  wrote:
>
>> Ethernet will work without any configuration if you have dhcp on your
>> network. If not, you'll have to configure a static ip. If you do have dhcp
>> (you probably do) you can just change the hostname (
>> https://wiki.debian.org/HowTo/ChangeHostname) to something nice, then
>> use that instead of an ip for ssh, avoiding the insanity of a static ip.
>>
>> On Monday, September 8, 2014 12:14:17 PM UTC-7, William Hermans wrote:
>>
>>> Yes you can. You did not mention which distro you're using on the
>>> beaglebone black though. Assuming Debian . . .
>>>
>>> https://wiki.debian.org/NetworkConfiguration
>>>
>>> On Mon, Sep 8, 2014 at 11:47 AM,  wrote:
>>>
>>>>
>>>> I want to use the single usb port on beaglebone black for a usb webcam,
>>>> so can i avoid using the usb and control the beaglebone through the
>>>> Ethernet?,
>>>> I don't have a monitor either for the beaglebone black.
>>>>
>>>> --
>>>> 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 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/XbVuaXA9qYQ/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] Is it possible to command a beaglebone black over Ethernet.

[Brandon I]

Ethernet will work without any configuration if you have dhcp on your 
network. If not, you'll have to configure a static ip. If you do have dhcp 
(you probably do) you can just change the hostname (
https://wiki.debian.org/HowTo/ChangeHostname) to something nice, then use 
that instead of an ip for ssh, avoiding the insanity of a static ip.

On Monday, September 8, 2014 12:14:17 PM UTC-7, William Hermans wrote:

> Yes you can. You did not mention which distro you're using on the 
> beaglebone black though. Assuming Debian . . .
>
> https://wiki.debian.org/NetworkConfiguration
>
> On Mon, Sep 8, 2014 at 11:47 AM, > wrote:
>
>>
>> I want to use the single usb port on beaglebone black for a usb webcam, 
>> so can i avoid using the usb and control the beaglebone through the 
>> Ethernet?, 
>> I don’t have a monitor either for the beaglebone black.
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[beagleboard] Re: color ball tracking with opencv on BBB

[Brandon I]

You're desktop PC is > 10 times faster than the Beaglebone processor.

This may help:  How to Achieve 30 fps with BeagleBone Black 



On Monday, September 8, 2014 6:03:58 PM UTC-7, janszyma...@gmail.com wrote:
>
> Hi,
>
>  I need to implement tracking of color ball with opencv on BBB.
> I have a rev.C BBB with latest (default Debian) including opencv 2.3.1
> On my desktop Ubuntu I have installed opencv 2.4.9
> To check the initial performance I used the example webcam program from 
> the book "Practical OpenCV" listing 4-4 p.34 playing
> the video from USB camera (Logitech C920)
> I need a resolution of 640x480. 
> The problem is with a speed on BBB, having a significant delay. It's good 
> on a desktop PC.
>
> I would like to ask for advice how to improve the performance on BBB if 
> possible.
>
> Jan
>
>

-- 
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: registering asynchronous events on kernel thread in user space

[Brandon I]

See UIO: https://www.kernel.org/doc/htmldocs/uio-howto/

The uio_pruss.c driver that comes with the pru package is a good example.

> I have written a kernel module that registers interrupts on the rising 
edge on a GPIO pin and want to relay this message to user space. 

The sysfs gpio interface already does this. Check out the code.

On Thursday, August 28, 2014 2:44:12 AM UTC-7, sid...@gmail.com wrote:
>
> I have read online that we can't handle interrupts from user 
> space. Instead - 
> 1) We can write a kernel thread and have that thread wait on an event. 
> 2) Once the interrupt occurs, send one asynchronous event from the kernel 
> module/driver to user space where we will have one signal handler with 
> FASYNC to tackle this
>
> I have written a kernel module that registers interrupts on the rising 
> edge on a GPIO pin and want to relay this message to user space. How do I 
> go about implementing the above?
>
> 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] Can "allocated pins" on BBB be used as GPIOs ?

[Brandon I]

halfbrain,

> - If I used the EMMC pins I would need to boot from SD Card everytime?

Correct. You'll use the beaglebone white/sd card images. The beaglebone
will automatically boot from the SD card since it wont be able to find the
EMMC.

> - And if I used the HMDI Pins it wouldn't be possible to connect the
uHdmi Cable to the bbb and connect some screen to it? Because they are
connected to the same pins?

No HDMI if you disable HDMI, but you can still ssh/vnc in.

The way I'm suggesting is the proper way to disable built in overlays that
are loaded at boot. For some reason, only the hdmi and emmc interfaces are
added as overlays that can be disabled at boot. i2c and the likes are hard
coded in the dts file. Why? I don't know. Maybe there's a good reason,
probably not.

--Brandon


On Thu, Sep 4, 2014 at 7:28 AM, halfbrain  wrote:

> Thanks for your Answer Brandon
>
> Just a few questions for my Information:
> - If I used the EMMC pins I would need to boot from SD Card everytime?
> - And if I used the HMDI Pins it wouldn't be possible to connect the uHdmi
> Cable to the bbb and connect some screen to it? Because they are connected
> to the same pins?
>
> The way you unallocated the pins and the way john recommend me to
> unallocate the pins seem to be very different. To be honest I don't
> understand the difference of the two ways. Which way is the easier one and
> can this way be used to unallocate every pin on the bbb? I just wan't to
> make things trickier than they are :-) But i'm very thankful for your help
> so far ;-)
>
> Am Mittwoch, 3. September 2014 22:00:16 UTC+2 schrieb Brandon I:
>
>> halfbrain, I forgot to mention, you should tie the eMMC cmd and clock
>> pins low on P8.20 and P8.21, as suggested by the wiki: http://elinux.org/
>> Beagleboard:BeagleBoneBlack#Onboard_eMMC
>>
>> On Wednesday, September 3, 2014 12:58:09 PM UTC-7, Brandon I wrote:
>>>
>>> halfbrain,
>>>
>>> If you're using angstrom or debian, you can disable the emmc by adding
>>> this to the optargs in uEnv.txt on the usb mass storage
>>> partition: capemgr.disable_partno=BB-BONE-EMMC-2G
>>>
>>> If you're not using hdmi, you can free up those
>>> too: capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-
>>> HDMIN,BB-BONE-EMMC-2G
>>>
>>>
>>> On Saturday, August 23, 2014 1:11:22 AM UTC-7, halfbrain wrote:
>>>>
>>>> Would be nice if you could explain how to disable eMMC on debian. I ran
>>>> out of GPIO's in my project. Tried to use P9_19 and P9_20 (both I2C's) in
>>>> the device tree overlay but since i did that the overlay doesn't work
>>>> correctly anymore.
>>>>
>>>> Am Sonntag, 18. Mai 2014 22:19:16 UTC+2 schrieb john3909:
>>>>>
>>>>>
>>>>> From: Dhruv Vyas 
>>>>> Reply-To: 
>>>>> Date: Sunday, May 18, 2014 at 2:42 AM
>>>>> To: 
>>>>> Subject: [beagleboard] Can "allocated pins" on BBB be used as GPIOs ?
>>>>>
>>>>> Hello,
>>>>>
>>>>> I recently started working on my BBB A6A. I went through necessary
>>>>> getting started guides and it works like a charm. Now as a part of my
>>>>> project, I need to use some of the GPIOs on P8/P9 header. While googling
>>>>> how to use them as a GPIO, and how to set pinmux and etc, I went through
>>>>> this guide.  http://derekmolloy.ie/gpios-
>>>>> on-the-beaglebone-black-using-device-tree-overlays/ and he explained
>>>>> everything very clearly.
>>>>>
>>>>> Now my question is : is there any way i can use allocated pins as
>>>>> GPIOs other than available pins ? If yes, how ? If no, why ?
>>>>>
>>>>> For example, P9_19 and P9_20 are Allocated to (Group:
>>>>> pinmux_i2c2_pins) and hence it can not be used as GPIOs ?
>>>>>
>>>>> If pins are also connected to circuitry on the board that cannot be
>>>>> disabled then you cannot use those pins for GPIO. For example, pins used
>>>>> for the eMMC can be used for GPIO as long as eMMC is disabled. Same for 
>>>>> LCD
>>>>> pins, but then you cannot use LCD or HDMI. I2C2 isn't connected to other
>>>>> circuity on the board so you can use it for GPIO.
>>>>>
>>>>> Regards,
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>

Re: [beagleboard] Can "allocated pins" on BBB be used as GPIOs ?

[Brandon I]

halfbrain, I forgot to mention, you should tie the eMMC cmd and clock pins 
low on P8.20 and P8.21, as suggested by the 
wiki: http://elinux.org/Beagleboard:BeagleBoneBlack#Onboard_eMMC

On Wednesday, September 3, 2014 12:58:09 PM UTC-7, Brandon I wrote:
>
> halfbrain,
>
> If you're using angstrom or debian, you can disable the emmc by adding 
> this to the optargs in uEnv.txt on the usb mass storage 
> partition: capemgr.disable_partno=BB-BONE-EMMC-2G
>
> If you're not using hdmi, you can free up those 
> too: capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
>
>
> On Saturday, August 23, 2014 1:11:22 AM UTC-7, halfbrain wrote:
>>
>> Would be nice if you could explain how to disable eMMC on debian. I ran 
>> out of GPIO's in my project. Tried to use P9_19 and P9_20 (both I2C's) in 
>> the device tree overlay but since i did that the overlay doesn't work 
>> correctly anymore.
>>
>> Am Sonntag, 18. Mai 2014 22:19:16 UTC+2 schrieb john3909:
>>>
>>>
>>> From: Dhruv Vyas 
>>> Reply-To: 
>>> Date: Sunday, May 18, 2014 at 2:42 AM
>>> To: 
>>> Subject: [beagleboard] Can "allocated pins" on BBB be used as GPIOs ?
>>>
>>> Hello,
>>>
>>> I recently started working on my BBB A6A. I went through necessary 
>>> getting started guides and it works like a charm. Now as a part of my 
>>> project, I need to use some of the GPIOs on P8/P9 header. While googling 
>>> how to use them as a GPIO, and how to set pinmux and etc, I went through 
>>> this guide.  
>>> http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/
>>>  
>>> and he explained everything very clearly.
>>>
>>> Now my question is : is there any way i can use allocated pins as GPIOs 
>>> other than available pins ? If yes, how ? If no, why ? 
>>>
>>> For example, P9_19 and P9_20 are Allocated to (Group: pinmux_i2c2_pins) 
>>> and hence it can not be used as GPIOs ?
>>>
>>> If pins are also connected to circuitry on the board that cannot be 
>>> disabled then you cannot use those pins for GPIO. For example, pins used 
>>> for the eMMC can be used for GPIO as long as eMMC is disabled. Same for LCD 
>>> pins, but then you cannot use LCD or HDMI. I2C2 isn’t connected to other 
>>> circuity on the board so you can use it for GPIO. 
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>> 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...@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] Can "allocated pins" on BBB be used as GPIOs ?

[Brandon I]

halfbrain,

If you're using angstrom or debian, you can disable the emmc by adding this 
to the optargs in uEnv.txt on the usb mass storage 
partition: capemgr.disable_partno=BB-BONE-EMMC-2G

If you're not using hdmi, you can free up those 
too: capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G


On Saturday, August 23, 2014 1:11:22 AM UTC-7, halfbrain wrote:
>
> Would be nice if you could explain how to disable eMMC on debian. I ran 
> out of GPIO's in my project. Tried to use P9_19 and P9_20 (both I2C's) in 
> the device tree overlay but since i did that the overlay doesn't work 
> correctly anymore.
>
> Am Sonntag, 18. Mai 2014 22:19:16 UTC+2 schrieb john3909:
>>
>>
>> From: Dhruv Vyas 
>> Reply-To: 
>> Date: Sunday, May 18, 2014 at 2:42 AM
>> To: 
>> Subject: [beagleboard] Can "allocated pins" on BBB be used as GPIOs ?
>>
>> Hello,
>>
>> I recently started working on my BBB A6A. I went through necessary 
>> getting started guides and it works like a charm. Now as a part of my 
>> project, I need to use some of the GPIOs on P8/P9 header. While googling 
>> how to use them as a GPIO, and how to set pinmux and etc, I went through 
>> this guide.  
>> http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/
>>  
>> and he explained everything very clearly.
>>
>> Now my question is : is there any way i can use allocated pins as GPIOs 
>> other than available pins ? If yes, how ? If no, why ? 
>>
>> For example, P9_19 and P9_20 are Allocated to (Group: pinmux_i2c2_pins) 
>> and hence it can not be used as GPIOs ?
>>
>> If pins are also connected to circuitry on the board that cannot be 
>> disabled then you cannot use those pins for GPIO. For example, pins used 
>> for the eMMC can be used for GPIO as long as eMMC is disabled. Same for LCD 
>> pins, but then you cannot use LCD or HDMI. I2C2 isn’t connected to other 
>> circuity on the board so you can use it for GPIO. 
>>
>> Regards,
>> John
>>
>>
>>
>> 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...@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] Tri-state GPIOs?

[Brandon I]

As a side note, you can also emulate open drain. Set the pin output state 
to 0, then enable/disable the output driver. And, for performance, writing 
to the gpio registers rather than doing file operations with sysfs is > 30 
times faster.

And, pin muxing (pullups/down and input receiver enable for reading pin 
state) is separate from the gpio operations (output driver enable/disable, 
reading physical pin state, setting output driver level).

On Wednesday, August 27, 2014 12:02:11 PM UTC-7, Gerald wrote:
>
> But, you have to watch the pullups and pull downs when you do that.
>
> Gerald
>
>
>
> On Tue, Aug 26, 2014 at 8:20 PM, John Syn 
> > wrote:
>
>>
>>  From: Gerald Coley >
>> Reply-To: "beagl...@googlegroups.com " <
>> beagl...@googlegroups.com >
>> Date: Tuesday, August 26, 2014 at 1:06 PM
>> To: "beagl...@googlegroups.com " > >
>> Subject: Re: [beagleboard] Tri-state GPIOs?
>>
>> No.
>>
>> You can emulate tristate by changing GPIO outputs to GPIO inputs.
>>
>> Regards,
>> John
>>
>>
>> Gerald
>>
>>
>>
>> On Tue, Aug 26, 2014 at 4:36 AM, > 
>> wrote:
>>
>>> Hey Guys
>>>
>>> Has the Beaglebone black *tri-state gpios*?
>>>
>>> When yes, how can I set up them?
>>>
>>> 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...@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...@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...@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] Re: Accessing DDR from PRU-ICSS

[Brandon I]

I responded to your other 
post: https://groups.google.com/d/msg/beagleboard/u28ytaoNenU/2OeuvwF4cHwJ

On Wednesday, August 13, 2014 2:22:49 PM UTC-7, rakesh.safir wrote:
>
> Hi,
>
> I want to use the DCAN interface on PRU-ICSS to send/receive data present 
> on DDR RAM at a fixed physical address. 
>
>- Address of DDR is 0x8000_ to 0x9000_(256MiB)
>- My buffer is present at 0x8FF0_ to 0x9000_ (1MiB)
>
>  As soon as I access the hardware address 0x8FF0_ the PRU-ICSS goes 
> into some faulty state and becomes unresponsive.
>
> Is there some other way to access DDR from PRU-ICSS ?
>
> Rakesh 
>

-- 
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] Setting the Bitrate of I2C2 on the Beaglebone Black

[Brandon I]

I think this can only mean that a device isn't responding to the address
you're providing. Did you set the i2c device address to the same value used
with i2ctest?


On Thu, Aug 14, 2014 at 10:09 AM, Akhil Panyamparambil <
akhilpana...@gmail.com> wrote:

> Hi all. Can you guys help me.I am using beaglebone black i2c2 pin 19 and
> 20 of p9. Somewhere in the net it was told i2c2 has told accessed with
> i2c-1 in /dev folder. I am booting default amstrom linux from emmc.
> Hardware is completely checked and verified. I have connected 3 io
> expansion modules to i2c bus. I can communicate to them by i2ctest commands
> from command line. But the problem is with the file writes. I cant write to
> /dev/i2c-1 file with "write" function. The file descriptor doeant have an
> error. Also the ioctl calls doest make any errors. But the write function
> is having problem. And thus I cant access i2c bus in application layer.
>
> --
> 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/vbuM-4oShS8/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: PRU FAQ 2013-05-15

[Brandon I]

You have to enable the ocp master port (section 10.1.2)  to access main
memory. Here's an explanation

.

And, the resulting code is (if you want to do it in the pru):

// clear STANDBY_INIT bit in syscfg register so memory between pru <->
system can be accessed (enable ocp master)
LBCO r0, C4, 4, 4
CLR r0, r0, 4
SBCO r0, C4, 4, 4

See section 3.1.2 in the pru reference
 for limitations
(accessing memory below main memory 0x0008 requires enabling an offset,
section 10.1.10).



On Wed, Aug 13, 2014 at 2:02 PM, rakesh.safir 
wrote:

> Hi,
>
> I want to use the DCAN interface on PRU-ICSS to send/receive data present
> on DDR RAM at a fixed physical address.
>
>- Address of DDR is 0x8000_ to 0x9000_(256MiB)
>- My buffer is present at 0x8FF0_ to 0x9000_ (1MiB)
>
>  As soon as I access the hardware address 0x8FF0_ the PRU-ICSS goes
> into some faulty state and becomes unresponsive.
>
> Is there some other way to access DDR from PRU-ICSS ?
>
> Rakesh
>
> On Thursday, May 16, 2013 2:42:39 AM UTC+5:30, Jason Kridner wrote:
>>
>> Frequently asked questions regarding "PRU":
>>
>>- What is a "PRU"?
>>- PRU stands for Programmable Real-time Unit.  The overall subsystem
>>   is typically called the ICSS, PRU-ICSS or PRUSS.  ICSS stands for
>>   Industrial Communications Subsystem and PRUSS stands for Programmable
>>   Real-time Unit Subsystem.
>>- What does a PRU do?
>>   - A PRU is a 200MHz microcontroller that is really useful at
>>   "bitbanging" and has some peripherals attached to it that make it well
>>   suited for building real-time interfaces to all types of digital
>>   electronics.
>>- What are the processing elements within the AM33xx PRUSS used on
>>BeagleBone and BeagleBone Black?
>>   - 2 32-bit 200MHz PRU cores
>>   - Each with 8KB of program memory
>>   - Direct access to general purpose I/O
>>   - Single cycle operations without cache or pipelines (instructions
>>   *always* 5ns)
>>   - Shared 12KB data memory
>>   - Scratch pad registers
>>   - Parallel and serial capture modes
>>   - 32-bit port to memory and other peripherals outside of the
>>   PRUSS, including external memory
>>- What are some example things built out of PRUs?
>>   - DMX512 lighting protocol: http://beagleboard.
>>   org/CapeContest/entries/BeagleBone+DMX+Cape/
>>   
>>   - 6502 memory interface: http://elinux.org/
>>   images/a/ac/What's_Old_Is_New-_A_6502-based_Remote_Processor.pdf
>>   
>> 
>>   - Emulated memory interface on an Atari 600XL with BeagleBone
>>   decoding video directly into Atari 600XL display memory:
>>   http://www.youtube.com/watch?v=1irR4TQ5aMA
>>   
>>   - Nixie tube interface: https://github.com/mranostay/beagle-nixie
>>   - Software UART: http://processors.wiki.ti.com/index.php/Soft-UART_
>>   Implementation_on_AM335X_PRU_-_Software_Users_Guide
>>   
>> 
>>   - Sine wave generator using PWMs: http://elinux.org/
>>   ECE497_BeagleBone_PRU
>>   - 3D printer stepper motor driver: http://
>>   hipstercircuits.com/pypruss-a-simple-pru-python-binding-for-
>>   beaglebone/
>>   
>> 
>>   - Camera interface: http://www.hitchhikeree.org/beaglebone_
>>   capes/interacto/
>>- Where do I get some more details?
>>   - https://github.com/beagleboard/am335x_pru_package is the
>>   official location for documentation and tools for the PRUSS on 
>> BeagleBone
>>   and BeagleBone Black.
>>   - http://elinux.org/Ti_AM33XX_PRUSSv2 is the community wiki page.
>>
>>
>>  --
> 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/u28ytaoNenU/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: i wanna 8bit gpio control

[Brandon I]

I believe the only way is to remove them from the main device tree overlay
since that will be loaded before anything else you can do. Decompile the
dtbo, remove the usr led entries in the resulting dts, and recompile to
dtbo (at least this is how it used to work).


On Wed, Aug 13, 2014 at 3:10 PM, Patrick Sheridan  wrote:

> Hi Brandon,
>
> I'm currently using mmap (in Python) to achieve register wide GPIO.  I'm
> concerned though, that the kernel still thinks it owns that memory and
> might inadvertently write to it (for ex:  if you forget to disable the
> heartbeat trigger).  Do you know of a way to disable the sysfs interface /
> claim those pins as being in use so that you can safely manipulate the mmap
> either through software or a device tree overlay?
>
> Thanks for your help.
>
>
> On Tuesday, July 29, 2014 3:09:08 PM UTC-4, Brandon I wrote:
>>
>> That's still one bit control. There's going to be some unknown time
>> between the bits that will depend on cpu usage. For true 8 bit, you need to
>> use mmap to get a pointer to the gpio control block and modify the
>> registers directly.
>> Each gpio block has 32 pins, and each gpio block has a set and clear
>> register that's 32 bits wide, one bit for each pin. Setting a bit in the
>> set register will set the pin. Setting a bit in the clear register will
>> clear the pin. So, to set 8 pins at once, you would write the 8 bits to the
>> set, then to clear all 8, you would write those 8 bits to the clear
>> register. This will truly be "at once", at least to the capabilities of the
>> hardware.
>>
>> Sysfs has some pretty absurd overhead, so you'll get a few hundred kHz at
>> most. With the the register manipulation using mmap, you'll end up with ~4
>> MHz for a toggle like that.
>>
>>
>> On Sunday, July 27, 2014 4:09:56 AM UTC-7, kthab...@gmail.com wrote:
>>>
>>> /sys/class/gpio/export  this driver file i have used.
>>>
>>> but this control only one bit. so, i try to 8bit control like this
>>>
>>> #include "bb_gpio.h"
>>> #include 
>>> #include 
>>> //#include 
>>>
>>> void main(void)
>>> {
>>> gpio_export(p9_11); gpio_export(p9_12);
>>>  gpio_export(p9_13); gpio_export(p9_14);
>>> gpio_export(p9_15); gpio_export(p9_16);
>>> gpio_export(p9_17); gpio_export(p9_18);
>>>
>>> gpio_direction(p9_11,out); gpio_direction(p9_12,out);
>>> gpio_direction(p9_13,out); gpio_direction(p9_14,out);
>>>  gpio_direction(p9_15,out); gpio_direction(p9_16,out);
>>> gpio_direction(p9_17,out); gpio_direction(p9_18,out);
>>>  while(1){
>>> pin_write(p9_11,1); pin_write(p9_12,1);
>>> pin_write(p9_13,1); pin_write(p9_14,1);
>>>  pin_write(p9_15,1); pin_write(p9_16,1);
>>> pin_write(p9_17,1); pin_write(p9_18,1);
>>> sleep(1);
>>>  pin_write(p9_11,0); pin_wirte(p9_12,0);
>>> pin_write(p9_13,0); pin_wirte(p9_14,0);
>>> pin_write(p9_15,0); pin_wirte(p9_16,0);
>>>  pin_write(p9_17,0); pin_wirte(p9_18,0);
>>> sleep(1);
>>> };
>>> }
>>>
>>>
>>> #include "bb_gpio.h"
>>>
>>> #ifndef BB_GPIO_H_
>>> #define BB_GPIO_H_
>>>
>>> #include 
>>> #include 
>>>
>>> /
>>> * BB_GPIO headerfile
>>> * This file only used to gpio control
>>> * other feature using device-tree-overlay
>>> * when using GPIO, the pin work to MODE7
>>> *=formula==
>>> * GPIO N1[N2]
>>> * gpio_number = (32 x N1) + N2
>>> *==
>>> */
>>>
>>> #define out 1
>>> #define in 0
>>>
>>> #define  export_PATH  "/sys/class/gpio/export"
>>> #define  value_PATH "/sys/class/gpio/gpio%d/value"
>>> #define  direction_PATH "/sys/class/gpio/gpio%d/direction"
>>> #define unexport_PATH "/sys/class/gpio/unexport"
>>>
>>> //*P9***
>>> #define  p9_11   30
>>> #define  p9_12   60
>>> #define  p9_13   31
>>> #define  p9_14  50
>>> #define  p9_15  48
>>> #define  p9_16  51
>>> #define  p9_17 5
>>> #define  p9_18 4
>>> //#define  p9_19 13
>>> //#define  p9_20 12
>>> #define  p9_21 3
>>> #define P9_22 2
>>> #define  p9_23  49
>>>

Re: [beagleboard] long term BBB based art installation

[Brandon I]

You can do read only with stock debian using this approach:
http://ecloud.org/index.php?title=Debian_on_read-only_media

This is very important for long term installs with flash media. If you do
need to write, use a usb flash disk that the customer can get to and
replace when needed, because it will eventually fail.





On Sat, Aug 2, 2014 at 9:46 PM, Daniel Pickford  wrote:

> Matty,
>
> Sounds like a fun project!  My issues with the BBBs historically have all
> been power related and SD card related.  I can't say I've ran one for
> longer that a few months without rebuilding it, but it's the first few
> months that generally present the hardware problems.
>
> In regards to a long term BBB install, the duty cycle on the SD card is of
> significant concern (if you have a high quality power supply).  I'm seeing
> uSD cards start to fail with <10K's of block rewrites on "professional"
> grade microsd's right now.  There are MLC/SLC industrial cards out there,
> but they are pretty expensive.  The idea of throwing any logs or writes
> onto a ramdisk is solid.  I don't have experience with the long term
> reliability of the onboard eMMC (in general I find the r/w speeds a little
> slow and I like keeping a default bootable image around in case sd card
> starts dying (see previous paragraph...)) but if you can get rid of every
> last block rewrite regardless of what flash storage type, it'll be worth it.
>
> If you concerned about boot times, check out systemd, super easy to get
> working on the current debian stable.  I spend more time waiting for USB
> peripherals to boot up than the OS services nowadays.
> https://wiki.debian.org/systemd.  You just have to pass the systemd
> kernel parameter in uEnv.txt.   If it's autobootable by OSX you are likely
> running fat32 on the /boot volume. It's not that robust of a filesystem,
> and is a little long in the tooth.  You might want to switch to ext2+.
> Because of the aforementioned flash duty cycle issues, I try to leave the
> boot volume alone and effectively read only.
>
> The file being interpreted as a binary is a nasty one - it actually sounds
> like the file could be getting corrupted.  I'd use the file command on the
> scripts you are having problems with, it basically checks to see if you
> have any non-null bytes.   How do you fix it?  Delete the file and copy a
> new one?
>
> On Aug 2, 2014, at 9:01 PM, Matt Pinner  wrote:
>
> tldr: im using 2x beagle bone in a long term install and hope to enable
> anyone to update the configurations.
>
> Thanks for all the great advice thus far. i'm starting to feel confident
> about a few things.
>
> ok, im not sure im ready for the read-only mount. i like using the eMMC.
> are there advantages wrt stability. i aim to keep the debian as close to
> stock as possible. im considering upgrading to the 4gb bbb's in an effort
> to avoid disk issues and get the stock os.
>
> i quite like being able to mount the beagle eMMc /boot/uboot as a
> removeable drive on my mac. exposing this usb drive can potentially enable
> a complete noob to update configurations.  i put im having all scripts
> source /boot/uboot/env.sh by default to enable some global values.  when i
> move and edit files on /boot/uboot/ when mounted as a drive on my mac,
> occasionally, the file will become unexecutable as bash script and become
> interrupted as binary?  know what causing that?
>
> i've roughly put my latest configuration in
> https://github.com/mpinner/Active
>
> --matt
>
>
> On Tue, Jul 29, 2014 at 1:19 PM, Brandon I 
> wrote:
>
>> Don't forget, read only mount! Flash has limited writes and is can easily
>> be corrupted/damaged from power failure.
>>
>> On Tuesday, July 29, 2014 9:02:52 AM UTC-7, Ben Gamari wrote:
>>
>>> Matt Pinner  writes:
>>>
>>> > tldr: can i run a BBB for three years?
>>> >
>>> Sure!
>>>
>>> > I'm about to fly a BBB (w the latest debian) high into the rafters at
>>> a
>>> > space in Denver.
>>> >
>>> Awesome!
>>>
>>> > It will control 1440 leds over SPI from pixel data sent over UDP via
>>> OPC.
>>> >
>>> What is OPC? Presumably this isn't OLE for Process Control?
>>>
>>> > This is all very exciting for me and things have been running fairly
>>> > smoothly and the community support and blogs have been enormously
>>> helpful.
>>> >
>>> > Now i'm kind of freaking out bc this thing should ideally run as
>>> stably as
>>> > any light fixture and i'm no

Re: [beagleboard] Re: Maximum current on GPIO?

[Brandon I]

Serge, I was talking about the pin driver circuit inside the package
(something like this <http://i.stack.imgur.com/f3Dz6.png>) not an external
connection to 3.3V or ground, but I totally agree for external connections.
Always make sure the current in and out of the pin, in any oops type
configuration, will be limited to what the pin can handle.




On Wed, Jul 30, 2014 at 10:37 PM,  wrote:

>
>
> On Thursday, July 31, 2014 12:39:42 AM UTC+6, Brandon I wrote:
>>
>> The gpio are push pull/pseudo open drain, so there's a transistor/switch
>> going from 3.3V to the pin,...
>>
>>
> At boot time the respective Sitara pins become outputs high/low level as
> needed.
> Then, please never assume your GPIO is tri-state.
>
>
> In theory you may connect 3.3v power line direct to the pin if:
> 1) you are sure it is not used at boot time as the output
> 2) it is 3.3v domain power related pin.
>
> Feel free to ground the pin if:
> 1) you are sure it is never used at boot time as an output, and you never
> drive it High.
>
>
> To live safe and feel happy always add pulling resistors, never connect
> pin to the VCC or GND dorectly.
>
> --
> 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/cWGCEtg9syY/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: Maximum current on GPIO?

[Brandon I]

The gpio are push pull/pseudo open drain, so there's a transistor/switch
going from 3.3V to the pin, and a transistor going from ground to the pin.
When you set the pin high, you're turning on only the transistor to 3.3V,
so it's sourcing the current from 3.3V, through the transistor, out of the
pin. When you set it low, you're turning on the transistor to ground, so
it's sinking the current into the pin, through the transistor, and to
ground. If you have both off (high impedance), there isn't any significant
current going anywhere (I think it's some nA).





On Wed, Jul 30, 2014 at 6:11 AM,  wrote:

> A GPIO configured as an input will not draw substantial current from the
> line it's connected to.  It is sensitive to the charge level on the line
> and will not draw current from it (exempting the gate capacitor charge-up).
>  A GPIO that is set to OUTPUT a high signal is now a potential source of
> current.   If you hook that up to the + end of a motor it will try to power
> the motor with the output.  In that case you MUST insure that your circuit
> limits the current to a maximum of 6mA.  The same is true if you OUTPUT a
> low signal.  Hook that to the - lead on a motor and the + lead to supply
> and the CPU is now trying to absorb all the current from that motor and
> will go poof.
>
> So if you were to connect directly to the positive supply and say somehow
> that pin ever becomes an output that is low you now have a dead short
> through the I/O pin and at best you'll fry that pin or its whole bank,
> you'll likely kill the whole chip.  Since the I/O on these devices is
> programmatic I never like to connect a pin directly to the supply rails.
>
> --
> 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/cWGCEtg9syY/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] long term BBB based art installation

[Brandon I]

Don't forget, read only mount! Flash has limited writes and is can easily 
be corrupted/damaged from power failure.

On Tuesday, July 29, 2014 9:02:52 AM UTC-7, Ben Gamari wrote:
>
> Matt Pinner > writes: 
>
> > tldr: can i run a BBB for three years? 
> > 
> Sure! 
>
> > I'm about to fly a BBB (w the latest debian) high into the rafters at a 
> > space in Denver. 
> > 
> Awesome! 
>
> > It will control 1440 leds over SPI from pixel data sent over UDP via 
> OPC. 
> > 
> What is OPC? Presumably this isn't OLE for Process Control? 
>
> > This is all very exciting for me and things have been running fairly 
> > smoothly and the community support and blogs have been enormously 
> helpful. 
> > 
> > Now i'm kind of freaking out bc this thing should ideally run as stably 
> as 
> > any light fixture and i'm not sure a good way to really test that kind 
> of 
> > thing.   
> > 
> Indeed it's not easy to test for stability. I've found the BBB hardware 
> to be rock solid but YMMV. The obvious place to start would be just to 
> let the board sit running your code for as long as you can. 
>
> > the sub one-minute boot up time seems acceptible enough, so the client 
> can 
> > always reboot it, but then what does that do the filesystem? 
> > 
> > i've started looking into logrotate to keep the disk cleared, but there 
> is 
> > still the question how many read/write cycles will the eMMC accept 
> before 
> > drama happens? 
> > 
> If at all possible I would try to keep the root file system mounted as 
> read-only.  It can be difficult to predict the rate of disk writes 
> (e.g. logging rate) on a running system and I wouldn't want to risk it 
> just for log files. This is especially true if you may have flaky power 
> (SD cards have been known to die when power is removed at the wrong 
> point in a write operation). My first instinct would be to play it safe 
> and put /var on a tmpfs. 
>
> > I plan to have a private network running so i should be able to login to 
> > the BBB for some kind of maintenance and troubleshooting. do i run a 
> long 
> > (100ft) serial cable? and usb cable as well? 
> > 
> It certainly wouldn't hurt to have something like this in place, 
> especially at first. 
>
> > im tempted to put it online so i can check from afar, but i feel that 
> > invites all kinds of new room for disaster and abuse. 
> > 
> If you firewall all but port 22 and configure sshd securely (either 
> a particularly strong password or exclusively key-based authentication) 
> I'd say the risk is pretty low. 
>
> Let us know how it goes and don't hesitate to ask more questions! 
>
> Cheers, 
>
> - Ben 
>

-- 
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: i wanna 8bit gpio control

[Brandon I]

That's still one bit control. There's going to be some unknown time between 
the bits that will depend on cpu usage. For true 8 bit, you need to use 
mmap to get a pointer to the gpio control block and modify the registers 
directly. 
Each gpio block has 32 pins, and each gpio block has a set and clear 
register that's 32 bits wide, one bit for each pin. Setting a bit in the 
set register will set the pin. Setting a bit in the clear register will 
clear the pin. So, to set 8 pins at once, you would write the 8 bits to the 
set, then to clear all 8, you would write those 8 bits to the clear 
register. This will truly be "at once", at least to the capabilities of the 
hardware.

Sysfs has some pretty absurd overhead, so you'll get a few hundred kHz at 
most. With the the register manipulation using mmap, you'll end up with ~4 
MHz for a toggle like that.


On Sunday, July 27, 2014 4:09:56 AM UTC-7, kthab...@gmail.com wrote:
>
> /sys/class/gpio/export  this driver file i have used.
>
> but this control only one bit. so, i try to 8bit control like this
>
> #include "bb_gpio.h"
> #include 
> #include 
> //#include 
>
> void main(void)
> {
> gpio_export(p9_11); gpio_export(p9_12);
> gpio_export(p9_13); gpio_export(p9_14);
> gpio_export(p9_15); gpio_export(p9_16);
> gpio_export(p9_17); gpio_export(p9_18);
>
> gpio_direction(p9_11,out); gpio_direction(p9_12,out);
> gpio_direction(p9_13,out); gpio_direction(p9_14,out);
> gpio_direction(p9_15,out); gpio_direction(p9_16,out);
> gpio_direction(p9_17,out); gpio_direction(p9_18,out);
>  while(1){
> pin_write(p9_11,1); pin_write(p9_12,1);
> pin_write(p9_13,1); pin_write(p9_14,1);
> pin_write(p9_15,1); pin_write(p9_16,1);
> pin_write(p9_17,1); pin_write(p9_18,1);
> sleep(1);
> pin_write(p9_11,0); pin_wirte(p9_12,0);
> pin_write(p9_13,0); pin_wirte(p9_14,0);
> pin_write(p9_15,0); pin_wirte(p9_16,0);
> pin_write(p9_17,0); pin_wirte(p9_18,0);
> sleep(1);
> };
> }
>
>
> #include "bb_gpio.h"
>
> #ifndef BB_GPIO_H_
> #define BB_GPIO_H_
>
> #include 
> #include 
>
> /
> * BB_GPIO headerfile
> * This file only used to gpio control
> * other feature using device-tree-overlay
> * when using GPIO, the pin work to MODE7
> *=formula==
> * GPIO N1[N2]
> * gpio_number = (32 x N1) + N2
> *==
> */
>
> #define out 1
> #define in 0
>
> #define  export_PATH  "/sys/class/gpio/export"
> #define  value_PATH "/sys/class/gpio/gpio%d/value"
> #define  direction_PATH "/sys/class/gpio/gpio%d/direction"
> #define unexport_PATH "/sys/class/gpio/unexport"
>
> //*P9***
> #define  p9_11   30
> #define  p9_12   60
> #define  p9_13   31
> #define  p9_14  50
> #define  p9_15  48
> #define  p9_16  51
> #define  p9_17 5
> #define  p9_18 4
> //#define  p9_19 13
> //#define  p9_20 12
> #define  p9_21 3
> #define P9_22 2
> #define  p9_23  49
> #define  p9_24  15
> #define  p9_25  117
> #define  p9_26  14
> #define  p9_27  115
> //#define  p9_28  113
> //#define  p9_29  111
> #define  p9_30 112
> //#define  p9_31  110
> #define  p9_41  20
> //#define  p9_41  116
> //#define  p9_42  114
> #define  p9_42 7
> //*
>
>
> //*P8***
> //*
>
>
>
> //**function*
> int gpio_export(int);
> int gpio_unexport(int);
> int gpio_direction(int, int);
> int pin_write(int, int);
> int pin_read(int);
> //***
>
>
> #endif /*BB_GPIO_*/
>
> int gpio_export(int gpio_number)
> {
> FILE* fp=0;
>
> if((fp = fopen(export_PATH,"w"))==NULL){
> printf("Cannot open export file(>>%s).\n", export_PATH);
> return -1;
> }
> fprintf(fp,"%d",gpio_number);
> fclose(fp);
> }
>
> int gpio_unexport(int gpio_number)
> {
> FILE* fp;
>
> if((fp = fopen(unexport_PATH,"w"))==NULL){
> printf("Cannot open unexport file(>>%s).\n", unexport_PATH);
> return -1;
> }
> fprintf(fp,"%d",gpio_number);
> fclose(fp);
> }
>
> int gpio_direction(int gpio_number,int direction)
> {
> FILE* fp;
> char set_value[4]={0};
> char dir_path[50]={0};
> sprintf(dir_path, direction_PATH, gpio_number);
> if((fp = fopen(dir_path,"w"))==NULL){
> printf("Cannot open direction file(>>%s).\n",dir_path);
> return -1;
> }
>  rewind(fp);
> if(direction == out){
> strcpy(set_value,"out");
> fwrite(&set_value,sizeof(char),3,fp);
> fclose(fp);
> } else if(direction == in){
> strcpy(set_value,"in");
> fwrite(&set_value,sizeof(char),2,fp);
> fclose(fp);
> } else{
> printf("invalue pin mode(%d)\n",direction);
> return -1;
> }
> fclose(fp);
> return 1;
> }
>
> int pin_write(int gpio_number,int value)
> {
> FILE* fp;
> char val_path[50]={0};
> char set_value[2]={0};
>
> sprintf(val_path, value_PATH, gpio_number);
> if((fp = fopen(val_path,"w"))==NULL){
> printf("Cannot open value file(>>%s).\n",val_path);
> return -1;

Re: [beagleboard] Re: Maximum current on GPIO?

[Brandon I]

Source 6mA, sink 8mA, with the following pins limited to sourcing 4mA:

 P9_19 gpio0[13]

· P9_20 gpio0[12]

· P9_24 gpio0[15]

· P9_26 gpio0[14]

· P9_41 gpio0[20]

· P9_42 gpio0[7]

On Monday, July 28, 2014 7:24:52 AM UTC-7, Gerald wrote:
>
> 6mA. 
>
> No.
>
> Gerald
>
>
>
> On Mon, Jul 28, 2014 at 9:03 AM, PLyttle > 
> wrote:
>
>> This question has been asked and answered before. There is a search box 
>> with a big blue button marked "Search" next to it. I suggest you use it.
>> The document you need is the processor data sheet. (SPRS717F) table 2.7
>>
>>
>> On Monday, July 28, 2014 8:26:48 AM UTC+2, ope...@gmail.com wrote:
>>>
>>> Hi,
>>>
>>> I already searched trough TI AM3358 TRM and BBB manual but with no 
>>> success, so I'll have to ask it here: what ist the maximum current one can 
>>> pull out of an GPIO pin?
>>>
>>> And does the CPU/the related pin die in case of short-circuit of a GPIO 
>>> or is there an internal protection mechanism?
>>>
>>> Cheers
>>>
>>> Jim
>>>
>>>  -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[beagleboard] Re: C Code to send UDP packets using Ethernet

[Brandon I]

There's nothing Beaglebone about this question, really. Just google "send 
udp packets c posix".


On Thursday, July 17, 2014 3:46:18 AM UTC-7, msc.a.f...@googlemail.com 
wrote:
>
>
> Hi everyone,
>
> I am new with the Beaglebone black and I would like to make a little 
> program in C to send UDP packets using Ethernet. Can someone please tell me 
> where I can find some code to do this or to point in the right direction to 
> do this?
>
> Thank you for the help
>

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

[beagleboard] Python Help

[Brandon I]

That exception class is an attribute of the serial module, not of the Serial 
object instance, "ser", that you have there.

So catch serial.SerialException.

I think you're importing and handling the exceptions fine. For importing, you 
won't be able to access all the other stuff in the serial module if you just 
import the Serial class. Also, polluting the global name space makes things 
confusing for those reading your code ("where did this come from?" rather than, 
"this is obviously from the serial module"). 
For the exception, there's no reason to catch all here. Catch what you expect 
and leave the regular traceback for the rest.

-- 
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] Build Kernel Module for BeagleBone Black

[Brandon I]

You don't need the whole source to build modules, only the headers. They 
usually come in a package, like Linux-headers, or should be available to 
download from wherever you found your distribution. 

-- 
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: PRU Pin Mux

[Brandon I]

I don't believe the reads/writes to the GPIO registers would have worked
without the OCP master being enabled.

Thanks, I'll check out the library to see what magic is missing from that
code.
On Jun 21, 2014 8:20 AM, "TJF"  wrote:

> A miss click and a miss post ...
>
> The PRUSS can access the Control Modul pin mux registers.  It's working
> for a lot of libpruio users. Did you enable the OCP master port?
>
> --
> 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/ukPLH3-1hbA/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: PRU Pin Mux

[Brandon I]

I apologize, a miss click posted that...full code below.


> *// enable ocp master.*LBCO r0, C4, 4, 4
> CLR r0, r0, 4
> SBCO r0, C4, 4, 4
> *// try to set gpio address*
>
> *// gpio on*mov r1, 0x4000# gpio 0, bit 14, p9.29
> mov r0, 0x44E07194  # gpio 0 set register
> SBBO r1, r0, 0, 4
> *// led on p9.26 light up here, devmem2 shows this address was set*
>
> *// readback*LBBO r1, r0, 0, 4
> *// readback matches!*
>
> *// gpio off*mov r1, 0x4000  # bit 14, p9.29
> mov r0, 0x44E07190  # gpio 0 clear register
> SBBO r1, r0, 0, 4
> *// led on p9.26 shuts off here, devmem2 shows this address was set*
> LBBO r1, r0, 0, 4 
> *// readback matches*
>
>
> *// try to set config address, P8.40*mov r1, 0x25
> mov r0, 0x44E108B8  
>
> *// devmem 2 says 0x44E108B8 = 0x5 (what i have it set to in dts)*SBBO 
> r1, r0, 0, 4
> *// devmem 2 says 0x44E108B8 is still 0x5!*
> LBBO r1, r0, 0, 4 
> *// readback doesn't match! r1 is now 0x5!*



You had me excited, even though I'd tested this before, and have read in 
multiple places that it's not possible.  :(

--Brandon


On Saturday, June 21, 2014 1:24:32 AM UTC-7, Brandon I wrote:
>
> "You have 100% full control over anything the PRU can access."
>
> This pru code seems to disproves this. The PRU cannot modify the 
> configuration registers.
>
>
> // enable ocp master.
> LBCO r0, C4, 4, 4
> CLR r0, r0, 4
> SBCO r0, C4, 4, 4
>
> // turn on gpio
> mov r1, 0x4000
> mov r0, 0x44E07194
> SBBO b, a, 0, 4
> // readback
> LBBO b, a, 0, 4
>
> // gpio off
> mov b, 0x4000
> mov a, 0x44E07190
> SBBO b, a, 0, 4
> // readback
> LBBO b, a, 0, 4 
>
>
>
> On Monday, May 19, 2014 2:36:51 PM UTC-7, Charles Steinkuehler wrote:
>>
>> On 5/19/2014 4:06 PM, Brandon I wrote: 
>> > The pin mux registers require privileged memory access, which is why 
>> > the kernel space is usually required.  The pru can write these!? 
>>
>> Of course.  The PRU is directly wired into the on-chip bus, and bypasses 
>> all ARM side sanity checks like memory page access restrictions.  You 
>> have 100% full control over anything the PRU can access, which is just 
>> about every significant chunk of hardware on the die except for: 
>>
>> * SGX-530 GPU 
>> * AES & SHA crypto accelerator 
>> * USB 
>> * MMC 
>>
>> Details are in the Interconnects section of the TRM (section 10), and 
>> remember: 
>>
>>   With great power comes great responsibility! 
>>
>> -- 
>> Charles Steinkuehler 
>> cha...@steinkuehler.net 
>>
>

-- 
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: PRU Pin Mux

[Brandon I]

"You have 100% full control over anything the PRU can access."

This pru code seems to disproves this. The PRU cannot modify the 
configuration registers.


// enable ocp master.
LBCO r0, C4, 4, 4
CLR r0, r0, 4
SBCO r0, C4, 4, 4

// turn on gpio
mov r1, 0x4000
mov r0, 0x44E07194
SBBO b, a, 0, 4
// readback
LBBO b, a, 0, 4

// gpio off
mov b, 0x4000
mov a, 0x44E07190
SBBO b, a, 0, 4
// readback
LBBO b, a, 0, 4 



On Monday, May 19, 2014 2:36:51 PM UTC-7, Charles Steinkuehler wrote:
>
> On 5/19/2014 4:06 PM, Brandon I wrote: 
> > The pin mux registers require privileged memory access, which is why 
> > the kernel space is usually required.  The pru can write these!? 
>
> Of course.  The PRU is directly wired into the on-chip bus, and bypasses 
> all ARM side sanity checks like memory page access restrictions.  You 
> have 100% full control over anything the PRU can access, which is just 
> about every significant chunk of hardware on the die except for: 
>
> * SGX-530 GPU 
> * AES & SHA crypto accelerator 
> * USB 
> * MMC 
>
> Details are in the Interconnects section of the TRM (section 10), and 
> remember: 
>
>   With great power comes great responsibility! 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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: changing the triggers of gpio pins

[Brandon I]

If you want to use the triggers provided by the led interface, use the led 
interface. The pin will go high or low voltage with the led interface or 
gpio interface.

GPIO is  for general purpose io, so it's not going to have fancy patterns 
or anything, just on, off, in, out.


On Tuesday, June 17, 2014 1:32:45 PM UTC-7, ÖMER KARATAŞ wrote:
>
> Hi everyone,
>
> I am experiencing beaglebone black and using it on Debian. I figured out  
> that there are directories for gpio pins and leds. When i am in these 
> directory by changing value and direction field i can use it as what i 
> want. But i want to be use gpio pins as same as led pins. Means that, there 
> is no any "trigger" for gpio pins but i wannt to add like "heartbeat" 
> trigger to any pins,non-leds. Is there anyway to get it?
>
> Or i also figured out "device tree overlay" structure during my web 
> searching like here 
> ,
>  
> there are some sample of .dts files but i can not find that how can be done 
> adding trigger to any pins in means of syntax. How can i use any pins that 
> triggered by heartbeat,cpu0 etc?
> Thanks a lot,
>
> ömer 
>

-- 
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: Raw device on I2C bus

[Brandon I]

The first result  for "i2c with 
bonescript" refers to node-i2c. That link has some examples.

There are many good tutorials on i2c. Your transactions will contain a 
device address and some number of bytes to read or write. What those bytes 
are is specific to each device, so you'll have to read your devices 
datasheet/documentation.

What's the device?

On Tuesday, June 17, 2014 11:35:06 AM UTC-7, Chriskner wrote:
>
> Hi Helmut,
>
> I'm afraid that I can't help with BoneScript.  Perhaps a good solution 
> does exist (and other will chime in).  
>
> However, another option would be to use Python.  I am doing this now, and 
> talking to my I2C devices is working fine.
>
> For Python, one needs to install 'smbus':
>
> apt-get install python-smbus
> Regards,
>
> Chris
>
> On Tuesday, June 17, 2014 9:16:47 AM UTC-4, Helmut Friederici wrote:
>>
>> Hi folks,
>>
>> I have a hardware circuit (internally named SAL) based on a MSP430 
>> microcontroller which should be connected via I2C to the BBB.
>> After physically connecting the SAL via I2C to the BBB it responds to 
>> i2cdetect correctly and I am able to start some actions via i2cget because 
>> my SAL software interprets register numbers as internal commands - not nice 
>> but it works (partially).
>>
>> But what I really want is to start actions by executing scripts based on 
>> BoneScript. As far as I understand there is a suitable driver needed for 
>> this device which obviously doesn't exist. Am I right? Or could the dummy 
>> driver be used in any way and how?
>> In Bonescript I can create a new dummy device at a given address and I 
>> can read and write files but are there any files connected to the dummy 
>> driver which I can read/write to communicate with my device? 
>>
>> Sorry for those basic questions but I have never done anything with I2C.
>>
>> Any help/hint is appreciated
>> Helmut
>>
>>

-- 
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] SD Card containing OS and apps dead after three months use

[Brandon I]

I assumed that everything is the same (flash technology, memory block size,
memory block life, etc) between the 4Gb and 16Gb card, except the number of
memory blocks. The more free memory blocks there are, the more blocks the
wear leveler can touch before cycling through all of them.

I assumed you had 2Gb of free space on your old card, so, scaling the time
by the extra memory blocks available: 3months * 14Gb/2Gb = 21 months.

Flash is crazy dense and cheap to make, but the eventual failure is the
price you pay for, literally, shooting electrons through glass. :)



On Fri, Jun 13, 2014 at 8:37 AM, Fred Basset 
wrote:

> Brandon,
>
> I'm curious as to how you calculated a lifetime of 2 yrs for the 16Gb card
> with 2Gb free?
>
>
> On Thu, Jun 12, 2014 at 11:55 AM, Brandon I 
> wrote:
>
>> With a 16Gb card, you'll most likely get about 2 years use before the
>> card fails, assuming you had 2gb free on your failing cards card, the 16Gb
>> card has the same number of writes until failure for the memory blocks, and
>> the same disk activity.
>>
>> This assumes that you're have a perfect power supply that never shuts off
>> during a write (which will damage the memory cells) or unflushed operation
>> (which can corrupt the filesystem).
>>
>> If you're writing to flash media, it will eventually fail. :-\ Ideally,
>> you would have your os disk read only (read only partition doesn't
>> necessarily work due to sd card wear leveling controller not being aware of
>> partitions), and log files logged elsewhere where your software could
>> gracefully handle the eventual failure of the log file flash disk. Have
>> this log file disk easily accessible for customers to change.
>>
>> You could not flush your log file writes until some sort of failure or
>> buffer size, so that you're not writing whole erase blocks for a sentence
>> worth of log message. And, of course, turn off all the access time
>> capabilities with your mount options (noatime, nodiratime).
>>
>> The only solution is to reduce the number of writes each memory block is
>> seeing in a day, and be aware that eventual failure can't be avoided if
>> writing anything.
>>
>> On Thursday, June 12, 2014 7:24:14 AM UTC-7, RobertCNelson wrote:
>>
>>> On Thu, Jun 12, 2014 at 9:14 AM, Frank Talamy 
>>> wrote:
>>> >
>>> > Hi everyone,
>>> >
>>> > I've been using the BeagleBone Black for a while now. I got my apps
>>> running
>>> > just fine for like 2-3 months straight, not a single problem.
>>> >
>>> > OS : Debian Wheezy installed on Samsung 4GB µSD card.
>>> > Cross compilation platform : ELDK (armv7-hf)
>>> >
>>> > I've tested my apps on different brands of SD Cards (Kingston,
>>> samsung,
>>> > sandisk ...) and have killed several Kingston cards in a matter of
>>> days. By
>>> > killing, I mean the BeagleBone wasn't booting on them anymore and they
>>> were
>>> > no longer mounted when plugged via a USB-Card-reader. I had this kind
>>> of
>>> > dmesg output (the [...] here means a lot of the same 7 lines in a
>>> loop):
>>> >
>>> > [626903.528266] sd 11:0:0:0: [sdd] Device not ready
>>> > [626903.528268] sd 11:0:0:0: [sdd]  Result: hostbyte=DID_OK
>>> > driverbyte=DRIVER_SENSE
>>> > [626903.528272] sd 11:0:0:0: [sdd]  Sense Key : Not Ready [current]
>>> > [626903.528275] sd 11:0:0:0: [sdd]  Add. Sense: Medium not present
>>> > [626903.528279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00
>>> 00 08
>>> > 00
>>> > [626903.528287] end_request: I/O error, dev sdd, sector 0
>>> > [626903.528290] Buffer I/O error on device sdd, logical block 0
>>> > [626903.530266] sd 11:0:0:0: [sdd] Device not ready
>>> > [626903.530269] sd 11:0:0:0: [sdd]  Result: hostbyte=DID_OK
>>> > driverbyte=DRIVER_SENSE
>>> > [626903.530272] sd 11:0:0:0: [sdd]  Sense Key : Not Ready [current]
>>> > [626903.530275] sd 11:0:0:0: [sdd]  Add. Sense: Medium not present
>>> > [626903.530279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00
>>> 00 08
>>> > 00
>>> > [626903.530287] end_request: I/O error, dev sdd, sector 0
>>> > [626903.530290] Buffer I/O error on device sdd, logical block 0
>>> > [626903.532391] sd 11:0:0:0: [sdd] Device not ready
>>> > [626903.532393] sd 11:0:0:0: [sdd]  Result: hostbyte=DID_OK
>>> > driverbyte=DRIVER

Re: [beagleboard] SD Card containing OS and apps dead after three months use

[Brandon I]

With a 16Gb card, you'll most likely get about 2 years use before the card 
fails, assuming you had 2gb free on your failing cards card, the 16Gb card 
has the same number of writes until failure for the memory blocks, and the 
same disk activity.

This assumes that you're have a perfect power supply that never shuts off 
during a write (which will damage the memory cells) or unflushed operation 
(which can corrupt the filesystem).

If you're writing to flash media, it will eventually fail. :-\ Ideally, you 
would have your os disk read only (read only partition doesn't necessarily 
work due to sd card wear leveling controller not being aware of 
partitions), and log files logged elsewhere where your software could 
gracefully handle the eventual failure of the log file flash disk. Have 
this log file disk easily accessible for customers to change.

You could not flush your log file writes until some sort of failure or 
buffer size, so that you're not writing whole erase blocks for a sentence 
worth of log message. And, of course, turn off all the access time 
capabilities with your mount options (noatime, nodiratime). 

The only solution is to reduce the number of writes each memory block is 
seeing in a day, and be aware that eventual failure can't be avoided if 
writing anything.

On Thursday, June 12, 2014 7:24:14 AM UTC-7, RobertCNelson wrote:
>
> On Thu, Jun 12, 2014 at 9:14 AM, Frank Talamy  > wrote: 
> > 
> > Hi everyone, 
> > 
> > I've been using the BeagleBone Black for a while now. I got my apps 
> running 
> > just fine for like 2-3 months straight, not a single problem. 
> > 
> > OS : Debian Wheezy installed on Samsung 4GB µSD card. 
> > Cross compilation platform : ELDK (armv7-hf) 
> > 
> > I've tested my apps on different brands of SD Cards (Kingston, samsung, 
> > sandisk ...) and have killed several Kingston cards in a matter of days. 
> By 
> > killing, I mean the BeagleBone wasn't booting on them anymore and they 
> were 
> > no longer mounted when plugged via a USB-Card-reader. I had this kind of 
> > dmesg output (the [...] here means a lot of the same 7 lines in a loop): 
> > 
> > [626903.528266] sd 11:0:0:0: [sdd] Device not ready 
> > [626903.528268] sd 11:0:0:0: [sdd]  Result: hostbyte=DID_OK 
> > driverbyte=DRIVER_SENSE 
> > [626903.528272] sd 11:0:0:0: [sdd]  Sense Key : Not Ready [current] 
> > [626903.528275] sd 11:0:0:0: [sdd]  Add. Sense: Medium not present 
> > [626903.528279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 
> 00 08 
> > 00 
> > [626903.528287] end_request: I/O error, dev sdd, sector 0 
> > [626903.528290] Buffer I/O error on device sdd, logical block 0 
> > [626903.530266] sd 11:0:0:0: [sdd] Device not ready 
> > [626903.530269] sd 11:0:0:0: [sdd]  Result: hostbyte=DID_OK 
> > driverbyte=DRIVER_SENSE 
> > [626903.530272] sd 11:0:0:0: [sdd]  Sense Key : Not Ready [current] 
> > [626903.530275] sd 11:0:0:0: [sdd]  Add. Sense: Medium not present 
> > [626903.530279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 
> 00 08 
> > 00 
> > [626903.530287] end_request: I/O error, dev sdd, sector 0 
> > [626903.530290] Buffer I/O error on device sdd, logical block 0 
> > [626903.532391] sd 11:0:0:0: [sdd] Device not ready 
> > [626903.532393] sd 11:0:0:0: [sdd]  Result: hostbyte=DID_OK 
> > driverbyte=DRIVER_SENSE 
> > [626903.532396] sd 11:0:0:0: [sdd]  Sense Key : Not Ready [current] 
> > [626903.532400] sd 11:0:0:0: [sdd]  Add. Sense: Medium not present 
> > [626903.532404] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 08 00 
> 00 08 
> > 00 
> > [626903.532412] end_request: I/O error, dev sdd, sector 8 
> > [...] 
> > [626903.812724] sd 11:0:0:0: [sdd] Device not ready 
> > [626903.812725] sd 11:0:0:0: [sdd]  Result: hostbyte=DID_OK 
> > driverbyte=DRIVER_SENSE 
> > [626903.812728] sd 11:0:0:0: [sdd]  Sense Key : Not Ready [current] 
> > [626903.812731] sd 11:0:0:0: [sdd]  Add. Sense: Medium not present 
> > [626903.812734] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 
> 00 08 
> > 00 
> > [626903.812740] end_request: I/O error, dev sdd, sector 0 
> > [626903.814725] sd 11:0:0:0: [sdd] Device not ready 
> > [626903.814728] sd 11:0:0:0: [sdd]  Result: hostbyte=DID_OK 
> > driverbyte=DRIVER_SENSE 
> > [626903.814731] sd 11:0:0:0: [sdd]  Sense Key : Not Ready [current] 
> > [626903.814735] sd 11:0:0:0: [sdd]  Add. Sense: Medium not present 
> > [626903.814739] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 
> 00 08 
> > 00 
> > [626903.814747] end_request: I/O error, dev sdd, sector 0 
> > [626903.820536] sdd: detected capacity change from 3947888640 to 0 
> > 
> > 
> > That's why I chose to use Samsung sd cards instead. Everything was fine 
> for 
> > 2-3 whole months, but now I had one of my systems getting the exact same 
> > symptoms as when using the Kingston cards. 
> > 
> > Did anyone experience this kind of problem using his beagle bone so far 
> ? 
> > Does anyone have an idea of something that could damage the SD card so 

[beagleboard] Re: Two BBBs on same host's USB

[Brandon I]

I'm not sure you're ending up with a sane network configuration using the 
same subnet mask for each, but did you change the udhcpd config file to 
give the host a different ip for each usb connection? The host gets its ip 
from the beaglebone's dhcp server. I say not sane, because the beaglebone's 
wont be able to communicate with each other because there's no route 
between them.

For a more proper (?) configuration, you could use use the 192.168.7.2, 
subnet 255.255.255.252, host ip range of 192.168.7.1 (start and stop in the 
udhcpd config file). For the other (looking at this subnet calculator 
), 192.168.7.6, subnet 255.255.255.252, 
host ip 192.168.7.5 (start and stop in its udhcpd config file).

I ended up making a python script to set the usb ip based on the hash of 
the board id stored in eeprom so I wouldn't have to worry (too much, only 
14 bits) about any two beaglebone's clashing

--Brandon


On Tuesday, June 10, 2014 11:58:10 AM UTC-7, ec1...@gmail.com wrote:
>
> Hi,
>
> I have two BBBs, and each can connect to a host via USB0 with no 
> problems.  
>
> One as IP 192.168.7.2 and subnet mask 255.255.255.0 (changed from ...252) 
> and another on 192.168.7.7.  For some reason they both cannot connect at 
> the same time as PuTTY gives me a conn timeout.  Is there a way to have 
> more than one BBB on a single USB host network?
>
> Thanks!
>
> E C
>

-- 
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 GPIO's as SPI

[Brandon I]

> but you can't run the clock much faster than 1 KHz using a user-space 
program under Linux. 

Not true at all! You can get over 3MHz just fine with mmap to the gpio 
registers. If you try to open and close a file each gpio toggle, like the 
insanely inefficient sysfs interface, then yeah...you'll be severely 
limited, but still much faster than 1kHz.

Did you google? http://e2e.ti.com/support/arm/sitara_arm/f/791/t/296484.aspx

On Thursday, June 5, 2014 8:31:24 AM UTC-7, William Hermans wrote:
>
> Sounds like fun. Good luck :)
>
>
> On Wed, Jun 4, 2014 at 2:17 PM, > wrote:
>
>> Hey William... 
>>
>> I do know that the Chip Select line can be used to toggle between 
>> different SPI units... But I need data to be collected simultaneously from 
>> multiple sensors... As of now I have 32 sensors - I have clubbed them into 
>> groups of 4 and so I have 8 sets of SPI units that I want to communicate 
>> with "simultaneously"... 
>>
>>
>> On Wednesday, June 4, 2014 11:46:21 AM UTC-4, William Hermans wrote:
>>
>>> It sounds as though you need to read more concerning what SPI actually 
>>> *is*.
>>>
>>> *Devices communicate in master/slave mode where the master device 
 initiates the data frame. Multiple slave devices are allowed with 
 individual slave select lines. Sometimes SPI is called a four-wire serial 
 bus, contrasting with three-, two-, and one-wire serial buses. SPI is 
 often 
 referred to as SSI (Synchronous Serial Interface).*

>>>
>>> http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
>>>
>>> What does this mean ? Multiple devices can share the same data bus, and 
>>> only CS( chip select ) needs be different for each device. CS only needs to 
>>> go high, or low, which hey remarkably is exactly what GPIO pins do ! :)
>>>
>>>
>>> On Wed, Jun 4, 2014 at 7:37 AM,  wrote:
>>>
  I am trying to run multiple SPI modules (more than the two available 
 on the BBB) to try and read data from a bunch of accelerometers (LSM303D). 

 I was therefore wondering if it would be possible to implement the SPI 
 module using code (preferably C/C++) on the abundant GPIO pins. I have 
 been 
 scanning through a lot of documentation but I cant seem to find anything 
 that fits the bill. 

 Please help --- getting desperate...


  -- 
 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...@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 Black libraries for GPIO access in C/C++?

[Brandon I]

Two other features of going low level with mmap:

 Open drain output: By controlling the output enable registers, you can 
do open drain by setting the output to drive 0, then enable output to pull 
low, disable output to for high (with external pullup or internal through 
pin muxing).

 Simultaneous toggling: You can set the pin states of a whole gpio bank 
at once. This is nice if you're bit banging.

2.8MHz seems slow. I was at 4MHz through an mmap in *Python*. Make sure 
you're using the set registers rather than doing a read-modify-write and 
only opening the mmap once...and I suppose your clock scaling will matter 
too, so maybe it's the same.

--Brandon

On Wednesday, June 4, 2014 2:26:32 PM UTC-7, john3909 wrote:
>
>
> From: Tony DiCola >
> Reply-To: >
> Date: Wednesday, June 4, 2014 at 8:29 AM
> To: >
> Subject: Re: [beagleboard] Beaglebone Black libraries for GPIO access in 
> C/C++?
>
> Thanks for the replies everyone--looks like some nice libraries to check 
> out.
>
> Regarding memory mapped GPIO, check out this nice blog post for more info: 
> http://vabi-robotics.blogspot.com/2013/10/register-access-to-gpios-of-beaglebone.html
>  
>  You can effectively map the GPIO registers to a process' memory space and 
> directly access them so there's no overhead of making the system calls to 
> read, write, etc. the sysfs-based GPIO.  
>
> I actually just tried out a couple quick tests and saw toggling a pin high 
> and low in a tight loop with sysfs is pretty slow, only a few hunded khz. 
>  However using memory mapped GPIO registers it's much, much faster.  I'm 
> seeing around 2.8 mhz toggling a pin with this approach.  Now neither 
> approach is technically going to ever give you a real time guarantee of 
> course, but it's nice to have the ability to read and write GPIO fairly 
> quickly in some cases with memory mapped GPIO.
>
> The downside is you cannot support GPIO interrupts. 
>
> Regards,
> John
>
>
>
> On Wed, Jun 4, 2014 at 5:00 AM, Micka > 
> wrote:
>
>> William Hermans, how did you controlled the GPIO ?
>>
>> The only way that I know is with :
>>
>>
>> /sys/class/gpio/gpio%d/value
>>
>>
>> but you talk about mmap ? How did you use it with this 
>> /sys/class/gpio/gpio%d/value ?
>>
>> Thx you,
>>
>> Micka,
>>
>>
>>
>>
>> On Tue, Jun 3, 2014 at 11:57 PM, William Hermans > > wrote:
>>
>>> sysfs, and mmap. I've seen mention of both on the web ( including for 
>>> the BB white ).
>>>
>>> *wiringPi*

>>>
>>> Whats this ? The Arduino IDE for the rPI ? Nothing like this exists for 
>>> the BBB that I am aware of. 
>>>
>>>
>>> On Tue, Jun 3, 2014 at 2:45 PM, Jacek Radzikowski >> > wrote:
>>>
 
 https://github.com/piranha32/IOoo
 

 j.


 On Tue, Jun 3, 2014 at 5:42 PM, Tony DiCola >>> > wrote:
 > Sorry if this is a common question, but I've searched around the web 
 and the
 > forum here and am curious are there any somewhat mature or popular 
 libraries
 > for simple digital GPIO access on the Beaglebone Black in C/C++?  I'm
 > curious if there's anything like wiringPi or similar for the BBB yet. 
  If
 > not, are folks just rolling their own thing with access to sysfs or 
 mmap?
 >
 > --
 > 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.



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

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to the Google 
 Groups "BeagleBoard" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to beagleboard...@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...@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/Mef65w6PZ7s/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> beagleboard...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> -- 
> For more opt

Re: [beagleboard] Re: PRU FAQ 2013-05-15

[Brandon I]

And a quick google search "pru ethercat am335x" provides a nice overview:
http://www.ti.com/lit/wp/spry187c/spry187c.pdf


On Tue, Jun 3, 2014 at 6:05 AM, Gerald Coley  wrote:

> That is all covered in the datasheet for the processor.
>
> http://www.ti.com/product/am3358
>
> Gerald
>
>
>
> On Tue, Jun 3, 2014 at 7:05 AM, euerka  wrote:
>
>> Dear Gerald,
>>
>> Thanks for your reply. Sorry that i am not very clear about Signals are
>> missing on the expansion headers? you means the signals suppose to link to
>> Ethernet PHY, now link to expansion headers(P8,P9)? if so it means it
>> possible rewire the signals? Because i saw this
>> https://www.youtube.com/watch?v=M1LxQBjttWg , please take a look; it
>> seems Sascha rewire it.
>>
>> Even though it is impossible to implement this, may i know what signals i
>> need if i want to implement etherCat Master by PRU on BBB, which signals
>> are missing now? Any clues, documentations, links will be appreciated.
>>
>> Thank very very much!
>>
>>
>> On Monday, 2 June 2014 20:15:28 UTC+8, Gerald wrote:
>>
>>> No. It is not possible.Signals are missing on the expansion headers
>>> to implement ether-cat.
>>> It cannot be done.
>>>
>>> Gerald
>>>
>>>
>>>
>>> On Sun, Jun 1, 2014 at 11:21 PM, euerka  wrote:
>>>
  Dear all,

 As i understand it is impossible to implement PRU, ethercat slave on
 Beagleboard, since i refer to ( https://groups.google.com/
 forum/#!searchin/beagleboard/ethercat|sort:relevance/
 beagleboard/EiiZ4rwo9q0/ZvqUXIKAS28J ) and ( https://groups.google.com/
 forum/#!searchin/beagleboard/ethercat|sort:relevance/
 beagleboard/1_yqmvkguZY/y-mrwkY7IJsJ).

 *I am still wondering that is it possible to use PRU as ethercat or
 powerlink master on Beagleboard?* Because in my opinion, i can
 purchase commercial motor driver such as yaskawa or panasonic as slave?

 Any ideas?

 --
 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 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/u28ytaoNenU/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] Can the BBB get damaged due to a hard power down?

[Brandon I]

For the damage question, yes, with all flash media, if you're not using a 
read only mount: http://cseweb.ucsd.edu/~swanson/papers/DAC2011PowerCut.pdf

Btw, you're crazy if you're not using a read only mount (or guaranteeing no 
writes) for the rootfs of an appliance. ;)

On Tuesday, May 27, 2014 7:46:07 AM UTC-7, stino wrote:
>
> Hi Gerald, Look I'm sorry if you took offence by my comment. It’s an 
> awesome board, don’t let anybody convince you otherwise  It's just that 
> I've not seen it being mentioned anywhere that a correct power down 
> procedure is required. If it was a deliberate design choice not to provide 
> some kind of fail-safe, I personally would have definitely made this clear 
> to every buyer.  I work hands-on with computer equipment of various makes 
> and models on a daily basis and I honestly can’t remember the last time a 
> box got bricked due to a power outage.  I myself, and as I suspect many 
> others, am thinking about turning the BBB into an embedded appliance which 
> makes the power button inaccessible.  
>
> Can you suggest how we can extend the powerbutton of from the board?
>
>
> Op dinsdag 27 mei 2014 15:27:21 UTC+2 schreef Gerald:
>>
>> This is why there is a power button. I suggest that you go to your PC and 
>> yank the power cord. Whether it is running Linux or Windows, I suspect it 
>> won't like it.
>>
>> If you can't use the power button, then yes you can design a cape 
>> that will let it gracefully shutdown properly. When I designed the board I 
>> felt that a button was less expensive that all the other stuff you would 
>> need to put on the cape. Not to mention the small form factor of 
>> the board made it tough to fit all that onto the board. And yes, in a small 
>> number of instances, we have seen that yanking the power may cause damage 
>> to the processor because the PMIC does not have enough time to power down 
>> the processor in the correct voltage sequence. So, use the power button.
>>
>>
>>
>> Gerald
>>
>>
>> On Mon, May 26, 2014 at 10:37 AM, William Hermans wrote:
>>
>>> What happens, or *can* happens when you just yank the power on a PC 
>>> running Linux ?
>>>
>>> 1) You can make teh file system read only.
>>> 2) You can design or create a power cape that shutdown gracefully when 
>>> power goes missing.
>>> ...) ???
>>>
>>>
>>> On Mon, May 26, 2014 at 6:32 AM, stino  wrote:
>>>

 I read over at another forum that the BBB could get damaged if it 
 recieved an unexpected "hard" power down.., is this true, what can we do 
 about this? 

 Seems like a serious design flaw to me. One can't expect a power source 
 to be 100% stable and especially with a development board which is likely 
 to used for embedded appliances this is a reall issue..

 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...@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...@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: PRU FAQ 2013-05-15

[Brandon I]

You can access all regular gpio, but those will be slower than the one tick
pru gpio access.

Check out the PRU documentation at
https://github.com/beagleboard/am335x_pru_package , it explains how to use
R30 and R31, section 5.2.2.

Here's an explanation on accessing main memory from the pru:
http://nomel.tumblr.com/post/30006622413/beaglebone-tutorial-accessing-main-memory-from-the-pru

To control the regular gpio blocks, you would access them through their
registers. You can find the gpio registers and their addresses in the
processor manual at http://www.ti.com/lit/pdf/SPRUH73 , section 2.1 for
addresses of gpio blocks, and section 25 for offsets of the different gpio
registers for each block.



On Tue, May 27, 2014 at 6:18 AM,  wrote:

>
> Am Mittwoch, 2. Oktober 2013 22:03:29 UTC+2 schrieb Charles Steinkuehler:
>
>>
>> Each PRU has it's own r30, which drives the direct outputs (assuming you
>> have the pinmux setup properly).  You can only drive a limited number of
>> the BeagleBone header pins using PRU direct I/O, and a lot of the pins
>> are shared with the LCD/HDMI interface.
>>
>>
> I afraid this is the part I didn't understand with PRU. Assumed Pin-Mux is
> correct for usage of plain GPIOs - is PRU able to access all of them? If
> not: which ones are accessible?
>
> And I already stumbled upon this r30 thingy...how can I set/read GPIOs
> with it?
>
> Thanks for helping me with these stupid questions!
>
>  --
> 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/u28ytaoNenU/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] 4G eMMC Durability?

[Brandon I]

> MLC NAND enables around 10k write cycles
> SLC NAND enables more than 100k write cycles.

And, of course, these are the number of cycles for whole erase 
blocks. 
If you write one byte and flush the operation to your flash disk, you're 
actually writing the erase block size (say 4MB's), resulting in some "write 
amplification factor". 

So, many continuous small writes, that are flushed to disk, can very 
quickly touch all of the remaining erase blocks on your disk. For log file 
messages a few hundred bytes each, each flushed to disk as most log 
messages are, with a best case memory controller that touches the least 
used block next, and a 4MB erase block size, you'll have written 4GB to 
your card after 1024 messages. So you get 10 million log file writes if you 
have a card with 4GB of free space. If your OS partition is using 2GB then 
you get around 5 million.

If you're writing to flash of any kind, you cannot think of it as "will my 
product fail". You *must* think of it as "when will my product fail", 
because that's the nature of the medium. Sometimes it's many years. In our 
case, it was many weeks. Then we reduced the log messages making it months. 
Now, we use a read only mount, so it's based on the read 
disturb. 
But, even though it's a read only, it will still eventually fail. But, 
that'll be long past our support life.

The undeniable rule of flash: Your flash storage will eventually fail, 
because you're destructively blasting electrons through 
glass
 (oxide).


On Thursday, May 22, 2014 12:39:44 AM UTC-7, lisarden wrote:
>
> eMMC and SD cards are almost the same as Gerald said.
>
> eMMC is based on MLC NAND
>
> MLC NAND enables around 10k write cycles
>
> SLC NAND enables more than 100k write cycles. That is why we use only SLC 
> in our industrial products. I'm sure when you supply products with 5 year 
> warranty you don't want to discuss "eMMC/MLC reliability". Less risks - 
> less profit lost.
>
>
> 2014-05-22 11:13 GMT+04:00 Willem Buitendyk 
> >:
>
>> I wasn't seeing data corruption due to Linux but from the cards going 
>> completely kaput.  No amount of effort seemed to restore them.  I was under 
>> the impression the eMMC used MLC rather than TLC or MBC?  That would imply 
>> a different controller and ideally a much longer lifespan.
>>
>>
>>
>> On Wednesday, May 21, 2014 12:27:28 PM UTC-7, Gerald wrote:
>>
>>> Reliability at the cell level is the exactly the same. he controller is 
>>> exactly the same.
>>>
>>> However, having more unused space enhances the wear leveling where cells 
>>> get used less often.
>>>
>>> It does not however prevent issues with data corruption for any Linux 
>>> issues.
>>>
>>> Gerald
>>>
>>>
>>>
>>>
>>>
>>>  On Wed, May 21, 2014 at 2:21 PM, Willem Buitendyk wrote:
>>>
  I have about 150 beaglebone's running wild over a large geographical 
 area, basically all over British Columbia.  When I first deployed them 
 last 
 year they all started failing within about a month.  That amounted to a 
 lot 
 of needless driving, hair pulling, forehead banging and just general over 
 anxiety - its a wonder I'm still alive.  

 I eventually ended up using two uSD cards, one with a read only mounted 
 filesystem and the other used for writing data (ext4).  My beaglebone's 
 are 
 paired with a msp430 so I have managed to ensure they also receive a nice, 
 clean power down.  So far its been about a year and I'd say well over 95% 
 are still working fine.  However, I recently talked with a tech support 
 from an industrial SD card manufacturer and he informed me that SD cards 
 that are only ever read to can also fail eventually.  He suggested that 
 you 
 write a little bit once in a while to activate the wear levelling 
 mechanism.  As things seem to be working (for now) I haven't drummed up 
 the 
 courage to try writing again.  

 Now we have the beaglebone black with 4G eMMC and I'm wondering just 
 how much more reliable eMMC is compared to the stock Kingston 4GB cards in 
 read only mode that came with the Beaglebone.  I know eMMC is supposed to 
 be much improved having an integrated controller but wonder if in a 
 read-only scenario it makes any difference? Furthermore,  I wonder if 
 others on here can offer any experiences or comparisons of eMMC to say SLC 
 memory?

 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...@googlegroups.com.

 For more options, visit https://groups.google.com/d/o

[beagleboard] Re: PRU Pin Mux

[Brandon I]

The pin mux registers require privileged memory access, which is why the kernel 
space is usually required.  The pru can write these!? 

-- 
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] User LED forward to GPIO

[Brandon I]

I use this: https://github.com/nomel/beaglebone/tree/master/led-header

Makes setting up leds super easy.

On Thursday, May 8, 2014 9:35:31 AM UTC-7, Charles Steinkuehler wrote:
>
> The way these systems are configured, I don't know if you can do what 
> you want without generating a custom device tree. 
>
> The leds class has a trigger function and can be tied to various GPIO 
> pins, but I believe that conflicts with exporting that same GPIO pin. 
>
> If anyone knows of a way to do this without requiring customizing a 
> device tree to move GPIO pins from /sys/class/gpio to /sys/class/leds/ 
> entries, or if there's a way to have both for the same pin, I'd love to 
> hear it! 
>
> On 5/8/2014 10:49 AM, Hannes Hörting wrote: 
> > Hello John! 
> > 
> > Thank you! 
> > I`m using Debian and also the universal device tree from 
> > Charles: https://github.com/cdsteinkuehler/beaglebone-universal-io 
> > 
> > Not sure if its there also available? I doesnt find an information about 
> > heartbeat and cpu for user led on the GPIO. 
> > 
> > Thank you! 
> > 
> > 
> > Am Mittwoch, 7. Mai 2014 20:58:10 UTC+2 schrieb john3909: 
> >> 
> >> 
> >> On 5/7/14, 11:32 AM, "Hannes Hörting" > 
> >> wrote: 
> >> 
> >>> Hello! 
> >>> 
> >>> Can I forward the User Led to the GPIO? 
> >>> I want to build my own Expansion Board and need this LED. 
> >>> 
> >>> OR is this function already connectet to some GPIO? 
> >>> 
> >>> Thank you! 
> >> You can change the GPIO for the User LED by modifying the BBB device 
> tree. 
> >> Look at arch/arm/boot/dts/am335x-bone-common.dtsi 
> >> 
> >> 
> >> Regards, 
> >> John 
> >>> 
> >>> -- 
> >>> 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. 
> >> 
> >> 
> >> 
> > 
>
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

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

[Brandon I]

In all seriousness, is there a donation link you could post so we could 
send you some thanks?


On Sunday, May 4, 2014 10:56:40 AM UTC-7, RobertCNelson wrote:
>
>
> On May 4, 2014 4:43 AM, "Timbo" > wrote:
> >
> > Thanks for the info, Robert, and thanks for making these images, 
> installation scripts, and so on.  BTW is this a solo effort, or are other 
> people involved in Beagle Debian?
> >
> > The major extras in the "official" image seem to include lxde, wicd, 
> compilation utilities, audio utilities, and probably a lot of other stuff I 
> didn't recognise.  Apart from the extra packages, are there any particular 
> differences in kernel, configuration, etc?
>
> No! That would mean more work, and I'm pretty lazy!
>
> >
> >
> > -- 
> > For more options, visit http://beagleboard.org/discuss
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "BeagleBoard" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to beagleboard...@googlegroups.com .
> > For more options, visit https://groups.google.com/d/optout.
>  

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

Re: [beagleboard] power up using +5 volt jack

[Brandon I]

The beaglebone had a power up issue. Rev A6A fixed it:

>From the wiki
:  "Changed C24 to a 2.2uF capacitor. This extends the reset signal to 
solve an issue where some boards would not boot on power up."

I have around 40 beaglebones running and this was a pretty serious problem 
for us. Our users guides have a somewhat embarrassing "If the board doesn't 
boot, unplug the power and wait 10 seconds." I have around 20 Rev. B 
boards, and I haven't seen one fail to power up.

You could always rework the board yourself! :D


On Friday, May 2, 2014 5:14:03 AM UTC-7, Gerald wrote:
>
> Sounds like you may have an issue with your board. You can always send it 
> in on an RMA and we can look at it.
>
> Gerald
>
>
>
> On Thu, May 1, 2014 at 10:51 PM, DLF  >wrote:
>
>> Hi and thanks for your reply
>>
>> Well this is not true for me (my BBB won't boot directly with DC (Rev 
>> A5C))... but it is not a deal breaker for me.  
>>
>> As this is Richard's thread I'll back out now I don't want to be a 
>> budinski.
>>
>> BTW, Gerald & Robert, a friendly thank-you for all the work with BBB.   
>> I've learned a few things along the way and I appreciate your efforts.
>>
>> merci,
>>
>>
>>
>> On Tuesday, 29 April 2014 19:39:03 UTC+2, Gerald wrote:
>>
>>> Do not touch the power button unless you plan to turn it off. The SRM is 
>>> correct.
>>>
>>> To power on all you have to do is plug in the power, either USB or DC.
>>>
>>> Gerald
>>>
>>>
>>>
>>> On Tue, Apr 29, 2014 at 12:35 PM, DLF  wrote:
>>>
 Hi,

 now I am confused because I thought it was normal procedure to hold the 
 power button after inserting the 5V jack.   (as noted by Richard-tx)

 I always have to hold the power button after inserting the jack.  When 
 I insert the jack, I see a brief blue light from the pwr LED next to the 
 5V 
 connector and then nothing.  If I hold the power button it boots.  - every 
 time.

 This thread lead me to believe the power button was the right way to do 
 it !https://groups.google.com/forum/#!topic/beagleboard/FGeL6jzOcB0

 however the SRM indicates otherwise   :(

 7. Booting the Board
 As soon as the power is applied to the board, it will start the booting 
 up process.
 When the board starts to boot the LEDs will come on in sequence as 
 shown in Figure
 15 below. It will take a few seconds for the status LEDs to come on, so 
 be patient.
 The LEDs will be flashing in an erratic manner as it boots the Linux 
 kernel.


 It is not the end of the world for me, but just interested all the same.

 cheers,


 On Monday, 28 April 2014 14:17:43 UTC+2, Gerald wrote:

> It is supposed to power up automatically when you plug in the DC cable.
>
> Gerald
>
>
>
> On Sun, Apr 27, 2014 at 10:20 AM, Richard-tx wrote:
>
>> The way my BBB works is like this:
>>
>> To power up the BBB from OFF when powered from the 5 v jack, I have 
>> to press the power button.
>> To power up using the mini-usb connector, all I have to do is turn on 
>> the USB power.
>>
>> My question is this.  Is there a way to have the BBB automatically 
>> power up when power is applied to the +5 jack?
>>
>> .
>>  
>> -- 
>> 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...@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...@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] Re: What went wrong

[Brandon I]

This is incorrect. There's nothing wrong with applying power through USB 
and VDD_5V (DC plug) at the same time, from the reference manual:

"The selection of either the 5VDC or the USB as the power source is handled 
internally to the TPS65217C  and automatically switches to 5VDC power if 
both are connected."

On Wednesday, April 9, 2014 1:47:10 PM UTC-7, Gunjan Gupta wrote:
>
> Hi,
>
> You have used both the 5V power source and the mini usb cable. I guess 
> thats why your board got fried up. Use only one of them for the next time.
>
> Regards
> viraniac
>
> On Tuesday, April 8, 2014 2:36:29 AM UTC+5:30, A M Kent wrote:
>>
>> I've recently purchased the BBB and over the weekend I went through 
>> setting it up. I have to say I'm thoroughly impressed with the setup and 
>> the size. I followed the supplied instructions of connecting the device to 
>> my computer using the USB cable connecting it from the micro USB port to a 
>> port on my laptop, installing the necessary files to communicate with the 
>> device. My
>> issue occurred when I connected the BB in the following manner.
>>
>> 1. From micro HDMI port to HDMI port on monitor.
>> 2. Connected the 5V power source into the BB
>> 3. Connected a USB cable from the USB jack on the BB to my 4 port powered
>> USB hub.
>> 4. Connected the micro USB cable into the 4 port hub.
>> 5. Inserted wireless keybrd/mouse dongle into the 4 port hub.
>>
>> When I applied power to the BB within 1 minute of doing so I hear a faint 
>> high pitch tone and shortly thereafter I see a spark coming from the board. 
>> Based on the setup described what could have gone wrong?
>>
>

-- 
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: python gui?

[Brandon I]

Could always use python as a web back end and render the gui in the 
browser. ;)

On Wednesday, April 9, 2014 3:28:56 AM UTC-7, Eric Palmer wrote:
>
> In my day job I erite backend code.  Not gui stuff.  I'm building a large 
> robot and will use a BBB and display for data display and more.  
>
> I would like to use python. What gui tools work with python on the BBB?
>
> I could also do this with node.js o some other web server.  But python 
> might be fun.
>
> -- 
> Eric Palmer
>  

-- 
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: I2C2: Bad address, without checking

[Brandon I]

Do you have a pullup on the i2c line?

On Monday, March 31, 2014 1:59:46 AM UTC-7, Rafael Fiebig-Bindner wrote:
>
> Hi community,
>  
> I am currently trying to access a temperature sensor via I2C. The problem 
> is whenever I want to send data I get the error message: "Bad address", 
> but the BBB doesn't even check for the address on the I2C bus. The address 
> is 0x48 so it is free for use.
> I want to use the Pins P9,17 and P9,18. The BBB is running Angstrom. I am 
> using C++ and i2c-dev.h to access the built in i2c-1 device file. 
> I hope someone has some ideas how to solve this.
>  
> Best regards
> Rafael Fiebig-Bindner
>

-- 
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: eMMC data corruption due to power removal?

[Brandon I]

Rh, my earlier reply was to you, and that link shows that it is now a
problem with androids use of ext4.


On Thu, Mar 27, 2014 at 4:55 PM, rh_  wrote:

> On Thu, 27 Mar 2014 13:41:24 -0500
> Charles Steinkuehler 
> wrote:
>
> > On 3/27/2014 12:26 PM, rh_ wrote:
> > > On Thu, 27 Mar 2014 07:41:11 -0500
> > > Charles Steinkuehler
> > >  wrote:
> > >
> > >> On 3/26/2014 10:22 PM, Yiling Cao wrote:
> > >>> Thanks Brandon for your experience. I do agree with that better to
> > >>> put whole disk read only.
> > >>>
> > >>> But how do iPhone and Android survive? Esp for those Android
> > >>> phones? They are very prone to sudden power removal as well.
> > >>
> > >> What?  These devices are battery powered, and other than opening
> > >> the case and physically removing the battery they are guaranteed
> > >> enough power to do a proper and orderly shutdown.
> > >
> > > I pull the battery on my android frequently doing devel. Never had
> > > any problems. I pull the plug on my BBB all the time too, at least
> > > once/day. No problems.
> >
> > Yes, but are you writing to the flash when you pull the power?
>
> Don't know. But it's possible. How would I know? If it doesn't boot?
> For android there's JAFFS (or is it YAFFS) so it's more robust than ext4
> I guess.
>
> >
> > There is a huge difference between "it works for me" and *RELIABLY*
> > avoiding data corruption when power is unexpectedly removed with
> > significant write activity in-progress.
>
> Ok, but I haven't encountered a problem yet, and I'm never that lucky.
> With the millions and millions (billions?) of handsets I would think
> data corruption would be a much more visible problem. I haven't seen
> it happen yet over many phones and many years.
>
> --
> 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/dV0ctlQykYI/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.

[beagleboard] Re: First one, then two, then three....

[Brandon I]

> The only thing I wish for is the ability to change I2C bus speeds on the 
fly.

You can do anything with a kernel module and some memory pokes. ;)


On Thursday, March 27, 2014 2:47:10 AM UTC-7, Richard-tx wrote:
>
> I bought a BBB about 3 weeks ago.  Was impressed enough that I bought two 
> more.  I have a few Rpis is use around the house as well so I have a little 
> experience with SBCs  Anyway. all three BBB has been flawless.  No problems 
> at all.
>
> I did discover one thing.  Of all the Linux distros out there, I like 
> Ubuntu the best.  I found that Ubuntu does not suffer as badly from 
> creeping featurism or from a lack of essential packages.  I tried Angstrom 
> first.  It got flushed.  Then I tried Arch and Debian.  Didn't like Arch at 
> all.  Debian was tolerable.  Lastly I tried Ubuntu.  Ubuntu seems to be the 
> easiest to get configured and  running.  I was porting code in under an 
> hour.  I don't use a GUI so Ubuntu might not be for everyone.
>
> The really nice part about the BBB is the fact that it boots without a SD 
> card.  That leaves the SD card slot available for extra file storage.  
> SInce I do some software development as well as create various 
> appliance-like things, the added hot-plugable storage is wonderful.
>
> The only thing I wish for is the ability to change I2C bus speeds on the 
> fly.
>
> All in all, I am very happy with the BBB.
>
> Well done!
>
> Richard
>
>
>
>
>
>
>
>
>
>
> .
>

-- 
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: eMMC data corruption due to power removal?

[Brandon I]

That's because your phone uses a sane filesystems that takes into account
this use case and isn't writing constantly (write one byte, the disk writes
a whole erase block). This doesn't protect you from eventual disk
corruption. The wear leveling bad-block type tables will eventually
corrupt/run out of memory lng before your disk space is eaten by bad
blocks.

http://arstechnica.com/information-technology/2010/12/ext4-filesystem-hits-android-no-need-to-fear-data-loss/

"Most Android devices currently use YAFFS, a lightweight filesystem that is
optimized for flash storage and is commonly used in mobile and embedded
devices."

My production Beaglebone image does not support this.

"Developers who are accessing the filesystem directly will have to be
mindful about Ext4's buffering behavior and make sure that the data is
actually reaching persistent storage in a timely manner so that it won't be
lost in the event of a system failure."

It is now an issue with Android!

"T'so says that there isn't much need for concern. Google and the handset
makers will catch platform-level filesystem reliability issues, ensuring
that the high-level storage APIs are safe."

Is the API you use for disk writes safe? Nope.

-Brandon

On Thu, Mar 27, 2014 at 10:26 AM, rh_  wrote:

> On Thu, 27 Mar 2014 07:41:11 -0500
> Charles Steinkuehler 
> wrote:
>
> > On 3/26/2014 10:22 PM, Yiling Cao wrote:
> > > Thanks Brandon for your experience. I do agree with that better to
> > > put whole disk read only.
> > >
> > > But how do iPhone and Android survive? Esp for those Android
> > > phones? They are very prone to sudden power removal as well.
> >
> > What?  These devices are battery powered, and other than opening the
> > case and physically removing the battery they are guaranteed enough
> > power to do a proper and orderly shutdown.
>
> I pull the battery on my android frequently doing devel. Never had any
> problems. I pull the plug on my BBB all the time too, at least once/day.
> No problems.
>
> For people having issues I would suspect a problem elsewhere.
>
> --
> 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/dV0ctlQykYI/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] eMMC data corruption due to power removal?

[Brandon I]

Here's a good read: http://www.embeddedarm.com/about/resource.php?item=459

I had a lng discussion about this with a colleague of mine after we 
started seeing boards die.

Basically you're eventually doomed unless you mount the whole disk as read 
only since the wear leveling algorithms in the flash have no knowledge of 
what a partition is and will eventually end up with 
suppesed-to-be-read-only data mixed in with the writable partition erase 
blocks. If you're writing to flash, it will eventually fail by unfortunate 
design.

It tooks his previous company 6 months of fighting to come to terms with 
this in their last product. They had to write data, so eventually used usb 
flash that the customer could easily replace when things eventually died. 
They tried every flash card they could get their hands on, read only 
partitions, etc and eventually had to give up.

Use the SD card you say! Any micro SD card you can put in the slot is 
absolutely not meant for continuous writing. The SD card spec has a very 
specific use case in mind (video and images), and logging or using it as a 
sparse write file system goes completely against the intended SD card 
design specs. Industrial grade write-tolerant flash will cost you hundreds 
of dollars more than something on Amazon.

With our current product, I told my boss that I was worried about 
corruption and that we would eventually go to read only once we debugged 
the boards. Within two weeks of only log messages, all of our boards 
started dyeing. The next day, all disks were mounted as read only and 
issues are debugged with the in-memory log files. We haven't seen any 
failures in 6 months now.

The easy solution is trying to force the answer of "why are you writing 
anything to persistent storage?" to be "there's no good reason since it 
eventually bricks our product". If you want something that will last 
forever, you will not write to standard flash media. If you can't, then 
maybe use a usb flash drive (MUCH better life than a micro sd card) and 
count the days until it corrupts or someone pulls the power at an 
inopportune time. You could always use a battery backup to get rid of the 
power off issue. :-\

This is all doom and gloom, but it's a consequence of inconsistent power, 
buffers, and the destruction nature of quantum tunneling.

-Brandon

On Wednesday, March 26, 2014 2:45:57 PM UTC-7, Sungjin Chun wrote:
>
> How about making system partition be mounted as read-only and data 
> partition be mounted after booting and checking? In this case, only data 
> partition has possibility of corruption.
>
> Sent from my iPad
>
> On Mar 26, 2014, at 9:53 PM, Yiling Cao > 
> wrote:
>
> Hi I have some my products deployed with am335x with Micron eMMC 2GB, but 
> my products allow users to unplug power as they wish. 
>
> My linux app very rarely writes to the eMMC. and my /etc/fstab specifies 
> /var/log and /tmp to tempfs; fstab mount all partitions with "noatime" 
> properties.
>
> But around 2 months of deployment, I found that around 1-2% am335x 
> machines, have some sort of data corruption, resulting fail to boot up.
>
> Can anyone share some thoughts/ experience about how to resolve this 
> issue? In real life product, whats the best practice?
>  
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>

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

[beagleboard] Re: Encouragement for the disencouraged

[Brandon I]

> My only real issue that I have no idea what the Angstrom is really 
capable of and what really comes with it.

I think the biggest hurdle for people is they have some embedded mindset 
with talk of processors and whatnot. Think of this as it is, a resource 
limited general purpose Linux computer in a small form factor. You develop 
for it just like you would a normal desktop computer.

Don't think of it as what Angstrom is really capable of because Angstrom 
has nothing to do with it. Install Debian if you want and you'll be able to 
accomplish the same (maybe with less free RAM) using almost identical code.

The biggest hurdle I had was to do things right the "Linux way", as in 
using the abstracted to infinity drivers and sysfs interfaces to do 
something like access a single register for some hard ip. You can go bang 
registers and be done with it, but the whole point is that you don't have 
to care about the specific platform if you use the standard interfaces 
allowing you to port your code to some other future embedded (or not) 
system.

2 ranty cents for you.

On Thursday, March 20, 2014 3:05:17 PM UTC-7, Thorsten Gonschior wrote:
>
> Hi to you all out there, new to the BBB, new to Linux, new to whatever?
>
> This is no request for a particular solution but somehow a thought to 
> whats wrong with me, ... or some of the others?
>
> Never worked with Linux or Unix, never did anything else than windows and 
> TI embedded stuff. I would think of me as a professional senior engineer 
> for embedded systems, automotive and industrial control.
>
> Now, I entered the embedded Linux world and I am thrilled and frustrated 
> at the same time. Before some days system and software engineering was 
> somehow deterministic to me, something you plan and do. yea, welcome to 
> waynes world.
>
> After reading some hundred hours in the internet, peeking through about 12 
> new books I bought like hands on the beagle bone black for hyperdummies 
> down to realtime driver development in subatomicmicrokernels I am almost as 
> clueless as before. almost ;) 
> After trying to do some really complex stuff like hello world on a php web 
> page I am beginning to understand that I have to let go some very basic 
> principles of thinking like an engineer if I want to act in and survive 
> this new scene.
>
> My first impression on the BBB was somehow, oh wow now I can do everything 
> I always wanted for free. Today I am more on the way of thinking what I 
> could do if noone or nothing unavoidably unseen screws me up, kicks me in 
> the back and stabs me with a fork in my ass (in my sleep).
>
>
> After this esotheric discourse for all you out there finding yourself here 
> I will come to the encouragement thing I promised.
> You cannot make it run? its not there? dont know where, why, how or when?
>
> Its there and it is quite simple and so much more complex you will ever 
> imagine. Know what? give a damn, go get it and make it any way you can.
>
> Newbie/Noob Rule 1: there is no correct way, there ist never only one way, 
> and what ever way you find out, if ever, its the wrong one anyway.
> Newbie/Noob Rule 2: dont do it on your own. its already there. dont even 
> start thinking how you can solve a subtask. just go and get your component 
> out of the internet. talking caipirinha serving robots doing your laundry, 
> just call for it. it will never be a 100% solution. be happy if it works 
> just good enough, more or less. On the other hand, if you do it on your 
> own, how perfect would you think you would do it, after endless doing your 
> stuff . There is just nothing you can do on your own against the 10.000 
> man years of productive work you buy with your cellphone ;) 
> Newbie/Noob Rule 3: dont believe in all the creeps out there. my 
> impression is that there are seemingly 50 people out there not talking 
> crap. they are easy to find.
> Newbie/Noob Rule 4: if you are confronted with the fishermans feed fish 
> and net crap, skip the page, its not with it.
> Newbie/Noob Rule 5: I dont know how, but all the people out there managed 
> to make it somehow. even if you have no Idea what you are doing, in the end 
> it works. you dont know why, or for how long, but it does. thanks and 
> regards to all of you out there contributing to this vast community. With 
> the stuff you do and how you do it, you would not have survived in any kind 
> of industrial working environment. On the other hand this so professional 
> industrial working environment is just loosing the edge against you. And 
> that feels great :D
>
>
> In direct words to the BBB and my experiences of the first days:
> after two days of stumbling around to understand how to get ubuntu on my 
> BBB I was able to set up my SD Card and power up the ubuntu. Just early 
> enough to undertsand that Angstrom ist not half as bad as everybody tries 
> to state. Now I am back to angstrom and I like it (today).
> After endless discussions from guys who tried

[beagleboard] Re: Kernel headers for Linux beaglebone 3.13.6-bone8

[Brandon I]

For Angstrom, you can install the kernel-dev and kernel-headers packages. 
This will be enough to compile kernel modules.

There have been times in the past where the packages where out of sync with 
the actual kernel being used. Not sure what the current state is. Check the 
stable branch...lol, just kidding.

On Saturday, March 22, 2014 4:35:25 AM UTC-7, Vlad Ungureanu wrote:
>
> Anybody has a clue where can I get the kernel headers? 
> https://raw.github.com/gkaindl/beaglebone-ubuntu-scripts/master/bb-get-rcn-kernel-source.shdoes
>  not work.
>
> Best,
> /vvu
>

-- 
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: PRU Interrupt managing in Beaglebone Black

[Brandon I]

Use prudebug or some other pru debugger and step through your pru code. 
Maybe you are setting that interrupt.

You can also "cat /proc/interrupts" to view interrupt counts to see if it's 
not blocking because your interrupt is firing. The pru interrupts will be 
there as pruss_evt0, evt1, etc.

-Brandon

On Monday, March 17, 2014 8:22:54 AM UTC-7, Carlo Pane wrote:
>
>
> Hi, 
>
> I'm using a beaglebone black for my project and I would like to use the 
> PRUs included into Sitara processor.
>
> I've followed some "how to"s  found on internet and in all of them there 
> are examples employing PRU0, but not PRU1. I've have done some tuning in 
> order to use PRU1, but I can't make it works. My set up for using PRU with 
> interrupt is the following:
>
> For the C part:
> #include "prussdrv.h" 
> #include  
> [...] 
> tpruss_intc_initdata pruss_intc_initdata = PRUSS_INTC_INITDATA; 
> [...] prussdrv_open(PRU_EVTOUT_1); 
> [...] prussdrv_pruintc_init(&pruss_intc_initdata); 
> [...] prussdrv_exec_program (PRU_NUM, "./prucode.bin"); 
> prussdrv_pru_wait_event (PRU_EVTOUT_1); /* things... 
> */prussdrv_pru_clear_event
> (PRU_EVTOUT_1,PRU1_ARM_INTERRUPT);
>
>
>
>
> While, in the assembly part i do:
>
> #define PRU1 
> #ifdef PRU0 
> #define PRU_OFFSET 0x22000 
> #else 
> #define PRU_OFFSET 0x24000 
> #endif 
>
> // Refer to this mapping in the file - pruss_intc_mapping.h 
> #define PRU0_PRU1_INTERRUPT 17 
> #define PRU1_PRU0_INTERRUPT 18 
> #define PRU0_ARM_INTERRUPT 19 
> #define PRU1_ARM_INTERRUPT 20 
> #define ARM_PRU0_INTERRUPT 21 
> #define ARM_PRU1_INTERRUPT 22 
> #define CONST_PRUCFG C4 
> #define CONST_PRUDRAM C24 
> #define CONST_PRUSHAREDRAM C28 
> #define CONST_DDR C31 
>
> // Address for the Constant table Block Index Register (CTBIR) 
> #define CTBIR PRU_OFFSET+0x00020 
> // Address for the Constant table Programmable Pointer Register 0(CTPPR_0) 
> #define CTPPR_0 PRU_OFFSET+0x00028 
> // Address for the Constant table Programmable Pointer Register 1(CTPPR_1)
> #define CTPPR_1 PRU_OFFSET+0x0002C 
> // Enable OCP master port 
> LBCO r0, CONST_PRUCFG, 4, 4 
> CLR r0, r0, 4 
> SBCO r0, CONST_PRUCFG, 4, 4 
>
> /* Configure the programmable pointer register for PRU0 by setting 
> c28_pointer[15:0] field to 0x0120. This will make C28 point to 0x00012000 
> (PRU shared RAM).*/ 
>
> MOV r0, 0x0100
> MOV r1, CTPPR_0 
> ST32 r0, r1 CLOOP: 
> [...] 
> MOV r31.b0, PRU1_ARM_INTERRUPT +16 
> [...] 
> JMP CLOOP
>
> My problem is that fuction *prussdrv_pru_wait_event *has not a blocking 
> behavior. Or rather, program doesn't wait on that function for the PRU 
> instruction  
>
>
> *MOV r31.b0, PRU1_ARM_INTERRUPT +16.*Am I doing something wrong?
>

-- 
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: BBB PRU input test

[Brandon I]

I think I see the problem. You have the pin muxed for pru gpio in the 
device tree overlay, but you're trying to read the arm gpio block. PRU gpio 
is accessed directly with register r30 for output and r31 for input 
(section 5.2.2.3 in the somewhat terrible pru reference 
guide<https://github.com/beagleboard/am335x_pru_package/blob/master/am335xPruReferenceGuide.pdf>
).

On Tuesday, March 11, 2014 7:49:47 AM UTC-7, Manu wrote:
>
> I read your last email with attention by still I can't understad why my 
> code is not working. I a few words: 
> The code works when properly when I comment the line " WBS r31.t15 //Wait 
> til GPIO-15-in is high... P9_24"
>
> *PINMUX DTS:*
>
> /dts-v1/;  
> /plugin/;  
>   
> / {  
>   compatible = "ti,beaglebone", "ti,beaglebone-black";  
>   
>   /* identification */  
>   part-number = "BB-BONE-W";  
>   version = "00A0";  
>   exclusive-use =  "P9.24";  
>  
>   
>   fragment@0 {  
> target = <&am33xx_pinmux>;  
> __overlay__ {  
>   mygpio: pinmux_mygpio{  
> pinctrl-single,pins = <   
>  0x184 0x36 /* P9 24 pr1_pru0_pru_r31_16.GPIO0_15: | PULLUP | 
> MODE6 | INPUT */
>   >;  
>   };  
> };  
>   };  
>   
>   fragment@1 {  
> target = <&ocp>;  
> __overlay__ {  
>   test_helper: helper {  
> compatible = "bone-pinmux-helper";  
> pinctrl-names = "default";  
> pinctrl-0 = <&mygpio>;  
> status = "okay";  
>   };  
> };  
>   };  
>   
>   fragment@2{  
>   target = <&pruss>;  
> __overlay__ {  
>   status = "okay";  
> };  
>   };  
> };  
>
> *PIN MUX STATUS:*
> # cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep "pin 97"
>pin 97 (44e10984) 0036 pinctrl-single 
>
> *UNAME +DIST:*
> # uname -a
> Linux don-t001 3.8.13-bone30 #1 SMP Thu Nov 14 11:19:20 UTC 2013 armv7l 
> armv7l armv7l GNU/Linux
> # cat /etc/issue
> Ubuntu 12.04.3 LTS \n \l
>
> *ASM CODE:*
>
> .origin 0
> .entrypoint START
>
> #define PRU0_ARM_INTERRUPT 19
> #define AM33XX
>
> #define GPIO1 0x4804c000
> #define GPIO_CLEARDATAOUT 0x190
> #define GPIO_SETDATAOUT 0x194
>
> START:
> //Enable OCP master port
> LBCO r0, C4, 4, 4
> CLR r0, r0, 4 // Clear SYSCFG[STANDBY_INIT] to enable OCP master port
> SBCO r0, C4, 4, 4
> 
> MOV r1, 1000 //# cycles
>
> INPUTTEST:
>  
>  WBS r31.t15 //Wait til GPIO-15-in is high... P9_24
>  SUB r1, r1, 1 //Subtract from counter
> QBNE INPUTTEST, r1, 0 //Loop if counter not at zero
>
> // Send notification to Host for program completion
> MOV R31.b0, PRU0_ARM_INTERRUPT+16
>
> MOV r1, 0
> HALT
>
>
> *INIT PROGRAM USING PyPRUSS:*
>
> #!/usr/bin/python
>
> ''' ddr_write.py - Finds the DDR address and size, passes that info to the 
> PRU0 
> data memory, executes a program and reads back data from the first and 
> last banks'''
>
>
> import pypruss
> import mmap
> import struct 
>
> pypruss.modprobe()
> ddr_addr = pypruss.ddr_addr()
> ddr_size = pypruss.ddr_size()
>
> print "DDR memory address is 0x%x and the size is 0x%x"%(ddr_addr, 
> ddr_size)
>
> ddr_offset  = ddr_addr-0x1000
> ddr_filelen = ddr_size+0x1000
> ddr_start = 0x1000
> ddr_end = 0x1000+ddr_size
>
> pypruss.init() # Init the PRU
> pypruss.open(0) # Open PRU event 0 which is PRU0_ARM_INTERRUPT
> pypruss.pruintc_init() # Init the interrupt controller
> pypruss.pru_write_memory(0, 0, [ddr_addr, ddr_addr+ddr_size-4]) # Put the 
> ddr address in the first region 
> pypruss.exec_program(0, "./ddr_write.bin") # Load firmware 
> "ddr_write.bin" on PRU 0
> pypruss.wait_for_event(0) # Wait for event 0 which is connected to 
> PRU0_ARM_INTERRUPT
> pypruss.clear_event(0) # Clear the event
> pypruss.exit() # Exit PRU
>
> with open("/dev/mem", "r+b") as f: # Open the physical memory device
> ddr_mem = mmap.mmap(f.fileno(), ddr_filelen, offset=ddr_offset) # mmap the 
> right area
>
> read_back = struct.unpack("L", ddr_mem[ddr_start:ddr_start+4])[0] # Parse 
> the data
>
>
> print "The first 4 bytes of DDR memory reads "+hex(read_back)
>
>
> ddr_mem.close() # Close the memory 
> f.close() # Close the file
>
>
> No way to read the P9_24 PIN From BBB using PRUSS
>
> May be the *WBS *does no work as I think . a week working on that and 
> still nothing

Re: [beagleboard] Re: BBB PRU input test

[Brandon I]

>When I do an interruput up or down the ASM keeps waiting and nothing

Read my previous email. Your code will not work as is.


On Mon, Mar 10, 2014 at 8:11 PM, Manu  wrote:

> My DTS is:
>
> /dts-v1/;
> /plugin/;
>
> / {
>   compatible = "ti,beaglebone", "ti,beaglebone-black";
>
>   /* identification */
>   part-number = "BB-BONE-W";
>   version = "00A0";
>   exclusive-use =  "P9.24";
>
>
>   fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
>   mygpio: pinmux_mygpio{
> pinctrl-single,pins = <
>
>  0x184 0x16 /* P9 24 pr1_pru0_pru_r31_16.GPIO0_15: | PULLUP |
> MODE6 | INPUT */
>>;
>   };
> };
>   };
>
>   fragment@1 {
> target = <&ocp>;
> __overlay__ {
>   test_helper: helper {
> compatible = "bone-pinmux-helper";
> pinctrl-names = "default";
> pinctrl-0 = <&mygpio>;
> status = "okay";
>   };
> };
>   };
>
>   fragment@2{
>   target = <&pruss>;
> __overlay__ {
>   status = "okay";
>   pinctrl-names = "default";
>   pinctrl-0 = <&mygpio>;
> };
>   };
>
> };
>
>
> and the
> cat /sys/devices/bone_capemgr.*/slots
>  0: 54:PF---
>  1: 55:PF---
>  2: 56:PF---
>  3: 57:PF---
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
>  8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-W
>
> cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep "pin 97"
> pin 97 (44e10984) 0037 pinctrl-single  BEFORE
>
> root@donkeytom-t001:/texka/pinmux# echo BB-BONE-W >
> /sys/devices/bone_capemgr.9/slots
> root@donkeytom-t001:/texka/pinmux# cat
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep "pin 97"
> pin 97 (44e10984) 0016 pinctrl-single  AFTER
>
>
> When I do an interruput up or down the ASM keeps waiting and nothing
>
>
> Thank you!
>
> Manuel
>
> El lunes, 10 de marzo de 2014 23:36:42 UTC-3, Charles Steinkuehler
> escribió:
>>
>> Provide the *.dts source for the overlay you are trying to load, and the
>> contents of /sys/devices/bone_capemgr.*/slots, and maybe we can figure
>> out what's going wrong.  It looks like something has already grabbed the
>> pin you want to use.
>>
>> Note the "pruss: failed to hardreset" always shows up and doesn't
>> indicate a problem (or at least not the problem you're having).  Your
>> issue is presumably the pin overlay that fails to load.
>>
>> On 3/10/2014 9:20 PM, Manu wrote:
>> > I was finding what is wrong and finally I got it. The thing is that I
>> don't
>> > know how to fix it.
>> > My BBB is Ubuntu last 12.04 version with 3.8 kernel by nelson.
>> > The error is here:
>> > *706.650640] omap_hwmod: pruss: failed to hardreset*
>> > [  706.682785] pinctrl-single 44e10800.pinmux: pin 44e10984 already
>> > requested by helper.12; cannot claim for 4a30.pruss
>> > [  706.694442] pinctrl-single 44e10800.pinmux: pin-97 (4a30.pruss)
>> > status -22
>> > [  706.702096] pinctrl-single 44e10800.pinmux: could not request pin 97
>> on
>> > device pinctrl-single
>> > [  706.738323] pruss_uio 4a30.pruss: pins are not configured from
>> the
>> > driver
>> > [  706.765286] bone-capemgr bone_capemgr.9: slot #7: Applied #3
>> overlays.
>> >
>> >
>> >
>> >
>> > El lunes, 10 de marzo de 2014 20:10:55 UTC-3, Brandon I escribió:
>> >>
>> >> Along with what the others have described, since you're the arm
>> processor
>> >> gpio rather than a pru gpio, meaning you're going all the way out to
>> system
>> >> memory, you have to connect the pru to system memory. Here's an
>> example of
>> >> accessing system memory with the pru:
>> >>
>> >>
>> >> http://nomel.tumblr.com/post/30006622413/beaglebone-
>> tutorial-accessing-main-memory-from-the-pru
>> >>
>> >> To set the pin mux for arm gpio, you can use one of these gpio
>> overlays.
>> >> Just follow the instructions:
>> >>
>> >> https://github.com/nomel/beaglebone/tree/master/gpio-header
>> >>
>> >> Also, there ar

[beagleboard] Re: BBB PRU input test

[Brandon I]

Along with what the others have described, since you're the arm processor 
gpio rather than a pru gpio, meaning you're going all the way out to system 
memory, you have to connect the pru to system memory. Here's an example of 
accessing system memory with the pru:

http://nomel.tumblr.com/post/30006622413/beaglebone-tutorial-accessing-main-memory-from-the-pru

To set the pin mux for arm gpio, you can use one of these gpio overlays. 
Just follow the instructions:

https://github.com/nomel/beaglebone/tree/master/gpio-header

Also, there are a few pru debuggers out there now so you can view/step pru 
execution.

-Brandon


On Sunday, March 9, 2014 6:37:09 PM UTC-7, Manu wrote:
>
> I was trying a few days to enable PRU (BBB Ubuntu 12.04)  and run a input 
> testing code using the pin P9_24.
>
> MUX = pin 97 (44e10984) 0006 pinctrl-single  (SET to MODE 6)
>
> P9 24 pr1_pru0_pru_r31_16.GPIO0_15: | MODE6 | INPUT
>
> Nothing happens when I put the pin to 1.8 or GND
>
> The ASM code is:
>
> .origin 0
> .entrypoint START
>
> #define PRU0_ARM_INTERRUPT 19
> #define AM33XX
>
> #define GPIO1 0x4804c000
> #define GPIO_CLEARDATAOUT 0x190
> #define GPIO_SETDATAOUT 0x194
>
> START:
> // clear that bit
> LBCO r0, C4, 4, 4
> CLR r0, r0, 4
> SBCO r0, C4, 4, 4
>
> MOV r0, 10 //# cycles
>
> INPUTTEST:
>  
>  WBS r31.t15 //Wait til GPIO-15-in is high... P9_24
> SUB r0, r0, 1 //Subtract from counter
> QBNE INPUTTEST, r0, 0 //Loop if counter not at zero
>  // Send notification to Host for program completion
> MOV R31.b0, PRU0_ARM_INTERRUPT+16
>
> MOV r0, 0
> HALT
>
> I don't know what I am doing wrong and in Internet are not examples for 
> INPUT tests.
>
>
>
>
>

-- 
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: problem with creating a kernel module program for angstrom os

[Brandon I]

Did you install the kernel-dev package?

On Saturday, March 8, 2014, siva kumar  wrote:

> hai,
>  thank u!!
> but  my  folder structure from my board looks like
>
> *root@beaglebone:/usr/src# ls*
> *backfire  linux-3.8.13*
> *root@beaglebone:/usr/src# cd linux-3.8.13/*
> *root@beaglebone:/usr/src/linux-3.8.13# ls*
> *include*
> *root@beaglebone:/usr/src/linux-3.8.13/include# ls*
>
> *asm  asm-generic  drm  linux  mtd  rdma  scsi  sound  uapi  video  xen*
>
> *root@beaglebone:/usr/src/linux-3.8.13/include/linux# ls*
>
> *byteorder  dvb isdnnetfilter_arp netfilter_ipv6  spi
> tc_ematch*
> *caif   hdlc  mmcnetfilter_bridge  nfsd  sunrpc  usb*
> *can   hsi netfilter  netfilter_ipv4raid  tc_act  wimax*
>
> *root@beaglebone:/usr/src/linux-3.8.13/include/linux# *
>
> this info shows that my board shipped with no module support by default
> ..!!!
>
> now question is
> [1] still i didn't update or upgraded my angstrom os ..shall i need to do
> or is there any other way to insert my hello_world.ko module into my board??
> i found 1 more link for installing  the module libs sturcture and soure
> into the running os . here the link
> http://wiki.replicape.com/index.php?title=Compiling_the_kernel
> will this link  help me to insert also to create  a modules without fail ..
>
> can you suggest your opinion..pls..
>
>
>
>
> regards
> siva
>
>
>
>
>
> On Saturday, 8 March 2014 14:52:49 UTC+5:30, Brandon I wrote:
>>
>> Missed first line on that copy paste. Should be
>>
>> KERNELDIR := /usr/src/kernel
>>
>>
>>
>> On Sat, Mar 8, 2014 at 1:21 AM, Brandon I  wrote:
>>
>>> Just a regular kernel type makefile. For examlpe, here's mine for a file
>>> phyaccess.c
>>>
>>>  BEAGLEBONE_PROJ=/systems/Projects/beaglebone/workspace/Beaglebone
>>> MDIO_ROOT=$(BEAGLEBONE_PROJ)/local/MDIODriver
>>>
>>> #http://stackoverflow.com/questions/10176238/how-do-i-
>>> add-an-include-path-for-kernel-module-makefile
>>> # for kernel module make uses kbuild. Paths have to be absolute, not
>>> relative.
>>> EXTRA_CFLAGS+=-I$(MDIO_ROOT)/include -I$(MDIO_ROOT)
>>> -I$(BEAGLEBONE_PROJ)/include -I$(BEAGLEBONE_PROJ)/Interface/local/include
>>> -Werror
>>>
>>> obj-m += phyaccess.o
>>>
>>> all:
>>>  make -C $(KERNELDIR) M=$(PWD) modules
>>>
>>> clean:
>>>  make -C $(KERNELDIR) M=$(PWD) clean
>>>
>>>
>>>
>>>
>>> On Fri, Mar 7, 2014 at 10:57 PM, siva kumar wrote:
>>>
>>>> thanks for your reply
>>>>
>>>> yes , u r right  i compiled the module against
>>>> arm-angstrom-linux-gnueabi-gcc but my angstrom os comes with Linaro
>>>> gcc
>>>> root@beaglebone:~# opkg list_installed | grep gcc
>>>> *gcc - linaro-4.7-r9.2*
>>>> gcc-symlinks - linaro-4.7-r9.2
>>>> libgcc-s-dev - linaro-4.7-r9.0
>>>> libgcc1 - linaro-4.7-r9.0
>>>> perl-module-extutils-cbuilder-platform-windows-gcc - 5.14.2-r13.1
>>>>
>>>> root@beaglebone:~# dmesg | head
>>>> [ 0.00] Booting Linux on physical CPU 0×0
>>>> [ 0.00] Initializing cgroup subsys cpu
>>>> *[ 0.00] Linux version 3.8.13 (koen@rrMBP) (gcc version 4.7.3
>>>> 20130205 (prerelease) (Linaro GCC 4.7-2013.02-01) ) #1 SMP Tue Jun 18
>>>> 02:11:09 EDT 2013*
>>>> [ 0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
>>>> cr=50c5387d
>>>> [ 0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
>>>> instruction cache
>>>> [ 0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI
>>>> AM335x BeagleBone
>>>> [ 0.00] Memory policy: ECC disabled, Data cache writeback
>>>> [ 0.00] On node 0 totalpages: 130816
>>>> [ 0.00] free_area_init_node: node 0, pgdat c0688d80, node_mem_map
>>>> c06e4000
>>>> [ 0.00] Normal zone: 1024 pages used for memmap
>>>>
>>>>  i done the following steps to update my modules for my board .but it
>>>> says  my kernel headers are up to date.
>>>>
>>>> --
>>>> 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

Re: [beagleboard] Re: problem with creating a kernel module program for angstrom os

[Brandon I]

Missed first line on that copy paste. Should be

KERNELDIR := /usr/src/kernel



On Sat, Mar 8, 2014 at 1:21 AM, Brandon I  wrote:

> Just a regular kernel type makefile. For examlpe, here's mine for a file
> phyaccess.c
>
> BEAGLEBONE_PROJ=/systems/Projects/beaglebone/workspace/Beaglebone
> MDIO_ROOT=$(BEAGLEBONE_PROJ)/local/MDIODriver
>
> #
> http://stackoverflow.com/questions/10176238/how-do-i-add-an-include-path-for-kernel-module-makefile
> # for kernel module make uses kbuild. Paths have to be absolute, not
> relative.
> EXTRA_CFLAGS+=-I$(MDIO_ROOT)/include -I$(MDIO_ROOT)
> -I$(BEAGLEBONE_PROJ)/include -I$(BEAGLEBONE_PROJ)/Interface/local/include
> -Werror
>
> obj-m += phyaccess.o
>
> all:
>  make -C $(KERNELDIR) M=$(PWD) modules
>
> clean:
>  make -C $(KERNELDIR) M=$(PWD) clean
>
>
>
>
> On Fri, Mar 7, 2014 at 10:57 PM, siva kumar 
> wrote:
>
>> thanks for your reply
>>
>> yes , u r right  i compiled the module against
>> arm-angstrom-linux-gnueabi-gcc but my angstrom os comes with Linaro gcc
>> root@beaglebone:~# opkg list_installed | grep gcc
>> *gcc - linaro-4.7-r9.2*
>> gcc-symlinks - linaro-4.7-r9.2
>> libgcc-s-dev - linaro-4.7-r9.0
>> libgcc1 - linaro-4.7-r9.0
>> perl-module-extutils-cbuilder-platform-windows-gcc - 5.14.2-r13.1
>>
>> root@beaglebone:~# dmesg | head
>> [ 0.00] Booting Linux on physical CPU 0×0
>> [ 0.00] Initializing cgroup subsys cpu
>> *[ 0.00] Linux version 3.8.13 (koen@rrMBP) (gcc version 4.7.3
>> 20130205 (prerelease) (Linaro GCC 4.7-2013.02-01) ) #1 SMP Tue Jun 18
>> 02:11:09 EDT 2013*
>> [ 0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
>> cr=50c5387d
>> [ 0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
>> instruction cache
>> [ 0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI
>> AM335x BeagleBone
>> [ 0.00] Memory policy: ECC disabled, Data cache writeback
>> [ 0.00] On node 0 totalpages: 130816
>> [ 0.00] free_area_init_node: node 0, pgdat c0688d80, node_mem_map
>> c06e4000
>> [ 0.00] Normal zone: 1024 pages used for memmap
>>
>>  i done the following steps to update my modules for my board .but it
>> says  my kernel headers are up to date.
>> *root@beaglebone:~#  opkg install kernel-headers*
>> *Package kernel-headers (3.8.13-r23a.22) installed in root is up to date.*
>>
>> [1] what should i do to get my modules to work with??
>>
>> On Saturday, 8 March 2014 02:42:31 UTC+5:30, Brandon I wrote:
>>
>>> dmesg will give you more details.
>>>
>>> This usually means you compiled the kernel modules against a different
>>> build of the kernel. So, the kernel source you used didn't match what was
>>> on the beaglebone.
>>>
>>> You can install the kernel-headers and kernel-dev packages and build
>>> directly on the beaglebone. For some time, these packages weren't in sync
>>> with the actual kernel installed...as always, good luck with Angstrom.
>>>
>>> On Thursday, March 6, 2014 10:30:41 PM UTC-8, siva kumar wrote:
>>>>
>>>> hello,
>>>>
>>>> i recently purchased beagle bone black . my bbb come with pre compiled
>>>> angstrom os( Angstrom v2012.12 - Kernel 3.8.13) still i didn't  updated my
>>>> os
>>>> i try to test my board with simple hello module program . but when i
>>>> insert a module i got the error message
>>>> root@beaglebone:~# insmod hello.ko
>>>> Error: could not insert module hello.ko: Invalid module format
>>>> root@beaglebone:~#
>>>>
>>>> i compiled the module program from my host pc against
>>>> arm-angstrom-linux-gcc compiler..and i transferred the hello.ko file via
>>>> scp protocol.
>>>>
>>>>
>>>>
>>>> my question is
>>>> [1] Is it possible to add  a module  program with my available angstrom
>>>> os..if yes what should i do to insert  modules
>>>> [2] what are all the basic things needed to insert a module??
>>>>
>>>>
>>>> help me to better understand the beagle bone black
>>>>
>>>>
>>>  --
>> 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/fIJ5YE_fJpg/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: problem with creating a kernel module program for angstrom os

[Brandon I]

Just a regular kernel type makefile. For examlpe, here's mine for a file
phyaccess.c

BEAGLEBONE_PROJ=/systems/Projects/beaglebone/workspace/Beaglebone
MDIO_ROOT=$(BEAGLEBONE_PROJ)/local/MDIODriver

#
http://stackoverflow.com/questions/10176238/how-do-i-add-an-include-path-for-kernel-module-makefile
# for kernel module make uses kbuild. Paths have to be absolute, not
relative.
EXTRA_CFLAGS+=-I$(MDIO_ROOT)/include -I$(MDIO_ROOT)
-I$(BEAGLEBONE_PROJ)/include -I$(BEAGLEBONE_PROJ)/Interface/local/include
-Werror

obj-m += phyaccess.o

all:
 make -C $(KERNELDIR) M=$(PWD) modules

clean:
 make -C $(KERNELDIR) M=$(PWD) clean




On Fri, Mar 7, 2014 at 10:57 PM, siva kumar wrote:

> thanks for your reply
>
> yes , u r right  i compiled the module against
> arm-angstrom-linux-gnueabi-gcc but my angstrom os comes with Linaro gcc
> root@beaglebone:~# opkg list_installed | grep gcc
> *gcc - linaro-4.7-r9.2*
> gcc-symlinks - linaro-4.7-r9.2
> libgcc-s-dev - linaro-4.7-r9.0
> libgcc1 - linaro-4.7-r9.0
> perl-module-extutils-cbuilder-platform-windows-gcc - 5.14.2-r13.1
>
> root@beaglebone:~# dmesg | head
> [ 0.00] Booting Linux on physical CPU 0×0
> [ 0.00] Initializing cgroup subsys cpu
> *[ 0.00] Linux version 3.8.13 (koen@rrMBP) (gcc version 4.7.3 20130205
> (prerelease) (Linaro GCC 4.7-2013.02-01) ) #1 SMP Tue Jun 18 02:11:09 EDT
> 2013*
> [ 0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c5387d
> [ 0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [ 0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI
> AM335x BeagleBone
> [ 0.00] Memory policy: ECC disabled, Data cache writeback
> [ 0.00] On node 0 totalpages: 130816
> [ 0.00] free_area_init_node: node 0, pgdat c0688d80, node_mem_map
> c06e4000
> [ 0.00] Normal zone: 1024 pages used for memmap
>
> i done the following steps to update my modules for my board .but it says
>  my kernel headers are up to date.
> *root@beaglebone:~#  opkg install kernel-headers*
> *Package kernel-headers (3.8.13-r23a.22) installed in root is up to date.*
>
> [1] what should i do to get my modules to work with??
>
> On Saturday, 8 March 2014 02:42:31 UTC+5:30, Brandon I wrote:
>
>> dmesg will give you more details.
>>
>> This usually means you compiled the kernel modules against a different
>> build of the kernel. So, the kernel source you used didn't match what was
>> on the beaglebone.
>>
>> You can install the kernel-headers and kernel-dev packages and build
>> directly on the beaglebone. For some time, these packages weren't in sync
>> with the actual kernel installed...as always, good luck with Angstrom.
>>
>> On Thursday, March 6, 2014 10:30:41 PM UTC-8, siva kumar wrote:
>>>
>>> hello,
>>>
>>> i recently purchased beagle bone black . my bbb come with pre compiled
>>> angstrom os( Angstrom v2012.12 - Kernel 3.8.13) still i didn't  updated my
>>> os
>>> i try to test my board with simple hello module program . but when i
>>> insert a module i got the error message
>>> root@beaglebone:~# insmod hello.ko
>>> Error: could not insert module hello.ko: Invalid module format
>>> root@beaglebone:~#
>>>
>>> i compiled the module program from my host pc against
>>> arm-angstrom-linux-gcc compiler..and i transferred the hello.ko file via
>>> scp protocol.
>>>
>>>
>>>
>>> my question is
>>> [1] Is it possible to add  a module  program with my available angstrom
>>> os..if yes what should i do to insert  modules
>>> [2] what are all the basic things needed to insert a module??
>>>
>>>
>>> help me to better understand the beagle bone black
>>>
>>>
>>  --
> 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/fIJ5YE_fJpg/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: Writing 8-bit data to GPIO pins - does one have to do it a bit at a time?

[Brandon I]

> When you use user space drivers, you no longer have that protection.

Since this is so off topic I'll just say, anyone interested about this
topic, there is plenty of tutorials and articles about sane user space
device drivers, along with production quality open source drivers. The
acceptance of the concept is somewhat new, and there are many
misconceptions.


On Fri, Mar 7, 2014 at 2:02 PM, John Syn  wrote:

>
> From: Brandon I 
> Reply-To: 
> Date: Friday, March 7, 2014 at 1:27 PM
> To: 
> Cc: 
> Subject: [beagleboard] Re: Writing 8-bit data to GPIO pins - does one
> have to do it a bit at a time?
>
> user space should not know how you talk to it physically
>
>
> I don't think this is generally accepted, otherwise user space device
> drivers wouldn't exist:
> http://www.embedded.com/design/operating-systems/4401769/Device-drivers-in-user-space
>
> With user space device drivers, you're free to push as little or as much
> into the kernel as you like.
>
> The normal practice is that a badly behaving user space application should
> not kill your complete system. Only the user space app should die. When you
> use user space drivers, you no longer have that protection. User space
> drivers are generally not a good idea unless you want to avoid the
> user/kernel switching delays.
>
> Regards,
> John
>
>
> -Brandon
>
> On Thursday, March 6, 2014 12:06:43 PM UTC-8, robert.berger wrote:
>>
>> Hi,
>>
>> On Thursday, March 6, 2014 11:25:14 AM UTC+2, c...@isbd.net wrote:
>>>
>>> All the examples and libraries (Python mostly) that I can find for
>>> doing IO to the GPIO pins seem to handle only a bit at a time.  This
>>> is fine for things like driving relays and LEDs but makes little sense
>>> for 8-bit data.
>>>
>>>
>> Taking your example. If we are talking about a device you want to connect
>> to your beagle user space should not know how you talk to it physically and
>> whether it's 8-bit data or i2c or something else underneath. Having said
>> that there was/is some attempt to do what you want in kernel space [1] and
>> it's called block GPIO [2] but I don't think it made it into mainline.
>>
>> Regards,
>>
>> Robert
>>
>> [1] http://lwn.net/Articles/533632/
>> [2] http://lwn.net/Articles/533557/
>>
> --
> 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 a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/91ikp6Mxi0s/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.

[beagleboard] Re: Writing 8-bit data to GPIO pins - does one have to do it a bit at a time?

[Brandon I]

>
> user space should not know how you talk to it physically 


I don't think this is generally accepted, otherwise user space device 
drivers wouldn't 
exist: 
http://www.embedded.com/design/operating-systems/4401769/Device-drivers-in-user-space

With user space device drivers, you're free to push as little or as much 
into the kernel as you like.

-Brandon

On Thursday, March 6, 2014 12:06:43 PM UTC-8, robert.berger wrote:
>
> Hi,
>
> On Thursday, March 6, 2014 11:25:14 AM UTC+2, c...@isbd.net wrote:
>>
>> All the examples and libraries (Python mostly) that I can find for 
>> doing IO to the GPIO pins seem to handle only a bit at a time.  This 
>> is fine for things like driving relays and LEDs but makes little sense 
>> for 8-bit data. 
>>
>>
> Taking your example. If we are talking about a device you want to connect 
> to your beagle user space should not know how you talk to it physically and 
> whether it's 8-bit data or i2c or something else underneath. Having said 
> that there was/is some attempt to do what you want in kernel space [1] and 
> it's called block GPIO [2] but I don't think it made it into mainline. 
>
> Regards,
>
> Robert
>
> [1] http://lwn.net/Articles/533632/
> [2] http://lwn.net/Articles/533557/
>

-- 
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: problem with creating a kernel module program for angstrom os

[Brandon I]

dmesg will give you more details.

This usually means you compiled the kernel modules against a different 
build of the kernel. So, the kernel source you used didn't match what was 
on the beaglebone.

You can install the kernel-headers and kernel-dev packages and build 
directly on the beaglebone. For some time, these packages weren't in sync 
with the actual kernel installed...as always, good luck with Angstrom.

On Thursday, March 6, 2014 10:30:41 PM UTC-8, siva kumar wrote:
>
> hello,
>
> i recently purchased beagle bone black . my bbb come with pre compiled 
> angstrom os( Angstrom v2012.12 - Kernel 3.8.13) still i didn't  updated my 
> os 
> i try to test my board with simple hello module program . but when i 
> insert a module i got the error message 
> root@beaglebone:~# insmod hello.ko
> Error: could not insert module hello.ko: Invalid module format
> root@beaglebone:~# 
>
> i compiled the module program from my host pc against 
> arm-angstrom-linux-gcc compiler..and i transferred the hello.ko file via 
> scp protocol.
>
>   
>
> my question is 
> [1] Is it possible to add  a module  program with my available angstrom 
> os..if yes what should i do to insert  modules
> [2] what are all the basic things needed to insert a module??
>
>
> help me to better understand the beagle bone black
>  
>

-- 
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] Need 16 GPIOs Next to each other on P8

[Brandon I]

> Provided, you don't interfere with their settings during power up as they 
are also the boot pins.

He's saying you shouldn't interfere with their state at boot. No driving, 
pullup, or pull down on any of these pins (besides the those that configure 
the sysboot setting on the board).

Relays wont flip, but there are 100k pullups on some of the pins, so they 
could be in a state you don't want.

You could isolate these pins with something like a bilateral switch (or a 
Va = Vb type unidirectional level shifter) during boot. Attach the enable 
to 3v3_exp, and make sure whatever is on the world side of the isolator is 
in a known state when the pins are at high impedance (using pull ups or 
down).

For any pins that you want to switch simultaneously (which requires memory 
writes), make sure they're in the same gpio bank.

-Brandon

On Sunday, March 2, 2014 2:04:25 PM UTC-8, Gerald wrote:
>
> As is indicated in the System Reference Manual, you can use the LCD pins 
> as GPIO pins. Provided, you don't interfere with their 
> settings during power up as they are also the boot pins.
>
> Gerald
>
>
>
> On Sun, Mar 2, 2014 at 1:32 PM, > wrote:
>
>> Hi,
>>
>> I would like to configure BBB P8 with 16 (2 rows of 8) GPIO pins next to 
>> each other.  They just need to be able to be set to high or low.  I see P7 
>> through P18 but I need 4 more.  I am not using any LCD screen.  Is it 
>> possible to reconfigure the pins?  I am a BBB newbie and would appreciate 
>> any help so I don't mess anything up.
>>
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
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/groups/opt_out.

Re: [beagleboard] How are the production BBB images built?

[Brandon I]

> Maybe we can become free from SD cards in the near future for BBB 
development.

Doesn't uboot support network boot already?

On Thursday, February 27, 2014 11:29:23 PM UTC-8, jhg...@gmail.com wrote:
>
> Robert,
>
> Have you resolved any of these mysteries in the mean time?
>
> I got into this by trying to "bitbake" a simpler image, such as 
> console-image, since I need no graphics or fancy webserver with node.js 
> foo. So far I have failed to boot from the SD card with anything which has 
> been made by the oebb.sh script or bitbake build system. Even Derek's 
> 2-year-old 
> instructionsseem
>  not to work for "console-image".
>
> After I succeed at booting the BBB with my own custom image, I plan on 
> updating u-boot to allow "fastboot", an feature more commonly supported by 
> Android which allows one to boot or flash over USB, ethernet, etc. Maybe we 
> can become free from SD cards in the near future for BBB development.
>
> Cheers,
> Joe
>
> On Friday, July 12, 2013 8:30:29 AM UTC-4, Robert P. J. Day wrote:
>>
>> On Fri, 12 Jul 2013, Chris Morgan wrote: 
>>
>> > On Friday, July 12, 2013, Koen Kooi wrote: 
>> > 
>> >   Op 12 jul. 2013, om 13:46 heeft Robert P. J. Day <
>> rpj...@crashcourse.ca> het 
>> >   volgende geschreven: 
>> > 
>> >   > On Fri, 12 Jul 2013, Koen Kooi wrote: 
>> >   > 
>> >   >> It's all in the SRM, but for people too lazy to read that: 
>> >   >> 
>> >   >> � � �Read 
>> http://www.angstrom-distribution.org/building-angstrom and follow the 
>> >   steps outlined there. 
>> >   > 
>> >   > �gaah ... i am not interested in the general philosophy 
>> of how to 
>> >   > build angstrom, that's *not* the question on the table. the 
>> question 
>> >   > is, which *particular* configuration of angstrom is the one 
>> that 
>> >   > matches what is currently shipping on the BBB? 
>> > 
>> >   The one I linked above. There is only one configuration of 
>> angstrom per release and 
>> >   the above matches the release that ships with the bones. 
>> > 
>> > 
>> > Hello. 
>> > 
>> > I followed those instructions and, although I had selected the yocto 
>> > 2013 release, I ended up with the component files in the deploy/ 
>> > directory but as rootfs and ubi files, not card images. 
>> > 
>> > The information yesterday about the emmc-prepare.sh and other 
>> > scripts has helped informationaly, I think I'll be able to build a 
>> > sd card image today using those steps, but at this point it seems 
>> > like a multi step process after following the angstrom build steps. 
>>
>>   actually, that's what i would have expected ... the primary purpose 
>> of OE/yocto is to build the fundamental images or objects, not so much 
>> to create the final bootable SD card image based on them, since some 
>> people might not want an SD card, they might be, say, trying to 
>> populate a TFTP or NFS server with those images. 
>>
>> rday 
>>
>> -- 
>>
>>  
>> Robert P. J. Day Ottawa, Ontario, CANADA 
>> http://crashcourse.ca 
>>
>> Twitter:   http://twitter.com/rpjday 
>> LinkedIn:   http://ca.linkedin.com/in/rpjday 
>> 
>
>

-- 
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/groups/opt_out.

[beagleboard] Re: How to turn on/off GPIOs in BBB

[Brandon I]

Pad control registers can only be changed in kernel space. You could write a 
kernel driver or do it the right way and use device tree.

See

https://github.com/nomel/beaglebone/tree/master/gpio-header

If you don't want to use it directly, you can use the generated files as an 
example.

-- 
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/groups/opt_out.

[beagleboard] Re: Connect two BeagleBoneBlack between USB serial cable with IP over USB

[Brandon I]

Yes it is!

The beaglebone gets the ip from a hardcoded value and the dev PC gets the 
ip from a dhcp server running on the beaglebone.

The beaglebones usb ip is set and the dhcp server is launched in 
the /usr/bin/g-ether-load.sh script, called by the the g-ether-load.service 
(run "systemctl status g-ether-load" to view details). At the bottom of 
this script you'll see:
/sbin/ifconfig usb0 192.168.7.2 netmask 255.255.255.252
/usr/sbin/udhcpd -f -S /etc/udhcpd.conf

That first line sets the beaglebones ip and subnet mask, the second fires 
up the dhcp server using the configuration file /etc/udhcpd.conf, seen here:
start  192.168.7.1
end192.168.7.1
interface  usb0
max_leases 1
option subnet 255.255.255.252

The start and end is the address range the server can assign to the dev PC. 
The subnet limits the network to  the 
addresses 192.168.7.1 - 192.168.7.2 (with a broadcast address of 
192.168.7.3).

The problem is, when you attach two beaglebones to the same dev PC, the 
dhcp server on each beaglebone assigns an address of 192.168.7.1. Your dev 
PC says, "wait, I can't have to interfaces with the same IP" so refuses 
it...but, even if more ips were allowed, the dhcp protocol has no way to 
handle this crazy network topology, so everything gives up.

To make two work on the same pc, change the hardcoded beaglebone ip in 
/usr/bin/g-ether-load.sh and the dhcp ip range in /etc/udhcpd.conf to a 
different subnet. Sticking with the 255.255.255.252 subnet mask, which 
allows 2 ips and a broadcast ip, the next subnet starts at 192.168.7.4, so 
assign the beaglebone to 192.168.7.5 and the dhcp range to 192.168.7.4 (or 
flipping the ips would work too, it's an arbitrary selection).

-Brandon

On Wednesday, January 29, 2014 1:32:01 AM UTC-8, Andrea Pola wrote:
>
> It's possible to connect two BeagleBoneBack using the IP over USB.
> One is acting like Dev PC and may have the 192.168.7.1 address and the 
> other act as normal BBB using 192.168.7.2 address.
>
> I'm trying to do it, and i'm encountering problem. 
> Someone has made anything about this?
>
> 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/groups/opt_out.

Re: [beagleboard] Beaglebone Black backordered everywhere

[Brandon I]

At arrow, I just asked, and they have an old A53 datasheet up, so the guy 
told me it was a rev A5B. Are the arrow boards A6A?

On Monday, January 27, 2014 4:38:26 PM UTC-8, smith.wi...@gmail.com wrote:
>
> On Monday, January 27, 2014 2:18:04 PM UTC-5, Gerald wrote:
>>
>> Arrow is showing 500 boards in stock. We have people buying boards to go 
>> into products, something we cannot plan for. When will that be fixed? I 
>> have no idea. We cannot plan for something we don't know about. 
>>
>>
> Thank you!  I've had them backorderd at both Digikey and Newark for weeks 
> now.  Arrow have already shipped my order.  They still have 436 in stock.
>
>  
>

-- 
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/groups/opt_out.

[beagleboard] Re: PRU I/O

[Brandon I]

Here's mine:
/dts-v1/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
part-number = "AQ-PRU-MDIO";
exclusive-use = "P8.43", "P8.44", "P8.45", "P8.46", "P8.39", "P8.40", 
"P8.41", "P8.42", "P8.27", "P8.28", "P8.29", "P8.30", "pru1";

fragment@0 {
target = <0xdeadbeef>;

__overlay__ {

pinmux_pru_mdio_pins {
pinctrl-single,pins = <0xa8 0xd 0xac 0xd 0xa0 0xd 0xa4 0xd 0xb8 0x35 0xbc 
0x35 0xb0 0x35 0xb4 0x35 0xe0 0x36 0xe8 0x36 0xe4 0x36 0xec 0x36>;
linux,phandle = <0x1>;
phandle = <0x1>;
};
};
};

fragment@1 {
target = <0xdeadbeef>;

__overlay__ {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <0x1>;
};
};

__symbols__ {
pru_mdio_pins = "/fragment@0/__overlay__/pinmux_pru_mdio_pins";
};

__fixups__ {
am33xx_pinmux = "/fragment@0:target:0";
pruss = "/fragment@1:target:0";
};

__local_fixups__ {
fixup = "/fragment@1/__overlay__:pinctrl-0:0";
};
};


I constructed mine by modifying one of the existing dts files on the 
beaglebone. I'll admit I don't completely understand it, but you could 
trimming it down to only your pins.

On Tuesday, January 21, 2014 6:56:41 PM UTC-8, Christopher Hopwood wrote:
>
> Hello all,
>
> I'm trying to use the PRU gpio pins, but cannot get them to work.  I've 
> modified Doctor Yoder's device tree example to enable the PRU pins, but my 
> program is still not getting the input.  What am I doing wrong?
>
> Here is my overlay:
> /dts-v1/;
> /plugin/;
>
> /{
>compatible = "ti,beaglebone", "ti,beaglebone-black";
>part-number = "MAY-gpio-set";
>version = "00A0";
>
>fragment@0 {
>  target = <&am33xx_pinmux>;
>
>  __overlay__ {
>   pinctrl_test: MAY-gpio-set {
> pinctrl-single,pins = <
>
> 0x0e4 0x36
> 0x0e0 0x36
>
>
> >;
>   };
>  };
>};
>
>fragment@1 {
> target = <&ocp>;
> __overlay__ {
> test_helper: helper {
> compatible = "bone-pinmux-helper";
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_test>;
> status = "okay";
> };
> };
> };
> };
>
>
>
>

-- 
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/groups/opt_out.

Re: [beagleboard] Re: PRU FAQ 2013-05-15

[Brandon I]

In the pru, R31 is for input, so in that table you're looking for pin
"pr1_pru1_pru_r31_8". That's on P8.27, which is used by the HDMI framer. If
you *need* to use this pin, instructions on disabling the hdmi framer can
be found by searching this group.

Of course you'll have to enable the receiver, otherwise the state of the
pin couldn't be measured!

Also, here's a easier to digest table for the pru header pins:
https://docs.google.com/spreadsheet/ccc?key=0As0aJokrBccAdGkxeHkyYW1qRHNQdm5yZDhPQlRNR2c#gid=0




On Tue, Jan 21, 2014 at 6:08 PM, Christopher Hopwood <
rockybulwin...@gmail.com> wrote:

> I need to make sure I'm understanding correctly.  If I want to use PRU1's
> pin 8 as an input, should I use the address 0x8e0 or 0x0e0?  Should I set
> the mode to 0x26 to use input and enable the receiver?  Thanks for the help!
>
>
> On Wednesday, January 22, 2014 1:40:27 AM UTC, Charles Steinkuehler wrote:
>
>> On 01/21/14 19:34, Christopher Hopwood wrote:
>> > Where can I find the correct pinmux settings for the PRU as well as
>> which
>> > pru gpio port maps to which header bin?  I don't see it on Derek
>> Molloy's
>> > header table.
>>
>> The details are all in the TI manuals, or you can reference an excellent
>> compilation from various official sources on github:
>>
>> https://github.com/selsinork/beaglebone-black-pinmux
>>
>> --
>> Charles Steinkuehler
>> cha...@steinkuehler.net
>>
>  --
> 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/u28ytaoNenU/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/groups/opt_out.
>

-- 
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/groups/opt_out.

[beagleboard] Re: bitcoin mining on BBB

[Brandon I]

What he means by that is, it'll cost you more in electricity to mine (with 
a crud cpu setup) than to just buy some with cash from an exchange.

On Saturday, January 18, 2014 8:57:19 AM UTC-8, Michael Mullin wrote:
>
> I'm sure you can tweak cgminer to re-enable CPU based mining... But that 
> feature was removed for a reason; it's pointless.  Even with a high end 
> intel i7 processor, you're wasting your time, electricity, and the usage of 
> the beaglebone.
>
> The bbb can be used as a controller for other hardware specific to mining 
> (aka ASIC hardware). 
>

-- 
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/groups/opt_out.

Re: [beagleboard] "Forbidden" pins on P8 and P9

[Brandon I]

And, you shouldn't rely on the pull up/down pins that are there now since 
they could change with the next beaglebone (as they did between the black 
and white). You can make them high impedance at boot by using something 
like a bilateral switch enabled with 3V3_EXP.

On Tuesday, January 14, 2014 6:49:50 AM UTC-8, dl4mea wrote:
>
> Take care you don't change one of the SYSBOOT pin's value by your own 
> pullup/pulldown. This happend on my cape, so that the automatic clock 
> detection does not work and we're getting wrong system time.
> A kernel patch solves that, but it may become worse if touching others.
>
> Günter (dl4mea)
>
>

-- 
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/groups/opt_out.

[beagleboard] Re: Has anybody tested the new Graphics SDK which should enable SGX on kernel 3.12?

[Brandon I]

I think everyone in the group (who isn't headless) would love to see some 
benchmark results!

On Wednesday, December 11, 2013 4:32:42 AM UTC-8, Giuseppe Iellamo wrote:
>
>
> Thank you this is a very good news for me!
>
> When I'll finish with RT part I'll try QT5 on BBB...
>
> Giuseppe
>
> Il giorno mercoledì 11 dicembre 2013 00:05:04 UTC+1, Daniel Nilsson ha 
> scritto:
>>
>> Hi,
>>
>> I haven't tried the links you posted below, but I played around tonight 
>> with the latest bits in the arago project and now I have accelerated 3D 
>> graphics support on a beaglebone black. Using the beaglebone black BSP 
>> support in meta-ti, I get a 3.12.4 Linux kernel and then I built 
>> the arago-base-tisdk-image as root filesystem. Result is a beaglebone black 
>> which displays accelerated 3D graphics on the display connected over HDMI, 
>> so the SGX drivers are now available för the 3.12 kernel (in arago) but 
>> still not packaged nicely for the BBB I guess.
>>
>> Regards
>> Daniel
>>
>>
>> On Monday, December 9, 2013 10:38:10 AM UTC+1, Giuseppe Iellamo wrote:
>>>
>>> As the title states... has anybody tried? 
>>>
>>>
>>> http://processors.wiki.ti.com/index.php/RN_5_00_00_01_alpha
>>>
>>>
>>> http://e2e.ti.com/support/arm/sitara_arm/f/791/p/298596/1072533.aspx#1072533
>>>
>>

-- 
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/groups/opt_out.

[beagleboard] Re: Has anybody tested the new Graphics SDK which should enable SGX on kernel 3.12?

[Brandon I]

I think everyone (that isn'in the group would 

On Wednesday, December 11, 2013 4:32:42 AM UTC-8, Giuseppe Iellamo wrote:
>
>
> Thank you this is a very good news for me!
>
> When I'll finish with RT part I'll try QT5 on BBB...
>
> Giuseppe
>
> Il giorno mercoledì 11 dicembre 2013 00:05:04 UTC+1, Daniel Nilsson ha 
> scritto:
>>
>> Hi,
>>
>> I haven't tried the links you posted below, but I played around tonight 
>> with the latest bits in the arago project and now I have accelerated 3D 
>> graphics support on a beaglebone black. Using the beaglebone black BSP 
>> support in meta-ti, I get a 3.12.4 Linux kernel and then I built 
>> the arago-base-tisdk-image as root filesystem. Result is a beaglebone black 
>> which displays accelerated 3D graphics on the display connected over HDMI, 
>> so the SGX drivers are now available för the 3.12 kernel (in arago) but 
>> still not packaged nicely for the BBB I guess.
>>
>> Regards
>> Daniel
>>
>>
>> On Monday, December 9, 2013 10:38:10 AM UTC+1, Giuseppe Iellamo wrote:
>>>
>>> As the title states... has anybody tried? 
>>>
>>>
>>> http://processors.wiki.ti.com/index.php/RN_5_00_00_01_alpha
>>>
>>>
>>> http://e2e.ti.com/support/arm/sitara_arm/f/791/p/298596/1072533.aspx#1072533
>>>
>>

-- 
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/groups/opt_out.

[beagleboard] Re: Program for making sinewaves in real time with Analog inputs (any language)

[Brandon I]

Google "beaglebone black adc" for a bunch of examples.

On Tuesday, November 26, 2013 9:24:14 PM UTC-8, Zain Dar wrote:
>
> Hi,  just like in the title, I'm trying to make a program code for making 
> sinewaves that work with the analog pins when I have analog accelerometers 
> connected to it. Is there a code that can take the voltages from the 
> sensors and plot them to a graph in real time? which language an if there 
> are any tutorials or any candidate who has the idea for making it. Thanks 
> to those to help, it will help me alot to finish my project.
>

-- 
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/groups/opt_out.

Re: [beagleboard] gpio.h No such file or directory error

[Brandon I]

All of the gpio registers have dedicated set and clear registers so you 
don't have to do read-modify-write operations. There wont be an issue with 
collisions between separate gpio bits if you're just setting or reading pin 
states.

On Sunday, November 24, 2013 11:13:21 PM UTC-8, rod calabio wrote:
>
> I copy that Dave.   Yes, need to use masks, multiple registers, xors, 
> ands, to toggle multiple bits quickly.  I wonder how fast the mux switches 
> also.   Yes, would need to look at all the interrupts and momentarily 
> turning some off when doing high speed gpio switching.   I am making a 80 
> way network switch using the bbb and fpga cpld.
>
> Rocketrod
>

-- 
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/groups/opt_out.

Re: [beagleboard] can not disable HDMI in uEnv.txt

[Brandon I]

Didn't you forget BB-BONELT-HDMIN?

On Monday, November 25, 2013 10:26:27 AM UTC-8, RobertCNelson wrote:
>
> On Mon, Nov 25, 2013 at 6:01 AM, Yiqing Liang 
> > wrote: 
> > Hi, 
> > 
> >I try to  disable HDMI and emmc by editing the file in 
> /boot/uEnv.txt: 
> > 
> > optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONE-EMMC-2G 
> > 
> > 
> > Then I reboot , type: 
> > cat /sys/devices/bone_capemgr.*/slots 
> > 
> > See following: 
> > 
> > Last login: Sat Jan  1 00:00:22 UTC 2000 on ttyGS0 
> > root@beaglebone:~# cat /sys/devices/bone_capemgr.*/slots 
> >  0: 54:P---L BeagleBone RS232 CAPE,00A1,Beagleboardtoys,BB-BONE-SERL-03 
> >  1: 55:PF--- 
> >  2: 56:PF--- 
> >  3: 57:PF--- 
> >  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G 
> >  5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI 
> > 
> > With letter L, it means it is still enable.. It does not work.,, 
> > 
> > So what is wrong, how could I do? 
>
> Verify what you did, was actually passed to the kernel.. 
>
> cat /proc/cmdline 
>
> Regards, 
>
> -- 
> Robert Nelson 
> http://www.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/groups/opt_out.

[beagleboard] Re: Is there a way to access the UART registers

[Brandon I]

You can find the memory offsets for the uart control, and then the offsets 
for the specific registers in that reference manual. From there, you can 
use an mmap to the registers in your program/script or use the devmem2 
command to read/write the registers directly.

*mmap example with gpio registers*: 
c\c++: 
http://stackoverflow.com/questions/13124271/driving-beaglebone-gpio-through-dev-mem
python:  
http://www.alexanderhiam.com/tutorials/beaglebone-io-using-python-mmap/

*devmem2: *http://man.cx/devmem2(1) just uses an mmap to access memory.

*read-modify-write:* concept is to read the current value, modify some bits 
in the read value, and then write back the modified value, preserving all 
of the bits you didn't want to change. Search for "bitwise operations" for 
your language. 

Make sure the bits you're trying to access aren't available with the sysfs 
and c interface first.

On Friday, November 22, 2013 6:49:50 AM UTC-8, Andrei wrote:
>
> Hello, 
>
> I have a problem, how can I access the UART registers on a BeagleBone 
> Black? I need to  change UART modes described in 
>  in:  TI AM335x ARM A8 Microprocessors technical reference manual 
>
> example of instructions. 
> Disable the UART before accessing the UARTi.UART_DLL and UARTi.UART_DLH 
> registers:
> Set the UART_MDR1[2:0] MODE_SELECT bit field to 0x7.
>
> 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/groups/opt_out.

Re: [beagleboard] Re: Setting the Bitrate of I2C2 on the Beaglebone Black

[Brandon I]

You don't need the kernel source. You can convert the compiled device tree 
blob to the text version, edit it, and the convert it back to the binary 
using dtc:

# backup the original .dtb
cp /boot/am335x-boneblack.dtb /boot/am335x-boneblack.dtb.orig

# generate the dts from the dtb
dtc -I dtb -O dts -o am335x-boneblack.dts /boot/am335x-boneblack.dtb

# modify the dts with a text editor

# generate the dtb from the modified dts
dtc -I dts -O dtb -o am335x-boneblack.dtb am335x-boneblack.dts


On Wednesday, November 20, 2013 6:18:53 AM UTC-8, cody wrote:

> If you have the kernel source it is located at 
> arch/arm/boot/dts/am335x-bone-common.dtsi
> Then you will need to recompile the am335x-boneblack.dtb
>
>
> On Wed, Nov 20, 2013 at 4:04 AM, chai 
> > wrote:
>
>> hi,
>> can i know where I can find the  am335x-bone-common.dtsi?
>> it is not present in /lib/firmware so where can i find out 
>>
>> -- 
>> 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/groups/opt_out.
>>
>
>

-- 
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/groups/opt_out.

[beagleboard] Re: Program C++ through putty using VI (Library installations needed?)

[Brandon I]

> I was wondering if it is possible to write a c/c++ code in vi through SSH 
on Putty and then generate an output file and run directly on the 
beaglebone?
I tried the simple helloworld.c program and it worked.

I have a network share set up, accessible by the beaglebone. I also have 
the beaglebone set up as a network share, with samba. I edit my files in my 
favorite modern editor, but compile and run from the network shares, 
directly, on the beaglebone. Biggest benefit is, if I hose something on the 
beaglebone or the flash/sd card dies or whatever, I just plug in a new 
beaglebone, and and up and running after I cd to my development directory.

Don't develop on the beaglebone flash without some sort of constant 
backup/source control. You will most likely break something at some point, 
like with a "opkg upgrade" and it's hard to get stuff off the emmc.

> but its my first time in Embedded

Forget the embedded part, just think of it as a low end little Linux PC. 
That's the whole point of Linux, it's nearly identical regardless of the 
machine you're on. This one is no different than a supercomputer cluster, 
except you have somewhat constrained resources ;) and some unusual, kick 
butt, peripherals, like the PRUs.

g++, gcc, python, perl, and node.js (probably forgetting some) are already 
installed. There are tens of thousands of tutorials on developing regular 
Linux applications, which is all you'll be doing (maybe accessing some 
interesting sysfs interfaces, but that's not unusual). With the kernel-dev 
and kernel-headers packages, you can even compile kernel modules right on 
the Beaglebone.

For opkg, you need the exact name. Use "opkg list" to find the package. You 
can use wildcards to list packages, so "opkg list *gcc*".


On Monday, November 11, 2013 2:32:25 PM UTC-8, siddharth...@gmail.com wrote:
>
> Could give me a link with specific commands for this process? 
> I tried installing G++ with "opkg install g++" I get 3-4 error messages 
> and there is no installation.
> Do I need to be in some kind of an administrator mode? 
> I'm very new  to Linux and to beaglebone. I have no clue how to do the 
> things you guys told me in the previous replies.
>
> I'm familiar with FPGA programming but its my first time in Embedded
>
> On Monday, November 11, 2013 1:12:59 AM UTC-6, siddharth...@gmail.comwrote:
>>
>> I was wondering if it is possible to write a c/c++ code in vi through SSH 
>> on Putty and then generate an output file and run directly on the 
>> beaglebone?
>> I tried the simple helloworld.c program and it worked.
>> But I tried to write LED blink program and I'm getting error messages.
>>
>> I used the code by Derek Molley on his website: That uses "FILE, fopen, 
>> fclose, sleep, NULL, " etc. I'm getting errors about these. 
>> Am I supposed to install some kind of libraries or a arm-gnueabi compiler 
>> before I try to run programs that access the GPIOs and the LEDs ? 
>>
>> Please also let me know the commands for installing the needed packages 
>> or an example LED code that would work this way. 
>>
>> Also is there a better OS than Angstrom for beginners on BBB? How is the 
>> Ti SDK? 
>>
>> Thank you
>>
>>

-- 
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/groups/opt_out.

Re: [beagleboard] beagleboneblack don't restart after power fluctuation.

[Brandon I]

> A cap big enough should be able to handle that.

Not sure if I did my math right, but for 2 seconds at 2W (beaglebone will
be booting), and assuming his 24V to 5V regulator can regulate with an
input voltage all the way down to 12V, that's around 20mF. I guess that's
doable with $$$.

It wouldn't be as simple as connecting the cap to the accessories line,
since this would absolutely destroy your relay contacts from the inrush in
charging this gigantic cap from 0V. And, you would have to throw a diode in
so you didn't power *all* of your accessories with this cap.


On Tue, Nov 5, 2013 at 9:15 PM, Wilfredo Nieves wrote:

> Not necessarily , my car is a 95 3kgt and it starts within 1-2 seconds of
> turning it over. A cap big enough should be able to handle that. As for the
> 24v idk how I didn't catch that, but then again who knows it is possible.
>
> -Wil
> On Nov 5, 2013 9:30 PM, "Brandon I"  wrote:
>
>>  > I've connected beagleboneblack to my car power supply with 24V to 5V
>> step down.
>>
>> 24V "power supply" in a car? If this means you're this from the
>> accessories circuit, you're doomed. Accessories are turned off while the
>> car is being started, and a cap won't be enough to power the beaglebone,
>> since they stay off as long as you're turning the engine. Another problem
>> is, you'll corrupt the filesystem with an out-of-the-box beaglebone. You'll
>> *have to* use a read only file system.
>>
>> You could tie the beaglebone directly to the battery (with a fuse of
>> course) and use some circuit to monitor when to turn it on and off.
>>
>> On Tuesday, November 5, 2013 9:24:49 AM UTC-8, Wilfredo Nieves wrote:
>>>
>>> I think you should be fine as long as you don't use a value that is too
>>> high or too low. Too high may cause problems with rise time and too low may
>>> not keep enough power supplied for the board to stay powered up. Also  caps
>>> aren't like batteries, the charge almost instantaneously where as batteries
>>> need time to fully charge so as long as you can get the cap charged fast
>>> enough the board should power up without any problems.
>>>
>>> -Wil
>>> On Nov 5, 2013 8:27 AM, "satya gowtham kudupudi" 
>>> wrote:
>>>
>>>> Thank you. I will give a try. As per the post here
>>>> https://groups.google.com/forum/#!msg/beagleboard/
>>>> aXv6An1xfqI/mURD3LfQ5dMJ? the power source should have proper rise
>>>> time. I'm afraid a capacitor will increase the rise time. Any way I'll give
>>>> a try.
>>>>
>>>>  --
>>>> 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/groups/opt_out.
>>>>
>>>  --
>> 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/groups/opt_out.
>>
>  --
> 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/5toeq-9pcfU/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/groups/opt_out.
>

-- 
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/groups/opt_out.

Re: [beagleboard] beagleboneblack don't restart after power fluctuation.

[Brandon I]

> I've connected beagleboneblack to my car power supply with 24V to 5V step 
down.

24V "power supply" in a car? If this means you're this from the accessories 
circuit, you're doomed. Accessories are turned off while the car is being 
started, and a cap won't be enough to power the beaglebone, since they stay 
off as long as you're turning the engine. Another problem is, you'll 
corrupt the filesystem with an out-of-the-box beaglebone. You'll *have to* 
use a read only file system.

You could tie the beaglebone directly to the battery (with a fuse of 
course) and use some circuit to monitor when to turn it on and off.

On Tuesday, November 5, 2013 9:24:49 AM UTC-8, Wilfredo Nieves wrote:
>
> I think you should be fine as long as you don't use a value that is too 
> high or too low. Too high may cause problems with rise time and too low may 
> not keep enough power supplied for the board to stay powered up. Also  caps 
> aren't like batteries, the charge almost instantaneously where as batteries 
> need time to fully charge so as long as you can get the cap charged fast 
> enough the board should power up without any problems.
>
> -Wil
> On Nov 5, 2013 8:27 AM, "satya gowtham kudupudi" 
> > 
> wrote:
>
>> Thank you. I will give a try. As per the post here 
>> https://groups.google.com/forum/#!msg/beagleboard/aXv6An1xfqI/mURD3LfQ5dMJ? 
>> the power source should have proper rise time. I'm afraid a capacitor will 
>> increase the rise time. Any way I'll give a try.
>>
>>  -- 
>> 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/groups/opt_out.
>>
>

-- 
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/groups/opt_out.

[beagleboard] Re: run a script at startup with a stock BBB

[Brandon I]

You can make a systemd service for your script:

http://patrakov.blogspot.com/2011/01/writing-systemd-service-files.html

http://kezhong.wordpress.com/2011/11/19/creating-my-own-systemd-service-files-on-fedora-16x86_64/
 

>On an unrelated note, are there any pre-compiled SD card images I can just 
use WinDiskImager to flash a microSD card with to boot something

You can use the beaglebone white images for the sd card. You'll have to 
delete the MLO file on the emmc to prevent booting from the emmc.

-Brandon

On Monday, October 28, 2013 1:43:19 PM UTC-7, joeyh...@gmail.com wrote:
>
> Hello,
>
> I'm trying to figure out how to run a script at start up on my new 
> BeagleBone Black. I created a something.desktop file in my 
> /home/root/.config/autostart/ directory, but the script it references 
> doesn't get executed. I am trying to make this BBB run completely 
> unattended. It will startup, ping a server which will give it a command to 
> execute, and then it will execute that command. Currently, what I want to 
> do is run chromium with the -kiosk parameter so it opens a full screen 
> browser to the URL I specify. I already have this fully functioning on a 
> raspberry pi, but the hardware isn't reliable.
>
> Also, I have noticed that nothing gets rendered to the screen until I tap 
> the ALT key after starting up. I'm not sure why it does that, but if I just 
> boot it unattended, it doesn't send a video signal to the screen. It also 
> goes to sleep after a little while, and I need to wake it up with a 
> keyboard press.
>
> And finally, I need to figure out how to do all this either via SSH or 
> command line, since I don't have a way to plug in both a mouse AND keyboard 
> at the same time. No USB hub available.
>
> On an unrelated note, are there any pre-compiled SD card images I can just 
> use WinDiskImager to flash a microSD card with to boot something like 
> raspbian for the pi? The wiki for the BBB is confusing as hell and I can't 
> figure out what I do and don't need to do to load another OS on this thing.
>

-- 
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/groups/opt_out.

Re: [beagleboard] GPIO in C weirdness with fseek/fwrite

[Brandon I]

You can always read/write to the gpio registers using mmap. This gets a 
somewhat unsteady 4MHz on-off-on-... toggle even with slow python.

On Friday, October 18, 2013 6:08:13 PM UTC-7, Paul Tan wrote:

> I did the fseek because it didn't work without the fseek, and I agree that 
> it doesn't make sense to fseek a psuedo device.  You might be right in that 
> the fseek was just adding delays or doing an fflush of the buffers.  (The 
> other reason was that I found examples on the Internet using fseek)
>
> When I converted over to unix io, I no longer needed the seeks.
>
> I just wanted to get this working quickly and will probably convert over 
> to using the PRU later.
>
> Thanks for the input.
>  On 2013-10-18 9:00 PM, "Juanjo" > wrote:
>
>> I might be wrong but I think doing fseek() on a GPIO "device" isn't quite 
>> correct.
>>
>> A GPIO device is more like a char device not a block device were you can 
>> actually seek it. So you are only limited to write 1 or 0, the delay in 
>> between is set by you plus all the variance that a common not-RT OS adds to 
>> it. We know that these are exposed on /sys fs and not on /dev where you can 
>> actually see if you are dealing with a char or block device.
>>
>> For a more precise bit banging PRUSS is the way to do it IMHO.
>>
>> On Friday, October 18, 2013 7:22:17 PM UTC-3, Paul Tan wrote:
>>>
>>> Thanks, I'll try to see if there is a difference with libsoc or not. 
>>>  However, I did manage to get it working with low level unix i/o (open, 
>>> write) instead of the buffered stream i/o (fopen, fwrite).  It works 
>>> correctly, I didn't need a seek operation, and I was able to get pulse 
>>> widths down to 10uS reliably.  Interesting difference though: fwrite 
>>> to "/sys/class/gpio/export" succeeds even if GPIO30 was already exported, 
>>> but write to "/sys/class/gpio/export" fails if GPIO30 was already exported.
>>>
>>> In case anyone's wondering why I'm trying to get really short pulses, 
>>> I'm trying to connect an iGaging DRO slides to a BeagleBone Black (yeah, 
>>> I'm trying to CNC my lathe using a DRO closed loop servo with my Dual Motor 
>>> Controller Capes).  Scoping out my iGaging DRO, I found that the builtin 
>>> controller uses 24uS pulses with a 128uS duty cycle.  I'm working off of 
>>> Yuriy's work on the Arduino (http://www.yuriystoys.com/p/**
>>> android-dro.html ), but 
>>> trying it on the BeagleBone.
>>>
>>> Paul Tan.
>>> http://exadler.com
>>> http://exadler.blogspot.com
>>>
>>>
>>>
>>> On Friday, October 18, 2013 1:26:31 PM UTC-4, Jack Mitchell wrote:

 On 18/10/2013 18:14, Paul Tan wrote: 
 > I'm having some weirdness that I don't quite understand.  I'm trying 
 to 
 > just toggle a GPIO pin (GPIO30) on and off using C and just the file 
 > subsystem.  Everything seems to work if there is a delay between the 
 > fseek and the fwrite.  See this pastebin for the relevant code 
 > http://pastebin.com/Ftvv0nvE.  As it is, it works.  If you uncomment 
 the 
 > code, instead of creating a square wave on the oscilloscope, it just 
 > creates pulse spikes (i.e. short on times).  Can someone explain what 
 is 
 > happening?  I'm working off a stock BeagleBone Black, no updates (I 
 > wanted to make sure the code worked on all versions, as people would 
 be 
 > getting their BBB and trying it directly). 
 > 
 > Paul Tan. 
 > http://exadler.blogspot.com 
 > http://exadler.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...@googlegroups.**com. 
 > For more options, visit 
 > https://groups.google.com/**groups/opt_out.
 >  


 Hi Paul 

 If you don't object to using a library there is libsoc[1] which is made 
 for this exact purpose. If nothing else, you could see if the same 
 behavior is observed using it? 

 https://github.com/jackmitch/**libsoc 

 Cheers, 
 Jack. 

 -- 

Jack Mitchell (ja...@embed.me.uk) 
Embedded Systems Engineer 
http://www.embed.me.uk 

 -- 

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

-- 
For more option

[beagleboard] Re: BeagleBone Black peripherals

[Brandon I]

Just to clarify, there's nothing beaglebone specific about the usb 
peripheral compatibility. It's just a standard usb port connected to a 
linux computer (the beaglebone). If the device works or not depends on if 
your distribution has drivers for it or if you can find drivers that you 
can compile for your version of the kernel. The lists Roland provided are 
for what's supported or can be easily supported by Angstrom (what comes on 
the beaglebone). If you install a more mainstream distribution like debian, 
you'll be compatible with, probably, thousands of usb devices.

On Tuesday, October 8, 2013 7:40:52 AM UTC-7, Roland Groeneveld wrote:
>
> Here is the official list of accessories that have been verified to work 
> with the BeagleBone Black: 
> http://circuitco.com/support/index.php?title=BeagleBone_Black_Accessories
>
> For USB Wifi see this link: 
> http://circuitco.com/support/index.php?title=BeagleBoneBlack#WIFI_Adapters
>
> And here is another list with more information: 
> http://elinux.org/BeagleBone
>
> Roland Groeneveld
> www.logicsupply.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/groups/opt_out.

[beagleboard] Re: Fast boot, no-GUI distro?

[Brandon I]

You can build angstrom without the gui. For some pre built images, check 
out the angstrom rootfs image at 
http://downloads.angstrom-distribution.org/demo/beaglebone/



On Monday, October 7, 2013 12:34:13 AM UTC-7, Rick M wrote:
>
> Hi. I'm getting started with my BBB, having done previous projects with 
> RPi and smaller boards.
>
> I'm wondering if anyone's made an Angstrom distribution designed for fast 
> boot, and that doesn't bother with any of the desktop and other graphical 
> UI elements. I'm embedding this in a robot, don't really want those things, 
> and the faster it boots, the better.
>
> It'd be nice if there was someone making a distro like this on a regular 
> basis, keeping it up to date. It would be a lot faster to install.
>
> Anyway, I'm not much of a linux user per se, and don't really know what 
> can be dumped
>
> Any pointers to projects would be much appreciated.
>
> 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/groups/opt_out.

Re: [beagleboard] Device Tree Overlay ? why do we need it?

[Brandon I]

2. > Why is a DT used to define the HDMI
Because this is a system-on-chip. The HDMI, gpio, gpu, pruss, etc are 
all peripherals of the cpu that are located on the chip, but still separate 
from the cpu.

3. If you just want to get gpio or leds working quickly, check out this 
post: https://groups.google.com/d/msg/beagleboard/75suL1Mhzao/FBZr4gPM2wkJ
And, make sure you have the latest production image and check out the 
/lib/firmware path. I think there's a device tree overlay for about 
everything on chip now.


On Sunday, October 6, 2013 12:19:55 AM UTC-7, Amalinda J' Gamage wrote:
>
>
> thank you Pedro  and Przemek .
>
> I read through the materiel provided but I still have some doubts. 
>
> 1. Do you know a place where a very beginner coming from TI 
> microcontrolers (e.g. MSP430 and ARM Cortex M) can learn this embedded 
> linux from the begining? can you provide a guidance? a series of videos or 
> an extemely good book or some really good source? because I dont seem to 
> get the hang of these stuff by going through posts and blogs because none 
> start from scratch. I haven't taken any units on e linux in uni either.
>
>
> 2.  Okay, I now get a little bigger picture that DTs are used to define 
> external hardware that can be or are already connected to the ARM Cortex A. 
> So, Why is a DT used to define the HDMI eMMC?  It is because the 
> new Linux kernel has not included any hardware definitions for HDMI and 
> eMMC ? 
>
> 3. Is it possible that GPIOs be programmed without doing anything with 
> Device trees  using the new Linux Kernel in the BBB? 
>
> thank you a lot for responses.
>
>
>
>
>
>

-- 
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/groups/opt_out.

Re: [beagleboard] Re: PRU FAQ 2013-05-15

[Brandon I]

> and a lot of the pins are shared with the LCD/HDMI interface.

Which can be made available by disabling the hdmi framer by adding the
following to uEnv.txt on the fat32 partition:
capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN




On Wed, Oct 2, 2013 at 1:03 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 9/30/2013 8:40 AM, dthphon...@gmail.com wrote:
> > Is it possible to use these two PRU (pru0 and pru1) simultaneously to
> > control fast GPIO in direct PRU - output mode? If yes, how can we do that
> > with only r30?
>
> Each PRU has it's own r30, which drives the direct outputs (assuming you
> have the pinmux setup properly).  You can only drive a limited number of
> the BeagleBone header pins using PRU direct I/O, and a lot of the pins
> are shared with the LCD/HDMI interface.
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
>

-- 
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/groups/opt_out.

[beagleboard] Re: PRU FAQ 2013-05-15

[Brandon I]

Yes it is. The PRUs are independent and have 1 tick access to their gpio 
pins, and something like 3 to 8 ticks (I can't remember exactly) access for 
regular gpio pins (they are in system memory, accessible by the pru).

You can find documentation, compiler, and examples here: 
https://github.com/beagleboard/am335x_pru_package
And here's a list of the pru-gpio header pins: 
https://docs.google.com/spreadsheet/ccc?key=0As0aJokrBccAdGkxeHkyYW1qRHNQdm5yZDhPQlRNR2c


On Monday, September 30, 2013 6:40:57 AM UTC-7, dthph...@gmail.com wrote:
>
> Is it possible to use these two PRU (pru0 and pru1) simultaneously to 
> control fast GPIO in direct PRU - output mode? If yes, how can we do that 
> with only r30?
>
> Phong
>
> Vào 04:12:39 UTC+7 Thứ năm, ngày 16 tháng năm năm 2013, Jason Kridner đã 
> viết:
>>
>> Frequently asked questions regarding "PRU":
>>
>>- What is a "PRU"?
>>- PRU stands for Programmable Real-time Unit.  The overall subsystem 
>>   is typically called the ICSS, PRU-ICSS or PRUSS.  ICSS stands for 
>>   Industrial Communications Subsystem and PRUSS stands for Programmable 
>>   Real-time Unit Subsystem.
>>- What does a PRU do?
>>   - A PRU is a 200MHz microcontroller that is really useful at 
>>   "bitbanging" and has some peripherals attached to it that make it well 
>>   suited for building real-time interfaces to all types of digital 
>>   electronics.
>>- What are the processing elements within the AM33xx PRUSS used on 
>>BeagleBone and BeagleBone Black?
>>   - 2 32-bit 200MHz PRU cores
>>   - Each with 8KB of program memory
>>   - Direct access to general purpose I/O
>>   - Single cycle operations without cache or pipelines (instructions 
>>   *always* 5ns)
>>   - Shared 12KB data memory
>>   - Scratch pad registers
>>   - Parallel and serial capture modes
>>   - 32-bit port to memory and other peripherals outside of the 
>>   PRUSS, including external memory
>>- What are some example things built out of PRUs?
>>   - DMX512 lighting protocol: 
>>   http://beagleboard.org/CapeContest/entries/BeagleBone+DMX+Cape/
>>   - 6502 memory interface: 
>>   
>> http://elinux.org/images/a/ac/What's_Old_Is_New-_A_6502-based_Remote_Processor.pdf
>>   - Emulated memory interface on an Atari 600XL with BeagleBone 
>>   decoding video directly into Atari 600XL display memory: 
>>   http://www.youtube.com/watch?v=1irR4TQ5aMA
>>   - Nixie tube interface: https://github.com/mranostay/beagle-nixie
>>   - Software UART: 
>>   
>> http://processors.wiki.ti.com/index.php/Soft-UART_Implementation_on_AM335X_PRU_-_Software_Users_Guide
>>   - Sine wave generator using PWMs: 
>>   http://elinux.org/ECE497_BeagleBone_PRU
>>   - 3D printer stepper motor driver: 
>>   
>> http://hipstercircuits.com/pypruss-a-simple-pru-python-binding-for-beaglebone/
>>   - Camera interface: 
>>   http://www.hitchhikeree.org/beaglebone_capes/interacto/
>>- Where do I get some more details?
>>   - https://github.com/beagleboard/am335x_pru_package is the 
>>   official location for documentation and tools for the PRUSS on 
>> BeagleBone 
>>   and BeagleBone Black.
>>   - http://elinux.org/Ti_AM33XX_PRUSSv2 is the community wiki page.
>>   
>>
>>

-- 
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/groups/opt_out.