Re: [beagleboard] Re: PRU Assumptions - True or False

Hello AMF  I have 5 year old quad core win 8.1 64 bit 8 G ram laptop running Ubuntu 16.04 VM  I used it to build SDK kernel no problems and  a new Debian 10 VM with a 64 bit GCC on same machine. The Debian VM is flaky last attempt  I just got memory calloc error on building 5.5 TI BSP from the

Re: [beagleboard] Re: PRU Assumptions - True or False

Hi lazarman, on ubuntu 20.04, this builds ok git clone https://github.com/RobertCNelson/ti-linux-kernel-dev.git cd ti-linux-kernel-dev git checkout remotes/origin/ti-linux-rt-5.4.y -b ti-linux-rt-5.4.y ./build_kernel.sh I've used VirtualBox before with Ubuntu 16/18/20 without any issues, what

Re: [beagleboard] Re: PRU Assumptions - True or False

> Be nice not keep downloading the 2G kernel source I know there is a > rebuild.sh but I am assuming that is used after a successful build > If these instruction need I tweek I can understand I can test them. If it old > and not supported a heads up would be appreciated. So I need something

Re: [beagleboard] Re: PRU Assumptions - True or False

I decided to make another attempt a clean dir on Mainline 5.4 I was blocked. No password . That was not there before  I guess I will take a break Linux Kernel This script will build the kernel, modules, device tree binaries and copy them to the deploy directory. Mainline | | | | | |

Re: [beagleboard] Re: PRU Assumptions - True or False

Hello  I've failed to build following those instructions twice in Mainline  and twice using the TI BSP.version. the 2nd attempt of TI BSP is hung as we speak after resolving dependencies for several hours. Each attempt takes hours and the build_kernel script doesnt care you already cloned 2G

[beagleboard] Re: PRU Assumptions - True or False

On Fri, 28 May 2021 13:15:20 -0400 (EDT), in gmane.comp.hardware.beagleboard.user Robert Heller wrote: > >YES. 5.x kernels only support UIO. You need a 4.x TI kernel for RemoteProc. > Ouch -- a reversion... > >I think the mainline kernels don't have the RemoteProc kernel code. At

[beagleboard] Re: PRU Assumptions - True or False

On Fri, 28 May 2021 10:11:46 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Bruce Chidester wrote: >Dennis, > >Thanks for your response. > >When developing with the UIO architecture, they use the term "interrupt", >so I assume they meant it somehow, but not willing to die on that hill. I

Re: [beagleboard] Re: PRU Assumptions - True or False

On Fri, May 28, 2021 at 2:53 PM Robert Nelson wrote: > > On Fri, May 28, 2021 at 2:45 PM Robert Nelson wrote: > > > > On Fri, May 28, 2021 at 2:41 PM Mark Lazarewicz wrote: > > > > > > Thanks!! > > > > > > Think of it as I'm validating the instructions I think having these is > > > something

Re: [beagleboard] Re: PRU Assumptions - True or False

On Fri, May 28, 2021 at 2:45 PM Robert Nelson wrote: > > On Fri, May 28, 2021 at 2:41 PM Mark Lazarewicz wrote: > > > > Thanks!! > > > > Think of it as I'm validating the instructions I think having these is > > something good. Unfortunately my VM blew up just now. > > > > I KNOW your adamant

Re: [beagleboard] Re: PRU Assumptions - True or False

On Fri, May 28, 2021 at 2:41 PM Mark Lazarewicz wrote: > > Thanks!! > > Think of it as I'm validating the instructions I think having these is > something good. Unfortunately my VM blew up just now. > > I KNOW your adamant about not supporting VM. > > So I'll build a dedicated Debian 8 dev box.

Re: [beagleboard] Re: PRU Assumptions - True or False

Thanks!!  Think of it as I'm validating the instructions I think having these is something good. Unfortunately my VM blew up just now. I KNOW your adamant about not supporting VM. So I'll build a dedicated Debian 8 dev box. Any hints tips lessons learned what you use be appreciated. Have a great

Re: [beagleboard] Re: PRU Assumptions - True or False

On Fri, May 28, 2021 at 2:19 PM 'Mark Lazarewicz' via BeagleBoard < beagleboard@googlegroups.com> wrote: > Thanks Robert > > I love these instructions very well done > my goal is to be able to build something stable from scratch not drop > binaries maybe modify kernel add drivers be self

