Re: [beagleboard] Support for BBB kernel

sudo sh -c "echo ‘BB-ADC' > /sys/devices/platform/bone_capemgr/slots" Regards, John > On Jul 1, 2016, at 3:34 PM, Greg Wilson-Lindberg wrote: > > Hi Robert, > The problem that I've got with that is the tag doesn't make sense, its > 3.14.49-ti-r62, which seems to be

Re: [beagleboard] Support for BBB kernel

Have you installed the ADC devicetree overlay? Regards, John > On Jul 1, 2016, at 3:34 PM, Greg Wilson-Lindberg wrote: > > Hi Robert, > The problem that I've got with that is the tag doesn't make sense, its > 3.14.49-ti-r62, which seems to be wrong, the 3.14.40 version

Re: [beagleboard] Support for BBB kernel

So did you do a git pull on your existing ti-linux-kernel-dev project? If you did, then it won’t build. To see the error, you have to scroll back, sometime you have to scroll back a lot to see the error. If the build was successful, you will see the deploy folder update successfully. The reason

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Here is a conversation I had with Robert about this issue: > From: Robert Nelson <robertcnel...@gmail.com> > Subject: Re: uio_pruss coexist with remoteproc > Date: June 30, 2016 at 11:43:29 AM PDT > To: John Syne <john3...@gmail.com> > > Hi John, > > On Thu,

Re: [beagleboard] RPMsg from Linux User Space to PRU on Beaglebone Black

Then I’m wondering if Robert had pulled in these changes from the https://git.ti.com/rpmsg V4.4 repo. If not, then the V4.0.2 examples should work fine. Regards, John > On Jun 30, 2016, at 11:00 AM, engkan2...@gmail.com wrote: > > I was actually using

Re: [beagleboard] RPMsg from Linux User Space to PRU on Beaglebone Black

Wonderful. If you change to the V4.4 kernel, you must update to PRU V5.0 examples because there is a change from mailbox to interrupt event. Regards, John > On Jun 30, 2016, at 8:23 AM, engkan2...@gmail.com wrote: > > Hi John! > > It is working now. I tried 4.1 and 4.4.9-ti-rt-r25. The

Re: [beagleboard] RPMsg from Linux User Space to PRU on Beaglebone Black

What does lsmod show? Regards, John > On Jun 28, 2016, at 6:55 AM, engkan2...@gmail.com wrote: > > I've changed my kernel to the same version as the poster (I'm using ubuntu). > I still don't see the device in /dev. > > [ 17.581262] pru-rproc 4a338000.pru1: sysevt-to-ch[18] -> 3 > [

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 30, 2016, at 2:11 AM, TJF wrote: > > Good morning John! > > Am Mittwoch, 29. Juni 2016 17:07:05 UTC+2 schrieb john3909: > What a silly argument. It is well known that when you don’t have physical > security, you don’t have any security. Once you can replace

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

@TJF What a silly argument. It is well known that when you don’t have physical security, you don’t have any security. Once you can replace the storage media, you can make the hardware do whatever you want. This is true of your laptop and your servers. Clearly by your argument, you haven’t even

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

@TJF, I didn’t copy the PRU developers because I believe there is nothing in your response that would be of interest to them. It is hard to keep up with your changing priorities. Addressing your security issues, you never answered my original question. How are you going to install PRU

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Reading virtio docs, I came across two sentences that may provide a way forward: 1) "Virtual queues, being virtual, are actually implemented as rings to traverse the guest-to-hypervisor transition. But this could be implemented any way, as long as both the guest and hypervisor implement it in

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 27, 2016, at 11:16 AM, William Hermans wrote: > > Also, /dev/mem/ + mmap() are identical to the PRU in relation to having > direct access to any memory address. Which is why many people have concerns > when it is used. > > By the way. You could lock down the PRUs

Fwd: [beagleboard] Ti's RPMsg Examples Significantly Changed

