Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

On Mon, Feb 6, 2017 at 11:00 AM, wrote: > I got the solutio (i think.. hehe) > If you're happy with the code you've got, who am I to argue about it ? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are

Re: [beagleboard] Re: Video image shifts right randomly

On Mon, Feb 6, 2017 at 1:52 PM, William Hermans wrote: >> >> Something I noticed is that if I pipe /dev/urandom to /dev/fb0, I get all the random colors, even in the left blank area when the image is shifted. Then I started our app and the top left 10 or so pixels remained the

Re: [beagleboard] Video image shifts right randomly

On Mon, Feb 6, 2017 at 3:09 PM, Brett wrote: > I am using 2014.01. Do we know what version this bug was introduced with? Well that bug has always been there, it was just fixed in v2017.01, something worth to try. Regards, -- Robert Nelson https://rcn-ee.com/ -- For

Re: [beagleboard] Video image shifts right randomly

I am using 2014.01. Do we know what version this bug was introduced with? On Monday, February 6, 2017 at 1:58:47 PM UTC-7, RobertCNelson wrote: > > On Mon, Feb 6, 2017 at 12:52 PM, Brett > wrote: > > Hey guys, our product based on the beaglebone black is experiencing an

Re: [beagleboard] Re: No LED light, My BBB perhaps died while running a PocketNC machine

Thanks all for great posts. Tomorrow I will start by cleaning the machine from all potential leftover aluminium chips from previous milling carefully. I believe that this is the most promising lead so far, a short circuit in a connector somewhere. I will keep you posted here of the result. --

Re: [beagleboard] Video image shifts right randomly

