Even Nick the TI resident PRU genius used 2 PRU to implement his FOC reference design.The AM64 demo app uses one Cortex ARM R4 to do the same thing. On a SOC like AM64x the PRU would only be needed if you ran out of peripherals.Amazing demo one R4 is running FFT no need to pass anything back to A53. The Application core(A53) is nothing more than a network gateway wired or wireless and a GUI Host. That turns Linux programmers into PC programmer's 🤭 and the Real Time programming is done in RTOS.Maybe in next release with quick boot they will fix RPMSg make it faster. Perhaps they ported libprio 👺 fixed it and documented it properly
Sent from Yahoo Mail on Android On Fri, Jun 18, 2021 at 2:58 AM, 'Mark Lazarewicz' via BeagleBoard<beagleboard@googlegroups.com> wrote: Slightly off subject but to me this AM64 looks big https://training.ti.com/sitara-am64x-processors-combine-powerful-communication-and-real-time-performance 1Meg of SRAM split between the 4 Cortex R4 that can run bare metal or Free RTOS and in next release instead of waiting for Linux to boot to load the firmware by Rproc it's loaded in about 500 mS. Supports Linux on dual A53 has 2 PRU and a 5th R5 onboard JTAG and GUI creator for Linux side and supports BLE and WiFi ( not sure if that's an add on) $99 for starter kit. I've ordered one Not sure if PRU has access to all that fast SRAM but anything done by the PRU can certainly be done by any of the R4 which has REAL interrupts and much easier to rapidly code and debug than the PRU. No hocus pocus transferring large amounts of Data from PRU or R4 using slow DDR and spending months trying to squeeze a few bytes of memory for the PRU😂👌🤭 Sent from Yahoo Mail on Android On Wed, Jun 16, 2021 at 11:52 AM, 'Mark Lazarewicz' via BeagleBoard<beagleboard@googlegroups.com> wrote: Both PRUs exchange the last ring buffer writing position by DRam (or scratch pad). Too many RAMS we need to be clear to avoid confusion please DDR is DRAM Internal RAM is SRAM and there are several SBL ARM internal SRAM (fast from ARM)PRU shared RAMPRU data and instruction RAM( fastest for PRU)The Shared SRAM between ARM and PRU and any DSP on other chips( used by rproc??) Thanks Sent from Yahoo Mail on Android On Tue, Jun 15, 2021 at 7:27 AM, TJF<jeli.freih...@gmail.com> wrote: I don't understand that concept. When you switch bits in the STEPENABLE register, you'd loose accurate ADC timing. What sampling rate are you talking about? AFAIR your target is to controlling two eletromagnetic valves (water medium?). They've a latency of more than 10 ms -> sampling rate & controller loop should be 1 kHz or above. When sampling all 5 channels continguously in one FIFO and fetching them by one PRU in a ring buffer (SRam), you can do this with accurate timing up to 40 kHz (more than enough). Meanwhile the other PRU evaluates the ring buffer, computing the standard channels (4 &) continguously and the other channels (1, 2, 3) on demand. Note: There're 1000 PRU cycles between two ADC samples, and 5000 PRU cycles between a sequencer loop (@ 40kHz). Both PRUs exchange the last ring buffer writing position by DRam (or scratch pad). This alternative concept does not only guarantee accurate timing, it's also easy to develop and maintain. BTW: It doesn't matter which PRU (or the ARM) does the configuration. Just starting the sequencer (CTRL register) should be done by the ADC-PRU. wal...@edenconceptsllc.com schrieb am Montag, 14. Juni 2021 um 19:55:30 UTC+2: I am thinking that I'll have PRU0 do all the configuration and enabling of the TSC and have the values for the two sensors that I want PRU1 to monitor put in FIFO1. I'll have PRU0 only read from FIFO0 and let PRU1 only read from FIFO1. I will set up the three I want to read in one-shot mode and have PRU0 enable them to be read again. the other two will be in continuous mode so PRU0 won't have to do anything as long as it doesn't change their configuration. If PRU-1 waits until PRU-0 is done then it can read FIFO1 as needed to get the data. I only need it to read these possibly as little as once per second so that alone will reduce the number of potential conflicts with PRU0. If this will work it will eliminate having PRU0 read FIFO1 and write the data into shared memory space where PRU1 could read it. That in itself would have a potential conflict on PRU0 write/PRU1 read.On Sunday, June 13, 2021 at 11:38:06 AM UTC-4 TJF wrote: wal...@edenconceptsllc.com schrieb am Freitag, 11. Juni 2021 um 18:44:27 UTC+2: ... setting up steps 1, 2 and 3 to read three analog lines in one-shot mode while steps 4 & are set up to read the other two analog lines in continous mode. I'll write data from steps 1, 2 and 3 into FIFO0 and 4 & 5 into FIFO1. Yes. You can use the FIFO_select bit (26) in the STEPCONFIGx registers to spread the samples. And when the Mode bits (1-0) are cleared (one-shot) the sequencer will disable that step after operation (in STEPENABLE register). Next turn the sequencer will again consider only enabled steps. The question is can PRU0 read FIFO0 while PRU1 might try to read FIFO1 at the same time? Not at the same time, but one after the other (L3 access control). AFAIR PRU-1 waits until PRU-0 is done. And both PRUSS are waiting until ARM is done. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/229ebebd-2672-449b-a9ac-5ff2c99d2027n%40googlegroups.com. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1443649067.432564.1623862352620%40mail.yahoo.com. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1340062927.789145.1624003075764%40mail.yahoo.com. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/711160824.788124.1624004408043%40mail.yahoo.com.
