Re: [beagleboard] Is there a way to send an interrupt from userspace to the PRU-ICSS?

So, there is a driver, although I do not know the name of this driver that populates /proc/irq/ , but if you cat /proc/interrupts, you'll easily see which number correlates to what. root@beaglebone:~# cat /proc/interrupts CPU0 16: 39266767 INTC 68 Level gp_timer 20: 11

Re: [beagleboard] Is there a way to send an interrupt from userspace to the PRU-ICSS?

I see what you are saying. But (from what I've read) it seems that many would also say that you can't *receive* interrupts in userspace. I guess that's technically true, but uio does provide a way, through sysfs, to determine if an interrupt was fired. Also from what I've read (I've been doing

Re: [beagleboard] Is there a way to send an interrupt from userspace to the PRU-ICSS?

On Tue, Mar 7, 2017 at 9:45 PM, ags wrote: > The mechanism for generating an interrupt from a PRU to the A8 (host) is > well-documented. Is there a way to send an interrupt (one of the 64 system > interrupt events documented in the PRU-ICSS literature) from userspace? > No, there are no such thi

[beagleboard] Is there a way to send an interrupt from userspace to the PRU-ICSS?

The mechanism for generating an interrupt from a PRU to the A8 (host) is well-documented. Is there a way to send an interrupt (one of the 64 system interrupt events documented in the PRU-ICSS literature) from userspace? >From reading the TI documentation, the only two that seem to be candidates

Re: [beagleboard] Help editing BBGW's device tree

On Wed, 3/8/17, Robert Nelson wrote: Subject: Re: [beagleboard] Help editing BBGW's device tree To: "Beagle Board" Date: Wednesday, March 8, 2017, 2:49 AM On Tue, Mar 7, 2017 at 6:11 PM,  wrote: > Hello everyone, sorry if my question has b

[beagleboard] Re: UART2 on Beaglebone Black Rev C - What changed from Debian 7 to Debian 8?

Further testing shows that there is a conflict during bootup [2.798087] bone_capemgr bone_capemgr: Using override eeprom data at slot 8 [2.798124] bone_capemgr bone_capemgr: slot #8: 'Override Board Name,00A0,Override Manuf,BB-ADC' [2.799100] bone_capemgr bone_capemgr: initialized OK

Re: [beagleboard] Help editing BBGW's device tree

On Tue, Mar 7, 2017 at 6:11 PM, wrote: > Hello everyone, sorry if my question has been already answered - I have been > looking around for a while and haven't found a good answer. > > I am interested in adding some hardware to the Beaglebone Green Wireless > board, but in order to do that I need

Re: [beagleboard] TI Sitara 57XX - Combining Debian FS Image from BeagleBoard-X-15 with Kernel/Boot from TI SDK

On Tue, Mar 7, 2017 at 5:52 PM, Jeff Andich wrote: > Hi all, > > > > First and foremost, is this the correct forum for newbies to ask follow up > questions? > > > > Also, please let me know if I haven't done enough "chewing" on the problem > before posting up... > > > I followed the procedure belo

[beagleboard] Help editing BBGW's device tree

Hello everyone, sorry if my question has been already answered - I have been looking around for a while and haven't found a good answer. I am interested in adding some hardware to the Beaglebone Green Wireless board, but in order to do that I need to change some of the device tree/pin mux setti

Re: [beagleboard] TI Sitara 57XX - Combining Debian FS Image from BeagleBoard-X-15 with Kernel/Boot from TI SDK

Hi all, First and foremost, is this the correct forum for newbies to ask follow up questions? Also, please let me know if I haven't done enough "chewing" on the problem before posting up... I followed the procedure below (if I understood everything correctly), but ended up getting a

Re: [beagleboard] Why is the SPI0 clock output configured as an input???

The pin direction is only relevant for GPIO. For subsystems like SPI, the pin direction is defined by the subsystem, not the pin direction defined by pinctrl-single. Regards, John > On Mar 7, 2017, at 2:40 PM, Jon Turner wrote: > > The overlay for the SPI0 interface includes the following

Re: [beagleboard] Why is the SPI0 clock output configured as an input???

The pin direction is only relevant for GPIO. For subsystems like SPI, the pin direction is defined by the subsystem, not the pin direction. Regards, John > On Mar 7, 2017, at 2:40 PM, Jon Turner wrote: > > The overlay for the SPI0 interface includes the following lines > pinctrl-s

Re: [beagleboard] BeagleBone Green CAD Files (Altium Designer)

Oh, OK. I picked up BeagleBone Black in the thread. I am sure Seeed will provide the needed information with the file already converted and cleaned up in Altium. Gerald On Tue, Mar 7, 2017 at 4:35 PM, John Syne wrote: > Yeah, I think the OP was asking for BeagleBone Green. > > Regards, > John

[beagleboard] Why is the SPI0 clock output configured as an input???

The overlay for the SPI0 interface includes the following lines pinctrl-single,pins = < 0x150 0x30 /* spi0_sclk, INPUT_PULLUP | MODE0 */ 0x154 0x30 /* spi0_d0, INPUT_PULLUP | MODE0 */ 0x158 0x10 /* spi0_d1, OUTPUT_PULLUP | MODE0 */ 0x15c 0x1

Re: [beagleboard] BeagleBone Green CAD Files (Altium Designer)

Yeah, I think the OP was asking for BeagleBone Green. Regards, John > On Mar 7, 2017, at 2:15 PM, Gerald Coley wrote: > > It has already been done, minus a couple of small changes. I suggest you > start with what has already been done and cleaned up. A basic ASCII > conversion has a lot of

Re: [beagleboard] BeagleBone Green CAD Files (Altium Designer)

It has already been done, minus a couple of small changes. I suggest you start with what has already been done and cleaned up. A basic ASCII conversion has a lot of things that require clean up. http://www.elinux.org/Beagleboard:BeagleBoneBlack#LATEST_PRODUCTION_FILES_.28C.29 Gerald On Tue, Mar

Re: [beagleboard] BeagleBone Green CAD Files (Altium Designer)

Hi James, You have two options here. Ask Gerald to provide the ascii version of the PCB or contact your local Allegro or Altium user group and ask someone to do the conversion for you. Regards, John > On Mar 7, 2017, at 1:23 PM, jam...@cladnetwork.com wrote: > > Hi John, > > Thank you fo

Re: [beagleboard] BeagleBone Black Rev C CAD Files (Altium Designer)

http://www.elinux.org/Beagleboard:BeagleBoneBlack#LATEST_PRODUCTION_FILES_.28C.29 These are latest files. There i sno Rev C PCB. Rev C was a result of a processor change as you can see on the link I provided that goes to the support WIKI. Altium files are provided. Gerald On Tue, Mar 7, 2017 a

Re: [beagleboard] BeagleBone Green CAD Files (Altium Designer)

Hi John, Thank you for the advice on the conversion process. I created this post after attempting to convert the .brd file available on the official BeagleBoard wiki using Altium, Ltd's instructions on how to do so (see here

Re: [beagleboard] flashing BBB with image made from /opt/scripts/tools/beag.... and getting kernel panic

I tried creating an image two more times but i've been getting the same error/issue On Tuesday, March 7, 2017 at 2:50:37 PM UTC-5, Aparna Velampudi wrote: > > Pasted : > > http://pastebin.com/QMK9aaPa > > > On Tuesday, March 7, 2017 at 2:46:51 PM UTC-5, RobertCNelson wrote: >> >> On Tue, Mar 7, 2

Re: [beagleboard] BeagleBone Green CAD Files (Altium Designer)

Converting Orcad/Allegro files to Altium is pretty easy if you can get the Allegro files in ascii format. There are several issues you have to clean up, especially the copper pour areas which I advise to delete and just recreate these areas. Some of the components included some artifacts which n

[beagleboard] Are the am335x_pru_package examples incorrectly (dangerously) accessing DDR memory?

I have been able to load/start/run/stop a PRU core from 4.4.30-ti-r64 using just the uio_pruss (& uio) drivers, without any of the prussdrv code. Big milestone in my project. A long time ago I asked a question about the examples in the pru here: https://groups.google.com/d/topic/beagleboard/Kv0

[beagleboard] BBB and MPU6050 I2C errors

Hello, I am trying to interface the BBB with an MPU6050 accelerometer/gyroscope. I am using the i2c-1 bus, with the interrupt connected to an unused pin. I am running kernel version 3.14.57-ti-r78, with the included inv-mpu6050 kernel mode driver. It seems to work well, but when I increase th

Re: [beagleboard] flashing BBB with image made from /opt/scripts/tools/beag.... and getting kernel panic

Pasted : http://pastebin.com/QMK9aaPa On Tuesday, March 7, 2017 at 2:46:51 PM UTC-5, RobertCNelson wrote: > > On Tue, Mar 7, 2017 at 1:26 PM, Aparna Velampudi > > wrote: > > but after i tried to flash it on to another beaglebone, i got the > following: > > > > Begin: Loading essential drive

Re: [beagleboard] flashing BBB with image made from /opt/scripts/tools/beag.... and getting kernel panic

On Tue, Mar 7, 2017 at 1:26 PM, Aparna Velampudi wrote: > but after i tried to flash it on to another beaglebone, i got the following: > > Begin: Loading essential drivers ... done. > Begin: Running /scripts/init-premount ... done. > Begin: Mounting root file system ... Begin: Running /scripts/loc

Re: [beagleboard] flashing BBB with image made from /opt/scripts/tools/beag.... and getting kernel panic

but after i tried to flash it on to another beaglebone, i got the following: Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... done.

[beagleboard] BeagleBone Black Rev C CAD Files (Altium Designer)

Hi all, I am the lead electrical engineer for a small company based in New York State. We have been using both the Beaglebone Green and Beaglebone Black internally for hardware development purposes for the past couple of months for an upcoming product. We are early in the process of transitioni

[beagleboard] BeagleBone Green CAD Files (Altium Designer)

Hi all, I am the lead electrical engineer for a small company based in New York State. We have been using both the Beaglebone Green and Beaglebone Black internally for hardware development purposes for the past couple of months for an upcoming product. We are early in the process of transitioni

Re: [beagleboard] flashing BBB with image made from /opt/scripts/tools/beag.... and getting kernel panic

On Tue, Mar 7, 2017 at 12:24 PM, Aparna Velampudi wrote: > after i did that, some more issues: > > > Tearing Down script environment > ==> Unmounting /tmp > umount: /tmp: not mounted > ==> Stopping Cylon LEDs ... > ==> Setting LEDs to > ==> Force writeback of eMMC buffers by Syncing: /dev/mmcblk0

Re: [beagleboard] flashing BBB with image made from /opt/scripts/tools/beag.... and getting kernel panic

after i did that, some more issues: Tearing Down script environment ==> Unmounting /tmp umount: /tmp: not mounted ==> Stopping Cylon LEDs ... ==> Setting LEDs to ==> Force writeback of eMMC buffers by Syncing: /dev/mmcblk0 /opt/scripts/tools/eMMC/functions.sh: line 250: 32380 *Terminated*

[beagleboard] Re: Seed Grove MiCS-6814 and Python

Davide: The adafruit library does some unexpected things (at least to my thinking) with respect to byte order of multiple byte reads and writes. I would look for some "known values" in the part that are multi-byte reads and writes, and make sure you are getting the expected results. I would not

Re: [beagleboard] flashing BBB with image made from /opt/scripts/tools/beag.... and getting kernel panic

On Tue, Mar 7, 2017 at 11:47 AM, Aparna Velampudi wrote: > just did that, but now when i'm trying to run that script: > > /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh: > line 27: syntax error near unexpected token `<<<' looks like local changes... git reset HEAD --h

Re: [beagleboard] flashing BBB with image made from /opt/scripts/tools/beag.... and getting kernel panic

just did that, but now when i'm trying to run that script: /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh: line 27: syntax error near unexpected token `<<<' On Tuesday, March 7, 2017 at 12:35:45 PM UTC-5, RobertCNelson wrote: > > On Tue, Mar 7, 2017 at 11:30 AM, Apar

Re: [beagleboard] flashing BBB with image made from /opt/scripts/tools/beag.... and getting kernel panic

On Tue, Mar 7, 2017 at 11:30 AM, Aparna Velampudi wrote: > I used microSD flasher script and got this issue: > > > > - > Starting eMMC Flasher from microSD media > Version: [1.20151007: gpt partitions with raw boot...] version_message="1.20161216: more fixes..." https

Re: [beagleboard] flashing BBB with image made from /opt/scripts/tools/beag.... and getting kernel panic

I used microSD flasher script and got this issue: - Starting eMMC Flasher from microSD media Version: [1.20151007: gpt partitions with raw boot...] - Checking for Valid bbb-eeprom header [ 10.824227] Kernel panic - not syncing: Attempted

[beagleboard] Seed Grove MiCS-6814 and Python

Hi everyone. I'm trying to read my Seed Grove Multichannel gas sensor. (http://wiki.seeed.cc/Grove-Multichannel_Gas_Sensor/) I now, in the webpage the're a red X on Beaglebone, but I thought It was due to lack of python library. So I started coding from the Arduino cpp library (that works): h

[beagleboard] Re: Hoking up the beaglebone black with the MPU-9250 Using C

Buy the book -- Exploring BeagleBone: Tools and Techniques for Building with Embedded Linux by Derek Molloy for John Wiley & Sons, 2014 It walks you through programming in C on the Beaglebone, and setting up a cross compiler. Look at his videos. The book is several years old, so the Beaglebone

[beagleboard] Re: Wifi problems

Thanks for the info. I wound up resolving this by going back to 7.11, which is mostly working as I want (barring wifi dropping connection periodically). Thanks Joe On Monday, March 6, 2017 at 10:11:51 PM UTC-6, Barry Day wrote: > > rtl_usb is buggy. The fact anything that depends on it works,

[beagleboard] Hoking up the beaglebone black with the MPU-9250 Using C

I have recently aquired a beaglebone black board. I need some direction, as I would like to write my code in C and still use the board. So far all the examples i have found are in bonescript or python. I'm also trying to stay away from adruino. The project is to make the MPU-9250 of invensen

[beagleboard] Re: UART2 on Beaglebone Black Rev C - What changed from Debian 7 to Debian 8?

Hello Dominik, Did you resolve this issue? I am seeing the same thing at the moment where the cape_mngr at boot up says it loaded the UARTs and the device appear on /dev/ttyO* but I am unable to communicate with the attached device. I am wondering if the fact that I am not seeing a pinmux_uart2