This message from Przemek didn’t get copied to everyone but I thought he had an interesting prospective to this discussion. Regards, John > Begin forwarded message: > > From: Przemek Klosowski > Subject: Re: [beagleboard] Ti's RPMsg Examples Significantly

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 27, 2016, at 1:49 AM, John Syne <john3...@gmail.com> wrote: > > >> On Jun 27, 2016, at 12:51 AM, TJF <jeli.freih...@gmail.com >> <mailto:jeli.freih...@gmail.com>> wrote: >> >> @John3909: >> >> Am Sonntag, 26. Juni 2016 2

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 27, 2016, at 12:51 AM, TJF wrote: > > @John3909: > > Am Sonntag, 26. Juni 2016 20:13:12 UTC+2 schrieb john3909: > It makes no sense to discuss that in detail here, since you obviously have no > idea on rapid prototyping controllers. (I can give you a private

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

So reading the UIO docs; https://www.kernel.org/doc/htmldocs/uio-howto/about.html "For some hardware that has more than one interrupt source internally, but not separate IRQ mask and status registers, there might be situations where

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 26, 2016, at 2:53 AM, TJF wrote: > > Obviously you have no idea how libpruio works and you have no experience on > the usecase it's made for. Do you really think you can give a professional > opinion on correct or incorrect? I'm sure I use it correct, because

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

ohn > >> On Jun 25, 2016, at 18:32 , John Syne <john3...@gmail.com> wrote: >> >> Think about what you are proposing. When the kernel loads, it discovers >> devices and then loads the appropriate drivers. Now what happens when it >> discovers the PRU, which drive

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

<rm...@latencyzero.com> wrote: > >> >> On Jun 25, 2016, at 14:44 , John Syne <john3...@gmail.com> wrote: >> >>> On Jun 25, 2016, at 2:20 PM, Rick Mann <rm...@latencyzero.com> wrote: >>> >>> >>>> On Jun 25, 2016, at 12:56 , John Syne &

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 25, 2016, at 2:20 PM, Rick Mann <rm...@latencyzero.com> wrote: > > >> On Jun 25, 2016, at 12:56 , John Syne <john3...@gmail.com> wrote: > >>> On Jun 25, 2016, at 11:56 AM, Jason Kridner <jkrid...@beagleboard.org> >>> wrote:

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

On the contrary, the TI kernel is for all TI processors and not just for the BBB. If you want features added to the “bone” kernel, why not request those features be added. Regards, John > On Jun 25, 2016, at 12:57 PM, William Hermans wrote: > > Also, instead of saying

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 25, 2016, at 11:56 AM, Jason Kridner wrote: > > I will work to enable uio_pruss functionality, and I think that is what you > want, not just getting remoteproc out. Please don’t do that. Robert Nelson has the “bone” kernel for this purpose which supports

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

I’ve included Ohad Ben-Cohen who was one of the originators of the RemoteProc/RPMSG framework. Hopefully he will be able to provide some prospective of what he was thinking when he created this framework. > On Jun 25, 2016, at 7:39 AM, TJF wrote: > > @John: > > ...

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 24, 2016, at 6:02 PM, Suman Anna wrote: > > Hi TJF, > > On 06/18/2016 10:23 AM, TJF wrote: >> Hi Suman, thanks for your statements. >> >> [Suman: Where do you use this from, I assume userspace? Using what - Shared >>> DRAM or regular PRU DRAM.] >>> >> >> Yes,

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

I think you forgot to take your meds this morning. I’m not even sure what this has to do with RPMsg. Looking at this list you provided, I’m not sure what you think is garbage? In any case, if there is something you don’t need, simply modify your config and remove the features you don’t want.

Re: [beagleboard] PRU Pattern bigger than 8k

Yet another solution would be to place the 24K in DDR and use DMA to populate the 12K shared PRU ram using a ping pong arrangement. The PRU would read from one buffer while the DMA fills the other buffer. When the PRU has finished with the one buffer, it will switch to the other buffer and

Re: [beagleboard] missing sys/devices/ at lib/firmware/

/sys/devices/platform/bone_capemgr/slots Regards, John > On Jun 21, 2016, at 11:54 PM, epi kao wrote: > > now hdmi is working, i don't know why, i have deleted the last empty line, > and actived the second cmdline instead the first > > so i am only looking for a

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

onsiderably also. etc . . . > > On Mon, Jun 20, 2016 at 6:14 PM, <ybeag...@rehut.com > <mailto:ybeag...@rehut.com>> wrote: > The ADC is a SAR ADC. Overclocking it is likely to have side effects on the > analog end of things which will reduce accuracy. > > Ign

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

. Overclocking it is likely to have side effects on the > analog end of things which will reduce accuracy. > > Ignoring that it is a very bad idea to keep doing things in userland: > > On Monday, June 20, 2016 18:06:09 John Syne wrote: > > That is a totally different issue

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

gt; > Ignoring that it is a very bad idea to keep doing things in userland: > > On Monday, June 20, 2016 18:06:09 John Syne wrote: >> That is a totally different issue. You were reading the same sample over and >> over again as opposed to increasing the sample rate by changing the clock

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

That is a totally different issue. You were reading the same sample over and over again as opposed to increasing the sample rate by changing the clock divider, open delay, sample delay, etc. In any case, at 200ksps, each sample occurs every 5uS. How is a user space app going to process samples

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

Well, I think that is still to be determined if the ADC can sample higher than 200ksps and that is why I’m adding DMA to this driver. But in any case, why not use a higher speed ADC connected via SPI or McASP? You can purchase boards that sample at a higher rate and connect those to the BBB.

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

Currently the ADC driver is configured for 16x oversample, Open Delay = 152 cycles and Sample Delay = 1 cycles. time in us for processing a single channel, calculated as follows: num cycles = open delay + (sample delay + conv time) * averaging num cycles: 152 + (1 + 13) * 16 = 376 clock

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

The ADC uses a sequencer and you can only read the sample when the samples are complete. The sequencer provides an interrupt or triggers a DMA transfer when the EOC (End of Conversion) is achieved. Since you cannot service interrupts in userspace, you will have to poll repeatedly to wait for

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

http://e2e.ti.com/support/arm/sitara_arm/f/791/p/382609/1349287#1349287 Regards, John > On Jun 20, 2016, at 12:00 PM, Stewart wrote: > > I'm looking to write a simple app for BBB. When

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

You don’t read the IIO driver that way. You read the samples from /dev/iio:device0. You can modify the open delay, sample delay, in the devicetree, but because the current driver uses interrupts, the cpu utilization increases as you increase the sample rate. Also, the convertor is specified as

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

You should read the info Steward provided. There is a conflict in the AM3358 datasheet because it does say max 200ksps, but in the register settings, it does show you can configure the ADC for 1.6msps. There are discussions on E2E about this issue and no one from TI has said you cannot achieve

Re: [beagleboard] Capture analog input at near maximum sample rate?

I have been working on adding DMA to the ADC driver, but it currently it throws overflow errors before DMA starts. The DMA should trigger when the ADC fifo reaches a predefined threshold, but for some reason there is a delay before DMA triggers. The ADC driver uses the IIO framework and I’m

Re: [beagleboard] Capture one Analog channel in continuous mode at near maximum speed?

I have been working on adding DMA to the ADC driver, but it currently it throws overflow errors before DMA starts. The DMA should trigger when the ADC fifo reaches a predefined threshold, but for some reason there is a delay before DMA triggers. The ADC driver uses the IIO framework and I’m

Re: [beagleboard] trouble with image bone-debian-8.5 / 2016-06-05

Because Devicetree is new and there is an effort to achieve consistency between all architectures. Remember, devicetree started on the PowerPC platform and it was only when Linus complained about the code duplication and conflicts between ARM platforms that Devicetree was adopted by the ARM

Re: [beagleboard] trouble with image bone-debian-8.5 / 2016-06-05

What was ugly was the original board files with duplicate code in the kernel source for each platform. Anyway, why is this ugly? It is simply a device address and a label. The driver needs this information, so you can either hard code it (not a good idea because it leads to duplicate code) or

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 17, 2016, at 2:22 PM, Anna, Suman <s-a...@ti.com> wrote: > > Hi TJF, > > My responses inlined.. > > Regards > Suman > > From: John Syne [mailto:john3...@gmail.com <mailto:john3...@gmail.com>] > Sent: Friday, June 17, 201

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

> On Jun 17, 2016, at 7:17 AM, TJF <jeli.freih...@gmail.com> wrote: > > @John Syne: > Correct, remoteproc is stabil since month. Stabil in the point that it isn't > usable. And that's why it is and it should be experimental. And experimental > features shouldn't polut

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Hi Jason Reeder, I think William forgot to include you in his response. As you can see, William is an experienced developer who had difficulty understanding the RPMSG/Remoteproc framework. A lot of this I believe is TI’s tendency to use terminology assuming the reader is familiar with and in

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Hi William, I think it would be helpful for Jason to see the pruss-uio docs you think are well written. I don’t want to provide Jason with a list of complaints, but rather a list of helpful suggestions that might guide him to a better solution. Regards, John > On Jun 16, 2016, at 6:19 PM,

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

>From what Jason Reeder was saying, you need to update to >pru-software-support-package V5. https://git.ti.com/pru-software-support-package Regards, John > On Jun 16, 2016, at 4:00 PM, Greg wrote: > > Hi Jason- >

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

. There's also source to an assembler. > > More responses below... > > On Thu, Jun 16, 2016 at 3:42 PM John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > Looking at am335x_pru_package, I see things like loaders which conflict with > RemoteProc so I’

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

<jkri...@ <>beagleboard.org >> <http://beagleboard.org/>> wrote: >> >> Nice request. >> >> I'd suggest putting things into the am335x_pru_package on GitHub, but I >> know there are some issues in bringing back code into TI. I'd just suggest

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

uggest putting things into the am335x_pru_package on GitHub, but I know > there are some issues in bringing back code into TI. I'd just suggest > updating that same sort of package such that we can merge the deltas, but one > place with a full experience. > > Thoughts? > >

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

alues articulated. Simply ignoring the > remoteproc interface supported in the mainline kernel doesn't make sense to > me. > On Thu, Jun 16, 2016 at 2:20 AM John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > One other thing, if you don’t like some fea

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Again, this makes no sense. /proc is just a processor monitor and doesn’t provide any interface between kernel and userspace. The only way to convey interrupts to userspace with UIO is via kernel events and latency could be 10s or 100s of milliseconds when the cpu is under load. With RPMSG,

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

As Robert has already said, RPMSG/RemoteProc will replace UIO_PRUSS. The problem is you haven’t taken the time to learn RPMSG/RemoteProc so you shouldn’t be providing advise to others. Your question “how does remoteproc make things better” has already been answered. It is possible to create

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

One other thing, I don’t know why TI labels the code as experimental, because it is fully functional and robust. Even with the changes over the last year, there wasn’t a lot of change to the examples, so the impact on developers code was minimal. Also, I believe you don’t have to use the

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

I am not arguing the need for a separate repo, because the original one has a loader defined and that would conflict with RemoteProc, which is just a loader. The examples that Jason suggested might be added to the repo could be done with minimal mods. The one thing I don’t like about UIO is it

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

s repo making sure both driver > mechanisms are supported and their values articulated. Simply ignoring the > remoteproc interface supported in the mainline kernel doesn't make sense to > me. > On Thu, Jun 16, 2016 at 2:20 AM John Syne <john3...@gmail.com > <mailto:john3...@gmail.

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

One other thing, if you don’t like some features of RPMSG/REMOTEPROC, then why not provide input to the developers with any suggestions you think will make things better? I have spoken to Jason Reeder and Suman Anna several times and they have been very responsive to my input. Regards, John

Re: [beagleboard] Ti's RPMsg Examples Significantly Changed

Oh, that is complete bunk and you know it. PRUSSDRV is nothing more than a UIO hack. RPMSG/REMOTEPROC is a lot more in that it support virtual drivers so you can have ethernet, serial, spi, i2c, and more virtual drivers that are defined in firmware. Also, the same implementation supports

Re: [beagleboard] Tools to debug the driver .

Well, you won’t be able to do much. For example, as you single step, the kernel can switch tasks and then you will be stepping through an unrelated thread. No way to switch back to your original thread, so you will have to set breakpoints in the source and hope to get back to your original

Re: [beagleboard] Latest Jessie: cannot write to disk, cannot connect Eth over USB, could before

Everyone here is a volunteer, giving their time freely and doing their best to help. I have seen this type of problem before and it has to do with a corrupt MBR. Best to erase the MBR and create a new partition table. I don’t know anything about your project, but in most cases, you would be

Re: [beagleboard] GPIO in C/C++ on the Beaglebone Black?

Read the Kernel docs to learn how to do this correctly. If you have the kernel source, the docs are under /Documentation/gpio. The board.txt file will explain how to access the DTS definitions for the GPIO. In the DTS, you will define which GPIO are allocated to your driver. The driver.txt file

Re: [beagleboard] BBB: bare metal programming in C - what is need on the SD card?

One thing to be aware of is the CortexA8 doesn’t perform very well if you don’t have Data and Instructions Cache enabled and you also have to have the MMU configured and enabled. For example, toggling a GPIO in Starterware with no Cache or MMU enabled, I get about 120KHz but if I enable both

Re: [beagleboard] Capemanager Not found

/sys/devices/platform/bone_capemgr/slots Regards, John > On Jun 3, 2016, at 3:37 AM, Raul Piper wrote: > > I build the kernel as per instructions on -> > https://eewiki.net/display/linuxonarm/BeagleBone+Black > uname -a gives : linux_arm 4.6.0-bone2 > > > On

Re: [beagleboard] Shutdown from inside a service is very slow

My guess is your systemd service isn’t exiting and so the shutdown pauses until your service exits or after a timeout, the service is sent a kill signal to exit. Regards, John > On Jun 2, 2016, at 3:28 PM, YP66 wrote: > > I am working on an automatic shutdown based on

Re: [beagleboard] Error when reading multiple Analog Inputs recursively

That is because this the the incorrect way to read ADC values. The ADC driver is based on the IIO framework, so instead of reading ADC values via sysfs, you should read the values from /dev/iio:device0. Search for "generic_buffer.c IIO” to see how to do this correctly. Regards, John > On

Re: [beagleboard] BeagleBone Black Kernel Main Differences

> On May 30, 2016, at 8:25 AM, yolc...@gmail.com wrote: > > These are a newbie questions, but it would be fine if a wiki exists with > clear explanantion about. > Which are the main differences between branches (ex. v4.1 vs v4.4)? Other than the obvious answer that V4.4 has for features/drivers

Re: [beagleboard] Adafruit BBIO Python library

I haven’t used this feature, but a simple Google search gives what looks like the answer you are looking for: http://stackoverflow.com/questions/16721346/linux-kernel-version-macro-definition So in your case:

Re: [beagleboard] PRU RPMsg device file missing

Hi Greg, It has been quite a while since I’ve worked on PRU, but with the TI kernel, are you not talking about pruss_remoteproc? I don’t have a pru_rproc in my remoteproc folder. root@beaglebone:/lib/modules/4.1.13-ti-r33/kernel/drivers/remoteproc# ls omap_remoteproc.ko pruss_remoteproc.ko

Re: [beagleboard] PRU RPMsg device file missing

Why not use modprobe so you don’t have to bother with paths and dependencies? To install modprobe pru_rproc To remove modprobe -r pru_rproc Regards, John > On May 28, 2016, at 6:40 AM, Greg wrote: > > Hi Torben, I'm puzzled by the extra steps with the stubs.h and

Re: [beagleboard] BeagleBone Black/Green SPI pins always low with 4.1.22 kernel

Hi Robert, You are talking about the edma not being registered for the SPI when using overlays, right? I’ve been working on adding DMA to the IIO ADC driver and I came across the same problem. It seems like prepare_unused_channel_list is only called the first time edma_alloc_channel is

Re: [beagleboard] PRU RPMsg device file missing

Probably something to do with the am335x-pru0-fw and am335x-pru1-fw. Did you generate these yourself and are they derived from V4 of the PRU Software Support Package? Here is what the log should look like [ 17.730877] pruss-rproc 4a30.pruss: 8 PRU interrupts parsed [ 17.730963]

Re: [beagleboard] Vdds_ddr decoupling caps in am3358

There are several other factors that affect decoupling: PCB Layout (smaller is better) Ground planes size, distance between ground planes and dielectric material used Decoupling cap ESR Proximity of the decoupling caps to the power pins Number and size of vias connected to power pins (think of

Re: [beagleboard] Driver Development : SPI or 4 wire Interface on BBB

Just Google “am335x pru” http://processors.wiki.ti.com/index.php/PRU-ICSS Regards, John > On May 25, 2016, at 12:33 AM, Raul Piper wrote: > > What is PRU?Can you post a link or keywords related to it.? > > On

Re: [beagleboard] Driver Development : SPI or 4 wire Interface on BBB

Best to use the PRU and control the I/O with software. Regards, John > On May 24, 2016, at 6:25 AM, Raul Piper wrote: > > My Question was Can CS be selectively made High or Low at nth or pth Clock > Pulse while using/writing the SPI driver? > > On Monday, May 23,

Re: [beagleboard] Source for 'right-angle jtag adapter' in UK?

ro.com> wrote: > > >> On May 23, 2016, at 15:01 , John Syne <john3...@gmail.com> wrote: >> >> I just bent the serial pins to about 80 deg and it works fine with a cape >> attached. > > This is what I do. It's gross. Better would be to put a right-angle

Re: [beagleboard] Source for 'right-angle jtag adapter' in UK?

I just bent the serial pins to about 80 deg and it works fine with a cape attached. Regards, John > On May 23, 2016, at 2:43 PM, Robert Nelson wrote: > > > > On Mon, May 23, 2016 at 4:33 PM, Marcos Scriven >

Re: [beagleboard] Analog IO with C/C++ code

See the answer to your posting from yesterday. Regards, John > On May 22, 2016, at 7:39 PM, justinmre...@gmail.com wrote: > > Hi guys, > Alright I submit, I give in and come to you and now ask for help. I am amiss > as to how this has been so magically elusive, but it has! > > Question >

Re: [beagleboard] Driver Development : SPI or 4 wire Interface on BBB

Here are the possible solutions: 1) Use spidev which allows a user space application to communicate with a device over SPI 2) Use PRU to communicate with device over SPI 3) Develop a device driver to communicate with device over SPI 4) Adapt an IIO driver that is similar to your device Regards,