Re: [beagleboard] Re: PRU Assumptions - True or False

Thanks Robert I love these instructions very well done my goal is to be able to build something stable from scratch not drop binaries maybe modify kernel add drivers be self sufficient at building everything and manually updating SD card as opposed to using an upgrade/update on the BB black.

Re: [beagleboard] Re: PRU Assumptions - True or False

On Fri, May 28, 2021 at 1:54 PM Robert Nelson wrote: > > > On Fri, May 28, 2021 at 1:45 PM Robert Nelson > wrote: > >> >> >> On Fri, May 28, 2021 at 1:39 PM 'Mark Lazarewicz' via BeagleBoard < >> beagleboard@googlegroups.com> wrote: >> >>> Dumb question by a Debian Newb >>> >>> I am following

Re: [beagleboard] Re: PRU Assumptions - True or False

On Fri, May 28, 2021 at 1:45 PM Robert Nelson wrote: > > > On Fri, May 28, 2021 at 1:39 PM 'Mark Lazarewicz' via BeagleBoard < > beagleboard@googlegroups.com> wrote: > >> Dumb question by a Debian Newb >> >> I am following this now Debian: Getting Started with the BeagleBone Black >>

Re: [beagleboard] Re: PRU Assumptions - True or False

On Fri, May 28, 2021 at 1:39 PM 'Mark Lazarewicz' via BeagleBoard < beagleboard@googlegroups.com> wrote: > Dumb question by a Debian Newb > > I am following this now Debian: Getting Started with the BeagleBone Black >

Re: [beagleboard] Re: PRU Assumptions - True or False

Dumb question by a Debian Newb I am following this now Debian: Getting Started with the BeagleBone Black | | | | | | | | | | | Debian: Getting Started with the BeagleBone Black This is a page about TI's Cortex-A8 based; BeagleBone Black. Availability Boards: BeagleBone Black at

Re: [beagleboard] Re: PRU Assumptions - True or False

On Fri, May 28, 2021 at 12:53 PM Robert Nelson wrote: > > On Fri, May 28, 2021 at 12:51 PM Robert Nelson > wrote: > > > > On Fri, May 28, 2021 at 12:47 PM Bruce Chidester > > wrote: > > > > > > Does the 5.x kernel support an interrupt from the PRU while also > > > supporting the

Re: [beagleboard] Re: PRU Assumptions - True or False

On Fri, May 28, 2021 at 12:51 PM Robert Nelson wrote: > > On Fri, May 28, 2021 at 12:47 PM Bruce Chidester > wrote: > > > > Does the 5.x kernel support an interrupt from the PRU while also supporting > > the bi-directional messaging through rproc? > > sorry, i completely missed these commits,

Re: [beagleboard] Re: PRU Assumptions - True or False

On Fri, May 28, 2021 at 12:47 PM Bruce Chidester wrote: > > Does the 5.x kernel support an interrupt from the PRU while also supporting > the bi-directional messaging through rproc? sorry, i completely missed these commits, so i have not personally tested it... It got merged in v5.11.x and has

Re: [beagleboard] Re: PRU Assumptions - True or False

Does the 5.x kernel support an interrupt from the PRU while also supporting the bi-directional messaging through rproc? On Friday, May 28, 2021 at 12:38:08 PM UTC-5 RobertCNelson wrote: > On Fri, May 28, 2021 at 12:36 PM Robert Nelson > wrote: > > > > On Fri, May 28, 2021 at 12:21 PM Bruce

Re: [beagleboard] Re: PRU Assumptions - True or False

On Fri, May 28, 2021 at 12:36 PM Robert Nelson wrote: > > On Fri, May 28, 2021 at 12:21 PM Bruce Chidester > wrote: > > > > I'm confused because I thought the plan was Remote Proc going forward. Do > > you seem to say it is UIO going forward? > > Mainline has been 'slowly' getting RemoteProc

Re: [beagleboard] Re: PRU Assumptions - True or False

At Fri, 28 May 2021 10:21:11 -0700 (PDT) beagleboard@googlegroups.com wrote: > > I'm confused because I thought the plan was Remote Proc going forward. Do > you seem to say it is UIO going forward? Only that the *stock* mainline kernels don't have Remote Proc support. I guess TI has not

Re: [beagleboard] Re: PRU Assumptions - True or False

