Re: [beagleboard] bbb Internal ADC configuration settings?

> On Mar 18, 2016, at 1:06 PM, Audrey wrote: > > Hm. > > Sorry, but unfortunately I'm still quite a bit lost. What should I be doing > to dev/iio:device0 (open?) in order to do the following: > echo 1 > in_voltage0_en >From memory, echo 1 >

Re: [beagleboard] Debugging with beaglebone black

Oh, and one more thing, CCSV4 won’t work with the V4 kernels because of data structure changes in the kernel. Regards, John > On Mar 18, 2016, at 2:51 PM, John Syne <john3...@gmail.com> wrote: > > CCSV4 was partially aware, but CCSV5 and CCSV6 are not. > > http://p

Re: [beagleboard] How to initialize DMA channels of SPI master

Look at how this is done in drivers/mmc/host/mmc_spi.c Regards, John > On Mar 18, 2016, at 6:53 AM, 'ilikepepsi' via BeagleBoard > wrote: > > Hi, > > I'm developing a kernel module that is supposed to communicate with a TI > ADS1274 ADC via SPI. So far I

Re: [beagleboard] Debugging with beaglebone black

To debug kernel modules with JTAG, you have to have a debugger which is kernel aware like Lauterbach. If you don’t want to use JTAG, then use printk or dev-dbg, dev-err, etc. You can also use ftrace, which requires you to build your own kernel and add support for the various ftrace features.

Re: [beagleboard] bbb Internal ADC configuration settings?

he one-shot directories, which are > completely separate from the continuous mode directory structure. > > On Fri, Mar 18, 2016 at 1:46 PM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > What is your kernel version? > > Regards, > John >

Re: [beagleboard] bbb Internal ADC configuration settings?

one-shot directories, which are > completely separate from the continuous mode directory structure. > > On Fri, Mar 18, 2016 at 1:46 PM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > What is your kernel version? > > Regards, > John > >

Re: [beagleboard] BBG fried. Hint needed to undestand why.

Whenever you have separate systems that may power up at different times or the I/O configuration is unpredictable, then you should always use tristate buffers so that you don’t drive I/O until it is ready. Also, some GPIO are also used for boot configuration and these pins should not be driven

Re: [beagleboard] How to setup socket-based pipe in Beaglebone Black?

ct. In the past, I've been playing along with your little game, but I'm > telling you right here and now that is going to stop. I will no longer > respond to anything you have to say on this forum in the future. > > On Fri, Mar 11, 2016 at 2:18 PM, John Syne <john3...@gmail.com

Re: [beagleboard] How to setup socket-based pipe in Beaglebone Black?

> On Mar 11, 2016, at 10:41 AM, William Hermans wrote: > > Dhanesh, netcat is pretty much a general purpose networking tool. It can take > stdin as input via using the pipe symbol at the command line, as well as pipe > that input on the opposite end to stdout. > > So as an

Re: [beagleboard] BBG fried. Hint needed to undestand why.

Use a tristate buffer between the BBB TX and the BBB/BBG RX. Use a 2 input AND gate with the output connected to the buffer enable and a GPIO_EN from the BBB RX board connected to on of the AND gate input and a GPIO_EN from the BBG RX board to the other AND gate input. When both BBB/BBG board

Re: [beagleboard] -bash: /sys/class/gpio/export: Permission denied

https://www.kernel.org/doc/Documentation/gpio/sysfs.txt Regards, John > On Mar 11, 2016, at 2:54 AM, epi...@gmail.com wrote: > > Hello, i am new at linux.. I use bbb with debian and usb remote desktop > I try this command on

Re: [beagleboard] bbb Internal ADC configuration settings?

face. It surely seems like you know what the iio > buffer is and does, and you know what some obscure device tree values for > the ADC are ( I never even knew of those ). But you definitely have no clue > about one shot mode. > You need to relax, take a breath. If you read the c

Re: [beagleboard] 120VAC load switching interrupting PRU loop?