Re: [beagleboard] Analog IO with C/C++ code

Well, that example shows the incorrect way to use IIO if you want to continuously collect samples from the ADC. The correct way to use IIO is to read from /dev/iio:device0 You start by selecting which channels you want to sample. For example, if you want to enable the first 2 channels echo

Re: [beagleboard] declare create interrupts gpio tren beaglebone black

I found this info in the book "Mastering Embedded Linux Programming” by Chris Simmonds HANDLING INTERRUPTS FROM GPIO In many cases, a GPIO input can be configured to generate an interrupt when it changes state, which allows you to wait for the interrupt rather than polling in an inefficient

Re: [beagleboard] connman issues on latest Debian 8.4 release?

Hi Robert, I would think that the need for tethering would be the exception so I’m not sure why you would set this on by default. Regards, John > On May 18, 2016, at 5:51 PM, Robert Nelson wrote: > > Hi Mike > > On Wed, May 18, 2016 at 7:08 PM, Mike Erdahl

Re: [beagleboard] Hardware watchdog for BBB

https://en.wikipedia.org/wiki/Supercapacitor If you operate the supercap at lower than max voltage and keep the temperature at close to 25C, the supercap will last as much as 20 years. No battery comes even close. You also need to look at

Re: [beagleboard] TPS65217 & Vdd_core 1.125V or 1.2V or 1.1V or .... ?

