[beagleboard] Device tree overlay does not affect GPIO pin but says so

Hi all, I am new in this forum so please correct me if I miss something. Currently I am struggeling with some modifications on an already working project from https://github.com/luigif/hcsr04 where a HCSR04 sonar is triggered via PRU. The sample works fine and I tried to move this to different

[beagleboard] Re: How can File I/O speed improvement in C

Your question already contains the answer: why do you always open and close it? Am Dienstag, 8. September 2015 12:51:22 UTC+2 schrieb 멘지: > > FILE *bin; > bin=fopen("header.bmp", "a"); > int fd_22=open("/sys/class/gpio/gpio22/value", O_WRONLY); > > for(k=0; k<153600; k++){ >

[beagleboard] Getting started - I'm lost, please help

Hi all, my first post here, and I am so new to this I am getting a little lost. My Beaglebone Black arrived and I installed the drivers, then connected it to my Win7_x64 PC, waited for windows to finish installing it's drivers (there were about 5 in the list) and then I opened the 'start.htm'

[beagleboard] Re: clpru label issue

I use clpru and it compiles inline asm quite good. I took some examples from here: http://www.embeddedrelated.com/showarticle/603.php and it works. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups

Re: [beagleboard] BBB P8/P9 GPIO pin availability

I/O pin functionality is a function of the processor. Not the board. Gerald On Mon, Sep 7, 2015 at 10:05 PM, rattus wrote: > On Monday, September 7, 2015 at 6:52:12 PM UTC-6, Graham wrote: >> >> Well, by definition, the boot programming pins are going to have the >>

[beagleboard] How can File I/O speed improvement in C

FILE *bin; bin=fopen("header.bmp", "a"); int fd_22=open("/sys/class/gpio/gpio22/value", O_WRONLY); for(k=0; k<153600; k++){ fd_45=open("/sys/class/gpio/gpio45/value", O_RDONLY); fd_44=open("/sys/class/gpio/gpio44/value", O_RDONLY); fd_23=open("/sys/class/gpio/gpio23/value",

[beagleboard] clpru label issue

Hello, i'm trying to write a delay function with the asm in my clpru program. I add the following text: void loop5(void) { __asm__ __volatile__ ( " LDI32 r10, 5000 \n" " DELAY: SUB r10, r10, 1 \n" " QBNE DELAY, r10, 0 \n" ); } but I get an error: "/tmp/06461GwSmDv", ERROR! at line

[beagleboard] Re: clpru label issue

What compiler are you using? TI's PRU-C-compiler does not support inline-assembler, so the whole thingy will nto work for you. Am Dienstag, 8. September 2015 12:52:02 UTC+2 schrieb BBBx: > > Hello, > > i'm trying to write a delay function with the asm in my clpru program. > I add the following

[beagleboard] Re: What determines the sampling frequency of BBB

For an oscilloscope this is quite slow. how about using PRU ADC sampling? Am Dienstag, 8. September 2015 06:52:18 UTC+2 schrieb TJF: > > The TSC_ADC_SS can sample at 200 kHz. > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed

Re: [beagleboard] How to Identify My BBB

On Tue, Sep 8, 2015 at 3:23 PM, Bruce Skelly wrote: > Hi, > > I need some help. Is there a software way to determine which Beagle Bone > Black I have? Is there a way to determine it from the hardware? > > There is a sticker on the side of mine that says 0 018132 957956 A5A. Is

[beagleboard] How to Identify My BBB

Hi, I need some help. Is there a software way to determine which Beagle Bone Black I have? Is there a way to determine it from the hardware? There is a sticker on the side of mine that says 0 018132 957956 A5A. Is any of that meaningful? Thanks, Bruce -- For more options, visit

Re: [beagleboard] how to fix cross compiling ftrace error for 4.1.2 kernel

crelloc@neoGenerationwork ~/linux $ cat /proc/version Linux version 3.13.0-37-generic (buildd@kapok) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 Also, i do indeed us the default bb.org_defconfig On Wednesday, August 26, 2015 at 11:56:08 AM UTC-7,

[beagleboard] Re: Beaglebone black MMC3

You may have to mess with some kernel source files: http://beagleboard.org/Community/Forums?place=topic%2Fbeagleboard%2FpPX-7HSt9E0%2Fdiscussion On Thursday, August 27, 2015 at 6:04:54 AM UTC-7, Dileep D R wrote: > > wl12xx_vmmc: fixedregulator@2 { > pinctrl-names = "default"; >

Re: [beagleboard] how to fix cross compiling ftrace error for 4.1.2 kernel

On Tue, Sep 8, 2015 at 2:07 PM, wrote: > > crelloc@neoGenerationwork ~/linux $ cat /proc/version > Linux version 3.13.0-37-generic (buildd@kapok) (gcc version 4.8.2 (Ubuntu > 4.8.2-19ubuntu1) ) #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 > > > Also, i do indeed us the

Re: [beagleboard] Re: Why beaglebone black restarts after a shutdown ??

On Tue, 8 Sep 2015 13:43:24 -0700 (PDT), you wrote: >Hi, > >Did anybody find the cause for the restart? >My BBB has the same problem, my adapter is 5V 2A and there is definitely no >restart issue with USB power. >I'm running Debian 3.8.13-bone70. >From what I remember, and I can be quite wrong,

Re: [beagleboard] Working links to blank-EEPROM flasher image?

On Tue, Sep 8, 2015 at 4:15 PM, Phil Mills wrote: > I have inherited responsibility for a bunch of 3rd-party direct clones of a > Beaglebone Black C5 (only known change is in silkscreening). > > Since none of these have any contents written to the onboard EEPROM, they > fail

Re: [beagleboard] Working links to blank-EEPROM flasher image?

Gerald, Robert's given me a workable answer to my question already, so I'm set, BUT it seems like a pretty heavy-weight option - totally suitable for manufacturing / mass-production / other "blank slate" scenarios, but very heavy for Joe User who's just accidentally typed "i2cset -y 1

Re: [beagleboard] How to Identify My BBB

The labels have pictures in the SRM describing what they mean as well, for those that are not afraid of documentation. http://www.elinux.org/Beagleboard:BeagleBoneBlack Gerald On Tue, Sep 8, 2015 at 3:25 PM, Robert Nelson wrote: > On Tue, Sep 8, 2015 at 3:23 PM,

Re: [beagleboard] how to fix cross compiling ftrace error for 4.1.2 kernel

I'm still receiving the same error when trying to compile: crelloc@neoGenerationwork ~/linux $ make ARCH=arm CROSS_COMPILE=${CC} where ${CC} is: crelloc@neoGenerationwork ~/linux $ echo ${CC} /home/crelloc/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- On

Re: [beagleboard] Working links to blank-EEPROM flasher image?

Take a real BBB and copy the contents if you need to. EEPROM data varies with serial number and revision data. But the EEPROM data is described in the SRM, is still valid and is not stale or old. Gerald On Tue, Sep 8, 2015 at 4:15 PM, Phil Mills wrote: > I have inherited

Re: [beagleboard] Working links to blank-EEPROM flasher image?

Gerald, I've got the SRM and know the format of the data that needs to get written there - I'm just stuck on HOW to get it there: Could anyone provide* a good set of instructions for getting access to a > uBoot prompt* from a stock flasher image OR provide current* links to the > blank-EEPROM

Re: [beagleboard] how to fix cross compiling ftrace error for 4.1.2 kernel

On Tue, Sep 8, 2015 at 3:27 PM, wrote: > I'm still receiving the same error when trying to compile: > > crelloc@neoGenerationwork ~/linux $ make ARCH=arm CROSS_COMPILE=${CC} > > where ${CC} is: > > crelloc@neoGenerationwork ~/linux $ echo ${CC} >

[beagleboard] Working links to blank-EEPROM flasher image?

I have inherited responsibility for a bunch of 3rd-party direct clones of a Beaglebone Black C5 (only known change is in silkscreening). Since none of these have any contents written to the onboard EEPROM, they fail to boot with "C" written to the serial console with no uSD card, and >

Re: [beagleboard] Working links to blank-EEPROM flasher image?

Just make sure you ground the Write Protect pin on the EEPROM. Gerald On Tue, Sep 8, 2015 at 4:38 PM, Phil Mills wrote: > Robert, > > Thanks for the prompt (and detailed!) reply. That's exactly the > information I'm trying to find. > > ...now I just have to convince our

Re: [beagleboard] Working links to blank-EEPROM flasher image?

On Tue, Sep 8, 2015 at 4:38 PM, Phil Mills wrote: > Robert, > > Thanks for the prompt (and detailed!) reply. That's exactly the information > I'm trying to find. > > ...now I just have to convince our IT staff / McAffee to white-list your web > server (if it ain't one

Re: [beagleboard] Working links to blank-EEPROM flasher image?

> On Sep 8, 2015, at 14:38 , Phil Mills wrote: > > ...now I just have to convince our IT staff / McAffee to white-list your web > server (if it ain't one thing, it's another) so I can get those files. Ugh, where do you work that you have such restrictions on servers?

Re: [beagleboard] Working links to blank-EEPROM flasher image?

We're not doing retail distribution, but I'll remind our product manager to check in w/ BeagleBoard.org to make sure we're not stepping on toes. As long as I can get it to boot / flash (thank you again!), the scripts to get it serialized & date-stamped as part of our configuration sequence

[beagleboard] Re: Why beaglebone black restarts after a shutdown ??

Hi, Did anybody find the cause for the restart? My BBB has the same problem, my adapter is 5V 2A and there is definitely no restart issue with USB power. I'm running Debian 3.8.13-bone70. Thanks. On Thursday, March 13, 2014 at 8:27:17 PM UTC+5:30, meerutmicr...@gmail.com wrote: > > Hi, > > I

[beagleboard] Re: Why beaglebone black restarts after a shutdown ??

Hi, Did anybody find the cause for the restart? My BBB has the same problem, my adapter is 5V 2A and there is definitely no restart issue with USB power. I'm running Debian 3.8.13-bone70. Thanks. On Thursday, March 13, 2014 at 8:27:17 PM UTC+5:30, meerutmicr...@gmail.com wrote: > > Hi, > > I

Re: [beagleboard] Working links to blank-EEPROM flasher image?

I2C writes is what we do. Gerald On Tue, Sep 8, 2015 at 4:32 PM, Phil Mills wrote: > Gerald, > > I've got the SRM and know the format of the data that needs to get written > there - I'm just stuck on HOW to get it there: > > Could anyone provide* a good set of

Re: [beagleboard] Working links to blank-EEPROM flasher image?

Robert, Thanks for the prompt (and detailed!) reply. That's exactly the information I'm trying to find. ...now I just have to convince our IT staff / McAffee to white-list your web server (if it ain't one thing, it's another) so I can get those files. This may be useful information to add to

[beagleboard] My audio cape layout

In case anyone cares, here is my audio cape layout for my antique podcast player project. Let me know if you spot any critical errors ;-) https://www.flickr.com/photos/jetforme/albums/72157658301949316 -- Rick Mann rm...@latencyzero.com -- For more options, visit

Re: [beagleboard] Working links to blank-EEPROM flasher image?

On Tue, Sep 8, 2015 at 4:59 PM, Phil Mills wrote: > Gerald, > > Robert's given me a workable answer to my question already, so I'm set, BUT > it seems like a pretty heavy-weight option - totally suitable for > manufacturing / mass-production / other "blank slate" scenarios,

Re: [beagleboard] Working links to blank-EEPROM flasher image?

Silly, ain't it. >From the McAfee naughty-naughty screen: *URL Categories:* Malicious Sites, Personal Pages, Technical/Business Forums, Malicious Downloads *Reputation:* High Risk (127) -phil On Tuesday, September 8, 2015 at 4:08:44 PM UTC-6, Rick M wrote: > > > > On Sep 8, 2015, at 14:38 ,

[beagleboard] Re: What determines the sampling frequency of BBB

On Tuesday, September 8, 2015 at 7:46:32 PM UTC+8, Karl Karpfen wrote: > For an oscilloscope this is quite slow. how about using PRU ADC sampling? > > Am Dienstag, 8. September 2015 06:52:18 UTC+2 schrieb TJF: > The TSC_ADC_SS can sample at 200 kHz. Agree, 200KHz is abit too slow, we are looking

Re: [beagleboard] Working links to blank-EEPROM flasher image?

> > *Well Intel owns McAfee, rcn-ee.com only provides ARM > stuff, and i once* > * told an Intel recruiter x86 was boring..* > > * Not surprised. ;)* That's pretty funny. Probably since it's true. heh But when will Intel realize that x86 is boring I wonder ? On Tue, Sep 8,

Re: [beagleboard] Working links to blank-EEPROM flasher image?

On Tue, Sep 8, 2015 at 5:20 PM, Phil Mills wrote: > Silly, ain't it. > > From the McAfee naughty-naughty screen: > URL Categories: Malicious Sites, Personal Pages, Technical/Business Forums, > Malicious Downloads > Reputation: High Risk (127) Well Intel owns McAfee,

Re: [beagleboard] Working links to blank-EEPROM flasher image?

On Tue, Sep 8, 2015 at 5:18 PM, Phil Mills wrote: > We're not doing retail distribution, but I'll remind our product manager to > check in w/ BeagleBoard.org to make sure we're not stepping on toes. > > As long as I can get it to boot / flash (thank you again!), the scripts

Re: [beagleboard] BBB P8/P9 GPIO pin availability

+1 for Gerald's "Add it to the cape" sentiment. ...and actually, given today's near zero-load CMOS inputs, having an assortment of I/O with pull-up and pull-down configured at reset makes it possible to directly tie GPIO pins to important signals (like chip selects or output enables) without

[beagleboard] Re: clpru label issue

I meant that the inline asm works. But the problem with the asm labels still presents. -- 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

Re: [beagleboard] element14 vs Circuitco Rev C

Please give me a hint, where the boot args are. btw: The BBB stop working after the log: [1.671200] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22<\r><\n> [1.678514] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single The BBB shut down(?)

Re: [beagleboard] element14 vs Circuitco Rev C

On Tue, Sep 8, 2015 at 11:36 AM, Fohnbit wrote: > Please give me a hint, where the boot args are. mmc0 is current device<\r><\n> SD/MMC found on device 0<\r><\n> reading uEnv.txt<\r><\n> 236 bytes read in 4 ms (57.6 KiB/s)<\r><\n> Loaded environment from uEnv.txt<\r><\n>

[beagleboard] element14 vs Circuitco Rev C

Hello! I have 5 BBB RevC from element14. Now I get 10 BBB from Circuitco, also Rev C. The shock: When I flash my own Image, where I made for the BBB and running on element14 Rev C, on the new BBB ... the flash starts ... ends ... and the BBB are not booting. Only the Power LED are on, all USR

Re: [beagleboard] element14 vs Circuitco Rev C

On Tue, Sep 8, 2015 at 9:59 AM, Fohnbit wrote: > Hello! > > I have 5 BBB RevC from element14. > Now I get 10 BBB from Circuitco, also Rev C. > > The shock: > When I flash my own Image, where I made for the BBB and running on element14 > Rev C, on the new BBB ... the flash

Re: [beagleboard] BBB P8/P9 GPIO pin availability

Definitely can add a lot of parts around it. Then again the board would cost more and everyone would pay for that feature, whiter they used it or not.. It would be less expensive to just add it to the cape on an add needed basis and not on every single pin. Gerald On Tue, Sep 8, 2015 at 12:02

Re: [beagleboard] BBB P8/P9 GPIO pin availability

Completely understood; however, assuming one could meet board area and timing constraints, it might be possible to wrap the processor with a circuit prophylactic, as it were... I've also been part of several ARM-based core silicon projects, and it would have been possible for that (i.e.

Re: [beagleboard] element14 vs Circuitco Rev C

Thank you! I´m able to boot the *BBB from Circuitco* from uSD and flash the eMMC with my image: http://pastebin.com/NwxFPXRZ After finished, the BBB are not booting. Only Power LED is on, no User LED. I just get as debug in Hex: 1B 00 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 I hear only

Re: [beagleboard] element14 vs Circuitco Rev C

Sounds like the Element14 product is different. Gerald On Tue, Sep 8, 2015 at 12:57 PM, Fohnbit wrote: > Thank you! > > I´m able to boot the *BBB from Circuitco* from uSD and flash the eMMC > with my image: > http://pastebin.com/NwxFPXRZ > > After finished, the BBB are not

Re: [beagleboard] Re: What determines the sampling frequency of BBB

PRU is running at 200 MHz, when you plan to have sample rates of more than 10 MHz you will have to do the whole ADC sampling of one frame in less than 20 clock cycles/with less than 20 instructions. Sounds like you have to do that with highly optimised PRU-ASM-code ... and I'm not sure if this

Re: [beagleboard] element14 vs Circuitco Rev C

Hello Gerald, yes, I also think this ... but this is bad for me. I thought that BBB RevC = BBB RevC :-( Maybe someone know who is different and maybe I can optimize my own image? Thanks! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are