Re: [beagleboard] Re: UART, serial port read C/C++

[Regina Choi]

Hi Hoang Vu, 

I am not really writing serial port driver, at least not kernel module. I'm 
using C for user space to program UART4 for beaglebone black. I have posted 
my question in following: 

https://groups.google.com/forum/#!category-topic/beaglebone/beagleboardorg-beaglebone-black/wfvfAUsu7fo

If you happen to know the solution, do let me know. Thanks!

Regina

On Monday, July 18, 2016 at 12:53:52 PM UTC+8, Lê Hoàng Vũ wrote:
>
> Hi Regina,
>
> Can I help you?
> Are you writing serial port driver with C?
>
> Best regard, 
>
> Le Hoang Vu
>
> Vào 18-07-2016 10:59, "Regina Choi"  
> đã viết:
>
>> Hello Andrey, 
>>
>> I am having almost similar problem as yours, just wondering have you 
>> found the reason behind it?  I have searching through the web but couldn't 
>> find related answer. 
>>
>>
>> Regards,
>> Regina
>> On Wednesday, May 7, 2014 at 2:42:34 AM UTC+8, Andrey wrote:
>>>
>>> Hello,
>>>
>>> I need to use an UART to communicate between beaglebone and the device. 
>>> I have written the C code, but it has a few problems within it. I can't 
>>> identify the cause of the problem or to be more precise don't know how fix 
>>> it.  
>>>
>>> The problem is of 
>>> reading in the information and displaying it on a shell. I can easily 
>>> write any information data set that I wish, but when I try to read in 
>>> response it either doesn't read in, with the perror being displayed as 
>>> (erno = EINTR [Interrupted function call]) meaning read () function 
>>> returned negative number. 
>>>  
>>> #include 
>>>
>>> #include 
>>>
>>> #include 
>>>
>>> #include 
>>>
>>> #include 
>>>
>>> #include 
>>>
>>> #include 
>>>
>>> #include 
>>>
>>> #include 
>>>
>>> #define BAUDRATE B19200
>>>
>>> #define PORT "/dev/ttyO4"
>>>
>>> #define _POSIX_SOURCE 1
>>>
>>>  
>>>
>>> #define FALSE 0
>>>
>>> #define TRUE 1
>>>
>>> volatile int STOP=FALSE;
>>>
>>>  
>>>
>>> void signal_handler_IO(int status);
>>>
>>> int wait_flag = TRUE;
>>>
>>>  
>>>
>>> int main ()
>>>
>>> {
>>>
>>> int fd=0, res=0;
>>>
>>> int check=0;
>>>
>>>  
>>>
>>> char SYNC  [] = {0x55};
>>>
>>> char PID [] = {0x6A};
>>>
>>>  
>>>
>>> struct termios oldtio, newtio;
>>>
>>> struct sigaction saio;
>>>
>>> char buff[255];
>>>
>>>  
>>>
>>> fd = open(PORT, O_RDWR | O_NOCTTY | O_NONBLOCK);
>>>
>>> if (fd<0) {perror(PORT); exit(-1);}
>>>
>>>  
>>>
>>> saio.sa_handler=signal_handler_IO;
>>>
>>> saio.sa_flags=0;
>>>
>>> saio.sa_restorer = NULL;
>>>
>>> sigaction(SIGIO, ,NULL);
>>>
>>> fcntl(fd, F_SETFL, FASYNC);
>>>
>>> check = tcgetattr(fd, );
>>>
>>> if (check<0){perror("tcgetattr");}
>>>
>>>  
>>>
>>> check = newtio.c_cflag = BAUDRATE | CS8 | CLOCAL | CREAD ; if (check
>>> <0){perror("c_cflag");}
>>>
>>> check = newtio.c_iflag = IGNPAR | IXON; if (check<0){perror(
>>> "c_iflag");}
>>>
>>> check = newtio.c_oflag = 0; if (check<0){perror("c_oflag");}
>>>
>>> //check = newtio.c_lflag = ICANON | ISIG;
>>>
>>> check = newtio.c_lflag = 0; if (check<0){perror("c_lflag  ");}
>>> /* c_cc is responsible for an erno error */
>>>
>>> check = newtio.c_cc[VMIN]=1; if (check<0){perror("c_cc[VMIN]");}
>>>
>>> check = newtio.c_cc[VTIME]=0; if (check<0){perror("c_cc[VTIME]");}
>>>
>>> tcflush(fd, TCIFLUSH); 
>>>  
>>>
>>> check = tcsetattr(fd, TCSANOW, ); if (check<0){perror(
>>> "tcsetattr");}
>>>
>>>  
>>>
>>> for(;;)
>>>
>>> {
>>> ioctl(fd, TIOCSBRK);
>>>
>>> usleep(1300);
>>>
>>> ioctl(fd,TIOCCBRK);
>>>
>>> usleep(200);
>>>
>>>  
>>> /* send request to actuator to receive the current setting and setup */
>>> check = write(fd, SYNC, sizeof(SYNC));  if (check<0){perror("SYNC"
>>> );}
>>>
>>> check = write(fd,PID, sizeof(PID)); if (check<0){perror("PID");}
>>>
>>> /* read response*/
>>> res = read(fd, buff,255); 
>>> if (res < 0)
>>>
>>> {
>>>
>>> perror("read");
>>> //if(errno ==EINTR) continue;
>>> }
>>>
>>> printf(": :%d :%d\n", res,buff);
>>>
>>>
>>>
>>> usleep(1);
>>>
>>> }
>>>
>>> close (fd);
>>>
>>> } 
>>>
>>>  
>>>
>>> void signal_handler_IO(int status)
>>>
>>> {
>>>
>>> wait_flag=FALSE;
>>>
>>>
>>> e}
>>>
>>> erno EINTR error is displayed only when i'm setting any non-zero values 
>>> to c_cc[VTIME] or c_cc[VMIN]. but still even if i set the both to zero, I 
>>> cannot read anything from the port, it's just blank. 
>>>
>>>
>>> I'm confident that i'm receiving response from the device, I have 
>>> checked it with oscilloscope. 
>>>
>>> Any assistance would be appreciated. if possible with the code examples 
>>> for me to see what should I modify.
>>>
>>> Thank you very much for the help. 
>>>
>> -- 
>> 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 
>> 