On Fri, May 28, 2021 at 12:21 PM Bruce Chidester wrote: > > I'm confused because I thought the plan was Remote Proc going forward. Do you > seem to say it is UIO going forward? Mainline has been 'slowly' getting RemoteProc work done by TI.. Regards, -- Robert Nelson https://rcn-ee.com/ --

Re: [beagleboard] Re: PRU Assumptions - True or False

I'm confused because I thought the plan was Remote Proc going forward. Do you seem to say it is UIO going forward? On Friday, May 28, 2021 at 12:15:34 PM UTC-5 hel...@deepsoft.com wrote: > At Fri, 28 May 2021 12:59:20 -0400 beagl...@googlegroups.com wrote: > > > > > On Fri, 28 May 2021

Re: [beagleboard] Re: PRU Assumptions - True or False

At Fri, 28 May 2021 12:59:20 -0400 beagleboard@googlegroups.com wrote: > > On Fri, 28 May 2021 08:13:05 -0700 (PDT), in > gmane.comp.hardware.beagleboard.user Bruce Chidester > wrote: > > >I am using BBB Revision C > > > >Please help me get clarity on my assumptions that I believe I have

[beagleboard] Re: PRU Assumptions - True or False

Dennis, Thanks for your response. When developing with the UIO architecture, they use the term "interrupt", so I assume they meant it somehow, but not willing to die on that hill. I could not get any form of "what they called interrupt" to work the remote proc architecture. I tried, and

[beagleboard] Re: PRU Assumptions - True or False

On Fri, 28 May 2021 08:13:05 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Bruce Chidester wrote: >I am using BBB Revision C > >Please help me get clarity on my assumptions that I believe I have learned >so far and tell me where I am incorrect: Can't confirm for everything,

Re: [beagleboard] Re: PRU Messaging

Bruce  Make sure any approach you choose meets your requirement of using more RAM than the PRUS have available if this is still a requirement. Mark On Tuesday, May 25, 2021, 01:41:27 PM CDT, Darren Freed wrote: Bruce, I feel your frustration with getting familiar with PRU.  What I

Re: [beagleboard] Re: PRU Messaging