e ) > > Le mer. 18 mai 2016 à 22:31, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> a écrit : >> On May 18, 2016, at 1:58 AM, Micka <mickamus...@gmail.com >> <mailto:mickamus...@gmail.com>> wrote: >> >> Hi,

Re: [beagleboard] Running multiple scripts in parallel at Boot up.

Why not create systemd services for each script which will run in parallel once the prerequisites have been met. Regards, John > On May 18, 2016, at 10:56 AM, gajeshwa...@gmail.com wrote: > > Hello, > I want to run few scripts in parallel at boot up. I am using Service routine > to run

Re: [beagleboard] TPS65217 & Vdd_core 1.125V or 1.2V or 1.1V or .... ?

> On May 18, 2016, at 1:58 AM, Micka wrote: > > Hi, > > In the u-boot > http://git.denx.de/?p=u-boot.git;a=blob;f=board/ti/am335x/board.c;h=4330be64994dc6cbfaff4b865fee44d82f660a3d;hb=HEAD#l255 > >

Re: [beagleboard] declare create interrupts gpio tren beaglebone black

BlackLib is for user space programming. To process interrupts, you have to be in kernel space so you have to use a Kernel Module or Device Driver to process interrupts. To pass the event onto user space, there are several options, such as blocking on a read, or sigaction, etc. Best to read