Re: [beagleboard] Re: PRU remoteproc Tutorial

[William Hermans]

Anyway, you can find the history behind the different toolchian for the
MSP430's, and all that on the 43oh.com forums. From which I've been a
member since around January 2013. All the gory details of TI, gcc, and
redhat etc and all that.

On Mon, Jul 18, 2016 at 6:15 PM, William Hermans  wrote:

> Well, it replaced both CCS and the old MSP430 GCC, and I think the
>> concensus is that it's for the good. There were issues in the
>> beginning, but now it's being worked on by both RedHat and TI, and
>> nobody recommends the old stuff for use any more.
>>
>> The usual argument for GCC is that it's relentlessly getting better;
>> proprietary alternatives tend to lose their initial advantage because
>> GCC contributors have a look at the differences and implement the
>> improvements. Look how far Dimitar got it, working on his own.
>>
>
> Well the msp430-gcc-4.6.3 is still the go to to tool chain for many in the
> gcc cap for the msp430G2 family MCU's. At least the ones meant to be used
> in the MSP430G2 v1.5 launchpad. There are some newer MCU's like the
> MSp430G2955 that have more flash and more RAM than the older G2's, end
> require the newer compilers. Something to do with memory addressing I
> believe, but it's been a long time since I've worried about all that. My
> personal favorite MSP430 is the G2553 . . .
>
> This is also the same compiler that comes with Debian I believe but
> perhaps that one was also P.A. Bigot's. The compiler I prefer to use
> actually comes with Energia, which also may be a port of P.A. Bigot's
> original project? Not sure.
>
>
> On Mon, Jul 18, 2016 at 5:47 PM, Przemek Klosowski <
> przemek.klosow...@gmail.com> wrote:
>
>> On Wed, Jul 13, 2016 at 11:09 AM, William Hermans 
>> wrote:
>> >
>> > Granted, now, I've read that redhat was contracted to build a newer gcc
>> port
>> > a few years back, and that this gcc is actually used by CCS now days(
>> for
>> > the MSP430 toolchain ). It is purported to support the newer MSP430G2
>> > variants, among others, but still is not as reliable as the gcc
>> toolchain it
>> > was meant to replace.
>>
>> Well, it replaced both CCS and the old MSP430 GCC, and I think the
>> concensus is that it's for the good. There were issues in the
>> beginning, but now it's being worked on by both RedHat and TI, and
>> nobody recommends the old stuff for use any more.
>>
>> The usual argument for GCC is that it's relentlessly getting better;
>> proprietary alternatives tend to lose their initial advantage because
>> GCC contributors have a look at the differences and implement the
>> improvements. Look how far Dimitar got it, working on his own.
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGH-eijzdkeyj9cL8O9jiGJj2QZ0L%3DqPNRFbH7%2B2R6cuQ%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORruUQG6mib1Yevf98MSedePGGKMSfmxJZUZRXCspwLtRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU remoteproc Tutorial

[William Hermans]

>
> Well, it replaced both CCS and the old MSP430 GCC, and I think the
> concensus is that it's for the good. There were issues in the
> beginning, but now it's being worked on by both RedHat and TI, and
> nobody recommends the old stuff for use any more.
>
> The usual argument for GCC is that it's relentlessly getting better;
> proprietary alternatives tend to lose their initial advantage because
> GCC contributors have a look at the differences and implement the
> improvements. Look how far Dimitar got it, working on his own.
>

Well the msp430-gcc-4.6.3 is still the go to to tool chain for many in the
gcc cap for the msp430G2 family MCU's. At least the ones meant to be used
in the MSP430G2 v1.5 launchpad. There are some newer MCU's like the
MSp430G2955 that have more flash and more RAM than the older G2's, end
require the newer compilers. Something to do with memory addressing I
believe, but it's been a long time since I've worried about all that. My
personal favorite MSP430 is the G2553 . . .

This is also the same compiler that comes with Debian I believe but perhaps
that one was also P.A. Bigot's. The compiler I prefer to use actually comes
with Energia, which also may be a port of P.A. Bigot's original project?
Not sure.


On Mon, Jul 18, 2016 at 5:47 PM, Przemek Klosowski <
przemek.klosow...@gmail.com> wrote:

> On Wed, Jul 13, 2016 at 11:09 AM, William Hermans 
> wrote:
> >
> > Granted, now, I've read that redhat was contracted to build a newer gcc
> port
> > a few years back, and that this gcc is actually used by CCS now days( for
> > the MSP430 toolchain ). It is purported to support the newer MSP430G2
> > variants, among others, but still is not as reliable as the gcc
> toolchain it
> > was meant to replace.
>
> Well, it replaced both CCS and the old MSP430 GCC, and I think the
> concensus is that it's for the good. There were issues in the
> beginning, but now it's being worked on by both RedHat and TI, and
> nobody recommends the old stuff for use any more.
>
> The usual argument for GCC is that it's relentlessly getting better;
> proprietary alternatives tend to lose their initial advantage because
> GCC contributors have a look at the differences and implement the
> improvements. Look how far Dimitar got it, working on his own.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGH-eijzdkeyj9cL8O9jiGJj2QZ0L%3DqPNRFbH7%2B2R6cuQ%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqJewKXHCfm%2BJx5rA61_MyadfCh73ZeA6340Xw89K3WqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU remoteproc Tutorial

[Przemek Klosowski]

On Wed, Jul 13, 2016 at 11:09 AM, William Hermans  wrote:
>
> Granted, now, I've read that redhat was contracted to build a newer gcc port
> a few years back, and that this gcc is actually used by CCS now days( for
> the MSP430 toolchain ). It is purported to support the newer MSP430G2
> variants, among others, but still is not as reliable as the gcc toolchain it
> was meant to replace.