My bet is you haven’t connected the GNDs correctly. Good design practices dictates that you connect all the GNDS to a single common point so that it looks like a star configuration. Think of every supply line has to be matched with a return line that connects to a GND source. If the GND for

Re: [beagleboard] bbb Internal ADC configuration settings?

ow this probably doesn’t make any sense to you because this is all to EE specific, but you did ask. Regards, John > > > > On Wed, Mar 9, 2016 at 11:24 AM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > Look at AM3358 TRM Figure 12-3 on Page 1497 &g

Re: [beagleboard] bbb Internal ADC configuration settings?

io" will produce a lot of > information. Much of it not so useful. At least for our use case, the > Beaglebone. > > On Wed, Mar 9, 2016 at 1:47 AM, William Hermans <yyrk...@gmail.com > <mailto:yyrk...@gmail.com>> wrote: > what the hell does what you've said there eve

Re: [beagleboard] bbb Internal ADC configuration settings?

.com > <mailto:yyrk...@gmail.com>> wrote: > what the hell does what you've said there even mean John ? voltagex_raw is > one shot mode, iio:deviceX is continuous mode. > > What you said above only serves to confuse the situation. > > On Wed, Mar 9, 2016 at 1:3

Re: [beagleboard] bbb Internal ADC configuration settings?

/* * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ /dts-v1/; /plugin/; / {

Re: [beagleboard] bbb Internal ADC configuration settings?

That is because you are doing this wrong. Reading attributes via sysfs is slow and not meant for this purpose. With IIO, you enable a scan element (echo 1 > in_voltage0_en) and then you enable the buffer (echo 1 > buffer/enable)and then you read the values from /dev/iio:device0. In the BB-ADC

Re: [beagleboard] Debugging the PRU through Code Composer Studio V6.1.1

I believe you need to associate your pinctrl with the bone-pinmux-helper driver. Just having the pinctrl definition in the DT does not configure the pinmux. The pinmux gets configured during the driver registration, in this case, during the platform_driver_register. With the bone-pinmux-helper

Re: [beagleboard] Re: Pinmuxing (Loadable) Kernel Module?

Well, that is what I meant by mode, which is pinmux Mode1 through Mode7, plus the pullup, pulldown, direction, etc. Rather than starting from scratch, I think it would be simple to add this to gpiolib. Also, gpiolib has uses debugfs to display info about the gpio pins. Look at

Re: [beagleboard] C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

That should read add mode feature Regards, John > On Mar 3, 2016, at 5:23 PM, John Syne <john3...@gmail.com> wrote: > > All you want to do is a a mode feature, correct? > > Regards, > John > > > > >> On Mar 3, 2016, at 3:08 PM, John

Re: [beagleboard] C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

All you want to do is a a mode feature, correct? Regards, John > On Mar 3, 2016, at 3:08 PM, John Syne <john3...@gmail.com> wrote: > > You mean like this? > > https://www.kernel.org/doc/Documentation/gpio/sysfs.txt > <https://www.kernel.org/doc/Documentation/g

Re: [beagleboard] C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

You mean like this? https://www.kernel.org/doc/Documentation/gpio/sysfs.txt Regards, John > On Mar 3, 2016, at 2:59 PM, TJF wrote: > > > Am Donnerstag, 3. März 2016 19:11:53 UTC+1 schrieb john3909: >

Re: [beagleboard] C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

Thinking a little about what your requirement, it would by simple to modify these parameters in BB-ADC driver via sysfs. Think of the DT as default parameters when the driver first starts. Regards, John > On Mar 3, 2016, at 12:41 AM, TJF wrote: > > Hi John! > >

Re: [beagleboard] C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

Why not use IIOScope? Regards, John > On Mar 3, 2016, at 12:41 AM, TJF wrote: > > Hi John! > > Thanks for the dts examples. > > Lets say I want to develop a simple osziloscop application and the user > should be able to choose the sampling rate or the number of

Re: [beagleboard] Re: C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

rport that any interrupt in Linux > works in the uS range. > > On Thu, Mar 3, 2016 at 12:26 AM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > Wrong again, UIO attempts to handle interrupts as events, but the concept is > slow (typically ms

Re: [beagleboard] Re: C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

matter how much CPU mmap() or iio uses. As any > % can preempt other code that needs to run *now* thus creating potential non > determinism. > > > On Thu, Mar 3, 2016 at 12:12 AM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > mmap is

Re: [beagleboard] Re: C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

o use the > interrupts too frequently. As it will do exactly as I stated. His words, not > mine. > > On Thu, Mar 3, 2016 at 12:06 AM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > Oh, and one more thing; the IIO driver uses a top half and

Re: [beagleboard] Re: C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

ode, and continuously opening / closing a > file descriptor to the ADC module. There is no such load when using mmap(), > as mmap() is light years faster. > > > On Wed, Mar 2, 2016 at 11:52 PM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: >

Re: [beagleboard] Re: C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

if the target is flash media. The ADC's can, > and will use up a lot of storage space, very quickly. Just using 7 channel in > one shot mode, one channel after the next. In a loop of 300k iterations. I > was using up ~3MB/s disk space. Maxed out, and all channel used. The ADC's > shou

Re: [beagleboard] C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

BTW, the was and update to BB-ADC-00A0.dts Regards, John > On Mar 2, 2016, at 10:56 PM, John Syne <john3...@gmail.com> wrote: > > /* > * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ > <http://www.ti.com/> > * > * This

Re: [beagleboard] Re: C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

/* * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/ * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ /dts-v1/; /plugin/; / {

Re: [beagleboard] Re: C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

in > one shot mode, one channel after the next. In a loop of 300k iterations. I > was using up ~3MB/s disk space. Maxed out, and all channel used. The ADC's > should use up ~9MB/s or more. > > > On Wed, Mar 2, 2016 at 4:06 PM, John Syne <john3...@gmail.com > <mailto:j

Re: [beagleboard] Re: C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

>> wrote: > You realize that you can read the ADC from Linux at full speed also? No need > to use the PRU. > Regards, > John > I do, because I've proven just that :) mmap() is dahmed fast . . . > > > On Wed, Mar 2, 2016 at 2:32 PM, John Syne <john3...@gmail.

Re: [beagleboard] Re: C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

You realize that you can read the ADC from Linux at full speed also? No need to use the PRU. Regards, John > On Mar 2, 2016, at 12:43 PM, TJF wrote: > > Hello PatM001! > > There's libpruio , which provides > ADC sampling

Re: [beagleboard] kernel 4.1.x-ti vs. 4.1.x-ti-rt in 8.3?

rt refers to the real-time option: https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO Regards, John > On Mar 1, 2016, at 8:57 PM, Wally Bkg wrote: > > I've just booted 2016-02-21 lxqt 8.3 image to get a

Re: [beagleboard] 4.1.16-bone18 #26 PREEMPT & CPU stuck for 90 second

5ms is not a good idea considering the thread switching time. Regards, John > On Feb 29, 2016, at 11:58 PM, Micka <mickamus...@gmail.com> wrote: > > But the CPU is stuck for 90 second, is that normal ? > > Micka, > > Le mar. 1 mars 2016 à 08:56, Jo

Re: [beagleboard] 4.1.16-bone18 #26 PREEMPT & CPU stuck for 90 second

It is not a bug. https://www.kernel.org/doc/Documentation/RCU/stallwarn.txt Regards, John > On Feb 29, 2016, at 11:15 PM, Micka wrote: > > Hi, > > I run 3 process doing serial test ( write on ttyO with a

Re: [beagleboard] Root NFS

You don’t have to delete connman for NFS to work. Just tell connman to stop managing eth0. This is required when using systemd. Regards, John > On Feb 29, 2016, at 2:42 PM, eli.jo...@gmail.com wrote: > > > Wow. > > I was dealing with issues trying to boot an NFS exported nfsroot with >

Re: [beagleboard] Remove the TPS65217 driver from the custom built kernel

Like Robert, I’m having a difficult time understanding what it is you are trying to do. If you are using the BBB, you cannot run the board without the TPS65217 enabled because it is this chip that is supplying all the voltage rails needed by the AM3358. If you have a different board with

Re: [beagleboard] Enabling the am335x-boneblack-prucape.dtsi overlay

In your overlay, you can add the following: fragment@1 { target = <>; __overlay__ { status = “disabled”; } } Regards, John > On Feb 28, 2016, at 2:25 PM, lucas wrote: > > Thank you for the quick response :) > > > Using the

Re: [beagleboard] Beaglebone Black write on GPIO using PRU

> On Feb 28, 2016, at 1:58 AM, Mihai Seba wrote: > > Hi guys, > > I'm trying to control a gpio using PRU but I not understand something. First > of all, I know that for certain pins, there is the PRU mode for writing and > reading (mode 5 and 6) and for gpio is mode 7.

Re: [beagleboard] Re: Anything similar

Yep, I agree with William. It looks like this is a direct competitor to the Raspberry Pi 2, providing similar I/O capabilities. From what I can see, this processor is targeted at the TV set top box. I was surprised to see the performance of the board is just 2x that of the RasPi2. Considering

Re: [beagleboard] Remove the TPS65217 driver from the custom built kernel

In addition to what Robert just explained, the TPS65217 also controls the sequence of turning on these various voltages. If you do not adhere to the AM3358 CPU datasheet voltage turn on and turn off sequence, you will damage the CPU. I cannot imagine there will be a way to use the BBB without

Re: [beagleboard] Anything similar

y of us can > also assume this person has no clue about the additional on die processors. > > On Sun, Feb 21, 2016 at 6:28 PM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > The OP question was "Are there any other boards out ther

Re: [beagleboard] Anything similar

ause of performance constraints. But I can think of > at least one situation. Out of thousands . . . > > On Sun, Feb 21, 2016 at 6:19 PM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > These processors only have ARM cores and GPU. No

Re: [beagleboard] Is it possible to write PRU firmware for remoteproc completely in Assembler?

PM, William Hermans <yyrk...@gmail.com> wrote: > > This isn't a pissing contest John. Go out and look into it on the VS front if > you want to. Otherwise don't worry about it. > > On Sun, Feb 21, 2016 at 3:55 PM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com

Re: [beagleboard] Anything similar

of these types of embedded > devboards to even a regular PC. USB also does not have the be the medium of > communication either. Communication could be done over ethernet, wifi, > bluetooth, *or* USB and remain practical. > > On Sun, Feb 21, 2016 at 3:47 PM, John Syne <john

Re: [beagleboard] Anything similar

> FTDI sells them as a lump in a USB cable. > Same guys that have been doing USB to Serial chips for a decade. They are > branching out. USB to hardware buses, USB to video, etc. > > Not hard to get a little or a lot of A->D, D->A, GPIO, in or out of a more > tradition

Re: [beagleboard] Is it possible to write PRU firmware for remoteproc completely in Assembler?

* be "changed > out", and the debugging system can be made to work with gcc tools if you > understand how. Honestly though, I personally do not find the effort worth it > anymore. > > grep works just fine if you understand how to use it correctly. > > On Sun, Feb 21

Re: [beagleboard] Anything similar

ency wise it also may not make > sense. But these are factors that not everyone cares about. > > On Sun, Feb 21, 2016 at 2:10 PM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > I’m not sure how you make this comparison. You are comparing a processor to a >

Re: [beagleboard] Anything similar

I’m not sure how you make this comparison. You are comparing a processor to a SOC (System on Chip). The AM5728 has direct access to GPIO, SPI, I2C, PCIe, USB3, UART, etc. The Pentium does not have direct access to these, but access PCI, USB3, UART via North/South bridge. No direct access to any

Re: [beagleboard] dpkg interrupted error when using apt-get install.

Try ntpdate-debian then sudo update sudo upgrade Regards, John > On Feb 21, 2016, at 8:26 AM, Tinashe Mudavanhu wrote: > > I have removed the c9-core-installer. Tried reinstalling it but still getting > to that looping point even after time sync (using ntpdate

Re: [beagleboard] Connect beaglebone black to mac

Open terminal, type: ssh debian@192.16.1.105 enter password This works just fine for me. Regards, John > On Feb 21, 2016, at 7:17 AM, Manuel Silva wrote: > > I've tried several ways to connect my BBB to mac (el capitan) through SSH >

Re: [beagleboard] Is it possible to write PRU firmware for remoteproc completely in Assembler?

based on gcc. As well as all the wonderful > Linux command line utilities. IDE "tools" are no longer necessary, and are in > fact less efficient. GUI's tend to get in the way, in this context. > > On Sun, Feb 21, 2016 at 12:11 AM, John Syne <john3...@gmail.com > <

Re: [beagleboard] Is it possible to write PRU firmware for remoteproc completely in Assembler?

e many of the features is has, including dark themes I can live with . . . > VIM classic mode, snippets, customizable code complete, etc. > > On Sat, Feb 20, 2016 at 11:54 PM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > On the contrary, I hav

Re: [beagleboard] Is it possible to write PRU firmware for remoteproc completely in Assembler?

erforming IDE written in java . . . > > Also do us both a favor. Don't try and tell me that CCS isn't buggy, and > isn't poor performing, You're not the only one whose been exposed to CCS for > years . . . > > On Sat, Feb 20, 2016 at 11:40 PM, John Syne <john3...@gmail.co

Re: [beagleboard] Is it possible to write PRU firmware for remoteproc completely in Assembler?

that CCS isn't buggy, and > isn't poor performing, You're not the only one whose been exposed to CCS for > years . . . > > On Sat, Feb 20, 2016 at 11:40 PM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > Ah, so I just use CCSV6 which has all the s

Re: [beagleboard] Is it possible to write PRU firmware for remoteproc completely in Assembler?

Hermans <yyrk...@gmail.com > <mailto:yyrk...@gmail.com>> wrote: > The IPU’s are CortexM4 processors. > Regards, > John > > You're just now figuring that out ? > > On Sat, Feb 20, 2016 at 11:20 PM, John Syne <john3...@gmail.com > <mailto:john3...@gmail

Re: [beagleboard] Help with Enabling SPI?

I agree with William, best to stay with everything on an SDCard for now. NFS is an acronym for Network File System and means that instead of the Debian OS residing on the SDCard, it is placed on your NFS Server (which can be your Linux desktop) and when your BBB boots, it loads the Debian OS

Re: [beagleboard] Is it possible to write PRU firmware for remoteproc completely in Assembler?

The IPU’s are CortexM4 processors. Regards, John > On Feb 20, 2016, at 9:53 PM, William Hermans wrote: > > I do expect that TI will improve the documentation on their implementation of > remoteproc / rpmsg sometime in the future though. As in the case of the X15, >

Re: [beagleboard] Is it possible to write PRU firmware for remoteproc completely in Assembler?

> On Feb 20, 2016, at 9:39 PM, William Hermans wrote: > > William, > > I must be missing something, because I see remoteproc as a > communication and management mechanism for code on CPUs other than the > main processor. The actual code that you are running on those >

Re: [beagleboard] Is it possible to write PRU firmware for remoteproc completely in Assembler?

he simplest, but anything demonstrating > using the onboard peripherals. ADC, I2C, CAN, or even just GPIO - whichever. > The ARM processor side code would not exactly be so important, except it > would be a good example of how the two sides of software interact with one > another. >

Re: [beagleboard] Custom Power Supply

It is possible to SMPS with a wireless circuitry, but you have to use good design principles. You need to study EMC/EMI/SI and this is a big field so I recommend you consult with an engineer who has experience in this field. In general, you need to isolate various subsystems so that they do not

Re: [beagleboard] Re: Is it possible to write PRU firmware for remoteproc completely in Assembler?

> On Feb 20, 2016, at 8:11 AM, Greg wrote: > > The support from TI is quite extensive: > > http://processors.wiki.ti.com/index.php/PRU-ICSS > > Download the C compiler manual. There is a section which describes several > ways to incorporate assembly code. > This

Re: [beagleboard] Custom Power Supply

You need to specify the current requirement for each voltage. Regards, John > On Feb 19, 2016, at 8:03 PM, Rizalino Antonio de Guzman > wrote: > > I opted for the LM317 design due to the adjustable feature, since im > supplying 3.3, 5, 12 and possibly 18V.

Re: [beagleboard] Custom Power Supply

Yep, a linear regulator will cook with a BBB attached. Assuming the BBB consumes 1A, then you will dissipate (25v - 5v) * 1A = 20Watts. This regulator cannot handle that power dissipation and will die. Better to use a switching regulator which has an efficiency of around 90% or better.

Re: [beagleboard] Help with Enabling SPI?

I’ve had this problem myself. If you are using NFS and systemd, then you must prevent connman from managing eth0: In /lib/systemd/system/connman.service, add -I eth0 to the connmand line Regards, John > On Feb 19, 2016, at 3:44 PM, Audrey wrote: > > Hi everyone, > > I

Re: [beagleboard] Is it possible to write PRU firmware for remoteproc completely in Assembler?

I recommend that you develop your code in C and then hand optimize the assembler where required. This helps document your code and make it more manageable. I have used CCSV6 for developing PRU apps and I think the support is pretty good. Make sure you use the scripts to configure the processor

Re: [beagleboard] 4.1 cape manager and disabling HDMI - how to check?

> On Feb 18, 2016, at 4:18 AM, 'PatM001' via BeagleBoard > wrote: > > After a couple weeks messing with my bbgreen and attempting to follow > (outdated) books and online tutorials I've finally settled on running debian > jessie. I've gotten to the point where I

Re: [beagleboard] Grounding ws281x LEDs with DGND

Is your 12V GND connected to the BBB DGND? Regards, John > On Feb 17, 2016, at 10:23 PM, charo...@gmail.com wrote: > > Hi all, > > I'm working on setting up a BBB to drive some LEDs. I'm using ws281x LEDs, > which require 12V+ and 5V data signals. I have a separate level converter >

Re: [beagleboard] How to set WIFI in Debian?

Setting up Wifi is way more complicated that ethernet because of the wireless settings and then there is the security setup like WPA2, etc and that is done before you start with the regular IP settins. Best to search Google “beaglebone wifi setup” which has lots of examples. I know the first

Re: [beagleboard] PRU Software Getting Started, Frequency Meter

http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs https://git.ti.com/pru-software-support-package/pru-software-support-package/

Re: [beagleboard] regarding how to make beaglebone as a web server to turn on/off led onboard.

I don’t know php, but doing the same with Node.js is very simple. Simply search google for “beaglebone node.js gpio” for examples. Regards, John > On Feb 17, 2016, at 1:52 AM, cynid...@gmail.com wrote: > > i wanted to turn on and off my onboard led by making beaglebone board only as > a

Re: [beagleboard] R or Python cross compiler for beaglebone

fast enough > works. Probably even most of the time. > > On Tue, Feb 16, 2016 at 3:36 PM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > The benefit of Python is the easy interface to C code, which means that when > your algorithm is slow, you

Re: [beagleboard] R or Python cross compiler for beaglebone

The benefit of Python is the easy interface to C code, which means that when your algorithm is slow, you can reimplement that code in C but keep the benefit of writing in a more feature rich language like Python. Regards, John > On Feb 16, 2016, at 1:47 PM, fiem.arghya...@gmail.com wrote: >

Re: [beagleboard] Slew rate when toggling Enhanced GPIO pins in the PRU?

I’ve used this code via pruss_remoteproc and I believe it toggles the PRU gpio every cycle when I removed the delay. https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/119bd86dbe7bd76011b7b28fd04da2ddb03c8d1e/examples/PRU_gpioToggle/PRU_gpioToggle.c

Re: [beagleboard] X15 as a Build Machine

It depends on what you want. If you are only interested in an ARM platform, then there are alternatives that are less expensive. If you are interested in using Dual CortexA15s, Dual DSP cores, Dual CortexM4s, quad PRUs, etc then there is nothing like this monster. Regards, John > On Feb

Re: [beagleboard] Beaglebone Black USB webcam trouble

Well, that is the difference between theory and reality. Perhaps the RT patch is causing a race condition that isn’t present when the BKL is used. I would recommend that you report your findings to the RT developers as this is something they might want to address. Regards, John > On Feb

Re: [beagleboard] Beaglebone Black USB webcam trouble

For the most part, RT shouldn’t break anything. As you can see from the rt-kernel notes below, the rt-kernel is simply breaking up the the big kernel lock by replacing spinlocks with mutexes so that code can be preempted. Unless there is some other code that is causing preemption, your app

Re: [beagleboard] Beaglebone Black USB webcam trouble

http://exploringbeaglebone.com/chapter12/ Regards, John > On Feb 15, 2016, at 10:57 AM, joelk wrote: > > I thought it would be more useful to start a new thread about this. > > On another thread (here: >

Re: [beagleboard] Beaglebone Black USB webcam trouble

If you look at Derek Molloy’s video on using Logitech C920 camera with Debian one the BBB, it worked fine. The C920 does H264 encoding in the camera and reduces the cpu requirements on the BBB. Regards, John > On Feb 15, 2016, at 10:57 AM, joelk wrote: > > I thought

Re: [beagleboard] Beaglebone Black GPIO Driver Interrupt probing

Looks way to complicated for me. Look at Derek Molloy’s example: https://github.com/derekmolloy/exploringBB/blob/master/extras/kernel/gpio_test/gpio_test.c Regards, John > On Feb 14, 2016, at 8:10

Re: [beagleboard] How do you enable analog on Beaglebone Black?

pins will be in whatever the default state is after boot up. >> Which I'm not certain what state that would be . . . >> >> On Thu, Feb 11, 2016 at 6:00 PM, John Syne <john...@gmail.com > >> wrote: >> My approach was wrong because you need the devicetr

Re: [beagleboard] How do you enable analog on Beaglebone Black?

om/2015/10/beaglebone-black-adc/> > > On Thu, Feb 11, 2016 at 5:52 PM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > Do you see /sys/bus/iio folder? > > If you don’t, then load the kernel module: > > modprobe ti_am335x_adc > > Re

Re: [beagleboard] How do you enable analog on Beaglebone Black?

le would, and will infact load > the same device module. The only problem with just loading the kernel module, > is the pins will be in whatever the default state is after boot up. Which I'm > not certain what state that would be . . . > > On Thu, Feb 11, 2016 at 6:00 PM, John Syne <

Re: [beagleboard] Re: Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

RemoteProc and RPMSG work just fine. By experimental, it means the interface may change and currently TI are adding support for PRU/Ethernet which will mean some rework. What this means is that when you update to a newer kernel, you may have to change your code, but the change will probably be

Re: [beagleboard] Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

en . . . > > You're like TJP or whatever his name. Everything is a nail, except instead of > prusio, or whatever it is, remoteproc is your hammer. > > > On Wed, Feb 10, 2016 at 7:22 PM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > Hi Greg, &

Re: [beagleboard] Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

William, what are you talking about? Why would I take what you say personally? You make these blanket statements about a technology you say you don’t know how to use and recommend that everyone else not use this technology. If you want to stay with a dead technology, that is your call, but

Re: [beagleboard] Large Arrays in DDR via PRU. Does prussdrv_map_extmem() always give contiguous physical addresses?

;hello world " messages into /var/log/messages . . > . I can do that with a bash script and no PRU . . . > > You do that, and I'll concede that remoteproc is at least semi useful. > > > On Wed, Feb 10, 2016 at 4:57 PM, John Syne <john...@gmail.com > > wrote: > William, wha

Re: [beagleboard] Reload a new PRU program in the PRU using pruss_remoteproc

This is a known problem. Back on Oct 6, I wrote the following: I have pruss_remoteproc/virtio_rpmsg_bus working on V4.1 when I boot for the first time. However, when I uninstall the KO with rmmod -f pruss_remoteproc and then install the KO with modprobe pruss_remoteproc, I get a kernel

Re: [beagleboard] Use GPIO as non-root user?

This is why Unix/Linux has groups. Do the following: ls -la /dev You will see groups such as i2c, dialout, tty, etc. If you want to access these devices from a regular user account, add your user to those groups. If you need to use a device that has root:root, then change the group and add

Re: [beagleboard] debian testing: 2016-01-31 (Node-RED)

Why don’t you use C/C++ addons for Nodejs? https://nodejs.org/dist/latest-v5.x/docs/api/addons.html With Nodejs C/C++ addons, you can interface to any I/O on the BBB. Regards, John > On Feb 2, 2016, at 1:39 PM, Wally Bkg

Re: [beagleboard] What limits Beagle Board Black HDMI resolution

Plug your numbers into this video timing calculator and you will see that given the AM3358 max pixel clock rate of 126MHz, you cannot do 60Hz. http://www.fccps.cz/download/adv/frr/video_timings/video_timings.xls Regards, John > On Feb 1, 2016, at 7:51 AM, micael.beron...@gmail.com wrote: >

Re: [beagleboard] Building Kernel with cross-compiler and sharing through USB

I always solve these types of problems with a process of elimination. Start with an SDCard that works and then using the same u-boot, move the kernel and DTB to your TFTP folder and copy the complete rootfs to your NFS folder. Check that your TFTP and NFS are working correctly. If you are using

Re: [beagleboard] Building Kernel with cross-compiler and sharing through USB

I use NFS all the time and this is what I have in uEnv.txt on my SDCard. ##Rename as: uEnv.txt to boot via nfs uname_r=4.1.12-ti-r25 ##https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt ##SERVER: sudo apt-get install tftpd-hpa ##SERVER: TFTP_DIRECTORY defined in

Re: [beagleboard] UART connection question

> On Jan 27, 2016, at 12:28 AM, Karl Karpfen wrote: > > > What is a good resource for writing programs for the uarts? Which > > programming language would be the best to write uart applications in C++, > > Python, or Java? > > This does not matter, from all languages

Re: [beagleboard] Direct io memory access in Linux Kernel

Oh damn. Simply disregard, I had some stupid filter on. Regards, John > On Jan 21, 2016, at 12:31 PM, John Syne <john3...@gmail.com> wrote: > > I believe you only use ioremap for CPUs that have a separate IO address bus. > The AM3358 IO is available on the same address bus

Re: [beagleboard] Direct io memory access in Linux Kernel

I believe you only use ioremap for CPUs that have a separate IO address bus. The AM3358 IO is available on the same address bus as regular memory. Simply read and write to 0xFA0022000 + should work just fine. You might ask why the address is different to the UART1 defined in TRM. This is done

Re: [beagleboard] Why does ioremap fail?

OK, so lets see if we can get a better understanding of what you need to do because this has been confusing to me also. Read Documentation/bus-virt-phys-mapping.txt and you will see they reference ioremap under PCI Memory access; however, accessing physical memory/registers, they talk about

<    1   2   3   4   5   6   7   8   >