Re: [beagleboard] Automatic shutdown options for loss of power?

I believe they are sponsored by the British government and they produce far bigger volumes. Regards, John > On May 16, 2016, at 4:45 PM, William Hermans wrote: > > that is . .. it would cost us 4-5x as much to make our own BBB's . . > > On Mon, May 16, 2016 at 4:44

Re: [beagleboard] Re: Hardware watchdog for BBB

Batteries have a limit number of charge cycles. Now you are going to say the battery remains charged, so you don’t have an issue with number of charge cycles, but if you keep the battery charged to greater than 90%, the battery won’t last more than 2 to 3 years. You can extend the life of LiPO

Re: [beagleboard] Re: Hardware watchdog for BBB

> On May 16, 2016, at 2:55 PM, Super Twang wrote: > > > > Hey y'all (yes, I'm in Texas), > > I have really appreciated all of the good ideas and thoughtful design ideas > here. There are some apples and oranges being discussed at times because the > problem of BBB

Re: [beagleboard] Hardware watchdog for BBB

PM, evilwulfie <evilwul...@gmail.com> wrote: > > spend 50 bux on a power supply to solve a 5 dollar problem yeah right. > > > On 5/16/2016 12:34 PM, John Syne wrote: >> >>> On May 15, 2016, at 4:25 PM, evilwulfie < >>> <mailto:evilwul.