Well, it replaced both CCS and the old MSP430 GCC, and I think the
concensus is that it's for the good. There were issues in the
beginning, but now it's being worked on by both RedHat and TI, and
nobody recommends the old stuff for use any more.

The usual argument for GCC is that it's relentlessly getting better;
proprietary alternatives tend to lose their initial advantage because
GCC contributors have a look at the differences and implement the
improvements. Look how far Dimitar got it, working on his own.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGH-eijzdkeyj9cL8O9jiGJj2QZ0L%3DqPNRFbH7%2B2R6cuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Extracting eMMC to image file on microSD card

[Kirk]

Maybe this will help:

Here's what the serial debug output looks like when it doesn't work.
I need some help interpreting it.
Thanks

U-Boot SPL 2013.04 (Sep 25 2013 - 00:49:30)
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img


U-Boot 2013.04 (Sep 25 2013 - 00:49:30)

I2C:   ready
DRAM:  512 MiB
WARNING: Caches not enabled
NAND:  No NAND device found!!!
0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net:not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot:  0
mmc0 is current device
SD/MMC found on device 0
reading uEnv.txt
236 bytes read in 7 ms (32.2 KiB/s)
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
reading uImage
11748096 bytes read in 1322 ms (8.5 MiB/s)
reading /am335x-boneblack.dtb
24884 bytes read in 12 ms (2 MiB/s)
## Booting kernel from Legacy Image at 8020 ...
   Image Name:   Linux-3.8.13
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:11748032 Bytes = 11.2 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 81ff
   Booting using the fdt blob at 0x81ff
   Loading Kernel Image ... OK
OK
   Using Device Tree in place at 81ff, end 81ff9133

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[1.368993] omap2_mbox_probe: platform not supported
[1.380022] tps65217-bl tps65217-bl: no platform data provided
[1.456012] bone-capemgr bone_capemgr.9: slot #0: No cape found
[1.493120] bone-capemgr bone_capemgr.9: slot #1: No cape found
[1.530230] bone-capemgr bone_capemgr.9: slot #2: No cape found
[1.567340] bone-capemgr bone_capemgr.9: slot #3: No cape found
[1.594051] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' 
failed
[1.659528] pinctrl-single 44e10800.pinmux: pin 44e10854 already 
requested by 44e10800.pinmux; cannot claim for gpio-leds.8
[1.671234] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status 
-22
[1.678546] pinctrl-single 44e10800.pinmux: could not request pin 21 on 
device pinctrl-single
Starting logging: OK
Initializing random number generator... done.
Starting network...
/etc/init.d/S93-am335x-pm-firmware-load: line 4: can't create 
/sys/devices/ocp.2/44d0.wkup_m3/firmware/am335x-pm-firmware.bin/loading: 
nonexistent directory
/etc/init.d/S93-am335x-pm-firmware-load: line 5: can't create 
/sys/devices/ocp.2/44d0.wkup_m3/firmware/am335x-pm-firmware.bin/data: 
nonexistent directory
/etc/init.d/S93-am335x-pm-firmware-load: line 6: can't create 
/sys/devices/ocp.2/44d0.wkup_m3/firmware/am335x-pm-firmware.bin/loading: 
nonexistent directory
Running /dev/mmcblk0p1/autorun.sh...
dd: can't open '/dev/mmcblk1': No such file or directory

Welcome to Buildroot
beaglebone login:

Welcome to Buildroot
beaglebone login:

 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d2799675-8314-473b-a0b8-b83e33f1d79d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[William Hermans]

Well, not to mention you installed a *bone* kernel anyhow. So what we're
talking about is really moot. e.g. a topic for a different discussion.

So. . . back on topic . . .

*Download suitable linu image and reboot:*
william@beaglebone:~$ sudo apt-get install linux-image-4.4.14-ti-r34
william@beaglebone:~$ sudo reboot

*Install git and check your dtc version:*
william@beaglebone:~$ sudo apt-get install git
william@beaglebone:~$ dtc -v
Version: DTC 1.4.1

*Clone the git into a suitable location:*
william@beaglebone:~$ cd dev
git clone -b 4.4-ti https://github.com/RobertCNelson/dtb-rebuilder
dtb-4.4-ti --depth=1
william@beaglebone:~/dev$ cd dtb-4.4-ti/

*Edit the needed board file( this will be different for every situation )*
william@beaglebone:~/dev/dtb-4.4-ti$ nano
src/arm/am335x-boneblack-emmc-overlay.dts
change:
/* #include "am33xx-pruss-uio.dtsi" */
to:
#include "am33xx-pruss-uio.dtsi"

*Build from source, and install the board file:*
william@beaglebone:~/dev/dtb-4.4-ti$ make
william@beaglebone:~/dev/dtb-4.4-ti$ sudo make install

*Blacklist the remoteproc drivers:*
william@beaglebone:~/dev/dtb-rebuilder$ sudo nano
/etc/modprobe.d/pruss-blacklist.conf
blacklist pruss
blacklist pruss_intc
blacklist pru-rproc
william@beaglebone:~/dev$ sudo reboot

*Test to see if the device tree file loaded successfully:*
william@beaglebone:~$ lsmod |grep  uio
uio_pruss   4928  0
uio_pdrv_genirq 3539  0
uio 8822  2 uio_pruss,uio_pdrv_genirq

On Mon, Jul 18, 2016 at 1:12 PM, Robert Nelson 
wrote:

>
>
> On Mon, Jul 18, 2016 at 3:08 PM, Joseph Heller  > wrote:
>
>> small progress here;
>> 4.4.x-ti r34 did not result in any good (only remoteproc as far as I
>> could tell), no uio.
>>
>> Therefore went for the bone version, non -rt:
>>
>> cd /opt/scripts/tools/
>> sudo git pull
>> sudo ./update_kernel.sh --bone-kernel --lts-4_4
>>
>> which gave me
>> kernel 4.4.15-bone11
>>
>> and a new dmesg after loading my dtbo:
>> [Mon Jul 18 19:44:48 2016] pruss_uio 4a30.pruss: pins are not
>> configured from the driver
>> [Mon Jul 18 19:44:49 2016] bone-pinmux-helper
>> ocp:pinctrl_generated_pinmux: could not find pctdev for node
>> /ocp/interrupt-controller@4820, deferring probe
>>
>
> ^ looks like you aren't using the dtc compiler for v4.1.x+ targets..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYgfQYcKT89EihmpdnORK%3D7t9M3zG7gG1SozLtQpaTtQJA%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrW-VQVyme2cEp1OtTCqpenn0NDGx%3DHOR43SdWv17TmLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Robert Nelson]

On Mon, Jul 18, 2016 at 3:08 PM, Joseph Heller 
wrote:

> small progress here;
> 4.4.x-ti r34 did not result in any good (only remoteproc as far as I could
> tell), no uio.
>
> Therefore went for the bone version, non -rt:
>
> cd /opt/scripts/tools/
> sudo git pull
> sudo ./update_kernel.sh --bone-kernel --lts-4_4
>
> which gave me
> kernel 4.4.15-bone11
>
> and a new dmesg after loading my dtbo:
> [Mon Jul 18 19:44:48 2016] pruss_uio 4a30.pruss: pins are not
> configured from the driver
> [Mon Jul 18 19:44:49 2016] bone-pinmux-helper
> ocp:pinctrl_generated_pinmux: could not find pctdev for node
> /ocp/interrupt-controller@4820, deferring probe
>

^ looks like you aren't using the dtc compiler for v4.1.x+ targets..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

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

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

small progress here; 
4.4.x-ti r34 did not result in any good (only remoteproc as far as I could 
tell), no uio. 

Therefore went for the bone version, non -rt:

cd /opt/scripts/tools/
sudo git pull
sudo ./update_kernel.sh --bone-kernel --lts-4_4

which gave me 
kernel 4.4.15-bone11

and a new dmesg after loading my dtbo: 
[Mon Jul 18 19:44:48 2016] pruss_uio 4a30.pruss: pins are not 
configured from the driver
[Mon Jul 18 19:44:49 2016] bone-pinmux-helper ocp:pinctrl_generated_pinmux: 
could not find pctdev for node /ocp/interrupt-controller@4820, 
deferring probe

Probably the pro loader does not work yet because of this, and quits with 
prussdrv_open() 
failed

So I think I need to figure out a bit of my device tree to get the correct 
pinmuxing / overlay file now. 

On Sunday, July 17, 2016 at 6:44:08 PM UTC+2, Joseph Heller wrote:
>
> ok thanks William for the heads-up. Did a check on 4.1.5-ti-r10, so the 
> non-rt version, but no luck yet (but not out of options). Had one failure 
> again truing to apt-get install a 4.1.5 bone15 kernel, so need to try that 
> as well. I missed Robert's remark though earlier in the post to use 
> 4.4.x-ti r34 or later and would like to try that as well. 
>
> ---> So to clarify, best bet is to use 4.4.x-ti r34, the non-rt version, 
> in order to use uio_pruss? 
>
> On Sunday, July 17, 2016 at 2:03:30 AM UTC+2, William Hermans wrote:
>>
>> So apparently you got bit by the rt kernel bug as many have in the past. 
>> So, if you want to use uio_pruss right now with TI's most recently kernel. 
>> You're going to have to opt out of using an rt kernel. Which honestly is 
>> not a huge deal.
>>
>> On Sat, Jul 16, 2016 at 4:58 PM, William Hermans  
>> wrote:
>>
>>> RT kernel strikes again apparently . . .
>>>
>>> william@beaglebone:~/dev/dtb-4.4-ti$ sudo apt-get install 
>>> linux-image-4.4.14-ti-r34
>>> william@beaglebone:~/dev/dtb-4.4-ti$ sudo reboot
>>>
>>> william@beaglebone:~$ uname -r
>>> 4.4.14-ti-r34
>>>
>>> william@beaglebone:~$ cd dev/dtb-4.4-ti/
>>> william@beaglebone:~/dev/dtb-4.4-ti$ sudo make install
>>> william@beaglebone:~/dev/dtb-4.4-ti$ sudo reboot
>>>
>>> william@beaglebone:~$ lsmod |grep  uio
>>> uio_pruss   4928  0
>>> uio_pdrv_genirq 3539  0
>>> uio 8822  2 uio_pruss,uio_pdrv_genirq
>>>
>>>
>>> On Sat, Jul 16, 2016 at 3:18 PM, William Hermans  
>>> wrote:
>>>
 Right, and  . . .

 william@beaglebone:~/dev/dtb-4.4-ti$ head /boot/uEnv.txt
 #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

 uname_r=4.4.14-ti-rt-r34
 #uuid=
 #dtb=

 ##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just 
 works..)

 ##BeagleBone Black: HDMI (Audio/Video) disabled:
 dtb=am335x-boneblack-emmc-overlay.dtb


 On Sat, Jul 16, 2016 at 3:13 PM, William Hermans  
 wrote:

> Robert. 
>
> You instructions here: 
> https://groups.google.com/forum/#!searchin/beagleboard/Robert$20Nelson$20r34%7Csort:date/beagleboard/l59Dx8ygxNg/GhdRzR7IDAAJ
>  
> do not work.
>
> I do not what to tell you other than I followed you instructions to 
> the "T" and . . .
>
> william@beaglebone:~$ lsmod |grep uio
> uio_pdrv_genirq 3661  0
> uio 8776  1 uio_pdrv_genirq
>
> william@beaglebone:~$ uname -r
> 4.4.14-ti-rt-r34
>
> william@beaglebone:~$ cat /etc/dogtag
> BeagleBoard.org Debian Image 2016-05-01
>
> william@beaglebone:~/dev/dtb-4.4-ti$ grep "#include" 
> src/arm/am335x-boneblack-emmc-overlay.dts
> #include "am33xx.dtsi"
> #include "am335x-bone-common.dtsi"
> #include "am33xx-overlay-edma-fix.dtsi"
> /* #include "am33xx-pruss-rproc.dtsi" */
> #include "am33xx-pruss-uio.dtsi"
>
>
>
> On Sat, Jul 16, 2016 at 10:22 AM, Robert Nelson  
> wrote:
>
>> On Jul 16, 2016 11:57 AM, "Joseph Heller"  
>> wrote:
>> >
>> > Hi William, thanks for the support, some input got me further at 
>> least. This is how far I got today: I now have the uio driver more or 
>> less 
>> enabled on 4.1.5-ti-rt-r10 via my DTS file: 
>>
>> I thought i was very explicit in my email, 4.4.x-ti r34 or later. For 
>> that specific kernel you are using, you'll be discovering the uoi patch 
>> in 
>> r34. 
>>
>> Regards,
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google 
>> Groups "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, 
>> send an email to beagleboard...@googlegroups.com.
>> To view this discussion on the web visit 
>> 