On Mon, Feb 6, 2017 at 12:52 PM, Brett wrote: > Hey guys, our product based on the beaglebone black is experiencing an issue > with the video image shifting to the right randomly. This usually happens no > sooner than 15mins after our application starts(sometimes it

Re: [beagleboard] Re: Video image shifts right randomly

> > Something I noticed is that if I pipe /dev/urandom to /dev/fb0, I get all > the random colors, even in the left blank area when the image is shifted. > Then I started our app and the top left 10 or so pixels remained the random > colors. If I then using dd fill /dev/fb0 with zero from

Re: [beagleboard] Ubuntu supporting BBBW's onboard Wifi

Hi Robert, Your new Ubuntu image does include connman. However connmanctl command "scan wifi" reports "Error /net/connman/technology/wifi: No carrier". Running iw and ifconfig shows the wifi is running as an access point - which appears to be the default BBBW startup configuration. It

[beagleboard] Re: Video image shifts right randomly

I forgot to mention that I am setting the resolution via kernel command line "video=HDMI-A-1:1024x768@60". The monitor settings do report the same resolution. On Monday, February 6, 2017 at 12:59:19 PM UTC-7, Brett wrote: > > When in the shifted state I have tried: > > >- Restarting our

[beagleboard] Re: Video image shifts right randomly

When in the shifted state I have tried: - Restarting our application - remains shifted, more reason to think it may not be something our app is doing - Killing our application then issuing "/etc/init.d/rc.pvr stop" followed by "/etc/init.d/rc.pvr start" - this had no

Re: [beagleboard] bone_capemgr.disable_partno=

On Mon, Feb 6, 2017 at 11:53 AM, wrote: > Hi all, > > tldr: is there a reference guide somewhere which lists all valid suffixes > for the command: bone_capemgr.disable_partno= > > Longer version: > I'm trying to get a custom cape (not my design) working on my BBBW. > The

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

I got the solutio (i think.. hehe) /*file doiscs.c Compile by: `gcc -Wall -o doiscs doiscs.c -lpruio` */ #include "stdio.h" #include "unistd.h" #include "../c_wrapper/pruio.h" #include "time.h" int main(int argc, char **argv) { float n[256]; float v1[128]; float

[beagleboard] I2C on beaglebone using Cloud9

Im new in BBBW, cloud9 and also in python language like 8days.I don't know where to start. Anyone can help me please. I want to create a project that uses a 2 I2Cs and a digital sensor like VEML6070, Si1145 and DHT22 on my BBBW. please share your codes. :( -- For more options, visit

[beagleboard] bone_capemgr.disable_partno=

Hi all, tldr: is there a reference guide somewhere which lists all valid suffixes for the command: bone_capemgr.disable_partno= Longer version: I'm trying to get a custom cape (not my design) working on my BBBW. The cape works with a plain old BBB, but has some challenges for the Wireless.

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

Or better yet, get rid of the second loop entirely, and just print the values as you receive them. However, printf() *is* a system all that would definitely slow down your ADC read speeds. Unless you pipe the output of the application to a file. Which would not be healthy for the emmc, or sdcard

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

Thinking about how to "throttle" reading from the ADC to get correct values. A little more. One way you could potentially deal with that situation could be to change both loops to a while() loop, and only increment your loop index value if the ADC index value is greater than 0. Or maybe test if

Re: [beagleboard] Configuration GPIO during Linux start up

On Mon, Feb 6, 2017 at 9:49 AM, Shimon Filtzer wrote: > Hello, guys! > For my application I need, that pin P8-13(GPIO23), will get output high > level as soon as possible. As I understand, I need to change both uboot and > kernel. (is it correct?) > But I can not find some

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

On Mon, Feb 6, 2017 at 9:12 AM, Rodrigo Mesquita < mesquita.rodrig...@gmail.com> wrote: > Mr, Willians, thanks for your answer. > > According to the lipruio's documentation, the variable io->DRam[0] > contains the index of the last ADC data read. > > About the part: > > do{ > . . . >

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

thank you so much for the answer, Mr. William. According do the documentation of the libpruio, the variable io->DRam[0] stores the index of the last data read. This data, is stored in the vector io->Adc->Value[]. I Just want 128 samples of each chanel. In fact, I completely agree with you:

[beagleboard] Configuration GPIO during Linux start up

Hello, guys! For my application I need, that pin P8-13(GPIO23), will get output high level as soon as possible. As I understand, I need to change both uboot and kernel. (is it correct?) But I can not find some manual for these changes. Any help? Thank you! -- For more options, visit

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

On Mon, Feb 6, 2017 at 4:21 AM, wrote: > Hello Mr. TJF > > First of All, thank you so much for providing support on real-time tasks > using a low cost plataform. > I'm trying to apply the libary "libpruio" to make a system for energy > meansurement using the

[beagleboard] What pins do SET PWM[] output to in PRU speak?

Hello! I've watched through the two "Hands-On BeagleBone Black Tutorial" videos and I've gotten the DIO working with PRU speak, but I can't figure out where the pin "SET PWM[0], 50" is outputting to. The "DIO[0], 1" works just fine but "PWM[0], 50" doesn't do anything. I'm using the image

Re: [beagleboard] issue booting from eMMC aftre downgrading from kernel 4.9.6-bone4 to 4.1.21-bone-rt-r20

On Mon, Feb 6, 2017 at 8:19 AM, malkowki wrote: > Hi fellows, > > I am having issue booting from eMMC after downgrading from Kernel > 4.9.6-bone4 to 4.1.21-bone-rt-r20. > I am using a beaglebone black REV C with Debian 8 distibution, I had trouble > communicating via USB

[beagleboard] issue booting from eMMC aftre downgrading from kernel 4.9.6-bone4 to 4.1.21-bone-rt-r20

Hi fellows, I am having issue booting from eMMC after downgrading from Kernel 4.9.6-bone4 to 4.1.21-bone-rt-r20. I am using a beaglebone black REV C with Debian 8 distibution, I had trouble communicating via USB LAN under address 192.168.7.2 then I decided to downgrade to older version that I

Re: [beagleboard] 4.3" Display Cape on BBB

Are you using the 4D systems cape? I have the 4.3 and 7 inch versions of these on several BBB with no issues. On Mon, Feb 6, 2017, 8:10 AM wrote: > Hi! > > Has anybody managed to get a 4.3" Display Cape working on BBB with a > recent Debian image (e.g. 8.6)? > I have

[beagleboard] Re: Beaglebone Novatel USB760 Freeze

http://sreenu.searchbuk.com/ On Monday, April 11, 2016 at 7:50:51 PM UTC+5:30, Bryan Wilcutt wrote: > > I've been running tests on a BBB using a Novatel USB760 cellular modem. > The test I am running is rather simple-- just pinging the modem for it's > RSSI settings so that I can modify some

[beagleboard] 4.3" Display Cape on BBB

Hi! Has anybody managed to get a 4.3" Display Cape working on BBB with a recent Debian image (e.g. 8.6)? I have uncommented dtb=am335x-boneblack-emmc-overlay.dtb in uEnv.txt as per the instructions at https://github.com/beagleboard/bb.org-overlays, which sort of gets the display to work,

[beagleboard] Understanding boot process of beaglebone black.

Hi All, I want to understand the boot process of beaglebone black. I googled and got an article in "Beyond logic" there is explained boot sequence as follows. By default, the ROM in the Sitara AM3359 will boot from the MMC1 interface first (the onboard eMMC), followed by MMC0 (MicroSD), UART0

[beagleboard] GPIO Pins are not working

Hi Everyone, I am using a beagleboard-xm rev A3, I am trying to access the gpio pins of expansion connector via /sys/class/gpio/gpio130 but when i am setting the direction as out and value as 1 then i am not getting any output through that pin. I tried to access gpio4 the user switch but when

[beagleboard] Buildroot support for BBBWireless

Hi, I am trying to create a minimal rootfs for BBBWireless. I see that buildroot does support BBB and cah generate a very minimal rootfs for it. But I could not find the support for BBBWireless in buildroot. The BBB image from buildroot works on BBBW, but , as expected, the WiFi doesn't work.

Re: [beagleboard] connecting to 192.168.7.2 failing after updating to kernel 4.1.36-bone-rt-r24

Hi Robert, after having compile the image 4.9.6-bone4 I still cannot ssh to 192.168.1.1 so I have tried to switch back to 4.1.21-bone-rt-r20 by modifying the uEnv.txt and reboot then I get: Checking if uname_r is set in /boot/uEnv.txt... gpio: pin 56 (gpio 56) value is 1 Running uname_boot

[beagleboard] Re: connecting to 192.168.7.2 failing after updating to kernel 4.1.36-bone-rt-r24

Le mercredi 21 décembre 2016 19:05:57 UTC+1, malkowki a écrit : > > Dear, > > after updating my beaglebone REVC board from kernel 4.1.21-bone-rt-r20 to > 4.1.36-bone-rt-r24 using Robert Nelson script , I am having issue > connecting from ssh Putty Host Window7 PC to the board via USB to >