Re: [beagleboard] Hardware watchdog for BBB

ator is arching, or a power line is arching on the ground, these all result in very strange power behavior. In summary, power failure isn’t just an on or off problem, but a multitude of more problematic cases. Regards, John > > On 5/15/2016 3:37 PM, John Syne wrote: >> >>> On

Re: [beagleboard] Hardware watchdog for BBB

> On May 15, 2016, at 3:14 PM, evilwulfie wrote: > > We use an external msp430 for our intelligent watchdog So who or what monitors the MSP430? Since it is a micro-controller, it is easy to get it into a lock situation. All you need is a programable power supply which

Re: [beagleboard] Hardware watchdog for BBB

I haven’t worked on this in a while, but the circuitry I proposed was for a voltage monitoring and safe shutdown and startup. The AM3358 already has a watchdog timer and will reset the board if the watchdog is not serviced in a predefined period. My proposed circuit included supercaps to power

Re: [beagleboard] Recommended workflow for audio codec driver development in BBB.

OK, so on my stopwatch, it takes 9.88 seconds. john:~/Download/GIT/ti-linux-kernel-dev/KERNEL$ touch sound/soc/codecs/tlv320aic3x.c john:~/Download/GIT/ti-linux-kernel-dev/KERNEL$ time make -j8 ARCH=arm LOCALVERSION=-ti-r33