Re: [beagleboard] Microphone Bias Voltage Level

[ybeagle3]

>From a pin allocation prospectively, allocating the right McASP pins may 
introduce other problems (pin sharing, etc). The ADCs have dedicated analog 
pins to avoid this.

For basic ("telephony quality") audio, the ADCs are quite work able. Things 
you need to consider are -
- Signal conditioning (converting the mV range into a signal that fits 
0-1.8V). Biasing is pretty easy - a cap and a resistor should work with many 
mics.
- Noise filtering.
- Software
- The reference on the BBB is hard wired to 1.8V.

I have gone down this path and have it working with PocketSphinx. Highlights 
of the journey - 
- Opamps or single transistor AMPs do work but there is a lot of tuning needed 
keep a usable signal from the ADC. over a range of distances to the mic 
without having to do a lot of shouting or dealing with clipping.
- Using a single chip AGC/mic preamp does make things a lot easier to tune.
- The ADC is quite noisy.
- The output sample rate is 8KHz. There are different settings that can give 
you 8KHz on the ADC but they have different noise characteristic. The settings 
will have to be tuned to match the signal conditioning circuit. 
- Data output via a simple character driver. Original plan was to get this 
into ALSA but haven't found time for that yet. IIO is nice but that requires 
some kind of userland decoding for pocketsphinx. The character driver outputs 
match the 'file' input format for pocketsphinx.


On Thursday, July 14, 2016 19:16:30 John Syne wrote:
> You would be better off using an audio codec for this purpose.
> Unfortunately, the Audio Cape doesn’t bring out the microphone circuitry,
> but you could use a audio preamp and connect to the audio cape audio input.
> 
> Regards,
> John
> 
> > On Jul 14, 2016, at 3:26 PM, keerthana.manivan...@gmail.com wrote:
> > 
> > 
> > Hi there,
> > 
> > I'm looking to use an electret microphone with a beaglebone black for my
> > project. Can't I directly plug the mic into an analog pin and use the
> > data? Do I need a pre amplifier circuit kind of thing to use the mic with
> > a BBB?
> > 
> > 
> > On Tuesday, March 10, 2015 at 11:49:16 PM UTC-5, sns wrote:
> > Will USB headset with mic work for audio application that records sound
> > and playback on beaglebone with quality?Here is there is no need for
> > separate pre- amplifier or circuit that requires biasing mic voltage?
> > 
> > On Thu, Feb 26, 2015 at 2:53 PM, Zainab S.V  > > wrote: What about using microphone input from a headphone
> > for recording and using the headset for playback? Does it need any extra
> > circuitry?
> > 
> > On Tue, Feb 24, 2015 at 8:22 PM, Fredrik Olofsson  > > wrote: all the usb soundcards i've tried so far can don't
> > need biasing.  just solder an electret mic directly to a minijack and
> > connect it to the input of the usb soundcard.  though note that sound
> > quality varies.  some cards make a lot of noise (one logilink model even
> > was blinking a led when active and that interfered and could be heard in
> > the mic input signal.) terratec aureon dual usb is the best sounding card
> > i've found so far.  though i don't own an audio cape so i can't compare.
> > 
> > If i use usb audio interface instead of the cape, is there a need for
> > biasing ?

-- 
Hunyue Yau
http://www.hy-research.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7774869.YUJZmHkPKk%40acer0.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] beaglebone white doesn't work when powered from the barrel connector

[John Syne]

Clearly you have to load the power supply to get an accurate voltage 
measurement. You could use a purely resistive load for a current of about 100mA 
and that would give you an accurate voltage measurement. Using the formula R = 
V/I, select a resistor that would give you close to 100mA. Remember the power 
dissipated in the resistor must be considered so given P=VI, a 100mA load will 
dissipate 1/2 watt, so the resistor size is important. 

Now Gerald says the power supply needs to be 5V, but I think he is being overly 
restrictive here. The datasheet for the TPS65217C shows the AC input should be 
between 4.3V and 5.8V, so my way of thinking is 5.2V should be fine as long as 
there are no noisy pikes that cause the voltage to exceed 5.8V. However, Gerald 
is the original designer and he has set the input voltage parameters for a 
reason. 

Regards,
John




> On Jul 18, 2016, at 7:20 AM, scma...@gmail.com wrote:
> 
> first thanks for your reply.
> 
> i am measuring without the BB connected since i want to know if i am able to 
> provide the required voltage..Also if i am not mistaken the BB white has a 
> voltage regulator so there is no reason to count with the BB connected 
> because there will be a voltage drop if i supply more (but not too much). Am 
> i wrong?
> In any case i can give it a go and measure with the BB connected..
> But again..does anyone know what is the supposed voltage to be supplied?Is it 
> the one i mentioned in my previous post?(5V +/-.1 ? ) Cause as i have already 
> said it seems that my bb works when provided with 5.26V and not with 
> 5V..(hope i won't destroy the board..)
> 
> Thanks again
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/5f923dec-579c-4f6a-820c-f2f65fb5e26f%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/90823A15-F090-442C-9D3D-D867D5D498C5%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] beaglebone white doesn't work when powered from the barrel connector

