[beagleboard] What's in the iot build?

So, I leave this project for half a year (maybe more), only to come back to a slightly new arrangement of builds, including an "iot" build. But there's no text on the page describing what's in the iot build. That's the kind of omission that makes it take so much longer to get anywhere with a

Re: [beagleboard] Re: PWM Pin Error on Boot

One more thing, you may want to look at /driver/pinctrl/pinctrl-single.c as this is where the pinmux gets set.You could also use dynamic tracing to help find the responsible routine. Look in /Documentation/dynamic-debug-howto.txt. Probably a little bit of trial and error will be needed to

Re: [beagleboard] Re: PWM Pin Error on Boot

Thanks for the reply John. I'm pretty new to modifying kernel modules and I haven't worked with u-boot at all. I'm not sure at the moment when the GPIO is modified but I think it happens whenever the system resets, most likely on startup. Should I try a kernel dump right after I boot?

[beagleboard] WLAN0 and ETH0

I've got a BBB running Debian 3.8. My WIFI dongle is a TPLink TL-WN722N (one of the recognized/working dongles). I'm running into the following issue. When I have eth0 connected, my wlan0 connection works great. When I remove my eth0 connection, my wlan0 connection no longer works. By no

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

Hi TJF, thank you very much for your reply. You were too fast, I was deleting the post right now. My mistake was to build only the FreeBasic library and not the one in the folder `c_wrapper` Sorry for waste your time. I have another question: I'm trying to read from the ADC the sound from a

Re: [beagleboard] Re: PWM Pin Error on Boot

Well, that depends on how skilled you are at modifying u-boot and the linux kernel? In each case, modify the code that toggles the GPIO pin by printing text to the console when the GPIO you want is modified. You could always issue a kernel dump when that GPIO is modified, which will list the

Re: [beagleboard] Using UART with bonescript

On Wed, Mar 30, 2016 at 5:05 AM, dorica wrote: > Hi. > I have a BBB rev C, with Debian 8.3, kernel 4.1.15-ti-rt-r40. I am logged in > as a regular user (not root). I loaded BB-UART1 overlay, to activate UART1 > (tried to load cape-universal first, then apply BB-UART1, but

Re: [beagleboard] Using UART with bonescript

sudo apt-get install bonescript-beta fails, unable to locate package on fresh 2016-03-27 lxqt SD card install. I'd like to give it a try along with node-red (which seems installed and running by default on boot with this image, which is IMHO nice). Actually, I just started the cloud9 IDE and

[beagleboard] Re: PWM Pin Error on Boot

Hey everyone I'm still stuck as to why my beaglebone keeps changing the polarity to 1 on boot. I can go in and manually change it but it always resets after reboot. Should I maybe write a start up script to force the polarity to 0? I'd rather find the root cause rather than a hack but at

Re: [beagleboard] Difference between Beaglebone Console and IOT images?

On Wed, Mar 30, 2016 at 2:09 PM, Wally Bkg wrote: > I'm curious as to difference between the Beaglebone Console and IOT images > and the reason(s) for choosing one over the other. > > Even on my BBW I prefer an lxde or lxqt image as I like to be able to do ssh > -X for

[beagleboard] Difference between Beaglebone Console and IOT images?

I'm curious as to difference between the Beaglebone Console and IOT images and the reason(s) for choosing one over the other. Even on my BBW I prefer an lxde or lxqt image as I like to be able to do ssh -X for things like gedit or geany from time to time, and I like the easy back-up and/or

Re: [beagleboard] Re: Arch linux and issues loading device tree overlay at boot via uEnv.txt

On Wed, Mar 30, 2016 at 1:02 PM, Axe wrote: > > RobertCNelson: I am not using initramfs > > After some experimentation I found a sort-of solution. > > I removed the call to bone_capemgr from uEnv.txt, then decompiled > /boot/dtbs/am335x-boneblack.dtb with > > dtc -I dtb -O

[beagleboard] Re: Arch linux and issues loading device tree overlay at boot via uEnv.txt

RobertCNelson: I am not using initramfs After some experimentation I found a sort-of solution. I removed the call to bone_capemgr from uEnv.txt, then decompiled /boot/dtbs/am335x-boneblack.dtb with dtc -I dtb -O dts am335x-boneblack.dtb > am335x-boneblack.dts then inserted the content of my

Re: [beagleboard] Force a PRU output's default state to LOW as Device Tree loads

Two questions with that method: 1. I can clearly see how gpio-hog works to define pins that are going to be used as GPIOs. *Is gpio-hog applicable to pins that need to get their MUX switched over to be used as PRU pins ?* 2. One of the tests I've done was delaying loading the

Re: [beagleboard] Re: How to read PWM in BBB GPIO....?

Am Mittwoch, 30. März 2016 17:34:58 UTC+2 schrieb Alex: > > So to do that we need to put the Pin PR1_ECAP0_ECAP_CAPIN_APWM_O > in input mode. > > Where can we find the source code of the libpruio doing that in the pru ? > libpruio doesn't use PR1_ECAP0_ECAP_CAPIN_APWM_O pin configuration.

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

Hi Andrea! It compiles OK, but the linker doesn't find the symbols (= doesn't find the binary libpruio.so). Where did you place the new binary? It should work when you override the original binary (ie. in /usr/local/lib). Otherwise you have to update the linker cache first: sudo ldconfig Or

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