Re: [beagleboard] Beagle on a chip - Octavo Systems releases OSD3358

Hi Jason, This is simply amazing. This removes all the high tech from the PCB design so almost anyone can build their own boards and also reduces significantly the board cost. What a great idea. Thanks for sharing. Regards, John > On May 9, 2016, at 9:31 AM, Jason Kridner

Re: [beagleboard] Recommended workflow for audio codec driver development in BBB.

I modified the file you are building and the build takes all of about 2 seconds. How much more time do you want to save? Regards, John > On May 8, 2016, at 11:00 PM, Rick Mann <rm...@latencyzero.com> wrote: > >> >> On May 8, 2016, at 22:25 , John Syne &l

Re: [beagleboard] Recommended workflow for audio codec driver development in BBB.

Sure you can, just run the "make -jx LOCALVERSION=xxx ARCH=xxx CROSS_COMPILE=xxx modules" command that is displayed in the script. Regards, John > On May 8, 2016, at 10:15 PM, Rick Mann wrote: > > >> On May 8, 2016, at 16:55 , Robert Nelson

Re: [beagleboard] Building kernel for beaglebone black

What is the problem? Regards, John > On May 7, 2016, at 1:02 PM, 02alkaya...@gmail.com wrote: > > hi > i have problem to beaglebone black kernel compilation for git hub in linux > 16.04, please suggest me what should i have to do? > > On Monday, May 27, 2013 at 7:10:55 PM UTC+5:30, Alex

Re: [beagleboard] Kinoma at the Embedded Linux Conference 2016

How is this different to Cloud9 IDE and bonescript? I took a brief look at their site, and I don’t see anything equivalent to LabView. All this could be achieved with Nodejs and the C/C++ Addon library to talk to I/O. The hardware with an old ARM processor and limited memory looks horrible.

Re: [beagleboard] Any difference for PIN9.15 (GPIO1_16) on new BBB

You can just do a git diff between the two releases. Search google on how to do this. There are probably a lot of changes, but concentrate on just the areas that would affect the issues you are concerned about. Regards, John > On May 5, 2016, at 1:11 PM, ht...@thingmagic.com wrote: > >

Re: [beagleboard] How to compile and and deploy code on dsp core

The DSP core is held in reset until the ARM core releases the DSP core. There are scripts in CCSV6 which will release the DSP core from reset to enable you to develop code for the DSP. Search on TI’s e2e.com for discussions on this topic. Regards, John > On May 4, 2016, at 11:48 PM,

<    1   2   3   4   5   6   7   8   >