[evilwulfie]

Measuring a power supply with no load will not give you a good reading.

On 7/18/2016 7:20 AM, scma...@gmail.com wrote:
> first thanks for your reply.
>
> i am measuring without the BB connected since i want to know if i am
> able to provide the required voltage..Also if i am not mistaken the BB
> white has a voltage regulator so there is no reason to count with the
> BB connected because there will be a voltage drop if i supply more
> (but not too much). Am i wrong?
> In any case i can give it a go and measure with the BB connected..
> But again..does anyone know what is the supposed voltage to be
> supplied?Is it the one i mentioned in my previous post?(5V +/-.1 ? )
> Cause as i have already said it seems that my bb works when provided
> with 5.26V and not with 5V..(hope i won't destroy the board..)
>
> Thanks again
> -- 
> 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
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/5f923dec-579c-4f6a-820c-f2f65fb5e26f%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8fd1981f-2589-1847-bf61-f534190c9b3f%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU IEP interrupt example

[Fred Frey]

Thanks a lot for this, friend. Can I ask where you sourced this 
information? The TRM is a little sparse on the topic of using the PRU as an 
ethernet controller, and I can't seem to find any other good sources.

On Friday, July 25, 2014 at 12:57:06 AM UTC-4, jsta...@gmail.com wrote:
>
> Full code at:  https://github.com/jstampfl/PruIEP_Int
>
> Also for example of using PRU IEP see:
>
>
> https://github.com/cdsteinkuehler/linuxcnc/blob/MachineKit-ubc/configs/ARM/PRU-Debugger/pruexample.p
>
> Here is the p code:
>
> //iepx.p   -  set up IEP interrupt on CMP0 hitting compare value.
> //toggles pin p9.31 -  attached to r30.t0 - mode 5 output
> //
> //Depends on call linux program to initialize the INTC 
> //
> .setcallreg r2.w0  //  Going to use r30
> .origin 0
> .entrypoint TB
> TB:
>set r30,r30, 0 //turn on 
>jmp ISET//this is the routine to setup
>
> TB1:
>ldi r17,0 // init loop counter
>call RSET // routine to clear & enable interrupts
>
> TB2:
>qbbc TB2,r31.t30 // spin here for interrupt
>xor r30,r30,1//toggle
>call RSET// clear, enable
>add r17,r17,1//loop counter
>qblt TB9,r17,50  //loop 50 times
>jmp TB2
>
>
> TB9://  exit point 
>mov r31,35  //trigger host interrupt for Linux
>HALT
>
> ISET: //  This section is to initialize the interrupts
>
> //INITIALIZE IEP INTERRUPTS
>
>mov r14,0xFF   //For CMP0, compare trigger
>sbco r14,c26,0x48,4
>mov r14,0x3// enable CMP0, and enable
>sbco r14,c26,0x40,4// counter reset on event
>mov r14,0x1
>sbco r14,c26,0x44,4// clear status for CMP0
>lbco r14,c26,0x4,4
>sbco r14,c26,0x4,4 // clear GLOBAL status, overflow
>mov r14,0x111  // enable IEP counter, inc 1
>sbco r14,c26,0,4
>
> //DONE WITH IEP SETUP
>
> //SETUP CHANNEL MAP
> //map SysEvent to Channel 0, leave 16 - 23 alone set by Linux
>mov r15,0x400//set up Channel map
>mov r14,0x09090909   // first map all unused events to
>sbco r14,c0,r15,4//  Channel 9
>mov r15,0x408
>sbco r14,c0,r15,4
>mov r15,0x40C// skiping offsets 410 & 414, they
>sbco r14,c0,r15,4// were set by the C program via prussdrv
>mov r18,0x43C// end for loop
>mov r15,0x414// start -4 for loop
> TB43:
>add r15,r15,4
>sbco r14,c0,r15,4
>qbgt TB43,r15,r18
>mov r14,0x00090909   // map SysEvt 7 to channel 0
>mov r15,0x404// now do 404, which has the
>sbco r14,c0,r15,4// entries for 4,5,6,7
>
> //   Done with Channel Map, Host Interrupt Map now
>// Host Interrupt 0 - 3 were setup by Linux   
>
>mov r14,0x09090909   // map channels 4,5,6,7 to Host Int 9 
>mov r15,0x804
>sbco r14,c0,r15,4
>mov r14,0x0909   // map channel 8 & 9 to Host Int 9
>mov r15,0x808
>sbco r14,c0,r15,4
>
>ldi r15, 0x24 //clear all events
>call ALLEVT
>
>
>ldi r15,0x28  // enable all events
>call ALLEVT
>jmp TB1
>
> RSET:  // Routine to clear & enable system events, also host interrupts
>mov r24,r2   // Save return address
> // so can call ALLEVT
>lbco r14,c26,0x4,4   // clear GLOBAL_STATUS
>sbco r14,c26,0x4,4
>lbco r14,c26,0x44,4  // clear CMP_STATUS
>sbco r14,c26,0x44,4
>lbco r14,c26,0x44,4
>mov r15,0x24 //  to clear system event
>call ALLEVT
>mov r15,0x28 //  to enable system event
>call ALLEVT
>
>mov r2,r24// restore return address
>ret
>
> ALLEVT:  //Insert the system envent in the proper INTC register
>  // register r15 must have the register offset
>  // will only work with registers that take the event number
>  // if you want to handle multiple events, just add 
>  //   ldi r14,"sys event no."
>  //   sbco r14, c0 ,r15,4
>
>ldi r14,0x7
>sbco r14, c0 ,r15,4
>ret
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8fa31a7b-9d57-4caf-925a-877c1d059fe0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] beaglebone white doesn't work when powered from the barrel connector

[Gerald Coley]

5V

On Mon, Jul 18, 2016 at 9:20 AM,  wrote:

> first thanks for your reply.
>
> i am measuring without the BB connected since i want to know if i am able
> to provide the required voltage..Also if i am not mistaken the BB white has
> a voltage regulator so there is no reason to count with the BB connected
> because there will be a voltage drop if i supply more (but not too much).
> Am i wrong?
> In any case i can give it a go and measure with the BB connected..
> But again..does anyone know what is the supposed voltage to be supplied?Is
> it the one i mentioned in my previous post?(5V +/-.1 ? ) Cause as i have
> already said it seems that my bb works when provided with 5.26V and not
> with 5V..(hope i won't destroy the board..)
>
> Thanks again
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/5f923dec-579c-4f6a-820c-f2f65fb5e26f%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
gcol...@emprodesign.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAHK_S%2Bf6bhffjwPX%3DrTye-hHfbvB0jRAp%2Bes9a_z%3DwhNVE8K%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] beaglebone white doesn't work when powered from the barrel connector

[scmanop]

first thanks for your reply.

i am measuring without the BB connected since i want to know if i am able 
to provide the required voltage..Also if i am not mistaken the BB white has 
a voltage regulator so there is no reason to count with the BB connected 
because there will be a voltage drop if i supply more (but not too much). 
Am i wrong?
In any case i can give it a go and measure with the BB connected..
But again..does anyone know what is the supposed voltage to be supplied?Is 
it the one i mentioned in my previous post?(5V +/-.1 ? ) Cause as i have 
already said it seems that my bb works when provided with 5.26V and not 
with 5V..(hope i won't destroy the board..)

Thanks again

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/5f923dec-579c-4f6a-820c-f2f65fb5e26f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Python GPIO Error

[Kelechi Ikegwu]

Hi,

Can you please not include me in future messages.

Thanks,
KC

On Sun, Jul 17, 2016 at 7:45 PM, Peter Lawler  wrote:

>
>
> On 14/07/16 22:40, msriram1...@gmail.com wrote:
>
>> While I try to implement it using the Beaglebone Black I am getting the
>> following error.
>> "Traceback (most recent call last):
>>File "ult.py", line 5, in 
>>  import BBIO.GPIO as GPIO# Import GPIO library
>> ImportError: No module named BBIO.GPIO"
>>
>> I need help.
>>
>>
> You do not say whether you have done this and are getting the error, but
> have you installed the BBIO python library?
>
>
> https://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/overview
>
> Cheers,
>
> Pete.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%2BOpcGXhsAZfqyeFca-v2O0dJyU5TQxaMNBCFY8WnTdtJiUtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] problems with static ip address on eth0

[bart . van . thielen2]

I downloaded the newest image 
(bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb) and I am now trying to 
configure the eth0 to be able to use the BBB on our network.
I can connect to it over USB link.
I changed the /etc/network/interfaces file to the content shown below, but 
after reboot the BBB gets address 169.254.129.50 (an address assigned after 
failed DHCP assignment attempt?)
After some searching, I have the impression that this is because the usb0 
link uses dhcp, and the BBB is also using this on eth0, although I tell it 
to use 'static' in the interfaces file.
If I restart the eth0 link using 'ifdown eth0' and 'ifup eth0' then it does 
get the right ip address, and I can ssh to it over the eth0 interface. But 
this is not really a good solution, and I have the impression that some 
other network settings, (dns, ...) are still misconfigured.

I tried deleting the usb0 link from /etc/interfaces, and disabling the 
/opt/scripts/boot/autoconfigure_usb0.sh script, but that didn't help either.
Is there any way I can force it to use a static IP address on eth0?

Thanks for any help

Bart


root@beaglebone:/etc/network# cat interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
dns-nameservers 8.8.8.8 8.8.4.4
address 30.0.0.39
netmask 255.0.0.0
network 30.0.0.0
gateway 30.0.0.1
# Example to keep MAC address between reboots
#hwaddress ether DE:AD:BE:EF:CA:FE

# The secondary network interface
#auto eth1
#iface eth1 inet dhcp

# WiFi use: -> connmanctl

# Ethernet/RNDIS gadget (g_ether)
# Used by: /opt/scripts/boot/autoconfigure_usb0.sh
iface usb0 inet static
address 192.168.7.2
netmask 255.255.255.252
network 192.168.7.0
gateway 192.168.7.1

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/50b0a595-e10a-435a-bce1-fb57aafab120%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BeagleBone Green Wireless HDMI Cape help.

[sahajsarup]

Hi,
New to Beaglebone here, i cannot get the hdmi cape for beagle bone green 
wireless working, 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/2188e176-f09d-42f8-ad5b-40abb6ecd2f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Change BeagleBone Green Wireless SSID

[VicS]

Been working with the SoftAp0 that comes with the BBGW from Seeed. Haven't 
found a way to change the BeagleBone SSID that shows up to something 
simple like 'MoonBeam'. Can anyone please suggest a way? Needed for a 
project that expects a simple known SSID in the desert.

Also found that the BeagleBone SSID mysteriously disappears after a 
while - doesn't show up in the SSID scan on many devices including the 
iPhone. What causes this?

VicS


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/167d7d29-cf91-4953-a05c-fcb24a67db9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] beablebone black is enumerated as ttyACM0 over usb power cable

[pointersaccurate]

My setup :

Ubuntu 14.04 LTS dual boot with windows 7.

uname -a

Linux nikhil 4.2.0-42-generic #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC 
2016 x86_64 x86_64 x86_64 GNU/Linux

I have a beaglebone black board, connected via a usb cable to power it up, one 
usb to uart cable. 
Few days back I was able to see the usb to uart as /ttyUSB0, now it is not 
enumerated.
I checked serial header on beaglebone and it was having 3.3 volts. I checked 
the supply from usb to uart cable and it is 5 volts
 (However I am not connecting the red cable). 
How can I know what have gone bad? Should I buy a new usb to uart cable?


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7f304840-4565-4d15-b7c2-16a2224857c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] How to change SSID(SoftAp0) of BBGW

[best . se04]

Do you know how to change SSID to be other name?
Currently It shows BeagleBoneXX, I have tried to find the way to change 
it but not found. :( 

Could you guy please help me?
Thank in advance.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c12558a8-c41d-4727-9c7d-42c610193e82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] How does beagle bone boot up ?