Hi TJF, I'm trying to solve the bug as you described to niro some posts ahead. After I've followed the instruction on the library site, I've: cd pruio/ vim pruio_adc.bas (modify buggy lines) ./make.sh ./build.sh After that a file named `libpruio.so` appear in the current directory The problem is

Re: [beagleboard] Re: How to read PWM in BBB GPIO....?

So to do that we need to put the Pin PR1_ECAP0_ECAP_CAPIN_APWM_O in input mode. Where can we find the source code of the libpruio doing that in the pru ? Le mer. 30 mars 2016 à 17:09, TJF a écrit : > You don't need GPIOs. Instead analyse the pulse train by hardware.

Re: [beagleboard] Force a PRU output's default state to LOW as Device Tree loads

On Wed, Mar 30, 2016 at 10:27 AM, Phil Mills wrote: > Board spins eat up weeks of project - software / firmware changes are > "free". ;-) > > ...so the powers that be would rather see this solved at the Beaglebone > rather than on our outboard hardware. And that's kind of

Re: [beagleboard] Force a PRU output's default state to LOW as Device Tree loads

Board spins eat up weeks of project - software / firmware changes are "free". ;-) ...so the powers that be would rather see this solved at the Beaglebone rather than on our outboard hardware. And that's kind of a legitimate request, too - nobody in their right mind would design a system

Re: [beagleboard] Force a PRU output's default state to LOW as Device Tree loads

Probably your only solution is a hardware solution. buffer the PRU lines with a tristate buffer and enable it when you want it enabled. On 3/30/2016 8:00 AM, Phil Mills wrote: > I'm working with a Beaglebone Black to do some signal acquisition > using a laser as a light source. > > The

[beagleboard] Re: How to read PWM in BBB GPIO....?

You don't need GPIOs. Instead analyse the pulse train by hardware. The eCAP modules in the PWMSS subsystems are designed for that purpose. The simplest (and most powerful) solution is to use libpruio . Check out the example pwm_cap

[beagleboard] Force a PRU output's default state to LOW as Device Tree loads

I'm working with a Beaglebone Black to do some signal acquisition using a laser as a light source. The sampling/acquisition system is driven through the PRU since I need pretty tight timing - including pulsing a laser to illuminate a sample. A problem that we just noticed is that as soon as I

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

Hi TJF, I've the same problem as Niro. So I've modified the file you talked about. I also follow the instructions on your site to rebuild `libpruio.so`: cd pruio vim pruio_adc.bas (edit buggy lines) ./make.sh ./build.sh After the build command a file named `libpruio.so` appear in the current

[beagleboard] Re: Beaglebone Black Ubuntu playing Music

Thanks a lot for sharing. Pretty useful. Audio cape 'Rev B' was not available and I had to buy the old 'REV A' and manged to work the 'audio out working' (have't tested the mic yet). Best Regards, Ramakanth On Sunday, November 1, 2015 at 8:24:00 PM UTC, man...@unlv.nevada.edu wrote: > >

Re: [beagleboard] Using UART with bonescript

For the 4.1 kernel, you need the beta version of BoneScript to use the pinmux helpers it understands. I believe the package is: apt-get install bonescript-beta > On Mar 30, 2016, at 5:05 AM, dorica wrote: > > Hi. > I have a BBB rev C, with Debian 8.3, kernel

[beagleboard] Using UART with bonescript

Hi. I have a BBB rev C, with Debian 8.3, kernel 4.1.15-ti-rt-r40. I am logged in as a regular user (not root). I loaded BB-UART1 overlay, to activate UART1 (tried to load cape-universal first, then apply BB-UART1, but could not do it both, so I have settled to BB-UART1). I have installed

Re: [beagleboard] BBB/G prices constantly rising

Ah...no...you are right, I forgot that there are some people playing stupid games with the currencies... 2016-03-29 16:15 GMT+02:00 Gerald Coley : > I was going to say that, but I assumed that was obvious and had already > been factored in. > > Gerald > > > On Tue, Mar