Thanks for the reference...everything helps. I will digest it as well. On Tuesday, May 25, 2021 at 1:41:32 PM UTC-5 darre...@gmail.com wrote: > Bruce, > > I feel your frustration with getting familiar with PRU. What I did, > working with the standard Debian that BB ships with (including

Re: [beagleboard] Re: PRU Messaging

Bruce, I feel your frustration with getting familiar with PRU. What I did, working with the standard Debian that BB ships with (including updates), was to start with Professor Yoder's PRUCookbook . That at least should get you going. He has

Re: [beagleboard] Re: PRU Messaging

Bruce  I agree with your assessment.There is no one way to do this I mentioned two.PRU cookbook and SDK Perhaps GitHub works as well.I know one method works doesn't mean others won't. I now understand better what you tried and where you got it from. Thanks . My parting comment is only an

Re: [beagleboard] Re: PRU Messaging

Other? (OK) When I mean others, I mean other people's post on this topic seems to get the message in dmesg, and looks like everyone else seems to get them fine. I however do not. The "other" I refer to, for example, is at: https://github.com/beagleboard/linux/issues/185 Laserman, I think

Re: [beagleboard] Re: PRU Messaging

Bruce What do " The Others" say is wrong? I have seen that PRU support package. In my reply last week it appears to me you have adopted what I call the apple  and oranges approach. I'm trying to say serious but I think "the other's" were a mysterious cult on star trek. These instructions look

[beagleboard] Re: PRU Messaging

I have a new image with 10.9 installed with an apt update; apt upgrade I wonder if my issue is around /dev/rpmsg_pru* Others suggest that after the following steps, the device shows up, but mine does not. cd /tmp git clone

[beagleboard] Re: PRU Messaging

Dennis, I have made a flasher and have flashed 10.9 image that you referred to me earlier. Re-adding everything on the system now and re-testing. Also processing the requests from Lazarman about the lab and quick start guide. Really appreciate the help On Tuesday, May 25, 2021 at 11:20:45

[beagleboard] Re: PRU Messaging

On Tue, 25 May 2021 07:40:20 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Bruce Chidester wrote: >*It is asking you to confirm which Beagle you are using.:* >I am using Beaglebone Black Revision C > > >*It will be much quicker to do an apt update/aptupgrade.:* >I performed the

[beagleboard] Re: PRU Messaging

*It is asking you to confirm which Beagle you are using.:* I am using Beaglebone Black Revision C *It will be much quicker to do an apt update/aptupgrade.:* I performed the update/upgrade and /etc/dogtag still reports the same info. Should I get a newer image? Is the issue my distro? On Monday,

[beagleboard] Re: PRU Messaging

On Mon, 24 May 2021 21:16:32 + (UTC), in gmane.comp.hardware.beagleboard.user "'Mark Lazarewicz' via BeagleBoard" wrote: >I don't own an AI and expecting someone to get your code and run it I can't do >it  is all I'm going to say. I can help guide you and MAYBE try it on BBWhite >if I

Re: [beagleboard] Re: PRU Messaging

@Dennis thanks for clarification I think his previous post a week ago  mentioned Bb AI but Bruce please don't assume everyone read your recent previous post is my advice. So you need to narrow down something after you reply to Dennis confirming you have correct Linux . Start with an unmodified

[beagleboard] Re: PRU Messaging

On Mon, 24 May 2021 10:25:57 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Bruce Chidester wrote: >*2 This is the BB AI correct?* >I do not know what this question means..please clarify. > It is asking you to confirm which Beagle you are using. > >*4 What is your ARM OS and

Re: [beagleboard] Re: PRU Messaging

*1 Most important what's it doing?* The original post was a link to all the code. It is at: https://gitlab.com/brucechidester/pru-messaging-example The Readme.txt file explains what I would like the solution to do. *2 This is the BB AI correct?* I do not know what this question means..please

Re: [beagleboard] Re: PRU Messaging

Hello Bruce in my opinion your missing some things important  1 Most important what's it doing?2 This is the BB AI correct?3 Where did this code come from?4 What is your ARM OS and version. Compiler host  details5 Brief Summary of what you tried  with important details(start from 5 and work

[beagleboard] Re: PRU Messaging

Maybe some code in the post will promote some response: *Main Application:* #include #include #include #include #include #include #include #define DEVICE_NAME "/dev/rpmsg_pru30" int main(int argc, char* argv[]) { int result = 0; struct pollfd pollfds[1]; pollfds[0].fd

Re: [beagleboard] Re: PRU I/O max speed

It was really a ping-pong buffer, not a ring. I did check the timing with an Agilent 54846B scope. this is snipped from a backup copy, I have re-purposed the BBB I did comment about this here already a year ago or so. My memory about that gets fuzzy... volatile register unsigned int __R30; 

Re: [beagleboard] Re: PRU I/O max speed

; > > > > > *From:* beagleboard@googlegroups.com > *On Behalf Of *Andrew P. Lentvorski > *Sent:* Thursday, April 22, 2021 5:01 AM > *To:* BeagleBoard > > *Subject:* [beagleboard] Re: PRU I/O max speed > > > > I would be stunned if the GPIOs don't

Re: [beagleboard] Re: PRU I/O max speed

limit. *From:* beagleboard@googlegroups.com *On Behalf Of *Andrew P. Lentvorski *Sent:* Thursday, April 22, 2021 5:01 AM *To:* BeagleBoard *Subject:* [beagleboard] Re: PRU I/O max speed I would be stunned if the GPIOs don't have synchronizer flip-flops as they are sampling a signal

RE: [beagleboard] Re: PRU I/O max speed

stopped working. There is definitely a speed limit. From: beagleboard@googlegroups.com On Behalf Of Andrew P. Lentvorski Sent: Thursday, April 22, 2021 5:01 AM To: BeagleBoard Subject: [beagleboard] Re: PRU I/O max speed I would be stunned if the GPIOs don't have synchronizer flip-flops

[beagleboard] Re: PRU I/O max speed

I would be stunned if the GPIOs don't have synchronizer flip-flops as they are sampling a signal asynchronous to the 200MHz clock. That would account for 2 clocks. You probably need one extra to clock data into R31. And then one clock to read R31. 50MHz is a pretty smoking speed for

Re: [beagleboard] Re: PRU cycle counter overflow

This isn't directly from TI but I found essentially the same code on in a TI lab or online somewhere. https://www.element14.com/community/community/designcenter/single-board-computers/next-genbeaglebone/blog/2019/08/12/beaglebone-pru-timer-functionality On Wednesday, April 21, 2021 at

Re: [beagleboard] Re: PRU cycle counter overflow

Hello Walter  Which TI  PRU examples are you using I've seen so many examples I've lost track. I've seen the archive that contains  the labs1 to labs 6.  Sent from Yahoo Mail on Android On Wed, Apr 21, 2021 at 2:55 PM, Walter Cromer wrote: Well the solution to the overflow was actually

Re: [beagleboard] Re: PRU cycle counter overflow

Well the solution to the overflow was actually simple. I had used some example code from TI where they use the value 0x to clear the IEP's counter. That didn't really make sense to me except of course if your very next instruction was to start the timer which would cause it to

Re: [beagleboard] Re: PRU cycle counter overflow

This Might be helpful Justin  helpful  https://e2e.ti.com/support/processors/f/processors-forum/209489/am335x-iep-interrupt #Or does it access the IEP clock over some bus Page 14 the block diagram in PRU Sub system pdf shows what's local to PRU so I would say not possible in one cycle. I also

Re: [beagleboard] Re: PRU cycle counter overflow

I'm attempting something very similar to what you were working on. If you are willing, please share how you eventually did this. Did you use the IEP clock or the PRU's cycle counter? I have IEP working with the iep_clk (although I'm having terrible RPMSG problems right now). Also, I can't

Re: [beagleboard] Re: PRU remoteproc1 and 2 missing

On Wed, Apr 7, 2021 at 5:15 PM Cheng Chen wrote: > > Hi Dennis, > > I am following second edition. > I actually tried both 4.14 and 4.19. Either of them does not work. > But it looks like Robert's comment solves the issue. Thanks for your > suggestion though. Ah, missed that.. Yeah, it "should

[beagleboard] Re: PRU remoteproc1 and 2 missing

Hi Dennis, I am following second edition. I actually tried both 4.14 and 4.19. Either of them does not work. But it looks like Robert's comment solves the issue. Thanks for your suggestion though. Regards, Cheng 在2021年4月7日星期三 UTC-4 下午6:06:10 写道： > On Wed, 7 Apr 2021 09:31:04 -0700 (PDT),

[beagleboard] Re: PRU remoteproc1 and 2 missing

On Wed, 7 Apr 2021 09:31:04 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Cheng Chen wrote: >I am following the Molloy's book chapter 15 to learn PRU. First or Second edition? >kernel:[4.19.94-ti-r42]

Re: [beagleboard] Re: PRU RemoteProc documentation

Hi Fischer  what I meant to say is the AM57xx is definitely more complicated as there's more cores and that will definitely break quickly  without correctly modifying the table for the DSP or M4.   There's absolutely no docs beyond the SDK and many people are not using  SDK they use the Debian

Re: [beagleboard] Re: PRU RemoteProc documentation

Hi Mark, Thanks for your reply, yes, I've not seen a lot posted about remoteProc when I searched, and I know it has to be an important issue due to at least PRU interest being almost totally based on it. Even with JTAG and directly programming your code into the PRUs, Linux still has to

Re: [beagleboard] Re: PRU RemoteProc documentation

Hello Fischer  This file looks like it's processing the resource table  https://docs.huihoo.com/doxygen/linux/kernel/3.7/remoteproc__core_8c_source.html * 804  * take a firmware and boot a remote processor with it. 805  */ 806  static int rproc_fw_boot(struct rproc *rproc, const struct

[beagleboard] Re: PRU RemoteProc documentation

Hi all, I solved my issue in the end of it not booting, or causing errors with "L3_main" in the title from remoteProc to dmesg. The issue turned out to be both having interrupts from the IEP timer, and that C++ needs .init_array in the linker command file to actually initialise the

[beagleboard] Re: PRU I/O max speed

With a sample size of one, r31 appears to be 4 instructions behind the state of the pin. On Thursday, February 25, 2021 at 12:26:16 PM UTC-5 Paul Beam wrote: > I am, unfortunately, bit-banging SPI with the PRU, and I seem to be > running into a speed limit < 50 MHz I desire. I can certainly

[beagleboard] Re: PRU RemoteProc documentation

The error message is emitted from the system bus driver (drivers/bus/omap_l3_noc.c ). I interpret it as a bug in your PRU firmware. When issue occurs, please try to inspect the PRU state. See https://zeekhuge.me/post/ptp_docs_commands_and_tools/ , or use JTAG. Regards, Dimitar On Thursday,

[beagleboard] Re: PRU RemoteProc documentation

Hi Dimitar, Thanks for your reply, yes, I don't understand that as its code to flash lights. Its built with different states, which makes it more complicated, but only flashes LEDs. How can I know what the kernel module is doing so I can see more details and know where to look? Such as, is

[beagleboard] Re: PRU RemoteProc documentation

Looks like PRU attempts to access PCIE1 address space. I suspect it's a bug in your PRU firmware. MASTER PRUSS2 PRU1 TARGET PCIE1 (Read): At Address: 0x00806664 TI has tutorials how to use JTAG to debug PRU. Another option is https://markayoder.github.io/PRUCookbook/04debug/debug.html

[beagleboard] Re: PRU 2 0 memory addresses

On Mon, 4 Jan 2021 19:46:53 -0300, in gmane.comp.hardware.beagleboard.user Vinicius Juvinski wrote: > >My main question is how to use the offsets. By adding them to the correct BASE address... >How 0x0002_2000 will become 0x4B2A2000? From my previous post: > Page 397

[beagleboard] Re: PRU 2 0 memory addresses

Hi Dennis, thanks. Im migrating a cape BBBMINI - Ardupilot cape for beaglebones. I will test, thanks again. Em segunda-feira, 4 de janeiro de 2021 01:41:09 UTC-3, Dennis Bieber escreveu: > > On Sun, 3 Jan 2021 17:50:17 -0800 (PST), in > gmane.comp.hardware.beagleboard.user Vinicius Juvinski

[beagleboard] Re: PRU 2 0 memory addresses

On Sun, 3 Jan 2021 17:50:17 -0800 (PST), in gmane.comp.hardware.beagleboard.user Vinicius Juvinski wrote: > >Anyone please help me in what is the addresses for PRU2_0 for this >addresses ? I tried all the addresses I found at AM5729 Reference manual >and digging the filesystem I achived this

[beagleboard] Re: PRU - I2C on BBAI (WAS: PRU - ADC on BBAI

On Wed, 2 Dec 2020 11:32:35 -0800 (PST), in gmane.comp.hardware.beagleboard.user bryan-1jvaXrIyeqQEMDE80E2L+VaTQe2KTcn/@public.gmane.org wrote: >Hey Dennis, > >Do you have any insight into whether that PRUDAQ module referenced by >Pierrick will work with the Ai without much (if any)

[beagleboard] Re: PRU - I2C on BBAI (WAS: PRU - ADC on BBAI

Hey Dennis, Do you have any insight into whether that PRUDAQ module referenced by Pierrick will work with the Ai without much (if any) modification? On Tuesday, October 20, 2020 at 9:18:42 AM UTC-6, Dennis Bieber wrote: > > On Tue, 20 Oct 2020 05:33:26 -0700 (PDT), in >

[beagleboard] Re: PRU - ADC on BBAI

Hi Denis, Thanks for the help and sorry that I only answer now. I understand what you mean with the I2C, I tried to change the topic of the post without luck yet. I am starting to work on that with the examples you have provided. Do you think that the PRUDAQ project (here

[beagleboard] Re: PRU Memory Store Instruction with Autoincrement?

@Dimitar SBBO is a two-cycle instruction. In order to get 200 MHz you've to use MOV. @Andrew The MVIx family of instructions provides an auto-increment feature. But it doesn't really help. Like Dimitar suggested it's best to code a sequence of immediate operations to store a burst of

[beagleboard] Re: PRU Memory Store Instruction with Autoincrement?

BeagleLogic[1] does some interesting tricks[2] to get a solid 100MHz sampling rate. The *PRU Cookbook* presents an overview of it. Check it out. --Mark [1] https://beaglelogic.readthedocs.io/en/latest/ [2]

[beagleboard] Re: PRU Memory Store Instruction with Autoincrement?

Hmm, that's an interesting idea, Dimitar, to encode the increment in the immediate. That's probably ... useful. That mechanism would give me a 64-sample burst per register which could possibly get me to 1920 samples *if* the SBBO doesn't stall out anywhere. I thought about the BeagleLogic,

[beagleboard] Re: PRU Memory Store Instruction with Autoincrement?

Hi, Do you require continuous 200MHz sampling? That would be difficult I think. If you require bursts of 200MHz sampling, how long should those bursts be? Even if you find autoincrement opcode, you would still need to add one jump instruction to "loop". You can try hardcoding the "increment"

[beagleboard] Re: PRU Memory Store Instruction with Autoincrement?

On Sun, 18 Oct 2020 00:16:44 -0700 (PDT), in gmane.comp.hardware.beagleboard.user "Andrew P. Lentvorski" wrote: > >As that stands, that's a 100MHz sample of R31. Is there anyway to do the >autoincrement on the store? That would double my sampling rate to 200MHz >which would be the maximum

Re: [beagleboard] Re: PRU - ADC on BBAI

I stumbled on this although it does reference the stmpe811 as a touch screen controller: https://lore.kernel.org/linux-devicetree/20191119202850.18149-2-c-ro...@ti.com/ Jon On Tue, Sep 15, 2020 at 9:45 AM Dennis Lee Bieber wrote: > On Mon, 14 Sep 2020 15:34:35 -0700 (PDT), in >

[beagleboard] Re: PRU - ADC on BBAI

On Mon, 14 Sep 2020 15:34:35 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Pierrick Rauby wrote: >Hi Denis, >Thanks for your answer, I agree with you that both boards have an ADC. I >think my initial message was miss-leading. > >comes to the Beaglebone AI, it is based on the

[beagleboard] Re: PRU - ADC on BBAI

Hi Denis, Thanks for your answer, I agree with you that both boards have an ADC. I think my initial message was miss-leading. The main difference is that the Beaglebone Bone Black is based on the ti-am335x which as a built-in ADC (tsc-adc module), for this configuration there is indeed

[beagleboard] Re: PRU - ADC on BBAI

On Mon, 14 Sep 2020 07:56:55 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Pierrick Rauby wrote: >Hi All, >I am trying to implement deterministic data acquisition on the Beaglebone >AI. >I was thinking of using the PRU with the ADC as it is done on one the >TechLab example

[beagleboard] Re: PRU interrupt program

On Mon, 13 Jul 2020 10:32:37 -0700 (PDT), in gmane.comp.hardware.beagleboard.user t.n.jayasudhaa-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: >Hello, > >I am trying to configure a low latency interrupt to detect change in GPIO >input pin i.e. input to Beagle Bone AI changes from 0 ->1 or 1-> 0

[beagleboard] Re: PRU IEP timers non-responsive

Ok I figured it out lol. I was adding the actual byte-size offsets to pointers to longs, so it was being offset by 4x as much as I would have expected. The program works fine otherwise. On Monday, June 15, 2020 at 11:47:30 AM UTC-4, Fred Frey wrote: > > Hello > > I'm trying to write a simple

[beagleboard] Re: PRU pins on BBAI

It's not a problem. I'm just surprised to see several on the ICSS2 PRU0 pins are attached to the header in two places. --Mark On Thursday, June 4, 2020 at 2:13:10 PM UTC-4, Mark A. Yoder wrote: > > I see that the SRM[1] ([2] is easier to read) for the BBAI shows that some > PRU pins appear at

[beagleboard] Re: PRU phandle is changing

Which kernel version are you using? Can you post your DTS changes? Yes, it is expected phandle to have different value for different DTBs. See https://elinux.org/Device_Tree_Mysteries#Phandle Personally I found it much easier to use rpmsg, which sits on top of remoteproc. The mainline example

[beagleboard] Re: PRU phandle is changing

Hi! I'm facing the same issue... Have you found a way to get pruss running from kernel module? Best regards Igor On Wednesday, 10 July 2019 02:10:18 UTC+2, kaigeis...@googlemail.com wrote: > > I'm writing a kernel driver that needs to control the PRUs' state using >

[beagleboard] Re: PRU example does not work

I did some further investigations. It's not a problem of the examples, I guess. If I directly address the PRUs via the linux system with echo 'start' > /sys/class/remoteproc/remoteprocX/state I get a write error: Invalid argument. My COM connections says remoteproc remoteprocX: Boot failed:

[beagleboard] Re: PRU example does not work

Sry, I totally forgot about this one. I just came back to playing around with the cloud9 examples. The pru examples work, if you take the right runner (which is C or C++ Beagle Makefile). In the meantime, I did a few things to my BB AI, e.g. I patched the kernel to 4.14.108-ti-xenomai-r127.

Re: [beagleboard] Re: PRU based Apple IIe videocard

@TJF, I'm a beginner here, and I used RemoteProc for PRU initialization... I'm going to read in depth this thread from 3 years ago, to understand better your opinion as well :) https://groups.google.com/forum/#!msg/beagleboard/cYHCN3GWw_E/nfPhNHy0BQAJ On Fri, Nov 22, 2019 at 4:49 PM TJF wrote:

Re: [beagleboard] Re: PRU based Apple IIe videocard

> On PRU-1 you can use 15 inputs and 16 outputs. Only on PRU-0 you can use > the full set of PINS (16 IN/17 OUT). For the later case you have to build a > custom SD-Slot connector. > > Find details at > http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaTNT.html#SecPruGpio >

Re: [beagleboard] Re: PRU based Apple IIe videocard

Hi! Am Donnerstag, 21. November 2019 19:43:49 UTC+1 schrieb Tomas Espeleta: > > If you have more bits in less time (higher frequency), this approach > unfeasible... but if the clock is low enough and you don't need HDMI, you > can play with PRU1 and use 16bits + some bits of control > On

Re: [beagleboard] Re: PRU based Apple IIe videocard

Hi Dan, For HDMI I share memory with the ARM core and there is a program running in userspace and interpreting video memory. (I use SDL for output). I suppose that your idea feasibility depends on the clock: with the 1Mhz of the apple ][ clock I had to capture 3 bytes in 489ns (half cycle). But

Re: [beagleboard] Re: PRU based Apple IIe videocard

I agree. PRUs are an amazing resource in the beaglebone computers - and - it is unfortunate there aren't more pins. I have an idea for a project along similar lines, to use the PRUs to emulate a bus master for a now obsolete workstation bus. It's 32 bits wide and I was thinking of an approach

Re: [beagleboard] Re: PRU based Apple IIe videocard

Thanks Dan! Yep, I created two versions: one capturing READS + interpreting the video address, and another one capturing the 6502 writes. With the latter was much easier to tune the timings, so that's what I'm doing. I use 8 bits in parallel, hooking the BBB to the Apple II peripherals bus. I

[beagleboard] Re: PRU based Apple IIe videocard

Very neat Tomas! A PRU is capturing the write to the video memory? Are you reading the data in via a parallel interface or serializing it? Cheers, Dan On Wednesday, November 20, 2019 at 9:19:44 AM UTC-7, Tomas Espeleta wrote: > > Helllo Guys, > I just wanted to share the first steps of my

[beagleboard] Re: PRU does not start.

I'm having the same issue and wondering if this was resolved? I'm getting the exact same error message when trying to start and here is my tail of dmesg [ 86.179253] pruss 4a30.pruss: creating PRU cores and other child platform devices [ 86.211623] remoteproc remoteproc1:

[beagleboard] Re: PRU Remoteproc Carveout Access from Userspace

Hallo Kai, Thanks for the suggestion. I considered doing something like that, and am still weighing my options. I have competing interests of wanting to make this usable for anyone who might be able to, wanting to keep it as simple as possible for myself, wanting to do things the most

[beagleboard] Re: PRU Remoteproc Carveout Access from Userspace

Hi Bill, I just did something very similar. If you have a working communication channel between PRU and user space anyway (probably RPMsg), you could read the location from the PRU code using: myvar = resourceTable.shared_mem.pa; and communicate that address to user space using RPMsg. If

Re: [beagleboard] Re: PRU Communications: Beaglebone Black

Yes, that's a further option. You can HALT one PRU and restart it by setting bit 1 (ENABLE) in the CONTROL register, using the other PRU. But note, you also have to increase the STATUS register, in order to jump over the HALT statement. Regards -- For more options, visit

Re: [beagleboard] Re: PRU Communications: Beaglebone Black

Thanks much. We are going to use this as a standby and try using the PRU core register flag setting as a default option. On Tue, Jul 2, 2019 at 11:21 PM TJF wrote: > Am Dienstag, 2. Juli 2019 19:23:19 UTC+2 schrieb Venkatesh Vadde: >> >> >> Thanks, TJF. Any PRU documentation on the access

Re: [beagleboard] Re: PRU Communications: Beaglebone Black

Am Dienstag, 2. Juli 2019 19:23:19 UTC+2 schrieb Venkatesh Vadde: > > > Thanks, TJF. Any PRU documentation on the access rules and how to avoid a > memory contention? > Find details in https://elinux.org/images/d/da/Am335xPruReferenceGuide.pdf In the DRAM each PRU has prefered access to its

  1   2   3   4   5   >