[antonius . riko]

Guys,

I'm wondering how can beagle bone boot up ?
What JTAG should I use for this TI processor ? I'm using Beaglebone black..

and I'm sure it's reading the flash memory before call embedded linux in SD 
card...
Where can I download the core source code ?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6b0e928c-7c69-4bf4-a6e3-4ff78aaf9231%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Building a cross compilation toolchain

[fernando26recor]

I had the exact same problem and this post saved me a lot of time

thanks guys

On Sunday, December 22, 2013 at 11:53:26 AM UTC-8, Robert Ianovich wrote:
>
> Hello,
>
> I have some problems following this instructions:
> http://wind.cs.purdue.edu/doc/crosscompile.html
>
> If I run MACHINE=beaglebone ./oebb.sh bitbake virtual/kernel as root the 
> folowing erro appears:
>
> rocessing openembedded-core: Current branch angstrom-staging-yocto1.4 is 
> up to date.
> Using environment-angstrom-v2013.06 to setup needed variables. It is 
> recommended to do '. environment-angstrom-v2013.06' and run 'bitbake 
> something' without using ./oebb.sh as wrapper
> Executing: MACHINE=beaglebone bitbake virtual/kernel
> Pseudo is not present but is required, building this first before the main 
> build
> ERROR:  OE-core's config sanity checker detected a potential 
> misconfiguration.
> Either fix the cause of this error or at your own risk disable the 
> checker (see sanity.conf).
> Following is the list of potential problems / advisories:
>
> Do not use Bitbake as root.
> ERROR: Execution of event handler 'check_sanity_eventhandler' failed
>
> Now changing to some other user, another error:
>
> Executing: MACHINE=beaglebone bitbake virtual/kernel
> Pseudo is not present but is required, building this first before the main 
> build
> ERROR: Error parsing configuration files
> Traceback (most recent call last):
>   File "/edi/setup-scripts/sources/bitbake/lib/bb/cooker.py", line 201, in 
> BBCooker.loadConfigurationData():
>  self.parseConfigurationFiles(self.configuration.prefile,
> > self.configuration.postfile)
>  except SyntaxError:
>   File "/edi/setup-scripts/sources/bitbake/lib/bb/cooker.py", line 988, in 
> BBCooker.parseConfigurationFiles(prefiles=[], postfiles=[]):
>  if data.getVar("BB_WORKERCONTEXT", False) is None:
> >bb.fetch.fetcher_init(data)
>  bb.codeparser.parser_cache_init(data)
>   File "/edi/setup-scripts/sources/bitbake/lib/bb/fetch2/__init__.py", 
> line 465, in fetcher_init(d=):
>  pass
> >revs.clear()
>  else:
>   File "/edi/setup-scripts/sources/bitbake/lib/bb/persist_data.py", line 
> 147, in SQLTable.clear():
>  def clear(self):
> >self._execute("DELETE FROM %s;" % self.table)
>  
>   File "/edi/setup-scripts/sources/bitbake/lib/bb/persist_data.py", line 
> 66, in SQLTable._execute(*query=('DELETE FROM BB_URI_HEADREVS;',)):
>  try:
> >return self.cursor.execute(*query)
>  except sqlite3.OperationalError as exc:
> OperationalError: attempt to write a readonly database
>
> Any idea ? i work on Linux Mint 16 (kind of ubuntu)
> Thanks in advance,
>
>
>
>
>
>
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0fc9e82a-f460-4d62-af87-2baee290f7dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Beaglebone black does not enumerate as ttyUSB0 in Ubuntu 14.04

[pointersaccurate]

My setup :

Ubuntu 14.04 LTS dual boot with windows 7.


I connected usb power cable which is a 5 volt supply. I also connected a 
usb to uart serial cable, and was able to see this to be as ttyUSB0 in 
ubuntu few days back.

After I did not see this ttyUSB0 only ttyACM0 (which I think is from usb 
power cable).


I have one doubt what is overcurrent?


I checked what power usb to uart cable is getting and it was 5 volts. I 
checked the voltage on serial header of beaglebone and it was 3.3 volts. 
How ever I am not connecting red cable on beaglebone black. 


I am unable to understand what exactly is the problem?


Please respond anything related to it.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/45108b57-c331-471e-a36a-396eb844fbf9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: How to use PRU constants table?

[John Syne]

The support package is just examples of how to use RemoteProc/RPMSG. Remember 
to use V4.02 for the V4.1 Linux Kernel and V5 for the V4.4 Linux kernel. The 
V4.02 uses mailbox events and the V5 uses interrupt events. If you want ARM 
sample code which interacts with the PRU firmware, look in the Linux source 
code /samples/rpmsg. 

Here is how to use the PRU support package:

http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs 



Regards,
John




> On Jul 17, 2016, at 10:33 PM, Karl Karpfen  wrote:
> 
> Thanks, I found it in the PRU support package. But I wonder if this really 
> saves some time/code...
> 
> Am Freitag, 15. Juli 2016 20:59:12 UTC+2 schrieb Greg:
> There is an example in the PRU support package:
> 
> http://git.ti.com/pru-software-support-package 
> 
> 
> Look in the examples folder for am335x.
> 
> Regards,
> Greg
> 
> 
> On Friday, July 15, 2016 at 3:41:06 AM UTC-5, Karl Karpfen wrote:
> Hi,
> 
> the AM335x TRM specifies a constants table for PRU which can be used for 
> easier access of memory addresses. As an example: for I2C1 registers which 
> originally use base-address 0x4802A000 a constant 2 is defined.
> 
> What I do not understand: how can one use these constants? How does the 
> mapping from a constant to a base-address work where I have to add an offset 
> in order to access desired registers?
> 
> Or is this an assembler-thingy only which can't be used out of PRU-C-Software?
> 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/3a31db16-a078-476f-928f-e1f50233c075%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/C1B97512-E121-41AC-863B-E10005DF54A5%40gmail.com.
For more options, visit https://groups.google.com/d/optout.