Re: [beagleboard] Re: Debug serial console not working
Hello Vinay Good News. I offer some good advice. If your career path is embedded software engineer as opposed to Linux application programmer buy these Jumper's. You could have fixed your cable easily but more importantly you can hook up o scope and logic analyzer and probe connectors. Today's logic analyzer very cheap used to be very expensive they also decode protocol's Cheers Here are Jumper's you could also make these soldering is also a good skill to have in your toolkit https://www.adafruit.com/product/758 Mark Sent from Yahoo Mail on Android On Mon, Jul 5, 2021 at 11:58 AM, Dennis Lee Bieber wrote: On Mon, 5 Jul 2021 13:34:17 +0530, in gmane.comp.hardware.beagleboard.user Vinayakumar Chikkadi wrote: >The pin positions for 5v, gnd, Rx, Tx on cable are not matching with J1 >header on bbb. > 5V is a danger already... A Raspberry-Pi serial<>USB (came with a Sparkfun Pi-Wedge) runs DTR Rx Tx 3.3V CTS GND Which is NOT compatible with BBB (the Rx and Tx are swapped). https://elinux.org/Beagleboard:BeagleBone_Black_Serial "The debug cable is a standard FTDI to TTL cable. Make sure you get the 3.3V version." Personally, the AdaFruit cable is probably more flexible as the four pins are free to connect anywhere, not tied to a specific sequence in one header. -- Dennis L Bieber -- 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/7de6egl8q3n7cc5h8ej7mtsnafm6dmvutt%404ax.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/172522526.1617223.1625512987213%40mail.yahoo.com.
Re: [beagleboard] Re: Debug serial console not working
Hi Vinay For future reference if you use a Ubuntu VM serial window the terminal can have no info like you see because the USB driver is claimed by Windows. That can be fixed in the VM but in my experience the connection can be intermittent when using VM. The nice thing about using Ubuntu VM is you could check your cable in Windows first and then get the appropriate drivers installed ( test cable). Something to keep in mind for future. The VM approach has issues with creating SD cards so yet another option is a dual boot Ubuntu/ Windows PC . Best wishes on finding a cable quickly. I'm sure you are excited to play with your board. Mark Sent from Yahoo Mail on Android On Sat, Jul 3, 2021 at 12:40 AM, Vinayakumar Chikkadi wrote: Hi Mark, Good day to you Saw this article it would help me to procure one. Thanks for your inputs. Regards,Vinay On Sat, 3 Jul 2021 at 5:05 AM, 'Mark Lazarewicz' via BeagleBoard wrote: Using Serial Debug Port on BeagleBone Black - KiranPalla.com | | | | || | | | | | Using Serial Debug Port on BeagleBone Black - KiranPalla.com It is interesting to see boot messages while the OS is coming up on BeagleBone Black. The messages are useful … | | | | Sent from Yahoo Mail on Android On Fri, Jul 2, 2021 at 12:44 PM, Dennis Lee Bieber wrote: On Fri, 2 Jul 2021 15:44:12 +0530, in gmane.comp.hardware.beagleboard.user Vinayakumar Chikkadi wrote: >I am using the prolific usb to serial connector. After I connect the usb WHICH "prolific usb to serial"? They have a whole slew of different models. And that doesn't count the packagers using a Prolific chip in their products (cf: https://www.amazon.com/prolific-usb-serial/s?k=prolific+usb+to+serial ) I'm guessing something similar to https://www.amazon.com/Serial-Adapter-Signal-Prolific-Windows/dp/B07R8BQYW1/ref=sr_1_8?dchild=1=prolific+usb+to+serial=1625245702=8-8 I can't really help with Prolific -- most of my USB<>serial devices are FTDI chips. I think the Adafruit 4-pin cable is the only Prolific chip device I have. >cable & When I check on Ubuntu with dmesg | tail >I could see it’s getting enumerated as ttyUSB0 >When I open with putty on the path >/dev/ttyUSB0 with 115200 8N1 >I am not able to open the com port using putty. Do you have privileges for the device? May not be relevant, but connecting a USB<>Serial to the USB side of my BBB (I don't have a native Linux desktop computer, and Windows won't be helpful to you) shows up like crw-rw 1 root dialout 188, 0 Jul 2 13:21 /dev/ttyUSB0 the default user for the machine does belong to the dialout group. I got the same thing for Debian running inside VirtualBox /after/ manually selecting the USB device from the VB0x menu... BUT... unlike the BBB, my user account under VBox does NOT belong to the dialout group, so I would have not permission to use it without making changes... crw-rw 1 root dialout 188, 0 Jul 2 13:31 /dev/ttyUSB0 wulfraed@debian:~$ groups wulfraed cdrom floppy sudo audio dip video plugdev netdev bluetooth lpadmin scanner vboxsf wulfraed@debian:~$ sudo usermod -a -G dialout wulfraed [sudo] password for wulfraed: wulfraed@debian:~$ groups wulfraed dialout cdrom floppy sudo audio dip video plugdev netdev bluetooth lpadmin scanner vboxsf wulfraed@debian:~$ -- Dennis L Bieber -- 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/rqhudg5e0ekfsmaetfe966socu9l1telkn%404ax.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/1430302616.2000350.162526373%40mail.yahoo.com. -- V.K.CHIKKADI -- 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/CA%2BqvWETA5eg1sbWQCHVDPpyxSgwVzu22yhOJzRiLiBwW7jSbGQ%40mail.gmail.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
Re: [beagleboard] Re: Debug serial console not working
Using Serial Debug Port on BeagleBone Black - KiranPalla.com | | | | || | | | | | Using Serial Debug Port on BeagleBone Black - KiranPalla.com It is interesting to see boot messages while the OS is coming up on BeagleBone Black. The messages are useful … | | | | Sent from Yahoo Mail on Android On Fri, Jul 2, 2021 at 12:44 PM, Dennis Lee Bieber wrote: On Fri, 2 Jul 2021 15:44:12 +0530, in gmane.comp.hardware.beagleboard.user Vinayakumar Chikkadi wrote: >I am using the prolific usb to serial connector. After I connect the usb WHICH "prolific usb to serial"? They have a whole slew of different models. And that doesn't count the packagers using a Prolific chip in their products (cf: https://www.amazon.com/prolific-usb-serial/s?k=prolific+usb+to+serial ) I'm guessing something similar to https://www.amazon.com/Serial-Adapter-Signal-Prolific-Windows/dp/B07R8BQYW1/ref=sr_1_8?dchild=1=prolific+usb+to+serial=1625245702=8-8 I can't really help with Prolific -- most of my USB<>serial devices are FTDI chips. I think the Adafruit 4-pin cable is the only Prolific chip device I have. >cable & When I check on Ubuntu with dmesg | tail >I could see it’s getting enumerated as ttyUSB0 >When I open with putty on the path >/dev/ttyUSB0 with 115200 8N1 >I am not able to open the com port using putty. Do you have privileges for the device? May not be relevant, but connecting a USB<>Serial to the USB side of my BBB (I don't have a native Linux desktop computer, and Windows won't be helpful to you) shows up like crw-rw 1 root dialout 188, 0 Jul 2 13:21 /dev/ttyUSB0 the default user for the machine does belong to the dialout group. I got the same thing for Debian running inside VirtualBox /after/ manually selecting the USB device from the VB0x menu... BUT... unlike the BBB, my user account under VBox does NOT belong to the dialout group, so I would have not permission to use it without making changes... crw-rw 1 root dialout 188, 0 Jul 2 13:31 /dev/ttyUSB0 wulfraed@debian:~$ groups wulfraed cdrom floppy sudo audio dip video plugdev netdev bluetooth lpadmin scanner vboxsf wulfraed@debian:~$ sudo usermod -a -G dialout wulfraed [sudo] password for wulfraed: wulfraed@debian:~$ groups wulfraed dialout cdrom floppy sudo audio dip video plugdev netdev bluetooth lpadmin scanner vboxsf wulfraed@debian:~$ -- Dennis L Bieber -- 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/rqhudg5e0ekfsmaetfe966socu9l1telkn%404ax.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/1430302616.2000350.162526373%40mail.yahoo.com.
Re: [beagleboard] Debug serial console not working
Try this https://www.dummies.com/computers/pcs/hardware/serial-ports-on-your-pc/ Sent from Yahoo Mail on Android On Fri, Jul 2, 2021 at 5:14 AM, Vinayakumar Chikkadi wrote: Hi I am trying to get the debug serial working on Ubuntu for my beagle bone black board. I am powering up the BBB with the 5V 2A power adapter. I am using the prolific usb to serial connector. After I connect the usb cable & When I check on Ubuntu with dmesg | tailI could see it’s getting enumerated as ttyUSB0 When I open with putty on the path /dev/ttyUSB0 with 115200 8N1I am not able to open the com port using putty. Kindly suggest if any of the steps missing out here. Best regards,Vinay -- V.K.CHIKKADI -- 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/CA%2BqvWES1aW44NhvDLe%2BVXdaJtoLNogJcJNRZUigcoGYLP-49sw%40mail.gmail.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/1045830782.1883127.1625238697486%40mail.yahoo.com.
Re: [beagleboard] Re: Reading ADC with both PRUs
Ooops I forgotten. I'm pretty sure the Matlab to implement FOC is already a possibility on Cortex R4 that's never going to happen for PRU Vector control, also called field-oriented control (FOC), is a variable-frequency drive (VFD) control method in which the stator currents of a three-phase AC or brushless DC electric motor are identified as two orthogonal components that can be visualized with a vector. Sent from Yahoo Mail on Android On Fri, Jun 18, 2021 at 3:20 AM, 'Mark Lazarewicz' via BeagleBoard wrote: 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 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 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 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
Re: [beagleboard] Re: Reading ADC with both PRUs
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 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 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 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
Re: [beagleboard] Re: Reading ADC with both PRUs
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 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 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. --
Re: [beagleboard] Re: Reading ADC with both PRUs
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 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.
Re: [beagleboard] Re: Reading ADC with both PRUs
#The question is can PRU0 read FIFO0 while PRU1 #might try to read FIFO1 at the same time? If these FIFOS are in Data RAM it's recommended to use shared memory. What's confusing is as I understood it there's a PRU shared RAM and another larger shared memory so sample code must be inspected carefully if that's true to understand exactly what's being referred to as Shared. I think the larger RAM is called OCM. Below and following link is the relavent blurb to support my comment I found here https://elinux.org/Ti_AM33XX_PRUSSv2 - One PRU may access the memory of another for passing information but it is recommend to use scratch pad or shared memory, see below. - Open Core Protocol (OCP) master port - Access to the data bus that interconnects all peripherals on the SoC, including the ARM Cortex-A8, used for data transfer directly to and from the PRU in Level 3 (L3) memory space. Shared Between PRUs - Scratch pad - 3 banks of 30 32-bit registers (total 90 32-bit registers). - Single-cycle access, can be accessed from either PRU for data sharing and signalling or for individual use. - 12KB data memory - Accessed over the 32-but bus, not single-cycle. Sent from Yahoo Mail on Android On Sun, Jun 13, 2021 at 10:38 AM, 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/f4f5965c-6350-442a-b91a-47b7535d9cecn%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/1993917417.3764103.1623655390603%40mail.yahoo.com.
Re: [beagleboard] Re: Reading ADC with both PRUs
Hello Walter Two ansychronous processor's it's entirely possible eventually ones writing and other is reading and gets bad Data that's why they invented hardware dual port ram. Ping pong circular buffer's work on one processor systems you disable interrupts in critical regions or lock it with a mutex controlled by RTOS. Perhaps it's not critical How long have you been waiting on an answer just curious? Mark Sent from Yahoo Mail on Android On Fri, Jun 11, 2021 at 12:33 PM, Dennis Lee Bieber wrote: On Fri, 11 Jun 2021 09:44:27 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Walter Cromer wrote: >I can have PRU1 do all the ADC configuration including 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. > >The question is can PRU0 read FIFO0 while PRU1 might try to read FIFO1 at >the same time? Given that each PRU is capable of accessing the other's data RAM (as I recall, each PRU sees its RAM at address 0, and sees the other's RAM at some fixed offset), I'd probably use a few words of PRU0's RAM and have PRU1 write into that space, along with a timestamp value -- PRU0 would look for a change in the timestamp, then grab the ADC values (allowing PRU1 to write new values while PRU0 processes the previous set -- Or PRU0 clears the timestamp [which is no longer a timestamp] which PRU1 sees as "okay to write new values", PRU1 then sets the timestamp byte to tell PRU0 "okay to read". Closest I can come to a shared semaphore/mutex (are there any synchronization primitives in the PRU runtime?). -- Dennis L Bieber -- 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/s377cghljsjo1uhfmsn4sbj7bi1206lcnq%404ax.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/1034361247.3488153.1623446916131%40mail.yahoo.com.
[beagleboard] ZWO ASI cameras on Beaglebone Black?
Hello, Does anyone in this community have any ZWO ASI cameras running on a Beaglebone Black? I have both the ASI290MM and the ASI183MM working only partially, and I'm wondering if anyone has either working properly. By comparison, both cameras appear to be working properly on a Beaglebone AI. Thank you. -- 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/CAM-_JtkDuDi5Yys0nyZhYg7zMtp%3DK2ps3tb1U7T1g%2B-0ZBHn%2BA%40mail.gmail.com.
RE: [beagleboard] Re: BeagleBone Black (C) USB based touch not working
The touch response on my am335x SK works well. SD card comes with a touch GUI. Schematics and BOM https://www.ti.com/tool/TMDSSK3358 Sent from Yahoo Mail on Android On Thu, Jun 3, 2021 at 5:32 PM, John Dammeyer wrote: #yiv9544055886 #yiv9544055886 -- _filtered {} _filtered {} _filtered {} _filtered {}#yiv9544055886 #yiv9544055886 p.yiv9544055886MsoNormal, #yiv9544055886 li.yiv9544055886MsoNormal, #yiv9544055886 div.yiv9544055886MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:New;}#yiv9544055886 a:link, #yiv9544055886 span.yiv9544055886MsoHyperlink {color:blue;text-decoration:underline;}#yiv9544055886 a:visited, #yiv9544055886 span.yiv9544055886MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv9544055886 p {margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:New;}#yiv9544055886 p.yiv9544055886MsoAcetate, #yiv9544055886 li.yiv9544055886MsoAcetate, #yiv9544055886 div.yiv9544055886MsoAcetate {margin:0cm;margin-bottom:.0001pt;font-size:8.0pt;}#yiv9544055886 p.yiv9544055886Code, #yiv9544055886 li.yiv9544055886Code, #yiv9544055886 div.yiv9544055886Code {margin:0cm;margin-bottom:.0001pt;font-size:8.0pt;}#yiv9544055886 span.yiv9544055886BalloonTextChar {}#yiv9544055886 span.yiv9544055886EmailStyle21 {font-family:New;color:#1F497D;}#yiv9544055886 span.yiv9544055886SpellE {}#yiv9544055886 .yiv9544055886MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv9544055886 div.yiv9544055886WordSection1 {}#yiv9544055886 The reason I ask is based on the information here: https://elinux.org/Beagleboard:BeagleBoneBlack_HDMI In the past I've had the most success using an external HDMI to VGA connector that then feeds into a Viewsonic LED 1080P Full HD monitor. VX2753MH-LED. This one doesn't really like 1920x1080@30 so the Beagle has trouble talking to it. https://www.viewsonic.com/nz/products/lcd/vx2753mh-led Do these smaller displays present as 30Hz? Seems given the capabilities of the BBB it might be better to target a small 7" to 10" LCD display in the 1280x768 size. I know I had a lot of trouble with the Mango screens for the Replicape project with the higher resolution. Touch on the Manga1 was crap. Support for the entire project kind of vanished and now it turns out one of the stepper drivers is toast. Never really got far with the Manga2 after all that But the point is the higher res screens on a small physical footprint don't do much so I was curious about this display and how well the touch actually worked. John From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of Peter Lange Sent: June-03-21 2:51 PM To: beagleboard@googlegroups.com Subject: Re: [beagleboard] Re: BeagleBone Black (C) USB based touch not working It was the Beaglebone USB connector. Touch is currently not calibrated. But on my WIN10 PC it works fine. Can recommend the display. John Dammeyer schrieb am Do., 3. Juni 2021, 22:27: So it was the display USB that had the issue. Not the BBB. How do you like the touch response on that display? From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of Peter Lange Sent: June-03-21 12:28 PM To: beagleboard@googlegroups.com Subject: Re: [beagleboard] Re: BeagleBone Black (C) USB based touch not working Hi Robert, it's solved. Hardware, the USB connector. Was able to solder, now it works fine. Sometimes there was a second entry with lsusb. Then I found out, it's the connector, with a little pressure it worked. Then microscope, solder iron I spent 2 days and nights on that But I learned a Lot Thanks to all Kasimir Robert Nelson schrieb am Do., 3. Juni 2021, 15:37: > > The project requires the pru units, that works fine. > Touch is eating up my time. And I expect it makes no sense to order other > touch displays and the status is still the same. > USB based touch was expected as "best and simple" solution. I need SPI and > GPIO for surrounding hardware. That works fine. > HDMI is required to have the possibility to connect "any" monitor. There is > 1m distance between BBB and display. > RPI is not an option for me, because I need the PRU's. lsusb ? i don't see it showing up in dmesg.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/qynrtLRdkvU/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYg%3DBonY6FnKgsxP%2B5SEdP1g376ZnAGYXnuFwCY9Tj2Tsw%40mail.gmail.com. -- For more options, visit http://beagleboard.org/discuss --- You received this message
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 instructions on Digikey. I have a 10 year old win 7 quad core desktop I think it has 8 gig ram I never used I was contemplating either a dual boot or nuke win 7 a native Linux build box. Problem is it's probably 32 bit. Which compiler are you using? 32 bit or 64 bit and a link to it would be great and Is this 5.x or 5.x I have several BBW, an am335x SK and two BBB for hardware. I'm also a JTAG user so I'd prefer nothing in EMC I don't know if that's possible? I also probably need SD preparation instructions to go with kernel. You know something like Robert has and the SDK has that even a college student can follow Thanks alot!! Mark Sent from Yahoo Mail on Android On Sun, May 30, 2021 at 11:02 AM, amf wrote: 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 VM are you using?Several years ago a company that I worked for used some other VM, it was a pain in the azz to get to work, if i hear the name again i'll know if that was the one.I haven't used Debian for a desktop, so I can't help you with that. On Saturday, May 29, 2021 at 3:45:46 PM UTC-5 lazarman wrote: 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 of code it clones torvald.gitso I retried 4 times by running build_kernel.sh twice in both directories The Mainline had some git branch errors today I paid to upgrade my internet for this testing and was ready to buy a 64 bit box but am scared these instructions need a refresh and I will waste $$ what would be lovely is a 2 line like is in the instruction pasted below with something that will work for sure.the two directories I created are both on wrong branches and dont complete a buil d 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 buildIf 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 like this below with everything needed to build a kernel including the previous two steps as my two directories are on the wrong branches Thanks For TI v5.4.x: Real-Time#~/ti-linux-kernel-dev/ git checkout origin/ti-linux-rt-5.4.y -b tmp Build: Build: #user@localhost:~/ti-linux-kernel-dev$ ./build_kernel.s Build: #user@localhost:~/ti-linux-kernel-dev$ ./build_kernel.s Build: #user@localhost:~/ti-linux-kernel-dev$ ./build_kernel.sh On Friday, May 28, 2021, 02:56:38 PM CDT, Robert Nelson wrote: 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 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 long weekend. > > > > VM's usually fail when using 'dd'.. so MLO/u-boot.img is usually the > > failure point.. > > I think mainline might work: > > debian@beaglebone:~$ uname -r > 5.13.0-rc3-bone2.2 > debian@beaglebone:~$ dmesg | grep pru > [ 2.044506] remoteproc remoteproc1: 4a334000.pru is available > [ 2.045701] remoteproc remoteproc2: 4a338000.pru is available > debian@beaglebone:~$ ls /dev/remoteproc/pruss-core* > /dev/remoteproc/pruss-core0: > coredump device firmware name power recovery state subsystem uevent > > /dev/remoteproc/pruss-core1: > coredump device firmware name power recovery state subsystem uevent > > @Mark Yoder can you test? ;) debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "start" > state [ 243.355728] remoteproc remoteproc1: powering up 4a334000.pru [ 243.366533] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 32456 [ 243.374135] remoteproc remoteproc1: remote processor 4a334000.pru is now up debi
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 | | | | | | | | | | | Debian: Getting Started with the BeagleBone Black This is a page about TI's Cortex-A8 based; BeagleBone Black. Availability Boards: BeagleBone Black at Digi-K... | | | Download: #~/ git clone https://github.com/RobertCNelson/bb-kernel cd bb-kernel/ On Saturday, May 29, 2021, 03:52:25 PM CDT, 'Mark Lazarewicz' via BeagleBoard wrote: 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 of code it clones torvald.gitso I retried 4 times by running build_kernel.sh twice in both directories The Mainline had some git branch errors today I paid to upgrade my internet for this testing and was ready to buy a 64 bit box but am scared these instructions need a refresh and I will waste $$ what would be lovely is a 2 line like is in the instruction pasted below with something that will work for sure.the two directories I created are both on wrong branches and dont complete a buil d 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 buildIf 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 like this below with everything needed to build a kernel including the previous two steps as my two directories are on the wrong branches Thanks For TI v5.4.x: Real-Time#~/ti-linux-kernel-dev/ git checkout origin/ti-linux-rt-5.4.y -b tmp Build: Build: #user@localhost:~/ti-linux-kernel-dev$ ./build_kernel.s Build: #user@localhost:~/ti-linux-kernel-dev$ ./build_kernel.s Build: #user@localhost:~/ti-linux-kernel-dev$ ./build_kernel.sh On Friday, May 28, 2021, 02:56:38 PM CDT, Robert Nelson wrote: 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 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 long weekend. > > > > VM's usually fail when using 'dd'.. so MLO/u-boot.img is usually the > > failure point.. > > I think mainline might work: > > debian@beaglebone:~$ uname -r > 5.13.0-rc3-bone2.2 > debian@beaglebone:~$ dmesg | grep pru > [ 2.044506] remoteproc remoteproc1: 4a334000.pru is available > [ 2.045701] remoteproc remoteproc2: 4a338000.pru is available > debian@beaglebone:~$ ls /dev/remoteproc/pruss-core* > /dev/remoteproc/pruss-core0: > coredump device firmware name power recovery state subsystem uevent > > /dev/remoteproc/pruss-core1: > coredump device firmware name power recovery state subsystem uevent > > @Mark Yoder can you test? ;) debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "start" > state [ 243.355728] remoteproc remoteproc1: powering up 4a334000.pru [ 243.366533] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 32456 [ 243.374135] remoteproc remoteproc1: remote processor 4a334000.pru is now up debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "stop" > state [ 296.981371] remoteproc remoteproc1: stopped remote processor 4a334000.pru Regards, -- Robert Nelson https://rcn-ee.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/1419458740.838013.1622321132117%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/1798894309.849361.1622330593235%40mail.yahoo.com.
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 of code it clones torvald.gitso I retried 4 times by running build_kernel.sh twice in both directories The Mainline had some git branch errors today I paid to upgrade my internet for this testing and was ready to buy a 64 bit box but am scared these instructions need a refresh and I will waste $$ what would be lovely is a 2 line like is in the instruction pasted below with something that will work for sure.the two directories I created are both on wrong branches and dont complete a buil d 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 buildIf 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 like this below with everything needed to build a kernel including the previous two steps as my two directories are on the wrong branches Thanks For TI v5.4.x: Real-Time#~/ti-linux-kernel-dev/ git checkout origin/ti-linux-rt-5.4.y -b tmp Build: Build: #user@localhost:~/ti-linux-kernel-dev$ ./build_kernel.s Build: #user@localhost:~/ti-linux-kernel-dev$ ./build_kernel.s Build: #user@localhost:~/ti-linux-kernel-dev$ ./build_kernel.sh On Friday, May 28, 2021, 02:56:38 PM CDT, Robert Nelson wrote: 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 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 long weekend. > > > > VM's usually fail when using 'dd'.. so MLO/u-boot.img is usually the > > failure point.. > > I think mainline might work: > > debian@beaglebone:~$ uname -r > 5.13.0-rc3-bone2.2 > debian@beaglebone:~$ dmesg | grep pru > [ 2.044506] remoteproc remoteproc1: 4a334000.pru is available > [ 2.045701] remoteproc remoteproc2: 4a338000.pru is available > debian@beaglebone:~$ ls /dev/remoteproc/pruss-core* > /dev/remoteproc/pruss-core0: > coredump device firmware name power recovery state subsystem uevent > > /dev/remoteproc/pruss-core1: > coredump device firmware name power recovery state subsystem uevent > > @Mark Yoder can you test? ;) debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "start" > state [ 243.355728] remoteproc remoteproc1: powering up 4a334000.pru [ 243.366533] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 32456 [ 243.374135] remoteproc remoteproc1: remote processor 4a334000.pru is now up debian@beaglebone:/dev/remoteproc/pruss-core0$ echo "stop" > state [ 296.981371] remoteproc remoteproc1: stopped remote processor 4a334000.pru Regards, -- Robert Nelson https://rcn-ee.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/1419458740.838013.1622321132117%40mail.yahoo.com.
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 long weekend. Regards Sent from Yahoo Mail on Android On Fri, May 28, 2021 at 2:35 PM, Robert Nelson wrote: On Fri, May 28, 2021 at 2:19 PM 'Mark Lazarewicz' via BeagleBoard 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 sufficient at building everything and manually updating SD card as opposed to using an upgrade/update on the BB black. Glad you like it, it's' my old eewiki page just updated and updated as users need help. ;) Not worried about having the most current linux wont ask any questions or need support just trying to learn building everything myself for scratch. I have NO capes no changes to .dts Im interested in the workings of this resource file and maybe getting the big shared RAM Thanks wish I had found this link before did not know it existed So I guess my question is which version will work as is for testing some PRU MSG examples as is? "as-is"... Either the 4.14.x-ti or 4.19.x-ti with Mark's pru cookbook: https://markayoder.github.io/PRUCookbook/ v5.13.x: closer... just another bug: ebian@beaglebone:~$ uname -r 5.13.0-rc3-bone2.1 debian@beaglebone:~$ dmesg | grep pru [ 2.040720] pruss 4a30.pruss: (null) is missing its 'cfg' node Regards, -- Robert Nelson https://rcn-ee.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/CAOCHtYgW8-jB9B6byJEeB_KFCX6O-s2ObWc-aAzT%2B-hm3PH3Tg%40mail.gmail.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/245629638.704247.1622230855720%40mail.yahoo.com.
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. Not worried about having the most current linux wont ask any questions or need support just trying to learn building everything myself for scratch. I have NO capes no changes to .dts Im interested in the workings of this resource file and maybe getting the big shared RAM Thanks wish I had found this link before did not know it existed So I guess my question is which version will work as is for testing some PRU MSG examples as is? Mark On Friday, May 28, 2021, 1:45:35 PM CDT, Robert Nelson wrote: On Fri, May 28, 2021 at 1:39 PM 'Mark Lazarewicz' via BeagleBoard wrote: 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 Digi-K... | | | To test this PRU stuff should I use Mainline or TI BSP? whats the difference? As we speak Im cloning the TI BSP version and looks like somehow I am on 4.14 Branch . I had bad internet last night and I lost the building during resolve after downloading the entire kernel of mainline . Today Im trying TI BSP cloning https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git into default location: /home/lazarman/am335x/ti-linux-kernel-dev/ignore/linux-src Use the "am33x-v5.13" branch of: https://github.com/RobertCNelson/bb-kernel There are "pre-builds" under apt... But, I think we need to update the device tree.. Regards, -- Robert Nelson https://rcn-ee.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/CAOCHtYjoJEDJgvnwdcz%2B-3ktqFCTmyebB3qF41g2mMSGij1hiA%40mail.gmail.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/281626775.704459.169545384%40mail.yahoo.com.
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 Digi-K... | | | To test this PRU stuff should I use Mainline or TI BSP? whats the difference? As we speak Im cloning the TI BSP version and looks like somehow I am on 4.14 Branch . I had bad internet last night and I lost the building during resolve after downloading the entire kernel of mainline . Today Im trying TI BSP cloning https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git into default location: /home/lazarman/am335x/ti-linux-kernel-dev/ignore/linux-src On Friday, May 28, 2021, 12:57:48 PM CDT, Robert Nelson wrote: 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 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 been tweaked since.. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml?h=v5.13-rc3 > > > > it "should" be an extension of the pru code found in > > v4.14.x-ti/v4.19.x-ti/v5.4.x-ti.. > > I see lots of interrupt hints here: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/remoteproc/pru_rproc.c irq driver for pru: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/irqchip/irq-pruss-intc.c Regards, -- Robert Nelson https://rcn-ee.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/CAOCHtYjHr%3D2Mx%2BKLa9enn2pd9rfid0SQ6kVw7ZNh8RPgJpZiFA%40mail.gmail.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/546397207.693159.167127508%40mail.yahoo.com.
Re: [beagleboard] SOLUTION - Missing /dev/rpmsg_pru30 and /dev/rpmsg_pru31
Very helpful post Bruce thanks. I am just a PRU observer. The resource file is discussed in some TI documents it's a way to let Linux understand what resources the PRU will need is what I understood. I'm guessing the SDK examples I played with had this all set up. My guess this file will be important if you use any DDR to store you're samples. Great to know you are on the path to success Mark Sent from Yahoo Mail on Android On Thu, May 27, 2021 at 12:00 PM, Bruce Chidester wrote: I am in the middle of struggling while introducing myself to the PRU. I want to contribute to the world to help some other struggling individual and this seems like the right place to post a solution. I am using Beaglebone Black Rec C. Running the uboot_overlay_pru=AM335X-PRU-RPROC-4-19-TI-00A0.dtbo defined in /boot/uEnv.txt If you do not see the /dev/rpmsg_pru3* devices and you expect them, the zip file I have attached has a working solution to make them show up. I believe the solution has a lot to do with the right resource file and the PRU code. They will not simply just show because you have 2 PRU's. This may seem obvious to the more advanced PRU people, but took me a couple of weeks to figure this (and other things) out. Here are my results after days of trying to figure out the magic to get the devices to show up: root@beaglebone:/home/debian/rpmsg_pru# ./run.shrpmsg_pru30rpmsg_pru31 Once the devices show for you: echo "test30" > /dev/rpmsg_pru30 echo "test31" > /dev/rpmsg_pru31 cat /dev/rpmsg_pru30 - c cat /dev/rpmsg_pru31 - c -- 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/562bed0a-c4d6-43aa-b62a-7528034cc8b6n%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/1266677995.450523.1622135618734%40mail.yahoo.com.
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 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 information on BBB as well as BBAI. df On Tue, May 25, 2021 at 11:51 AM Bruce Chidester wrote: 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 our ships are passing in the night. My messages do not seem to get to you properly, and not sure what to do to improve them. I apologize for any frustration I may cause. I may have also seemed to have found a real working example of userspace communicating back and forth with the PRU's. I am currently looking at these details if it meets my needs. I will report after looking at it. The example I am referring to is at: https://codedocs.xyz/pratimugale/PRUSS-Bindings/index.html On Tuesday, May 25, 2021 at 12:39:17 PM UTC-5 lazarman wrote: 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 like they were cut out of something. It's helpful to display a copy paste from your terminal window in Linux showing your prompt and maybe a directory list at end of / dev/. This procedure looks similar to what's in the sdk instructions but I'm guessing your not following that. It's possible your instructions are missing something. Let us know if " The other's" communicate back. Mark Sent from Yahoo Mail on Android On Tue, May 25, 2021 at 11:47 AM, Bruce Chidester wrote: 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 git://git.ti.com/pru-software-support-package/pru-software-support-package.gitcd /tmp/pru-software-support-package/examples/am335x/PRU_RPMsg_Echo_Interrupt0 export PRU_CGT=/usr/share/ti/cgt-prumake cp gen/PRU_RPMsg_Echo_Interrupt0.out /lib/firmware/am335x-pru0-fw echo start > /sys/class/remoteproc/remoteproc1/state I do not get the message: rpmsg_pru virtio0.rpmsg-pru.-1.30: new rpmsg_pru device: /dev/rpmsg_pru30 and the device does not show in /dev/ What is the secret to making those devices show up? On Tuesday, May 25, 2021 at 11:25:28 AM UTC-5 Bruce Chidester wrote: 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 AM UTC-5 Dennis Bieber wrote: 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 update/upgrade and /etc/dogtag still reports the same info. >Should I get a newer image? Is the issue my distro? > I don't think the "dogtag" gets updated from repositories. It likely just identifies the original image burned to the memory. debian@beaglebone:~$ uname -a Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55 UTC 2020 armv7l GNU/Linux debian@beaglebone:~$ cat /etc/dogtag BeagleBoard.org Debian Buster IoT Image 2020-08-19 debian@beaglebone:~$ I've been doing apt update/apt upgrade at least monthly since writing that image. -- Dennis L Bieber -- 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...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e55624c8-a8b1-4306-903c-5236174b53c1n%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+un
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 attempt to get other's to help you by your providing data that shows exactly what you're doing. Here it is again. It's helpful to display a copy paste from your terminal window in Linux showing your command prompt and any command's you typed output especially errors. Best wishes and Good luck Mark Sent from Yahoo Mail on Android On Tue, May 25, 2021 at 12:51 PM, Bruce Chidester wrote: 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 our ships are passing in the night. My messages do not seem to get to you properly, and not sure what to do to improve them. I apologize for any frustration I may cause. I may have also seemed to have found a real working example of userspace communicating back and forth with the PRU's. I am currently looking at these details if it meets my needs. I will report after looking at it. The example I am referring to is at: https://codedocs.xyz/pratimugale/PRUSS-Bindings/index.html On Tuesday, May 25, 2021 at 12:39:17 PM UTC-5 lazarman wrote: 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 like they were cut out of something. It's helpful to display a copy paste from your terminal window in Linux showing your prompt and maybe a directory list at end of / dev/. This procedure looks similar to what's in the sdk instructions but I'm guessing your not following that. It's possible your instructions are missing something. Let us know if " The other's" communicate back. Mark Sent from Yahoo Mail on Android On Tue, May 25, 2021 at 11:47 AM, Bruce Chidester wrote: 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 git://git.ti.com/pru-software-support-package/pru-software-support-package.gitcd /tmp/pru-software-support-package/examples/am335x/PRU_RPMsg_Echo_Interrupt0 export PRU_CGT=/usr/share/ti/cgt-prumake cp gen/PRU_RPMsg_Echo_Interrupt0.out /lib/firmware/am335x-pru0-fw echo start > /sys/class/remoteproc/remoteproc1/state I do not get the message: rpmsg_pru virtio0.rpmsg-pru.-1.30: new rpmsg_pru device: /dev/rpmsg_pru30 and the device does not show in /dev/ What is the secret to making those devices show up? On Tuesday, May 25, 2021 at 11:25:28 AM UTC-5 Bruce Chidester wrote: 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 AM UTC-5 Dennis Bieber wrote: 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 update/upgrade and /etc/dogtag still reports the same info. >Should I get a newer image? Is the issue my distro? > I don't think the "dogtag" gets updated from repositories. It likely just identifies the original image burned to the memory. debian@beaglebone:~$ uname -a Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55 UTC 2020 armv7l GNU/Linux debian@beaglebone:~$ cat /etc/dogtag BeagleBoard.org Debian Buster IoT Image 2020-08-19 debian@beaglebone:~$ I've been doing apt update/apt upgrade at least monthly since writing that image. -- Dennis L Bieber -- 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...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e55624c8-a8b1-4306-903c-5236174b53c1n%40googlegroups.com. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups &quo
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 like they were cut out of something. It's helpful to display a copy paste from your terminal window in Linux showing your prompt and maybe a directory list at end of / dev/. This procedure looks similar to what's in the sdk instructions but I'm guessing your not following that. It's possible your instructions are missing something. Let us know if " The other's" communicate back. Mark Sent from Yahoo Mail on Android On Tue, May 25, 2021 at 11:47 AM, Bruce Chidester wrote: 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 git://git.ti.com/pru-software-support-package/pru-software-support-package.gitcd /tmp/pru-software-support-package/examples/am335x/PRU_RPMsg_Echo_Interrupt0 export PRU_CGT=/usr/share/ti/cgt-prumake cp gen/PRU_RPMsg_Echo_Interrupt0.out /lib/firmware/am335x-pru0-fw echo start > /sys/class/remoteproc/remoteproc1/state I do not get the message: rpmsg_pru virtio0.rpmsg-pru.-1.30: new rpmsg_pru device: /dev/rpmsg_pru30 and the device does not show in /dev/ What is the secret to making those devices show up? On Tuesday, May 25, 2021 at 11:25:28 AM UTC-5 Bruce Chidester wrote: 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 AM UTC-5 Dennis Bieber wrote: 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 update/upgrade and /etc/dogtag still reports the same info. >Should I get a newer image? Is the issue my distro? > I don't think the "dogtag" gets updated from repositories. It likely just identifies the original image burned to the memory. debian@beaglebone:~$ uname -a Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55 UTC 2020 armv7l GNU/Linux debian@beaglebone:~$ cat /etc/dogtag BeagleBoard.org Debian Buster IoT Image 2020-08-19 debian@beaglebone:~$ I've been doing apt update/apt upgrade at least monthly since writing that image. -- Dennis L Bieber -- 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/e55624c8-a8b1-4306-903c-5236174b53c1n%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/67658706.2474576.1621964339723%40mail.yahoo.com.
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 example a simple one IRQ are cool but might need resources allocated in the DTS file. How about lab 4 from PRU support package 5.8 . Use binaries. Also Confirm you found the guidelines on these examples and the RPMSg quick start guide for Linux please read it. We need console messages from Linux prompt of errors and details of I did such then saw such. A detailed screen capture. 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 have time. In theory the AM 5729 should work the same. The binaries are in the TI AM 57xx Linux SDK its 3 Gig and requires a Linux machine. I can only help you with that if you're using a PRU cookbook example I'm unfamiliar the SDK guidelines support binaries for PRU and ARM and cross compiled Linux target compiled source code. As a beginner I suggest dropping binaries on ARM to be loaded to the PRU and dropping the ARM Linux application binary into filesystem. I won't even attempt to help you start compilation of any code especially if it's changed or gaze upon it without having your environment speculating why it won't compile. I respect your decision if you do choose to disregard my advice and try the Cookbook example but feel it's an exercise in frustration to do this by email without us having hardware and your environment. Too many unknowns. 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-exampleThe Readme.txt file explains what I would like the solution to do. Better idea to use an example that's documented 2 This is the BB AI correct?I do not know what this question means..please clarify. 3 Where did this code come from?I wrote this code from other examples attempting to get it to work. Which examples ? How would we know?4 What is your ARM OS and version. Compiler host detailsBeagleBoard.org Debian Buster IoT Image 2020-04-06, 4.19.94-ti-r42. A fresh release from https://beagleboard.org/latest-images 5 Brief Summary of what you tried with important details(start from 5 and work backwards trying to keep it clear and concise) I was trying several examples from everywhere and I cannot get any messaging example to work. The TI messaging examples that they provide do not include the application code that interacts with the PRU messaging. The UIO to Remote Proc change has made many of the examples out of date and it is getting frustrating trying to figure out the correct solution for the latest disto for the BBB. This my whole point. Read this above like you were us.What's out of date? The SDK guidelines are current for RPSg/ Rproc. What code are you modifying? What how-to/ guidelines/ book are you using ? Last week's email I described all this in detail to you step by step at least for TI Linux SDK. Of you're using something else tell us so some besides me who's knowledgeable doing that may comment. I have know idea whether the PRU cookbook is up to date for AM5729 I do know TI invented, designed RPROC and the documents are valid and correct even though this concept is years old. Hopefully it's more clear. Download the 3g tar Am57xx Linux SDK it's got documents. Ask specific questions. It's been done successfully my at least 3 people on Beaglebone Black. Or Hopefully someone can help support what your doing if it's not SDK code. Mark Sent from Yahoo Mail on Android On Mon, May 24, 2021 at 3:08 PM, Dennis Lee Bieber wrote: 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 version. Compiler host details* >BeagleBoard.org Debian Buster IoT Image 2020-04-06, 4.19.94-ti-r42. A >fresh release from https://beagleboard.org/latest-images > Unfortunately, that is a year out of date... It's basically the image that was shipped on new boards (to my knowledge the "testing" images don't get shipped). Doing an apt update/apt upgrade will take lots of space staging the files, and quite some time (it is Debian 10.3, and Debian is now at 10.9) You might want to grab one of the images at https://rcn-ee.net/rootfs/bb.org/testing/2021-04-27/ (buster is Debian 10, stretch is prior Debian 9). It will be much quicker to do an apt update/apt upgrade. Unfortunately you trimmed the description so that the question of board is still open. AM3358 (now se
RE: [beagleboard] Re: Reducing Boottime in Beaglebone Black
John Ohh boy you got me started now. My Verizon hotspot jetpack (my 3rd purchase) resets very frequently sometimes 4 time's rebooting during important updates to my online database of vinyl. It also Freeze's up after 2 years intermittently for days. Linux and poor design. I suspect it's the wifi radio and software interface to Linux GUI. Has to be a serious bug to reset Chip. No watchdog to reset radio just goodbye reboot hello repeatedly. Cheap design by some low payed QT PC programmer who's never seen an oscilloscope in his life is my guess. I read them the riot act at Verizon. The Verizon manager was a computer science graduate who could not find a job 6 years ago. Yes as consumer's we have to demand better and boycott bad engineering with our wallets. Rant over Mark Sent from Yahoo Mail on Android On Mon, May 24, 2021 at 12:32 PM, John Dammeyer wrote: #yiv3954327767 #yiv3954327767 -- _filtered {} _filtered {} _filtered {}#yiv3954327767 #yiv3954327767 p.yiv3954327767MsoNormal, #yiv3954327767 li.yiv3954327767MsoNormal, #yiv3954327767 div.yiv3954327767MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:New;}#yiv3954327767 a:link, #yiv3954327767 span.yiv3954327767MsoHyperlink {color:blue;text-decoration:underline;}#yiv3954327767 a:visited, #yiv3954327767 span.yiv3954327767MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv3954327767 p {margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:New;}#yiv3954327767 p.yiv3954327767Code, #yiv3954327767 li.yiv3954327767Code, #yiv3954327767 div.yiv3954327767Code {margin:0cm;margin-bottom:.0001pt;font-size:8.0pt;}#yiv3954327767 span.yiv3954327767EmailStyle19 {font-family:New;color:#1F497D;}#yiv3954327767 .yiv3954327767MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv3954327767 div.yiv3954327767WordSection1 {}#yiv3954327767 Just a totally irrelevant side note here. I finally found out why my Panasonic DMP-BD30 is so incredibly annoying on power up. I can press the power button and the display lights up and a 'HELLO' message shows up instantly. Then noises come from inside. The 'HELLO' brightens and then changes to 'READING'. About 20 seconds later the button to open the disk drawer finally works. When went searching to see if there was a firmware upgrade I found out it was running Linux. The inability of the disk drawer to be opened immediately is bad human factors engineering IMHO. When a user turns on power they expect and should be rewarded with the drawer opening immediately if the eject button is pressed. If it weren't running Linux but an RTOS or even just co-operative multi-threading the drawer operation wouldn't be delayed. But that just isn't possible in a stock Linux system unless a special task is written that is loaded early and handles the tray. Which would be very complicated I suspect and beyond the ability of the normal software engineer. What is sad is we are seeing acceptance of this sort of poor behavior as perfectly alright. Again IMHO. John From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of robert.sty...@gmail.com Sent: May-24-21 9:27 AM To: BeagleBoard Subject: Re: [beagleboard] Re: Reducing Boottime in Beaglebone Black Can you start these services later? If you cannot just sleep, or hibinate to save power, and have to cold boot quickly. I would hope for something like: Initially load the kernel loader load the kernel (load root file-system service) (load IPC or network service) load the turnkey application Then as Needed load device and file-system services For a screen based turnkey app, you can only display a splash screen for a few seconds, before the user thinks it is broken, a bit longer for an animated splash screen. Imagine a car radio, something has happen immediately after power on (speaker click or LED indicator or screen backlight), then less than half a second "Tuning..." before music appears. On Monday, 24 May 2021 at 16:42:08 UTC+1 RobertCNelson wrote: On Sun, May 23, 2021 at 9:19 PM Karishma Jaiswal wrote: > > @Dennis L Bieber Really thanks for your detailed explanation about the each > services. > I also updated ubuntu from 16 to 18 and done some modification in the > services. now my board's logs are as below > My system should be working as station mode but may be future, we will add AP > mode also. > I will also remove nginx services. > > > ubuntu@beaglebone:~$ systemd-analyze blame > 51.048s dev-mmcblk1p1.device > 28.951s generic-board-startup.service > 6.550s led-status.service > 6.133s systemd-hwdb-update.service > 4.805s grub-common.service > 4.611s loadcpufreq.service > 3.244s nginx.service > 3.053s systemd-udev-trigger.service > 2.971s avahi-daemon.service > 2.099s ssh.service > 1.958s ar
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 backwards trying to keep it clear and concise) Sent from Yahoo Mail on Android On Mon, May 24, 2021 at 10:44 AM, Bruce Chidester wrote: 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 = open(DEVICE_NAME, O_RDWR); if (pollfds[0].fd < 0) { printf("Failed to open %s\n", DEVICE_NAME); return -1; } /* Send 'hello world!' to the PRU through the RPMsg channel */ result = write(pollfds[0].fd, "hello world!", 13); while (1) { prussdrv_pru_wait_event(PRU_EVTOUT_0); printf("Responding to interrupt\n"); prussdrv_pru_clear_event(PRU_EVTOUT_0, PRU0_ARM_INTERRUPT); } return 0; } PRU Code: #include #include #include #include "resource_table_empty.h" volatile register uint32_t __R30; volatile register uint32_t __R31; #define PRU_ARM_INTERRUPT 19 #define HOST_NUM 2 #define CHAN_NUM 2 #define PRU_ARM_INTERRUPT_PULSE 0x23 #define HOST_INT ((uint32_t) 1 << 31) // PRU Interrupt control registers #define PRU_INTC 0x0002 // Start of PRU INTC registers TRM 4.3.1.2 #define PRU_INTC_GER ((volatile uint32_t *)(PRU_INTC + 0x10)) // Global Interrupt Enable, TRM 4.5.3.3 #define PRU_INTC_SICR ((volatile uint32_t *)(PRU_INTC + 0x24)) // Interrupt, TRM 4.5.3.6 #define PRU_INTC_GPIR ((volatile uint32_t *)(PRU_INTC + 0x80)) // Interrupt, TRM 4.5.3.11 void main(void){ /* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */ CT_CFG.SYSCFG_bit.STANDBY_INIT = 0; // Globally enable host interrupts CT_INTC.GER = 0x1; /* Clear any pending PRU-generated events */ __R31 = 0x; /* Enable Host interrupt 2 */ CT_INTC.HIEISR |= HOST_NUM; //Enable the system event to be propagated through the INTC CT_INTC.EISR |= PRU_ARM_INTERRUPT; /* Map channel 2 to host 2 */ CT_INTC.HMR0_bit.HINT_MAP_2 = CHAN_NUM; /* Map PRU0_ARM_INTERRUPT (event 19) to channel 2 */ CT_INTC.CMR4_bit.CH_MAP_19 = CHAN_NUM; /* Ensure PRU_ARM_INTERRUPT is cleared */ CT_INTC.SICR = PRU_ARM_INTERRUPT; volatile uint32_t gpio; /* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */ CT_CFG.SYSCFG_bit.STANDBY_INIT = 0; gpio = 0x000F; while (!(__R31 & HOST_INT)) { } while (1) { __R30 ^= gpio; __delay_cycles(10); __R31 = PRU_ARM_INTERRUPT_PULSE; // Clear interrupt CT_INTC.SICR = 15; } } On Sunday, May 23, 2021 at 2:10:24 PM UTC-5 Bruce Chidester wrote: Group, I have been attempting to make a messaging example and I am either very close or so far away I don't realize it since I cannot seem to get it to respond. Once I get it working I will leave the answer for the world, please help me get this example working. It is at: https://gitlab.com/brucechidester/pru-messaging-example In summary, it is the smallest possible example where the application code sends an interrupt (or message) to the PRU and the PRU sends an interrupt every second (with a GPIO pulse). Every time the pulse is sent from the PRU, the main application prints a message. Thanks in advance. -- 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/176deb85-62a7-4370-890a-c7ae7873d168n%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/1669188830.2230694.1621876388447%40mail.yahoo.com.
Re: [beagleboard] Re: ioctl messages to Beagle SPI port.
#Let's call it AssignIO(). This requests and locks #the scarce resource in prep for an open. Odds are #unless you have some fancy hardware #multiplexing it would stay assigned for the entire #program. But nothing stops you from doing a #ReleaseIO() and then setting a GPIO bit to mux in #the I2C logic and then an AssignIO() for the I2C. Take a barebones or Green Hills Integrity RTOS. Muxing is done in GPIO_Init and some registers are locked and can only be unlocked in ARM supervisor mode. GHS Integrity can be run in supervisor mode or virtual mode which uses the MMU and MPU. The intent is a bad application can't crash the processor each address space can run an application and won't bring down the processor as in VxWorks AE 653+ Arinc 653) they want that in flight control it's life critical. I didn't know Linux user space let you remux pins. The challenge with these SOCs the barebones startup code started getting very complex depending on what pins and peripheral you needed .I saw that with starterware code for barebones tons of clock and pin and board set-up Data so the code supported everything possible. In a supervisor mode system the startup code makes sure every pin is configuration won't cause a forging hammer to turn on ie it was safe. You added a peripheral or changed board's the code changed. In the Linux world all these board.c files got to be too much when most users didn't care about hardware hence these device trees. The problem in my opinion it's all keeps changing tree's to overlay to sysfs in user space. Config pins changing books out dated. I mean hell if you can keep abreast it's job security as it's seems the average Joe can't even a simple i2c device working. Just keep changing things. That is my biggest gripe against Linux beforehand if I wanted to add something I looked at GPIO init.c and immediately knew what was hooked up. And yes if I wanted to reconfigure something on the fly I could if I was running in supervisor mode other wise a IO Device ( GHS kernel driver's) abstracted the HW from the PC application programmer type that couldn't use a scope and was only safe writing algorithms. Flexibility comes at a cost. I'm struggling to stay informed and today saw yet another wiki or blog or book or cookbook that talked about GPIO on Linux. Something that takes 1 hour to get working ( toggle GPIO) in barebones or RTOS really should not be as difficult as I see people asking about .DTS files almost daily. I realize a .DTS is no different than a c array holding pin muxing Data I think the average user has no clue if it is uboot passing these to these hardware dependencies in.dts to the kernel or who loads an overlay. One final ramble I was researching FreeRtos on the Beaglebone bone today I was struck by the average free RTOS user is very ARM low level processor cognizant knowledgeable and I saw a readme says see the TRM to see 3 GPIO interrupts being generated to trigger task context switches and how little code was actually involved in a FreeRtos kernel Port some with lwip stack etc I mention this because if the goal of embedded Linux is to abstract hardware so the user doesn't need any knowledge I'm afraid they might change all this again right when I think I was starting to understand it and make another version of a book necessary Sent from Yahoo Mail on Android On Fri, May 21, 2021 at 10:01 PM, Dennis Lee Bieber wrote: On Fri, 21 May 2021 09:39:34 -0700, in gmane.comp.hardware.beagleboard.user "John Dammeyer" wrote: >static const char *device = "/dev/spidev1.0"; > fd = open(device, O_RDWR); > if (fd < 0) > pabort("can't open device"); > >One of two things happen. Either It opens the SPI bus which includes >everything that config-pin does or it fails because config-pin wasn't done. Hypothesis: The "device" (driver) is loaded -- but the pin-mux does not have the pins connected to the internal port(s) used by the driver... So the driver is basically dumping output into the "bit-bucket". It can't really take control -- since the same pins are used by I2C mode, if opening the "device" did the pin-mux one could really mess up data transfers (open "I2C" start transfer, then open SPI using the same pins). >> >Oh and none of this explains why the ioctl regardless of C or Pascal >> > >can't handle more than 4096 data bytes while the Python code can when sending >a large bitmap to the SPI port. >... >> debian@beaglebone:~$ cat /sys/module/spidev/parameters/bufsiz >> 4096 >> debian@beaglebone:~$ > >How did you know to look at this file to determine the SPI buf size? https://www.kernel.org/doc/Documentation/spi/spidev """ - There's a limit on the number of bytes each I/O request can transfer to the SPI device. It defaults to one page, but that can be changed using a module parameter. - Because SPI has no low-level transfer acknowledgement, you usually won't see any I/O
RE: [beagleboard] ioctl messages to Beagle SPI port.
# I can't step the machine code past the ioctl system call Hi John What are using to step? It's been a long time but I remember being able to go as deep as I wanted into the linux OS. The hard part was getting kernel source code setup but i had that working requires debugging from linux build machine but you don't seem adverse to assembly language. Probally unrelated but each high level language passes it's function parameters to the registers in a certain order. I know because we switched from PLM 86 to C one was right to left the other was reversed I wrote an assembler library to fix this in the 80s. You should be able to step into into anything in mixed c and assembler mode. Sorry if I'm not totally understanding but it sounds like you could get insight if you could step into the ioctl if its a function you should be able to . C Macros you can't but it doesn't look like what that is. Mark Sent from Yahoo Mail on Android On Wed, May 19, 2021 at 11:10 PM, John Dammeyer wrote: #yiv3788565027 #yiv3788565027 -- _filtered {} _filtered {} _filtered {}#yiv3788565027 #yiv3788565027 p.yiv3788565027MsoNormal, #yiv3788565027 li.yiv3788565027MsoNormal, #yiv3788565027 div.yiv3788565027MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:New;}#yiv3788565027 a:link, #yiv3788565027 span.yiv3788565027MsoHyperlink {color:blue;text-decoration:underline;}#yiv3788565027 a:visited, #yiv3788565027 span.yiv3788565027MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv3788565027 p {margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:New;}#yiv3788565027 p.yiv3788565027Code, #yiv3788565027 li.yiv3788565027Code, #yiv3788565027 div.yiv3788565027Code {margin:0cm;margin-bottom:.0001pt;font-size:8.0pt;}#yiv3788565027 span.yiv3788565027EmailStyle18 {font-family:New;color:windowtext;}#yiv3788565027 span.yiv3788565027EmailStyle20 {font-family:New;color:#1F497D;}#yiv3788565027 span.yiv3788565027SpellE {}#yiv3788565027 .yiv3788565027MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv3788565027 div.yiv3788565027WordSection1 {}#yiv3788565027 So to add this so the research I did isn't repeated. The control message breaks down as follows: Top two bits are the direction. The 'k' (0x6B) identifies the SPI type. The number of bytes is placed into the 32 bit word with the _IOC_NRSHIFT which in itself is also a macro all defined in the asm generic ioctl.h file. ret = ioctl(fd, _IOC(_IOC_WRITE,('k'),(1),(8), ); #define _IOC(dir,type,nr,size) \ (((dir) << _IOC_DIRSHIFT) | \ ((type) << _IOC_TYPESHIFT) | \ ((nr) << _IOC_NRSHIFT) | \ ((size) << _IOC_SIZESHIFT)) The shifts are defined to create this and it's quite convoluted to get there. SPI_IOC_MESSAGE(1) = 40206B00 define _IOC_NRBITS 8 #define _IOC_TYPEBITS 8 /* * Let any architecture override either of the following before * including this file. */ #ifndef _IOC_SIZEBITS # define _IOC_SIZEBITS 14 #endif #ifndef _IOC_DIRBITS # define _IOC_DIRBITS 2 #endif #define _IOC_NRMASK ((1 << _IOC_NRBITS)-1) #define _IOC_TYPEMASK ((1 << _IOC_TYPEBITS)-1) #define _IOC_SIZEMASK ((1 << _IOC_SIZEBITS)-1) #define _IOC_DIRMASK ((1 << _IOC_DIRBITS)-1) #define _IOC_NRSHIFT 0 #define _IOC_TYPESHIFT (_IOC_NRSHIFT+_IOC_NRBITS) #define _IOC_SIZESHIFT (_IOC_TYPESHIFT+_IOC_TYPEBITS) #define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS) #define _IOC_NRSHIFT 0 #define _IOC_TYPESHIFT (_IOC_NRSHIFT+_IOC_NRBITS) #define _IOC_SIZESHIFT (_IOC_TYPESHIFT+_IOC_TYPEBITS) #define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS) From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of John Dammeyer Sent: May-19-21 8:44 PM To: beagleboard@googlegroups.com Subject: [beagleboard] ioctl messages to Beagle SPI port. The spidev_test.c program from the Exploring BeagleBone by Derek Molloy (chp08) tests the SPI port by setting the SPI parameters and then writing out a test block. The text diagnostics I've added show what the macro was that is sent as part of the ioctl call. Trying to break down the macro through multiple files turned into a dead end and I'm not exactly sure what the 32 bit word means other than byte count and I believe message type. The program starts out by sending 6 ioctl messages that configure mode, size and speed. Here's the call that returns the 0x4006B00 and below the result of the message. ret = ioctl(fd, SPI_IOC_MESSAGE(1), ); debian@ebb:~/exploringBB/chp08/spi/spidev_test$ ./spidev_test SPI_IOC_WR_MODE = 40016B01 SPI_IOC_RD_MODE = 80016B01 SPI_IOC_WR_BITS_PER_WORD = 40016B03 SPI_IOC_RD_BITS_PER_WORD = 80016B03 SPI_IOC_WR_MAX_SPEED_HZ = 40046B04 SPI_IOC_RD_MAX_SPEED_HZ = 80046B04 spi mode: 0 bits per word: 8 max speed: 50 Hz (500 KHz) SPI_IOC_MESSAGE(1
Re: [beagleboard] Re: Shared PRU Memory and beyond
#saw one post on the TI E2E forum that indicated #that Remoteproc/RPMSG is not intended to be a #fast data transfer mechanism. That was by a TI #engineer I think. In a parallel processing architect that ability to share data quickly between processors is paramount.With out that the ARM is just a gatewayAs I understood TJF solved this issue with libpru but his solution wasn't adopted As I have mentioned before I have seen custom solutions to share data between the ARM and DSP so I know its possible using TI Socs On Tuesday, May 18, 2021, 04:10:00 PM CDT, 'Mark Lazarewicz' via BeagleBoard wrote: @TJF on this forum promotes a solution called libpruio that might work. I don't know if it's fast enough though. I thought libprio was designed to be very fast was my understanding. I Saw in TI forum docs that UIO isn't supported in SDK Linux by TI. I would definitely agree with below and your math and if the OP can't add I don't think he will get anything to work 來. He only said he'd reply if you did his math for him.藍 #saw one post on the TI E2E forum that indicated #that Remoteproc/RPMSG is not intended to be a #fast data transfer mechanism. That was by a TI #engineer I think. As far as getting the conversation to continue maybe TJF will reply. Sent from Yahoo Mail on Android On Tue, May 18, 2021 at 1:42 PM, Walter Cromer wrote: Regardless of the timing, you want to store 20,000 values but I think you've calculated correctly that you can only store 7,168 values in the 28k of combined PRU memory and that would only be true if some of the PRU memory wasn't used by your PRU program when it's loaded. So are you trying to find a way to store the data back in the main host memory instead? Remoteproc/RPMSG can send the data back but I don't think it's fast enough for you. I'm doing that now with code written in C. (It was a bear to learn and get going but I'm a rusty guy too. ) I am reading 12-bit AD with the onboard ADC (Touchscreen controller in general-purpose mode). I@TJF on this forum promotes a solution called libpruio that might work. I don't know if it's fast enough though. saw one post on the TI E2E forum that indicated that Remoteproc/RPMSG is not intended to be a fast data transfer mechanism. That was by a TI engineer I think. The only alternative I can think of is declaring variables in your PRU code whose address is actually in the main host memory (Linux) space. I've tried to do this using the example in Mark Yoder's PRU Cookbook but I could not get it to work. I decided that I didn't really need that and went another route. This is a good group so keep the discussion going and maybe we can figure something out. On Monday, May 17, 2021 at 8:26:49 PM UTC-4 lazarman wrote: Hello Google Am335x PRU Support package it's got 6 labs and examples including ADC. It's written for the SDK Linux Dennis mentioned but people have gotten these examples to work with Linux supported in this group There's also a Support package tar containing step by step HTML of all the labs above preserved from the old wiki. There's several PDF files supporting all this some are application notes Getting started with RPMSg on Linux is one If you start with these HTML files it's really well written it's a how-to Labs 1 to 3 require CCS JTAG The other labs deal with Linux The ADC example passes samples back to Linux. For a full blown PID loop using both PRU there's a example code also on GitHub preserved from TI support expert Nick. The PRU support package 5.8 code on GitHub or wherever get it in the examples shows linker commands for using shared RAM. The concept in any book of accessing these has more to do with pragma or compliler specific linker commands in gcc should not change Every book or cookbook or tutorial ever written was all this data I pointed you to explained by an experienced engineer's using TI wiki Data That my opinion. Remember this stuff will talk about building code from command line in the 4G SDK which requires a native Ubuntu box or a virtual box Ubuntu on windows 7. Officially vbox support isn't suppored anymore but I got it working recently only tested windows 7 All this discussion can be found by googling " PRU ADC beaglebone" also many discussion on E2E forum replace Beaglebone with 2E I'd suggest reading that getting started first Or use Mark Yoder's cookbook which is web-based compilation on the board itself. I have not tried that Lastly if you take the Apple's and Oranges approach which is taking the source code I mentioned and trying to follow the cookbook web based compilation. Most people seem to fail trying this I don't recommend it Pick one approach Good luckMark Sent from Yahoo Mail on Android On Mon, May 17, 2021 at 6:32 PM, Dennis Lee Bieber wrote: On Mon, 17 May 2021 13:00:04 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Bruce Chidester wrote: > Not sure
Re: [beagleboard] Re: Shared PRU Memory and beyond
@TJF on this forum promotes a solution called libpruio that might work. I don't know if it's fast enough though. I thought libprio was designed to be very fast was my understanding. I Saw in TI forum docs that UIO isn't supported in SDK Linux by TI. I would definitely agree with below and your math and if the OP can't add I don't think he will get anything to work 來. He only said he'd reply if you did his math for him.藍 #saw one post on the TI E2E forum that indicated #that Remoteproc/RPMSG is not intended to be a #fast data transfer mechanism. That was by a TI #engineer I think. As far as getting the conversation to continue maybe TJF will reply. Sent from Yahoo Mail on Android On Tue, May 18, 2021 at 1:42 PM, Walter Cromer wrote: Regardless of the timing, you want to store 20,000 values but I think you've calculated correctly that you can only store 7,168 values in the 28k of combined PRU memory and that would only be true if some of the PRU memory wasn't used by your PRU program when it's loaded. So are you trying to find a way to store the data back in the main host memory instead? Remoteproc/RPMSG can send the data back but I don't think it's fast enough for you. I'm doing that now with code written in C. (It was a bear to learn and get going but I'm a rusty guy too. ) I am reading 12-bit AD with the onboard ADC (Touchscreen controller in general-purpose mode). I@TJF on this forum promotes a solution called libpruio that might work. I don't know if it's fast enough though. saw one post on the TI E2E forum that indicated that Remoteproc/RPMSG is not intended to be a fast data transfer mechanism. That was by a TI engineer I think. The only alternative I can think of is declaring variables in your PRU code whose address is actually in the main host memory (Linux) space. I've tried to do this using the example in Mark Yoder's PRU Cookbook but I could not get it to work. I decided that I didn't really need that and went another route. This is a good group so keep the discussion going and maybe we can figure something out. On Monday, May 17, 2021 at 8:26:49 PM UTC-4 lazarman wrote: Hello Google Am335x PRU Support package it's got 6 labs and examples including ADC. It's written for the SDK Linux Dennis mentioned but people have gotten these examples to work with Linux supported in this group There's also a Support package tar containing step by step HTML of all the labs above preserved from the old wiki. There's several PDF files supporting all this some are application notes Getting started with RPMSg on Linux is one If you start with these HTML files it's really well written it's a how-to Labs 1 to 3 require CCS JTAG The other labs deal with Linux The ADC example passes samples back to Linux. For a full blown PID loop using both PRU there's a example code also on GitHub preserved from TI support expert Nick. The PRU support package 5.8 code on GitHub or wherever get it in the examples shows linker commands for using shared RAM. The concept in any book of accessing these has more to do with pragma or compliler specific linker commands in gcc should not change Every book or cookbook or tutorial ever written was all this data I pointed you to explained by an experienced engineer's using TI wiki Data That my opinion. Remember this stuff will talk about building code from command line in the 4G SDK which requires a native Ubuntu box or a virtual box Ubuntu on windows 7. Officially vbox support isn't suppored anymore but I got it working recently only tested windows 7 All this discussion can be found by googling " PRU ADC beaglebone" also many discussion on E2E forum replace Beaglebone with 2E I'd suggest reading that getting started first Or use Mark Yoder's cookbook which is web-based compilation on the board itself. I have not tried that Lastly if you take the Apple's and Oranges approach which is taking the source code I mentioned and trying to follow the cookbook web based compilation. Most people seem to fail trying this I don't recommend it Pick one approach Good luckMark Sent from Yahoo Mail on Android On Mon, May 17, 2021 at 6:32 PM, Dennis Lee Bieber wrote: On Mon, 17 May 2021 13:00:04 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Bruce Chidester wrote: > Not sure I am replying properly to preserve the format desired for this >page, but your (Dennis B) response definitely deserves a response from me. Difficult -- somehow your added comments are formatted as quoted text (ie, my comments). > >On Monday, May 17, 2021 at 12:39:53 PM UTC-5 Dennis Bieber wrote: > >> 80 samples/msec... or 8 per second. If I converted properly, about >> 0.0125msec per sample. >> >> I will be sampling from an ADC up to 1MHz maybe. The PRU itself only runs at 200MHz, and you have to account for how many instructions are needed to run your ADC-start, re
Re: [beagleboard] Weird C problem: PRU doesn't respond to host if two variables aren't initialized in loop
Hi Walter Probally unrelated but I wanted to share I saw if the linker command files didn't include startup code to initialize variables or zero them like the ARM does.A huge uncleaned index intyo an array wouldn't be good. Perhaps this PRUDebug tool can speed up your debugging have not tried it. Mark Sent from Yahoo Mail on Android On Tue, May 18, 2021 at 1:30 PM, Walter Cromer wrote: I've been pulling myhair out over a really weird problem and after trying everything I know to try,I'm posting it here in hopes of someone seeing the problem. I am running aBeaglebone Black. The output ofversion.sh is at the end of this post. Linux beaglebone4.19.94-ti-r61 #1buster SMP PREEMPT Wed Mar 31 15:23:20 UTC 2021 armv7lGNU/Linux I boot from an SDcard. I'm using remoteprocto communicate between a host program and the PRU code. The program is longand includes stuff that I don't think is important here like configured the ADCand IEP counter. The host programlets the user choose from a menu what they want the PRU to do. Then using RPMSG, the command is sent to thePRU. It receives the message, determineswhat it is and executes the appropriate action in the PRU code. This is done by reading the message and usingan "if-else if-else". One ofthe actions is to read three analog inputs and return the values read throughRPMSG. Each analog value is stored in aring buffer-type array, type unsigned int, that is allocated in the PRU Sharedmemory space. So once the hostsends the message to do the analog input read, it starts to listen forresponses from the PRU. This all worksgreat. I get data from the PRU and thehost program puts it in a CSV file that I can analyze with other tools. Now, though we needto do some basic math on the data in the PRU. I only need to do this on a subset of the data in the arrays and thestart and end points in the array can vary. So I have two integer variables that I use to store the start and endpoints. So, the routine that readsthe analog data sets the values of these two variables as voltage thresholdsare met. The code compiles just fine. However, if thesetwo variables are not set to a constant within the loop, the host never gets amessage from the PRU code. They are set to initial values before the loop (that code is not included below.) It's thecraziest thing I've ever run into I think. I have declared these variables as local and global and nothing seems tomatter. If they are set to a constant inthe loop, the host doesn't get a message from the PRU program. Here's the codesnippet with the two variables in bold. If those lines of code do not exist, the host doesn't hear from the PRU. count =HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFOCOUNT(0)); for(i = 0; i < count; i++) { Data= HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFODATA(0)); StepRead= (Data >> 16) & 0xF; RawAnalog= Data & 0xFFF; switch(StepRead) { case0: DetTSampleSet[pnr]=RawAnalog; break; case1: start_of_pulse= 0; end_of_pulse= 0; DetBSampleSet[pnr]=RawAnalog; if((pnr == end_of_pulse) && (in_pulse == E_YES)) // seen a pulse and atend of it analyze signal { DetBSignalAverage=AnalyzeSignal(start_of_pulse, pnr); start_of_pulse= -1; end_of_pulse= -1; samples_in_pulse= 0; in_pulse= E_NO; } else { DetBSignalAverage= 0; } if(RawAnalog > 0xB54) { __R30|= PanelYellowLED; // turn yellow LED on; at the sampling rate we're using thismay result in just a flicker in_pulse= E_YES; // once the leading edge of the pulse passes set this samples_in_pulse++;// count the number of samples in the pulse DetBSignalAverage= 999; // samples_in_pulse;//just using for debugging // //here we will check for a max # of samples in pulse while in a pulse to throwout start of fluid or end of fluid or pulses larger than a seed // if(start_of_pulse < 0) start_of_pulse = pnr; // set start pointer in ring buffer if it hasn't already been set forthis pulse } elseif ((RawAnalog <= 0xAC8) && (in_pulse == E_YES)) { __R30&= ~CAValve; // turn compressed airoff; stop fluid flow because the pulse has cleared the bottom detector in_pulse= E_NO; // pulse is over DetBSignalAverage= 1999; //samples_in_pulse;//just using for debugging // //this is an alternative place to check the number of samples in the pulse tothrow out start / end of fluid but we would never stop because Rawanalog //will never drop while there is no fluid in the tube // if(end_of_pulse < 0) end_of_pulse = pnr; // capture where we are in the ring buffer at the end of the pulse __R30|= VacValve; // turn vacuum on to hold fluid in place; ultimately this wouldread the pressure and attempt to hold it there __delay_cycles(4000); // put this delay cycle here for now. will be replaced with a routine to analyzepulse & maintain slight vacuum later __R30&=
Re: [beagleboard] Re: Shared PRU Memory and beyond
Hello Google Am335x PRU Support package it's got 6 labs and examples including ADC. It's written for the SDK Linux Dennis mentioned but people have gotten these examples to work with Linux supported in this group There's also a Support package tar containing step by step HTML of all the labs above preserved from the old wiki. There's several PDF files supporting all this some are application notes Getting started with RPMSg on Linux is one If you start with these HTML files it's really well written it's a how-to Labs 1 to 3 require CCS JTAG The other labs deal with Linux The ADC example passes samples back to Linux. For a full blown PID loop using both PRU there's a example code also on GitHub preserved from TI support expert Nick. The PRU support package 5.8 code on GitHub or wherever get it in the examples shows linker commands for using shared RAM. The concept in any book of accessing these has more to do with pragma or compliler specific linker commands in gcc should not change Every book or cookbook or tutorial ever written was all this data I pointed you to explained by an experienced engineer's using TI wiki Data That my opinion. Remember this stuff will talk about building code from command line in the 4G SDK which requires a native Ubuntu box or a virtual box Ubuntu on windows 7. Officially vbox support isn't suppored anymore but I got it working recently only tested windows 7 All this discussion can be found by googling " PRU ADC beaglebone" also many discussion on E2E forum replace Beaglebone with 2E I'd suggest reading that getting started first Or use Mark Yoder's cookbook which is web-based compilation on the board itself. I have not tried that Lastly if you take the Apple's and Oranges approach which is taking the source code I mentioned and trying to follow the cookbook web based compilation. Most people seem to fail trying this I don't recommend it Pick one approach Good luckMark Sent from Yahoo Mail on Android On Mon, May 17, 2021 at 6:32 PM, Dennis Lee Bieber wrote: On Mon, 17 May 2021 13:00:04 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Bruce Chidester wrote: > Not sure I am replying properly to preserve the format desired for this >page, but your (Dennis B) response definitely deserves a response from me. Difficult -- somehow your added comments are formatted as quoted text (ie, my comments). > >On Monday, May 17, 2021 at 12:39:53 PM UTC-5 Dennis Bieber wrote: > >> 80 samples/msec... or 8 per second. If I converted properly, about >> 0.0125msec per sample. >> >> I will be sampling from an ADC up to 1MHz maybe. The PRU itself only runs at 200MHz, and you have to account for how many instructions are needed to run your ADC-start, read, store, notify host logic. >> Does the second addition contain the updates to the remote proc process? > It uses Remote Proc for the examples -- but does NOT have ADC examples. It does warn that Remote Proc/rpmsg is fairly new (at the time of the book) and that things might change. Unfortunately TI has changed its document access, so the links in the 2nd edition book don't work. Most of the documentation seems to be at http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_PRU-ICSS_PRU_ICSSG.html#remoteproc-and-rpmsg (note: processor SDK -- TI's raw OS build system). The examples are the simple Blink LED until Button Pressed; a PWM generator, Ultrasonic distance sensor. >> Thanks for the DSP lead...that is awesome as well. On the BB AI -- and not much information has appeared on programming them. -- Dennis L Bieber -- 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/v2u5ag1dlpbh5fkli20unvb8d8a2b254o3%404ax.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/709657661.916715.1621297587749%40mail.yahoo.com.
Re: [beagleboard] Mikroe Click board inccorect.
Hi John Interesting we used Pic for a CAN to USB Bridge for a doctors laptop to get Data and and out of doctors tablet for an implantable heart pump. TI 28335 DSP was master, TI DSP Piccolo ran the implant motor and we had a PIC doing some system house keeping. All 3 processors were connected on CAN bus sharing data. Can stack wrote in house As was a simple scheduler on Master. Redundant battery packs wore by grandpa on belt so Grandpa could go hunting with his failed heart. CCS JTAG on two TI and PIC had JTAG I believe we added a Blue tooth module on PIC. Fast reliable and Life critical imagine Grandpa waiting 18 seconds after a reboot for his left ventricle to pump. the long run this probably won't matter because it seems like the Beagle itself is on its death bed. Hunch. Edecuated guess? I feel a lack of mojo myself. What is next the Dog pound board on OpenRisc is my guess? On the positive side all TI IP work the same pretty much on DSP or Soc so at least low level knowledge isn't wasted it's transferable to all TI DSP and other Socs if the AM335x chip isn't marketed as much which I doubt. I'm a big investor in NVDA and can't wonder how many Chip designer's are nervous about the ARM acquisition. My interest are at low level SW not Linux so I won't be migrating to any non ARM Soc no matter how much drum beating occurs. Hopefully they add JTAG. Love TI chips started as a Motorola guy, transitioned to ARM not an Intel Fan. IMX by NXP is interesting. Did one MIPS processor project. I remember working with a consultant on his first day at our stand up he bragged he was on his 50th job and he never met a microprocessor he didn't like LOL. I told him wow nice story I wouldn't share that later. Project was ESP32 he was fired after 90 days I didn't have a chance ask him if he still liked ESP32. Nice cheap chip. the support in the beginning of that chips life was horrible . Mostly open source Free RTOS community support. I own one somewhere. Mark Sent from Yahoo Mail on Android On Mon, May 17, 2021 at 3:49 PM, John Dammeyer wrote: A few years ago I did a project that needed high speed CAN message acquisition from power up. The Raspberry PiZeroW took about 18 seconds to boot in its fastest incantation which meant 18 seconds of vehicle start up and running messages would be lost. Eventually I used a PIC32 to do the power up data logging and dumped the data up to the PiZero acting as an SPI master while the PIC32 was the slave. Since I needed a number of features that weren't on the PIC32 I used an Automotive Networking Board (ANB) which had a number of Click expansion sockets. One was the mcp2542 CAN bus driver terminating in a DB-9 with standard CANopen CAN bus format. https://www.mikroe.com/mcp2542-click Since I was buying Click boards I picked up a cape for the BBB. https://www.mikroe.com/beaglebone-mikrobus-cape That was a few years ago. Now I thought I'd use the cape and the mcp2542-click for testing CAN1 communications with the Beagle. But there's a problem. Although the Click board worked properly on the ANB something wasn’t right with the Beagle installation. A bit of tracking with the scope and the schematics has shown there's an error on the click board. Or on the cape. Although the board worked on the ANB jumpers directed the signals so I'm going to suggest the problem is with the Click board. So: What is the problem? It derives from the ease of creating the TI processor silicon and putting the CAN1_TX signal on the same pin as the UART1_RX (GPIO14). That makes a carrier board like the cape difficult to deal with because it's marked Tx on a pin that is Tx for UART but Rx for CAN. The trouble is the mcp2542-click board also thinks that the Tx for Uart is the same as the Tx for CAN1. It's not. The MCP2542-Click also has the two HDR1 pins marking CAN_H and CAN_L reversed. The signals are correct on the DB-9. Because the ANB motherboard (attached photo) has jumpers that can allocate what pins get what signal the best solution is to change the MCP2542-Click with some trace cuts and jumper wires. I've passed on this information to www.mikroe.com but just be aware this Click board will not work on the BBB cape. The Logic Supply CBB-Serial Cape does not have problems and I've been able to use the socketCAN utilities with it on the 2018 OS. https://www.onlogic.com/cbb-serial/ It's been discontinued along with the Logic Supply name as the above link shows. In the long run this probably won't matter because it seems like the Beagle itself is on its death bed. John Dammeyer -- 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 beagleboar
Re: [beagleboard] Re: unexpected "low speed" of PRU 1
Thanks for future research. Unfortunately GDB won't work when your board doesn't run. For cost sensitive products using a OEM board isn't always an option. In high volume pennies make a difference that's why ESP32 it's low cost and is popular and I'm sure it now has a JTAG but yes GDB is an option on it although 3 year's ago it was serial port only. When you get handed a board that's radically different from reference design and it doesn't work or your designing a bootloader on a project that's a billion dollars what's a $100 for a JTAG. Certainly you would not give a hardware engineer a new design and not buy him an oscilloscope or logic analyzer. Just a different perspective may not apply for some Sent from Yahoo Mail on Android On Fri, May 14, 2021 at 4:31 PM, Peter Lange wrote: KasimirPS try out ddd in top of gdb ..easy to use, simple and efficient 'Mark Lazarewicz' via BeagleBoard schrieb am Fr., 14. Mai 2021, 23:18: CCS/JTAG works for me . I have used FPGA arm cores and ESP32 My position and opinion is unique in this group I see no value in a PRU UNLESS every peripheral is used on DSP/ARM and you need more peripherals I have seen that done in a RTOS on ARM DSP PRU omapL178 very complex Motor controller from an industry leaderThey also used TI Picolo for QEP and several other small processors Beyond having assembler run in 1 instruction on PRU a dedicated SoC with an RTOS or barebones is much more powerful and determinism on FDA and DO178B and Centelec systems use dedicated processors to achieve this Nick from TI has a two PRU very simple PID motor controller reference design but its not true control theory and not fault tolerant like the product I worked on. This PRU is a toy compared to the ARM core or a DSP its resource limited and its instruction set is limited especially to run MATLAB I did download PRUDEbug sorry for being negative it reminds me of desperate Linux programmers using GDB or even nworse yet the initial ESP32 had no jtag just serial debug Maybe Im an old stubborn old man but Printf killed that ESP32 project very slow getting good debug info out For custom board bring up JTAG is a must. I worked on a Military 8 core PowerPC application debugging the multiple core SOC boards in a VME rack say 4 boards we used print logs to debug Guess what all the consultants went home very rich $ it took years to validate this and it wasnt life critical it was mission critical so testing was extensive My new research project CCS/ debugging ARM code over ethernet yikes it uses GDB server LOL Thanks for informing me about PRUDEBUG I will try it to remind myself it is better than using LEDS to debug PRU. CCS is also used to automate V test cases using gel files In all fairness there are many ways to skin a cat whatever ones feels comfortable with I get that but when your custom board wont boot GDB is useless Mark On Friday, May 14, 2021, 03:42:35 AM CDT, Peter Lange wrote: Hi Mark, prudebug did help a lot. I'm missing a good debug environment for PRU development.Up to now it's time consuming try's more easy to use FPGA on top of Raspberry or use ESP32, 2. core for dedicated high speed functions. At the end I want to use the CPU in my own hardware, Beaglebone is my "emulator" and debug environment. The big value of the Sitara CPU are the PRU units. Think prudebug should be enhanced.Have a great dayKasimir -- 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/CAHjW%3DhdsFTxVM81oMtRkWC5U%3DHC3_yjwT56p-RGrRETbt8N7Yw%40mail.gmail.com. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/EvWTZ1wM8zQ/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/403093636.422819.1621027110789%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/CAHjW%3DhcfFugj2YxWbh-V7O20ZbZEZpG_QzDO7mn_GRKMuGmbXQ%40mail.gmail.com. -- For more options, visit http://beagleboard.org/discuss --- You received
Re: [beagleboard] Re: unexpected "low speed" of PRU 1
CCS/JTAG works for me . I have used FPGA arm cores and ESP32 My position and opinion is unique in this group I see no value in a PRU UNLESS every peripheral is used on DSP/ARM and you need more peripherals I have seen that done in a RTOS on ARM DSP PRU omapL178 very complex Motor controller from an industry leaderThey also used TI Picolo for QEP and several other small processors Beyond having assembler run in 1 instruction on PRU a dedicated SoC with an RTOS or barebones is much more powerful and determinism on FDA and DO178B and Centelec systems use dedicated processors to achieve this Nick from TI has a two PRU very simple PID motor controller reference design but its not true control theory and not fault tolerant like the product I worked on. This PRU is a toy compared to the ARM core or a DSP its resource limited and its instruction set is limited especially to run MATLAB I did download PRUDEbug sorry for being negative it reminds me of desperate Linux programmers using GDB or even nworse yet the initial ESP32 had no jtag just serial debug Maybe Im an old stubborn old man but Printf killed that ESP32 project very slow getting good debug info out For custom board bring up JTAG is a must. I worked on a Military 8 core PowerPC application debugging the multiple core SOC boards in a VME rack say 4 boards we used print logs to debug Guess what all the consultants went home very rich $ it took years to validate this and it wasnt life critical it was mission critical so testing was extensive My new research project CCS/ debugging ARM code over ethernet yikes it uses GDB server LOL Thanks for informing me about PRUDEBUG I will try it to remind myself it is better than using LEDS to debug PRU. CCS is also used to automate V test cases using gel files In all fairness there are many ways to skin a cat whatever ones feels comfortable with I get that but when your custom board wont boot GDB is useless Mark On Friday, May 14, 2021, 03:42:35 AM CDT, Peter Lange wrote: Hi Mark, prudebug did help a lot. I'm missing a good debug environment for PRU development.Up to now it's time consuming try's more easy to use FPGA on top of Raspberry or use ESP32, 2. core for dedicated high speed functions. At the end I want to use the CPU in my own hardware, Beaglebone is my "emulator" and debug environment. The big value of the Sitara CPU are the PRU units. Think prudebug should be enhanced.Have a great dayKasimir -- 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/CAHjW%3DhdsFTxVM81oMtRkWC5U%3DHC3_yjwT56p-RGrRETbt8N7Yw%40mail.gmail.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/403093636.422819.1621027110789%40mail.yahoo.com.
Re: [beagleboard] Re: Boot from SD without ROM code eMMCC
C means boot ROM icrocode isn't finding what's expected. Could be your hardware or that your needing something in EMC. You should read the AM335x TRM boot sequence and understand it well even if your only a hardware designer. - The AM335x has a boot loader (the '0th' stage if you will) physically encoded in discrete logic on the chip itself (which is one of the reasons there are v 1.0, 2.0, 2.1 'silicon'). As such there's no source/compilation/flashing option here - you get what you're given! 2 - This boot loader will go through a list of devices it can boot from, depending on some of the pins (on the BBB these are hardwired, with a second boot option available by long-pressing the 'Boot' button on the board) 3 - In the case of NAND (which again specifically on the BBB is the 2GB eMCC directly soldered on the board), the on-chip boot loader will look at the first bytes (at this point it knows nothing about 'partitions'), to determine a) the start address on the NAND of the MLO/SPL, b) how big the MLO img is, and c) where in memory the MLO should be copied. Surely if you understand hardware you hooked up a logic analyzer to validate your assumptions about SD card are valid? and cross checked the boot sequence with your pin settings. It's always a good idea to research what's supposed to happen from the technical documentation as opposed to asking opinions in group's or making assumptions that might be incorrect For example the steps above were found using Google they might not be correct but I do know a C on console is defined as failure. Obviously your new hardware might be an issue. Have you validated your hardware? Or are you planning to hand this to a software engineer and let him figure it out. Cold solder joints, board layout errors , manufacturing problems. Do you own a JTAG or are you expecting to copy a design and ignore all possible electrical issues that's a hardware engineer's domain. Typically a software board bring up engineer works with the hardware designer but as a highly skilled properly trained electrical engineer its not uncommon for you to wear both hats. Myself being an electrical engineer who does low level firmware I'm quick to make sure the hardware is working properly first. If this is your first design you might want to share that information and more details of what you have tried otherwise your chances of getting anything useful are diminished Sent from Yahoo Mail on Android On Thu, May 13, 2021 at 8:32 PM, ASH KR wrote: In addition I also checked the uart terminal log, its only printing char 'C' on terminal. On Friday, May 14, 2021 at 9:37:53 AM UTC+9 ASH KR wrote: Hi, I need some help in booting my board from SD card. Since I designed my board (call it BBEv1) based on BBE (beaglebone enhanced) and even after I tested it with the same image I was running on BBE/BBB actual board through SD. BBEv1 is not getting boot up from SD. Since everything is same and exactly as per BBE, I didn't understand the cause of happening so. Since there is no ROM code eMMC, it should be by default boot from SD, but nothing happen. Is this could be the hardware issue or boot image issue? Please suggest. Thanks,/Ash -- 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/2f627395-d04d-454c-ada9-8014dbfe7d39n%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/1465665955.248835.1620958185072%40mail.yahoo.com.
Re: [beagleboard] Re: unexpected "low speed" of PRU 1
Nevermind I understand I think now .PRU0_DRAM needs to be an address from linker command file that statement might work. Anyway linker command files have always been a murky science I might play around with. I use JTAG so the address being not correct is something you can catch quickly. Unfortunately Using RPMsg from my recent research isn't a good match with JTAG debugging. I'm interested in what memory the Rpmsg carves out for it's use. Seems like between the PRU shared RAM and unused PRU0_DRAM if using only one PRU one can squeeze additional RAM if resources are tight that's why I'm interested in researching the linker command files further. These PRU are limited in resources it's like using a small 8 bit processor from 20 year's ago and squeezing every possible byte out. Back in the day some guys got job security by using so many tricks to steal memory their code was unmaintainable. They liked that boss couldn't get rid of them because changing the software would break the entire application. Ahh I digress . Mark Sent from Yahoo Mail on Android On Thu, May 13, 2021 at 7:11 PM, 'Mark Lazarewicz' via BeagleBoard wrote: Hi Kasimir What's wrong with below?? My datastructure was not in internal ram.volatile Event_t *event_knoten = (Event_t *) (PRU0_DRAM + 0x200); IMO I think placing anything in a guaranteed memory area is best done with sections from linker command file. There's examples about placing data in PRU shared RAM in the those examples I mentioned. Yes external DDRAM yikes 蘭 the ARM is caching it. Glad you're rolling. Sent from Yahoo Mail on Android On Thu, May 13, 2021 at 6:26 PM, Kasimir wrote: Hi Mark,more simple .. in C source.My datastructure was not in internal ram.volatile Event_t *event_knoten = (Event_t *) (PRU0_DRAM + 0x200);and in main event_knoten = (Event_t *)malloc(100*sizeof(Event_t)); solved it. Kasimir -- 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/85feaea6-6059-4f9d-ba44-5bd44ea57f11n%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/484390211.240541.1620951078816%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/684080029.241326.1620952826607%40mail.yahoo.com.
Re: [beagleboard] Re: unexpected "low speed" of PRU 1
Hi Kasimir What's wrong with below?? My datastructure was not in internal ram.volatile Event_t *event_knoten = (Event_t *) (PRU0_DRAM + 0x200); IMO I think placing anything in a guaranteed memory area is best done with sections from linker command file. There's examples about placing data in PRU shared RAM in the those examples I mentioned. Yes external DDRAM yikes 蘭 the ARM is caching it. Glad you're rolling. Sent from Yahoo Mail on Android On Thu, May 13, 2021 at 6:26 PM, Kasimir wrote: Hi Mark,more simple .. in C source.My datastructure was not in internal ram.volatile Event_t *event_knoten = (Event_t *) (PRU0_DRAM + 0x200);and in main event_knoten = (Event_t *)malloc(100*sizeof(Event_t)); solved it. Kasimir -- 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/85feaea6-6059-4f9d-ba44-5bd44ea57f11n%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/484390211.240541.1620951078816%40mail.yahoo.com.
Re: [beagleboard] Re: unexpected "low speed" of PRU 1
Great news Can you share how it ended up in external RAM?Incorrect Linker cmd file? Mark On Thursday, May 13, 2021, 05:24:27 PM CDT, Kasimir wrote: Hi all, it's SOLVED :-)Thanks for all your input.Problem was located in memory allocation. Was not using the PRU-Dram. The external ram is very slow and I saw also some jitter.Now it's running with expected speed and I'm happy. Was expecting the local variables in local memory by default. That's not the case.Thanks againKasimir -- 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/ef7fb969-2794-4eed-8340-934370471cf3n%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/675651555.225185.1620945853393%40mail.yahoo.com.
Re: [beagleboard] Re: unexpected "low speed" of PRU 1
Have you seen the PRU Support Package examples???I saw examples of linker placement in shared RAM This example below the C variable is in by default in local RAM What is smallest pulse period you require for your application? void main(void){ volatile uint32_t gpio; /* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */ CT_CFG.SYSCFG_bit.STANDBY_INIT = 0; /* Toggle GPO pins */ /* Note: 0x_ toggles all GPO pins */ gpio = 0x; /* TODO: Create stop condition, else it will toggle indefinitely */ while (1) { __R30 ^= gpio; __delay_cycles(1); } On Thursday, May 13, 2021, 03:34:29 PM CDT, Kasimir wrote: Just a moment ago, I was standing on cliffs edge, now I made a big step forward . I'm able to generate a 10ns trigger pulse on __R30 Bit 4 :-)).I placed the and instruction to clear Bit 4. Now it's clear, both indirect loads ( lbbo ) areresponsible for the unexpected delay. I was expecting both are operating from dram withlatency of 3 cycles. What is wrong? The data structure is expected in local ram, to get best latency.In C it's declared that way:typedef struct Event Event_t; struct Event { unsigned int time; // number of loops unsigned char pattern; // Bit 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | // --+---+---+---++---++---+ // | | | |~z34|z34|~z12|z12| // --+---+---+---++---++---+ };int main( int argc, char *argv[]) { int i; int j; unsigned char u; Event_t event_knoten[100]; // later on, r15 is pointing to that address.ausgabe(pattern_liste.anzahl, _knoten[0].time, [0]) ; * change to debug delay in assembler *** naechster: and r30, r30, 0xEF ; debug lbbo , r15, 4, 1 ; (r15) = pattern <= slow lbbo , r15, 0, 2 ; load number of loops <= slow Any hint how to make the lbbo faster?I'm looking forward Kasimir -- 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/4a911162-7904-4709-b3c3-556e517ea887n%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/864131374.173508.1620938924527%40mail.yahoo.com.
Re: [beagleboard] unexpected "low speed" of PRU 1
Hello Kasmir I will take a look and hopefully others who are using PRU can also be helpful I began programming in asm many many years ago but haven't used PRU assembler. Can you reply whether you have an oscilloscope or high speed logic analyzer? This is what we used to debug many years ago. You could remove any memory Accesses by hard coding the data( modify your code) just do a tight loop toggling GPIO and measure the frequency. This will tell you the max frequency of your GPIO Perhaps write some test code doing just that and share results . Staring at source code isn't always the fastest way to find error especially since we don't have your exact set-up. In the meantime hopefully someone sees something obvious. I'm sure the max frequency of what you are attempting has been discussed. Maybe someone will comment on what they have achieved and share their solution. Break the problem into peices and resist the temptations to be drawn into detour's can be challenging when getting input. By running experiments you can stay busy while waiting for input from group members I hope that's helpful Mark Sent from Yahoo Mail on Android On Wed, May 12, 2021 at 2:57 PM, Kasimir wrote: This is my code to output pattern on __R30; .global ausgabe ausgabe: ldi r18, 0 ; initial value ldi r30, 0x10 ; debug ldi r17, 0x00 ; debug mov r13, r15 ; R15 contains start address, save in R13 mov r12, r14 ; R14 contains number of data points naechster: lbbo , r15, 4, 1 ; (r15) = pattern lbbo , r15, 0, 2 ; (r17) = time to wait to output next pattern warte: sub r17, r17, 1 ; delay loop qbne warte, r17, 0 ; add r15, r15, 5 ; next element, update pointer sub r14, r14, 1 ; number of remaining elements - 1 qbne naechster, r14, 0 ; was it the last one? mov r15, r13 ; yes, load addess pointer with saved value mov r14, r12 ; and load loop counter with saved number of elements lbbo , r16, 0, 1 ; load variable, if 0 run again, if != 0 exit or r30, r30, (1<<4) ; debug, trigger signal for oscilloscope qbeq naechster, r18, 0 ; as long handshake[0] = 0 is jmp r3.w2 ; r3 contains return address;* The datastructure:typedef struct Event Event_t; struct Event { unsigned int time; // number of loops to the next event unsigned char pattern; // Bit 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | // --+---+---+---++---++---+ // | | | d |~z34|z34|~z12|z12| // --+---+---+---++---++---+ }; int main( int argc, char *argv[]) { int i; int j; Event_t event_knoten[500]; ...ausgabe(pattern_liste.anzahl, _knoten[0].time, [0]) ; // asm to write pattern // as long handshake[0} == 0 It works fine, only the delay time loop need better resolution, at the moment the time for only one loop is too long.Have no idea to optimize ist. Also from or r30, r30, (1<<4) ; debug, trigger signal for oscilloscopetonaechster: lbbo , r15, 4, 1 ; (r15) = patternI measure 250nsec . was expecting 25nsec . I can see some jitter on my oscilloscope ( Tektronix THS730A ), has nothing to do withGND connection, long wires etc., all that is perfect. Oscilloscope works fine. Is it possible that "some what" from Linux / ARM area is disturbing my timing? Thanks again for any helpfull input.Kasimir -- 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/2a9748b2-ed2a-4278-9e30-fa153bf5c0fbn%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...
Re: [beagleboard] unexpected "low speed" of PRU 1
The memory access will add some cycle post your assembler code with comments you're correct it doesn't make sense maybe someone will see the issues. The PRU labs discuss measuring cycle times in CCS if you have JTAG but toggle a GPIO and measure with a scope is probably easier. Sent from Yahoo Mail on Android On Wed, May 12, 2021 at 8:40 AM, Kasimir wrote: Hi,I'm working on a sine - triangle modulator, is running on BeagleBone black / PRU 1.On Linux/Arm I calculate the pattern for one period in form of a data structurepattern to output and time to the next event.Output is PRU 1 __R30 bit 0, 1, 2, 3 ( 4 only for debug reasons, oscilloscope trigger )It works but I'm not surprised about the speed.The output loop of the PRU is written in some lines of ASM.Frequencies: triangle should be 400kHz, better 800kHz,sine wave is between 20kHz and 100kHzBeaglebone has to drive a high speed GaN H-Bridge. The datatransport and handshake between Linux and PRU works fine.A C-Program on PRU is watching for new data. Then the new data ( pattern-time structure )are copied into local ram, to get the best speed ( lowest latency ).If the data are stored in local ram, the assembler program is called, to output the given pattern. First the arguments are saved in registers, then the output starts in a loop.Pick up pattern from local RAM, and output,feed delay loop from local RAM,delay loop, update index register,check for possible new data,if not, back to the top, output next period. What I said ... it works. But with cycle time of 5nsec ( 1/200MHz ) and 1 cycle for most of the (ASM) instructions, I can't see the speed. So there is something wrong in my setup or code.If somebody would like to help debugging, let me know.Sources with Makefile etc are available. All based on latest Debian image, all udates are installed, HDMI is off. So, let me know, think it makes only sense to upload that stuff in case there is really somebody able to help on that. Thanks in advanceKasimir -- 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/e9fe59e9-e00d-476e-99e2-6b85a90695d2n%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/474549500.1653123.1620834888085%40mail.yahoo.com.
Re: [beagleboard] TI PRU_ADC_onChip example
Hello Walter and Cheng I spent 2 hours total doing following 1)Created Ubuntu 16.04 LTS Dev Box using VBOX on Win 72) Created SDK linux SD card using image writer on Windows booted Linux on Beaglebone White 3) Rebuilt kernel sources created images of customized kernel and replaced these on SD card I have a full development environ Now ! Next step add a kernel driver I wrote and understand how use the OCP shared RAM to get large amounts of data from PRU to linux *** _ _ _ _| _ |___ ___ ___ ___ | _ |___ ___ |_|___ ___| |_| | _| .'| . | . | | __| _| . | | | -_| _| _||__|__|_| |__,|_ |___| |__| |_| |___|_| |___|___|_| |___| |___| Arago Project http://arago-project.org am335x-evm ttyS0 Arago 2019.11 am335x-evm ttyS0 am335x-evm login: [ 143.131162] NET: Registered protocol family 15[ 143.545960] Initializing XFRM netlink socket _ _ _ _| _ |___ ___ ___ ___ | _ |___ ___ |_|___ ___| |_| | _| .'| . | . | | __| _| . | | | -_| _| _||__|__|_| |__,|_ |___| |__| |_| |___|_| |___|___|_| |___| |___| Arago Project http://arago-project.org am335x-evm ttyS0 Arago 2019.11 am335x-evm ttyS0 am335x-evm login: On Tuesday, May 11, 2021, 02:39:31 PM CDT, 'Mark Lazarewicz' via BeagleBoard wrote: HI Cheng I have two Beaglebone White and the am335x SK both have JTAG on the board so no soldering. The key is to follow the labs 1 to 3 only dont use any RPMsg examples The other key is the PRU gel script is crucial there is a typo error in the instructions about correct .gel file name and how to execute it I used CCS 6.0 win 7 and CCS 10 on windows 10 Id be glad to help if I can The power of the CCS/JTAG is reading memory locations and finding crashes quickly its worth the learning curve Any issues please ask but tell me your CCS version What I dont like about the PRU tutorials is all use Linux interaction as in interrupts and they assume SDK linux not Debian Its some work but you could use Windows to create a SDK linux SD card for JTAG if problems I have several jtags one is USBV2 and I have yours I also have two BBB but even being EE I dont solder Let me know be glad to help trust me after you master CCS/JTAG you will be very happy and have an awesome tool in your belt Mark On Monday, May 10, 2021, 11:51:35 PM CDT, Cheng Chen wrote: Hi Mark, Thanks a lot for the updates. I went through the SDK documents and I actually got a lot inspiration. Thanks for that. I bought an TMDSEMU110-U for debugging. That is recommended from TI tutorials of PRU debugging: PRU is connected with TMDSEMU110-U and then to the laptop. Is that how you debugged with JTAG ? I feel this approach is a little cumbersome since I need to set up a lot of environments manually. But it worked, so I just put up with it for now. I think both SDK and Beaglebone has a lot of interesting stuffs worth being explored. Appreciate your help! Regards,Cheng在2021年5月8日星期六 UTC-4 下午7:52:41 写道: Hello Cheng I learned a few things this weekend I thought I would share The PRU Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows 10 You can even debug both PRU0 and PRU1 at the same time examine memory and use HW uart debug to speed up development The RPMSG example LAB must be loaded by the linux or TI RTOS drivers running on ARM side I have win 7 and Windows 10 CCS/JTAG installations working one a Beaglebone White and the other AM335X SK BBB is also supported My Last step is building the SDK linux kernel from scratch with rproc kernel modules loaded from a VirtualBox Ubuntu VM on Win 7 The Linux SDK has binaries for the ARM side so a Native Linux BOX is NOT REQUIRED(but recommended ) CCS DOES NOT require linux to load and debug PRU For those that want to learn ARM TI RTOS Win 10 is required to build The SDK documents I saved as the wiki is disappearing are awesome I found some very detailed PRU documentation that talks about everything from running TI PRU firmware On PRU ICCS for complex Industrial protocols as well a custom PRU code The facts about clock cycles also were discussed. All of it in can be found by following the documentation tar ball I sent I you. I think too many people panic dont want to run SDK Linux or use CCS /JTAG dont read through all the documents as they dont want to go that route. Thats fine but the basic fundamentals of the whole SOC are then missed leading to confusion The SDK has done an excellent job of documenting this unfortunately unless your actually using the SDK all of this is hidden and I guess they are taking down some wikis so kind of sad this data will be lost. The approach in this group is wonderful especially for Linux App types that don't care about details they just want a working kernel
Re: [beagleboard] TI PRU_ADC_onChip example
HI Cheng I have two Beaglebone White and the am335x SK both have JTAG on the board so no soldering. The key is to follow the labs 1 to 3 only dont use any RPMsg examples The other key is the PRU gel script is crucial there is a typo error in the instructions about correct .gel file name and how to execute it I used CCS 6.0 win 7 and CCS 10 on windows 10 Id be glad to help if I can The power of the CCS/JTAG is reading memory locations and finding crashes quickly its worth the learning curve Any issues please ask but tell me your CCS version What I dont like about the PRU tutorials is all use Linux interaction as in interrupts and they assume SDK linux not Debian Its some work but you could use Windows to create a SDK linux SD card for JTAG if problems I have several jtags one is USBV2 and I have yours I also have two BBB but even being EE I dont solder Let me know be glad to help trust me after you master CCS/JTAG you will be very happy and have an awesome tool in your belt Mark On Monday, May 10, 2021, 11:51:35 PM CDT, Cheng Chen wrote: Hi Mark, Thanks a lot for the updates. I went through the SDK documents and I actually got a lot inspiration. Thanks for that. I bought an TMDSEMU110-U for debugging. That is recommended from TI tutorials of PRU debugging: PRU is connected with TMDSEMU110-U and then to the laptop. Is that how you debugged with JTAG ? I feel this approach is a little cumbersome since I need to set up a lot of environments manually. But it worked, so I just put up with it for now. I think both SDK and Beaglebone has a lot of interesting stuffs worth being explored. Appreciate your help! Regards,Cheng在2021年5月8日星期六 UTC-4 下午7:52:41 写道: Hello Cheng I learned a few things this weekend I thought I would share The PRU Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows 10 You can even debug both PRU0 and PRU1 at the same time examine memory and use HW uart debug to speed up development The RPMSG example LAB must be loaded by the linux or TI RTOS drivers running on ARM side I have win 7 and Windows 10 CCS/JTAG installations working one a Beaglebone White and the other AM335X SK BBB is also supported My Last step is building the SDK linux kernel from scratch with rproc kernel modules loaded from a VirtualBox Ubuntu VM on Win 7 The Linux SDK has binaries for the ARM side so a Native Linux BOX is NOT REQUIRED(but recommended ) CCS DOES NOT require linux to load and debug PRU For those that want to learn ARM TI RTOS Win 10 is required to build The SDK documents I saved as the wiki is disappearing are awesome I found some very detailed PRU documentation that talks about everything from running TI PRU firmware On PRU ICCS for complex Industrial protocols as well a custom PRU code The facts about clock cycles also were discussed. All of it in can be found by following the documentation tar ball I sent I you. I think too many people panic dont want to run SDK Linux or use CCS /JTAG dont read through all the documents as they dont want to go that route. Thats fine but the basic fundamentals of the whole SOC are then missed leading to confusion The SDK has done an excellent job of documenting this unfortunately unless your actually using the SDK all of this is hidden and I guess they are taking down some wikis so kind of sad this data will be lost. The approach in this group is wonderful especially for Linux App types that don't care about details they just want a working kernel and actually making one script to build linux makes sense as supporting keystroke errors and inability to read docs in a chronological orderly way would be a nightmare. So in summary In my humble Opinion if your goal is writing Linux apps on a open source board the SDK probally is NOT for you. If your goal is barebones, TI RTOS , board bring up, custom hardware , DSP programming Cortex M4 programming , advanced PRU apps or learning or adding Linux Device drivers the SDK is a great asset. Mark On Thursday, May 6, 2021, 05:28:39 PM CDT, Cheng Chen wrote: Hi Walter, Sorry for the late reply. The most important part I modified for TI's makefile is to make sure that the firmware is loaded into remoteproc1. I basically replaced the loading procedure in the shell script with Molly's version which I attached below. I also added the entire include file and modified some of the constants and variable names in the c code because compiler reports errors of unrecognized header file and variables. But except those, it runs pretty well. start: ifneq ($(PRU_DIR),) @echo write_init_pins.sh @$(COMMON)/write_init_pins.sh /lib/firmware/$(CHIP)-pru$(PRUN)-fw @echo "- Starting PRU $(PRUN)" @echo start > $(PRU_DIR)/state else ifeq ($(PROC),tidl) ti-mct-heap-check -c sudo mjpg_streamer -i "input_opencv.so -r 640x480 -d /dev/$(shell fgrep -v vpe /sys/class/video4linux/video*/name | perl -ne '/\/(video\d+)\/name/ &&
Re: [beagleboard] TI PRU_ADC_onChip example
Update AM335x SDK evaluation Sucess!! rebuild kernel sources in VBOX next will test my LInux on ARM on a board with RPROC drivers and lastly revist CCS and JTAG in Ubuntu VBOX as an option I prefer CCS on Windows but do recall CCS Linux is needed for Linux debugging Final eval steps use CCS to measure PRU instruction timings following the Labs OBJCOPY arch/arm/boot/zImage Kernel: arch/arm/boot/zImage is ready mark@mark-VirtualBox:~/ti-processor-sdk-linux-am335x-evm-06.03.00.106/board-support/linux-4.19.94+gitAUTOINC+be5389fd85-gbe5389fd85$ On Sat May 08 2021 18:52:36 GMT-0500 (CDT), 'Mark Lazarewicz' via BeagleBoard wrote: Hello Cheng I learned a few things this weekend I thought I would share The PRU Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows 10 You can even debug both PRU0 and PRU1 at the same time examine memory and use HW uart debug to speed up development The RPMSG example LAB must be loaded by the linux or TI RTOS drivers running on ARM side I have win 7 and Windows 10 CCS/JTAG installations working one a Beaglebone White and the other AM335X SK BBB is also supported My Last step is building the SDK linux kernel from scratch with rproc kernel modules loaded from a VirtualBox Ubuntu VM on Win 7 The Linux SDK has binaries for the ARM side so a Native Linux BOX is NOT REQUIRED(but recommended ) CCS DOES NOT require linux to load and debug PRU For those that want to learn ARM TI RTOS Win 10 is required to build The SDK documents I saved as the wiki is disappearing are awesome I found some very detailed PRU documentation that talks about everything from running TI PRU firmware On PRU ICCS for complex Industrial protocols as well a custom PRU code The facts about clock cycles also were discussed. All of it in can be found by following the documentation tar ball I sent I you. I think too many people panic dont want to run SDK Linux or use CCS /JTAG dont read through all the documents as they dont want to go that route. Thats fine but the basic fundamentals of the whole SOC are then missed leading to confusion The SDK has done an excellent job of documenting this unfortunately unless your actually using the SDK all of this is hidden and I guess they are taking down some wikis so kind of sad this data will be lost. The approach in this group is wonderful especially for Linux App types that don't care about details they just want a working kernel and actually making one script to build linux makes sense as supporting keystroke errors and inability to read docs in a chronological orderly way would be a nightmare. So in summary In my humble Opinion if your goal is writing Linux apps on a open source board the SDK probally is NOT for you. If your goal is barebones, TI RTOS , board bring up, custom hardware , DSP programming Cortex M4 programming , advanced PRU apps or learning or adding Linux Device drivers the SDK is a great asset. Mark On Thursday, May 6, 2021, 05:28:39 PM CDT, Cheng Chen wrote: Hi Walter, Sorry for the late reply. The most important part I modified for TI's makefile is to make sure that the firmware is loaded into remoteproc1. I basically replaced the loading procedure in the shell script with Molly's version which I attached below. I also added the entire include file and modified some of the constants and variable names in the c code because compiler reports errors of unrecognized header file and variables. But except those, it runs pretty well. start: ifneq ($(PRU_DIR),) @echo write_init_pins.sh @$(COMMON)/write_init_pins.sh /lib/firmware/$(CHIP)-pru$(PRUN)-fw @echo "- Starting PRU $(PRUN)" @echo start > $(PRU_DIR)/state else ifeq ($(PROC),tidl) ti-mct-heap-check -c sudo mjpg_streamer -i "input_opencv.so -r 640x480 -d /dev/$(shell fgrep -v vpe /sys/class/video4linux/video*/name | perl -ne '/\/(video\d+)\/name/ && print $$1') \ --filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8090 -w /usr/share/mjpg-streamer/www" else ./$(TARGET)$(EXE) endif Regards,Cheng Walter Cromer 于2021年5月4日周二 下午4:02写道: I am glad to have helped a little bit. Stick with it. When it clicks and you start really moving forward I think you'll be pleased. Can you share the changes to the Makefile that you made? I'm curious if it might help me. Right now I am reading the ADC every 2.7ms. I'm reading three channels. I include the step id too and check that. I am using switch-case to check the step and put the analog input into the right variable in my code. It might be slighter faster with an if-elseif but I like the neatness of the switch-case and until it causes me timing problems, I'm sticking with it. I am also fairly certain the ADC can be read faster. I have the ADC in one-shot mode and delay before I kick it off again. I've also run this with no averaging, 4 averages, and 16 averages and it makes very little difference in timin
Re: [beagleboard] TI PRU_ADC_onChip example
Hello Cheng I learned a few things this weekend I thought I would share The PRU Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows 10 You can even debug both PRU0 and PRU1 at the same time examine memory and use HW uart debug to speed up development The RPMSG example LAB must be loaded by the linux or TI RTOS drivers running on ARM side I have win 7 and Windows 10 CCS/JTAG installations working one a Beaglebone White and the other AM335X SK BBB is also supported My Last step is building the SDK linux kernel from scratch with rproc kernel modules loaded from a VirtualBox Ubuntu VM on Win 7 The Linux SDK has binaries for the ARM side so a Native Linux BOX is NOT REQUIRED(but recommended ) CCS DOES NOT require linux to load and debug PRU For those that want to learn ARM TI RTOS Win 10 is required to build The SDK documents I saved as the wiki is disappearing are awesome I found some very detailed PRU documentation that talks about everything from running TI PRU firmware On PRU ICCS for complex Industrial protocols as well a custom PRU code The facts about clock cycles also were discussed. All of it in can be found by following the documentation tar ball I sent I you. I think too many people panic dont want to run SDK Linux or use CCS /JTAG dont read through all the documents as they dont want to go that route. Thats fine but the basic fundamentals of the whole SOC are then missed leading to confusion The SDK has done an excellent job of documenting this unfortunately unless your actually using the SDK all of this is hidden and I guess they are taking down some wikis so kind of sad this data will be lost. The approach in this group is wonderful especially for Linux App types that don't care about details they just want a working kernel and actually making one script to build linux makes sense as supporting keystroke errors and inability to read docs in a chronological orderly way would be a nightmare. So in summary In my humble Opinion if your goal is writing Linux apps on a open source board the SDK probally is NOT for you. If your goal is barebones, TI RTOS , board bring up, custom hardware , DSP programming Cortex M4 programming , advanced PRU apps or learning or adding Linux Device drivers the SDK is a great asset. Mark On Thursday, May 6, 2021, 05:28:39 PM CDT, Cheng Chen wrote: Hi Walter, Sorry for the late reply. The most important part I modified for TI's makefile is to make sure that the firmware is loaded into remoteproc1. I basically replaced the loading procedure in the shell script with Molly's version which I attached below. I also added the entire include file and modified some of the constants and variable names in the c code because compiler reports errors of unrecognized header file and variables. But except those, it runs pretty well. start: ifneq ($(PRU_DIR),) @echo write_init_pins.sh @$(COMMON)/write_init_pins.sh /lib/firmware/$(CHIP)-pru$(PRUN)-fw @echo "- Starting PRU $(PRUN)" @echo start > $(PRU_DIR)/state else ifeq ($(PROC),tidl) ti-mct-heap-check -c sudo mjpg_streamer -i "input_opencv.so -r 640x480 -d /dev/$(shell fgrep -v vpe /sys/class/video4linux/video*/name | perl -ne '/\/(video\d+)\/name/ && print $$1') \ --filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8090 -w /usr/share/mjpg-streamer/www" else ./$(TARGET)$(EXE) endif Regards,Cheng Walter Cromer 于2021年5月4日周二 下午4:02写道: I am glad to have helped a little bit. Stick with it. When it clicks and you start really moving forward I think you'll be pleased. Can you share the changes to the Makefile that you made? I'm curious if it might help me. Right now I am reading the ADC every 2.7ms. I'm reading three channels. I include the step id too and check that. I am using switch-case to check the step and put the analog input into the right variable in my code. It might be slighter faster with an if-elseif but I like the neatness of the switch-case and until it causes me timing problems, I'm sticking with it. I am also fairly certain the ADC can be read faster. I have the ADC in one-shot mode and delay before I kick it off again. I've also run this with no averaging, 4 averages, and 16 averages and it makes very little difference in timing for me. Walter On Tuesday, May 4, 2021 at 11:33:51 AM UTC-4 chen...@gmail.com wrote: Hi Walter, Thank you so much for the reply. I think my setup is exactly the same as what you have (win10 and BBB wireless). That really motivated me to see somebody else successfully run the system with the same setup. I actually made some preliminary progress after two nights brooding and I am able to read out ADC data through rpmsg. Thanks a lot for your tips. I think the problem is still in the makefile and environment. As you mentioned, you are using makefile from PRUcookbook while I started off with TI's built-in makefile. I believe there is a couple of
Re: [beagleboard] TI PRU_ADC_onChip example
in the 57x SDK you should not have any problem loading up DSP CCS code. Pull the Linux SD card out on x15 I mean you're learning signal processing on 67x right. CCS and JTAG are the default TI DSP tools for at least 10 years Mark Sent from Yahoo Mail on Android On Tue, May 4, 2021 at 7:30 PM, Jeff Andich wrote: Very informative thread guys! Interesting article in E2E on accessing shared memory and RPMsg.. This statement by Jason Reader “…Also, if you are testing an RPMsg project you will need to use the pruss_remoteproc Linux module to load the code and not CCS over JTAG. …” could be a clue as to the issue I was having attempting to load the C66 with JTAG after remoteproc initially loaded the RPMsg example project. The stock example program was referred to in a post a couple of months ago ( https://forum.beagleboard.org/t/status-running-ti-sdk-built-c66-dsp-example-exe-on-bb-x15-beagleboard-debian/27469). If I allowed remoteproc to load the C66 example program, and downloaded only the symbol file for DSP1/C66 via CCS/JTAG, I was able to set and reach breakpoints. However, if I disabled remoteproc’s loading of the exe and attempted to load the entire C66 executable via JTAG, I got an error message ( from memory, remoteproc ID not found). I will reproduce and post up the detail in a separate post… On Tue, May 4, 2021 at 5:20 PM 'Mark Lazarewicz' via BeagleBoard wrote: Cheng Yes difference between the two Linux is why the E2E wants to know which Linux you running. Walter Here is a shared RAM CCS JTAG PRU discussion but as Cheng stated the user is using SDK Linux. Perhaps the code examples will help you solve your freeze up. It's possible ARM Linux is using that memory. Looks like the TI PRU expert is very helpful as long as your using the SDK. https://e2e.ti.com/support/processors/f/processors-forum/484479/issue-with-accessing-shared-memory-on-pru Sent from Yahoo Mail on Android On Tue, May 4, 2021 at 3:02 PM, Walter Cromer wrote: I am glad to have helped a little bit. Stick with it. When it clicks and you start really moving forward I think you'll be pleased. Can you share the changes to the Makefile that you made? I'm curious if it might help me. Right now I am reading the ADC every 2.7ms. I'm reading three channels. I include the step id too and check that. I am using switch-case to check the step and put the analog input into the right variable in my code. It might be slighter faster with an if-elseif but I like the neatness of the switch-case and until it causes me timing problems, I'm sticking with it. I am also fairly certain the ADC can be read faster. I have the ADC in one-shot mode and delay before I kick it off again. I've also run this with no averaging, 4 averages, and 16 averages and it makes very little difference in timing for me. Walter On Tuesday, May 4, 2021 at 11:33:51 AM UTC-4 chen...@gmail.com wrote: Hi Walter, Thank you so much for the reply. I think my setup is exactly the same as what you have (win10 and BBB wireless). That really motivated me to see somebody else successfully run the system with the same setup. I actually made some preliminary progress after two nights brooding and I am able to read out ADC data through rpmsg. Thanks a lot for your tips. I think the problem is still in the makefile and environment. As you mentioned, you are using makefile from PRUcookbook while I started off with TI's built-in makefile. I believe there is a couple of slight difference between Debian system and TI SDK environment which turns out to be critical in compiling. I carefully compared the difference between two makefiles and created one which is close to the makefile in the PRUcookbook. That works like a charm. Next step I also want to explore precise timing and see how fast the adc can run. May I ask what is the speed you are reading out from ADC? Regards,Cheng 在2021年5月3日星期一 UTC-4 上午11:24:23 写道: I just went through this pain and the people in this group were awesome help. I needed to read three analog inputs and it was a bear but once I got it, it has been going well. You don't mention the OS of your development platform or I may have missed it. I'm on a Windows 10 box and using a BBB Wireless. TI's entire learning system for this expects a Linux development platform so it's not as useful as it could be if you are on Windows. I didn't want to go to the trouble of even bringing up a virtual Linux on my Windows box for this. I did install Code Composer Studio (CCS) from TI, but gave up on it. There's no easy way to transfer your compiled firmware to the BBB from within it according to TI. So I just do everything on the Beagle and it meets my needs. I use the cloud9 IDE that ships with the BeagleBones for coding both the ARM and PRU code. This environment compiles the ARM-side code and executes it just like any normal host (aka Linux, aka ARM) program just fine. However
Re: [beagleboard] TI PRU_ADC_onChip example
Cheng Yes difference between the two Linux is why the E2E wants to know which Linux you running. Walter Here is a shared RAM CCS JTAG PRU discussion but as Cheng stated the user is using SDK Linux. Perhaps the code examples will help you solve your freeze up. It's possible ARM Linux is using that memory. Looks like the TI PRU expert is very helpful as long as your using the SDK. https://e2e.ti.com/support/processors/f/processors-forum/484479/issue-with-accessing-shared-memory-on-pru Sent from Yahoo Mail on Android On Tue, May 4, 2021 at 3:02 PM, Walter Cromer wrote: I am glad to have helped a little bit. Stick with it. When it clicks and you start really moving forward I think you'll be pleased. Can you share the changes to the Makefile that you made? I'm curious if it might help me. Right now I am reading the ADC every 2.7ms. I'm reading three channels. I include the step id too and check that. I am using switch-case to check the step and put the analog input into the right variable in my code. It might be slighter faster with an if-elseif but I like the neatness of the switch-case and until it causes me timing problems, I'm sticking with it. I am also fairly certain the ADC can be read faster. I have the ADC in one-shot mode and delay before I kick it off again. I've also run this with no averaging, 4 averages, and 16 averages and it makes very little difference in timing for me. Walter On Tuesday, May 4, 2021 at 11:33:51 AM UTC-4 chen...@gmail.com wrote: Hi Walter, Thank you so much for the reply. I think my setup is exactly the same as what you have (win10 and BBB wireless). That really motivated me to see somebody else successfully run the system with the same setup. I actually made some preliminary progress after two nights brooding and I am able to read out ADC data through rpmsg. Thanks a lot for your tips. I think the problem is still in the makefile and environment. As you mentioned, you are using makefile from PRUcookbook while I started off with TI's built-in makefile. I believe there is a couple of slight difference between Debian system and TI SDK environment which turns out to be critical in compiling. I carefully compared the difference between two makefiles and created one which is close to the makefile in the PRUcookbook. That works like a charm. Next step I also want to explore precise timing and see how fast the adc can run. May I ask what is the speed you are reading out from ADC? Regards,Cheng 在2021年5月3日星期一 UTC-4 上午11:24:23 写道: I just went through this pain and the people in this group were awesome help. I needed to read three analog inputs and it was a bear but once I got it, it has been going well. You don't mention the OS of your development platform or I may have missed it. I'm on a Windows 10 box and using a BBB Wireless. TI's entire learning system for this expects a Linux development platform so it's not as useful as it could be if you are on Windows. I didn't want to go to the trouble of even bringing up a virtual Linux on my Windows box for this. I did install Code Composer Studio (CCS) from TI, but gave up on it. There's no easy way to transfer your compiled firmware to the BBB from within it according to TI. So I just do everything on the Beagle and it meets my needs. I use the cloud9 IDE that ships with the BeagleBones for coding both the ARM and PRU code. This environment compiles the ARM-side code and executes it just like any normal host (aka Linux, aka ARM) program just fine. However, to compile the PRU code and load it I go over to a PUTTY session and use the make files from Mark Yoders' PRU Cookbook (https://markayoder.github.io/PRUCookbook/) . My process is clunky but my programs aren't huge or extremely complex (yet) and this works for me. I don't have and don't want to invest in a debug probe so debugging the PRU code can be a pain and slow. The only option really is to use RPMsg almost like printf to send messages back at key points in the PRU code to let me know where it is executing and what's happening. (Purists and more advanced developers are barfing and laughing at me right now I am sure.) I strongly encourage you to get the Technical Reference Manual for the TI ARM335x and specifically spend time with the Touchscreen Controller chapter. If you need precise timing, you'll want to spend time in the Industrial Ethernet Peripheral chapter too. These are powerful tools once you understand them. Also, get the PRU Optimizing C/C++ Compiler manual from TI and go through it. One thing that really tripped me up was their implementation of the __far keyword. GCC doesn't recognize that and I didn't understand what was going on at first. As Mark commented, some people encourage using remoteproc, some encourage using libpruio and some still use the uio. TI supports remoteproc and I expect them to be around so I went with remoteproc. It may have its drawbacks
Re: [beagleboard] TI PRU_ADC_onChip example
Walter This below code you posted in another thread was what I was referring to. Does the E2E forum support cloud 9 dev on BBB??? I'm also curious how you actually build/modify your Linux kernel with no Linux box. Walter Cromer wrote:changed the code to this and get the same error. fd = open ("/dev/mem", O_RDONLY | O_SYNC); // not sure O_SYNC is necessary since this is a read-only open situation Servo tester!!!ERROR: could not open /dev/mem. make: *** [/var/lib/cloud9/common/Makefile:173: start] Error 1rm /tmp/cloud9-examples/pwm-test.o Show more Sent from Yahoo Mail on Android On Mon, May 3, 2021 at 3:02 PM, Walter Cromer wrote: I'm using Debian and Cloud9 running on the Beagle. The Windows 10 box is really just providing a browser 'terminal' to the Beagle. What compiler errors? Do you mean __far? I don't think I asked about that on E2E. I just realized my mistake and did some reading to understand it. It's not an issue anymore. On Monday, May 3, 2021 at 3:44:10 PM UTC-4 lazarman wrote: Walter Yes I remember everything about your application including the Debian ARM Linux application delays nobody seemed to have answers on fixing. Your running windows 10 not using the SDK using cloud 9 and Debian as I understand. What is E2E saying about your compiler errors your asking about in this group??? Mark Sent from Yahoo Mail on Android On Mon, May 3, 2021 at 2:35 PM, Walter Cromer wrote: It was disappointing, to say the least that they said there wasn't an easy way to transfer the firmware but I believe that's what they meant. I had my application running on the ARM side just fine but we just couldn't get the deterministic timing we require for our application. That's why I went to the PRUs. We're getting awesome results on the timing now and RPMsg is fast enough on the transfer to get us the data for analysis that we need. Right now my problem is that I need to put 10 to 15 samples in an array and do some basic slope and standard deviation calculations on the values in the array but when I add that, I'm getting that my program won't fit into memory. I'm working now to learn how to initialize all my variables in the shared memory space. That's locking up the BBB every time right now. I'm following Molloy's book but it's not getting me there so far. On Monday, May 3, 2021 at 1:53:50 PM UTC-4 lazarman wrote: # I did install Code Composer Studio (CCS) from #TI, but gave up on it. There's no easy way to #transfer your compiled firmware to the BBB from #within it according to TI. Hi Walter This doesn't look correct or sound like TI.JTAG loads code extremely fast especially on the ARM. If you're referring to PRU code I've also done that as well. Your overall approach is fine imo just slow and a work in progress and yes they are helpful in E2E . CCS/ JTAG is for barebones/ RTOS ARM it will speed up PRU development. unfortunately again in my opinion a complex control loop would run on a DSP this PRU is too resource limited. It's purpose is offloading Glad to see your making progress I don't know if you saw a comment I completed your project all on the ARM side barebones very quickly unfortunately I don't recommend this for a beginner. To attempt this you really need a low level understanding of ARM so your current approach is probably your best choice Sent from Yahoo Mail on Android On Mon, May 3, 2021 at 10:24 AM, Walter Cromer wrote: I just went through this pain and the people in this group were awesome help. I needed to read three analog inputs and it was a bear but once I got it, it has been going well. You don't mention the OS of your development platform or I may have missed it. I'm on a Windows 10 box and using a BBB Wireless. TI's entire learning system for this expects a Linux development platform so it's not as useful as it could be if you are on Windows. I didn't want to go to the trouble of even bringing up a virtual Linux on my Windows box for this. I did install Code Composer Studio (CCS) from TI, but gave up on it. There's no easy way to transfer your compiled firmware to the BBB from within it according to TI. So I just do everything on the Beagle and it meets my needs. I use the cloud9 IDE that ships with the BeagleBones for coding both the ARM and PRU code. This environment compiles the ARM-side code and executes it just like any normal host (aka Linux, aka ARM) program just fine. However, to compile the PRU code and load it I go over to a PUTTY session and use the make files from Mark Yoders' PRU Cookbook (https://markayoder.github.io/PRUCookbook/) . My process is clunky but my programs aren't huge or extremely complex (yet) and this works for me. I don't have and don't want to invest in a debug probe so debugging the PRU code can be a pain and slow. The only option really is to use RPMsg almost like printf to send messages back at key points in th
Re: [beagleboard] TI PRU_ADC_onChip example
Walter Yes I remember everything about your application including the Debian ARM Linux application delays nobody seemed to have answers on fixing. Your running windows 10 not using the SDK using cloud 9 and Debian as I understand. What is E2E saying about your compiler errors your asking about in this group??? Mark Sent from Yahoo Mail on Android On Mon, May 3, 2021 at 2:35 PM, Walter Cromer wrote: It was disappointing, to say the least that they said there wasn't an easy way to transfer the firmware but I believe that's what they meant. I had my application running on the ARM side just fine but we just couldn't get the deterministic timing we require for our application. That's why I went to the PRUs. We're getting awesome results on the timing now and RPMsg is fast enough on the transfer to get us the data for analysis that we need. Right now my problem is that I need to put 10 to 15 samples in an array and do some basic slope and standard deviation calculations on the values in the array but when I add that, I'm getting that my program won't fit into memory. I'm working now to learn how to initialize all my variables in the shared memory space. That's locking up the BBB every time right now. I'm following Molloy's book but it's not getting me there so far. On Monday, May 3, 2021 at 1:53:50 PM UTC-4 lazarman wrote: # I did install Code Composer Studio (CCS) from #TI, but gave up on it. There's no easy way to #transfer your compiled firmware to the BBB from #within it according to TI. Hi Walter This doesn't look correct or sound like TI.JTAG loads code extremely fast especially on the ARM. If you're referring to PRU code I've also done that as well. Your overall approach is fine imo just slow and a work in progress and yes they are helpful in E2E . CCS/ JTAG is for barebones/ RTOS ARM it will speed up PRU development. unfortunately again in my opinion a complex control loop would run on a DSP this PRU is too resource limited. It's purpose is offloading Glad to see your making progress I don't know if you saw a comment I completed your project all on the ARM side barebones very quickly unfortunately I don't recommend this for a beginner. To attempt this you really need a low level understanding of ARM so your current approach is probably your best choice Sent from Yahoo Mail on Android On Mon, May 3, 2021 at 10:24 AM, Walter Cromer wrote: I just went through this pain and the people in this group were awesome help. I needed to read three analog inputs and it was a bear but once I got it, it has been going well. You don't mention the OS of your development platform or I may have missed it. I'm on a Windows 10 box and using a BBB Wireless. TI's entire learning system for this expects a Linux development platform so it's not as useful as it could be if you are on Windows. I didn't want to go to the trouble of even bringing up a virtual Linux on my Windows box for this. I did install Code Composer Studio (CCS) from TI, but gave up on it. There's no easy way to transfer your compiled firmware to the BBB from within it according to TI. So I just do everything on the Beagle and it meets my needs. I use the cloud9 IDE that ships with the BeagleBones for coding both the ARM and PRU code. This environment compiles the ARM-side code and executes it just like any normal host (aka Linux, aka ARM) program just fine. However, to compile the PRU code and load it I go over to a PUTTY session and use the make files from Mark Yoders' PRU Cookbook (https://markayoder.github.io/PRUCookbook/) . My process is clunky but my programs aren't huge or extremely complex (yet) and this works for me. I don't have and don't want to invest in a debug probe so debugging the PRU code can be a pain and slow. The only option really is to use RPMsg almost like printf to send messages back at key points in the PRU code to let me know where it is executing and what's happening. (Purists and more advanced developers are barfing and laughing at me right now I am sure.) I strongly encourage you to get the Technical Reference Manual for the TI ARM335x and specifically spend time with the Touchscreen Controller chapter. If you need precise timing, you'll want to spend time in the Industrial Ethernet Peripheral chapter too. These are powerful tools once you understand them. Also, get the PRU Optimizing C/C++ Compiler manual from TI and go through it. One thing that really tripped me up was their implementation of the __far keyword. GCC doesn't recognize that and I didn't understand what was going on at first. As Mark commented, some people encourage using remoteproc, some encourage using libpruio and some still use the uio. TI supports remoteproc and I expect them to be around so I went with remoteproc. It may have its drawbacks but it is working just fine for me. I can't comment on the other two as I have not tried
Re: [beagleboard] TI PRU_ADC_onChip example
# I did install Code Composer Studio (CCS) from #TI, but gave up on it. There's no easy way to #transfer your compiled firmware to the BBB from #within it according to TI. Hi Walter This doesn't look correct or sound like TI.JTAG loads code extremely fast especially on the ARM. If you're referring to PRU code I've also done that as well. Your overall approach is fine imo just slow and a work in progress and yes they are helpful in E2E . CCS/ JTAG is for barebones/ RTOS ARM it will speed up PRU development. unfortunately again in my opinion a complex control loop would run on a DSP this PRU is too resource limited. It's purpose is offloading Glad to see your making progress I don't know if you saw a comment I completed your project all on the ARM side barebones very quickly unfortunately I don't recommend this for a beginner. To attempt this you really need a low level understanding of ARM so your current approach is probably your best choice Sent from Yahoo Mail on Android On Mon, May 3, 2021 at 10:24 AM, Walter Cromer wrote: I just went through this pain and the people in this group were awesome help. I needed to read three analog inputs and it was a bear but once I got it, it has been going well. You don't mention the OS of your development platform or I may have missed it. I'm on a Windows 10 box and using a BBB Wireless. TI's entire learning system for this expects a Linux development platform so it's not as useful as it could be if you are on Windows. I didn't want to go to the trouble of even bringing up a virtual Linux on my Windows box for this. I did install Code Composer Studio (CCS) from TI, but gave up on it. There's no easy way to transfer your compiled firmware to the BBB from within it according to TI. So I just do everything on the Beagle and it meets my needs. I use the cloud9 IDE that ships with the BeagleBones for coding both the ARM and PRU code. This environment compiles the ARM-side code and executes it just like any normal host (aka Linux, aka ARM) program just fine. However, to compile the PRU code and load it I go over to a PUTTY session and use the make files from Mark Yoders' PRU Cookbook (https://markayoder.github.io/PRUCookbook/) . My process is clunky but my programs aren't huge or extremely complex (yet) and this works for me. I don't have and don't want to invest in a debug probe so debugging the PRU code can be a pain and slow. The only option really is to use RPMsg almost like printf to send messages back at key points in the PRU code to let me know where it is executing and what's happening. (Purists and more advanced developers are barfing and laughing at me right now I am sure.) I strongly encourage you to get the Technical Reference Manual for the TI ARM335x and specifically spend time with the Touchscreen Controller chapter. If you need precise timing, you'll want to spend time in the Industrial Ethernet Peripheral chapter too. These are powerful tools once you understand them. Also, get the PRU Optimizing C/C++ Compiler manual from TI and go through it. One thing that really tripped me up was their implementation of the __far keyword. GCC doesn't recognize that and I didn't understand what was going on at first. As Mark commented, some people encourage using remoteproc, some encourage using libpruio and some still use the uio. TI supports remoteproc and I expect them to be around so I went with remoteproc. It may have its drawbacks but it is working just fine for me. I can't comment on the other two as I have not tried them. Also, I've found the TI E2E forum's moderators to be patient with me as a neophyte. But the Google group's members do have wider experience. FYI - watch out for how TI puts some register settings that cross nibble or byte boundaries. It can really bite you! Take a look at the STEPCONFIGn registers implementation of averaging to see what I mean. I hope this helps! On Saturday, May 1, 2021 at 12:46:03 PM UTC-4 lazarman wrote: << wrote: Hey Mark, Thanks for spending time for replying. I really appreciate it. I totally agree with you that one should spend time investigating first. I apologize if they are dumb questions, but I have stuck there for two weeks. I am more a circuit guy and just started picking up Beaglebone as a hobby and potential career expansion. My first intention is to post in TI E2E support forums, but it requires a company email to do so. If this particular .org is not a good place for rookie questions, would you please advise some place for suitable for discussion? Regarding to the documents, are you referring to processor SDK Linux Software Developer's guide? If that is the one, I did follow its instructions, but maybe I missed something. I will go over it again. If that's not the one, which document are you referring to? I also went through PRUcookbook and Exploring BeagleBone by Derek Molly. Not
Re: [beagleboard] TI PRU_ADC_onChip example
<< wrote: Hey Mark, Thanks for spending time for replying. I really appreciate it. I totally agree with you that one should spend time investigating first. I apologize if they are dumb questions, but I have stuck there for two weeks. I am more a circuit guy and just started picking up Beaglebone as a hobby and potential career expansion. My first intention is to post in TI E2E support forums, but it requires a company email to do so. If this particular .org is not a good place for rookie questions, would you please advise some place for suitable for discussion? Regarding to the documents, are you referring to processor SDK Linux Software Developer's guide? If that is the one, I did follow its instructions, but maybe I missed something. I will go over it again. If that's not the one, which document are you referring to? I also went through PRUcookbook and Exploring BeagleBone by Derek Molly. Not a lot are mentioned regarding this topic. The code is built-in in the Beaglebone Black, this is one of the reasons I am confused why it cannot be compiled. One can also download freely from TI github (https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/). Again thanks for the advice and suggestion. I am very glad that there is such a nice place that I can call for help and I hope after some practice I am also able to contribute here. Regards,Cheng 在2021年4月30日星期五 UTC-4 下午5:09:01 写道: Hello I know the code. It's all explained in the SDK documention. I also like these examples.Your asking questions about an SDK that's supported by Texas Instruments. You do understand this .org group you posted in may contain TI employees but is NOT TI support it's Beagle board Debian. I think if you read the documents you will understand the answers I'm sure you could compile this with some work the sdk instructions talk about This. Hypothetical question ❓If the instructions told you a virtual box build was not supported and not recommended would you use one anyway and then ask the person who told you not too do this why it doesn't work. I'm struggling to be nice in this reply. I remember asking questions as a young engineer that clearly showed I made zero effort to research anything. Then one day I got some really critical replies about my skills. Do some reading then if stuck ask questions Or better yet follow what the sdk instructions suggest. If you found this code on internet and don't have a TI account or are not eligible for ITAR restrictions to download the sdk you have a big problem. I see you have a Gmail account Sent from Yahoo Mail on Android On Fri, Apr 30, 2021 at 3:09 PM, Cheng Chen wrote: Hi all, I am practicing PRU skills through some TI examples. I am playing with PRU_ADC_onChip example and ran into a few questions. I wonder if you can help me with. The nice thing about this example is it has a README.txt with all the procedures. The idea is to use rpmsg to communicate between arm and pru module and read out ADC value. I am using a Beaglebone Black wireless.Here is the basic procedures. FILE STRUCTUREPRU_ADC | |--pru_adc_firmware.c firmware loaded into PRU0 | |--pru_adc_userspace |--pru_adc_userspace.c userspace code that interacts with PRU0 BUILD FIRMWARE & USERSPACE CODE$ cd /examples/am335x/PRU_ADC_onChip/$ make clean$ make$ cd pru_adc_userspace/$ make clean$ make My BBB wireless can compile pru code successfully because I installed PRU_CGT compiler. But it is unable to compile ARM code. I think that is because ARM_CCT cross-compiler toochain environment is missing, in another word, I need to install processor-sdk-am335x My first questions is can I install processor-sdk-am335x into Debian system I currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a little confused about the relationship between this SDK and Debian system. Why is the tutorial asking me to compile pru_adc_userspace.c in the Beaglebone. I thought it is supposed to be executed in a cross-compilation environment. I ended up installing processor-sdk-am335x on my linux desktop and compiled successfully. Then I copied the generated file back to BBB wireless. But when I tried to run the program, it shows the following error. Reading voltage at ADC Channel: 5/dev/rpmsg_pru30 could not be opened.Trying to initialize PRU using sysfs interface.ERROR: Could not open /dev/rpmsg_pru30 Attached is the excerpt where the problem happened. Could anyone help me with some hints of what is going on here? Much appreciated. struct shared_struct message; /* use character device /dev/rpmsg_pru30 */ char outputFilename[] = "/dev/rpmsg_pru30"; /* test that /dev/rpmsg_pru30 exists */ FILE *ofp; uint16_t returnedVoltage; ofp = fopen(outputFilename, "r"); if (ofp == NULL) { printf("/dev/rpmsg_pru30 could not be opened. \n"); printf("Trying to initialize PRU using sysfs interface.\n"); FILE *sys
Re: [beagleboard] Re: TI PRU_ADC_onChip example
wrote: Hi Cheng The tarball has step by step instructions for that example you mentioned in initial post.you need that when starting out. Why? because few in this group use SDK. Unfortunately you have no choice to ask questions here. When code doesn't work on ARM you will get advise to use cookbook and Debian or even worse use libpruio in this group then you will really be confused. You asked howto to run sdk examples on Debian linux Your problems are 1) the instructions say use Ubuntu to install the SDK and build PRU code and Linux Application code in the SDK ie it's built on a Ubuntu LTS PC a specific version of Ubuntu as well. 2) the ARM example code you build to talk to PRU is designed for SDK Linux not Debian #1 above may be possible to overcome . BUT instead you could just take the SDK ARM example binary and the PRU firmware binary if it exist in SDK binary directory and put them on the ARM. What's in SDK directories how the example works step by step are described in SDK pdf.( I sent a link to tarball docs start there read how to install apSDK and host requirements ) #2Jeff built both sperm and PRU binary in his SDK and put them on Debian and said it it worked on Debian I don't know where Jeff installed his SDK but I doubt he put it on the BBB I don't recommend that. No body seems to understand my instructions in this group ive been told so if its not clear ask. Its all described in SDK Lastly I repeat Your going to be told don't use SDK use cookbook or libpruio樂 and Debian on ARM if you try this SDK example and it doesn't work it's already started your having problems asking questions correct? If you got an account on E2E They would say why aren't you using SDK Linux we don't support Debian Understand? You have nowhere to go you can't get in E2E Understand? I like the SDK myself but I did see Cookbook has similar RPM Message example and Marks documented that really well What happened there? Isn't there an RPMSG ADC example? Anyway you would not have any problems if you ran SDK linux with the code example you have and in theory it should work on Debian the differences are the SDK linux vs the Yocto SDK Linux maybe muxing I don't know. My am335x starter kit board i have at home came with SDK linux running on the ARM and my Beaglebone white I'm using with CCS has JTAG built in and has Ubuntu on the SD card I just pull it out. That's why I understand what's happening. I started out 5 years ago I tried Ubuntu on bone white followed this group's instructions it was easy then I bought EVM and learned Yocto SDK Linux building at that time if I had questions answers were in the SDK off tutorial and E2E forum would support me. Their board their SDK. Don't feel bad every month someone asks the same questions you did. they say "I found this PRU example in the SDK can I run this on Debian?" I say yes it will work what you are attempting. but I can't help you when Linux doesn't run your code and gets errors and when you ask for help in this group I expect you will be told use the Cookbook examples. Do yourself a favor make a choice again I give you 3 choices 1) install sdk on Ubuntu box build code for ARM and PRU use SDK Linux on SD card to test this example code. Or 2) use Debian and cookbook examples. Or best solution in my opinion 3) do #1 first get it working correctlybuy 2nd SD card put Debian on itthen try the binaries you build from #1 on Debian Everybody asks to mix both solutions your asking for trouble and wasted time trust me. Always Use the recommended linux host to build SDK or Debian and the SDK. To ignore instructions that describe host then ask for help is insane If you want grief use Fedora virtual machine on win 3 pc to build Debian and ask in this group why it doesn't work. You will get silence or be sent in 100 directions at once 藍 Mark Sent from Yahoo Mail on Android On Fri, Apr 30, 2021 at 8:10 PM, Cheng Chen wrote: Hey Dennis, Thanks for the reply. It makes a lot sense for cross-compiler. Thanks for the explanation. I am pretty sure I am running on 4.19.x-ti kernel. uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo I don't have any problem running other PRU examples. I also noticed that the original firmware is not running at first. But once it is loaded, it seems ok. I tried creating /dev/rpmsg by using "echo hello > /dev/rpmsg_pru30" before running example code. But it would leads to program freeze. I am also exploring direct memory access method to save acquired values in shared memory, but I haven't got any results yet. I think I will investigate into the device tree issue as you suggested. Thanks! Regards,Cheng 在2021年4月30日星期五 UTC-4 下午8:45:57 写道: On Fri, 30 Apr 2021 13:09:02 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Cheng Chen wrote: >My BBB wireless can compile pru code successfully because I installed >PRU_C
Re: [beagleboard] Re: TI PRU_ADC_onChip example
Hi Cheng The tarball has step by step instructions for that example you mentioned in initial post.you need that when starting out. Why? because few in this group use SDK. Unfortunately you have no choice to ask questions here. When code doesn't work on ARM you will get advise to use cookbook and Debian or even worse use libpruio in this group then you will really be confused. You asked howto to run sdk examples on Debian linux Your problems are 1) the instructions say use Ubuntu to install the SDK and build PRU code and Linux Application code in the SDK ie it's built on a Ubuntu LTS PC a specific version of Ubuntu as well. 2) the ARM example code you build to talk to PRU is designed for SDK Linux not Debian #1 above may be possible to overcome . BUT instead you could just take the SDK ARM example binary and the PRU firmware binary if it exist in SDK binary directory and put them on the ARM. What's in SDK directories how the example works step by step are described in SDK pdf.( I sent a link to tarball docs start there read how to install apSDK and host requirements ) #2Jeff built both sperm and PRU binary in his SDK and put them on Debian and said it it worked on Debian I don't know where Jeff installed his SDK but I doubt he put it on the BBB I don't recommend that. No body seems to understand my instructions in this group ive been told so if its not clear ask. Its all described in SDK Lastly I repeat Your going to be told don't use SDK use cookbook or libpruio樂 and Debian on ARM if you try this SDK example and it doesn't work it's already started your having problems asking questions correct? If you got an account on E2E They would say why aren't you using SDK Linux we don't support Debian Understand? You have nowhere to go you can't get in E2E Understand? I like the SDK myself but I did see Cookbook has similar RPM Message example and Marks documented that really well What happened there? Isn't there an RPMSG ADC example? Anyway you would not have any problems if you ran SDK linux with the code example you have and in theory it should work on Debian the differences are the SDK linux vs the Yocto SDK Linux maybe muxing I don't know. My am335x starter kit board i have at home came with SDK linux running on the ARM and my Beaglebone white I'm using with CCS has JTAG built in and has Ubuntu on the SD card I just pull it out. That's why I understand what's happening. I started out 5 years ago I tried Ubuntu on bone white followed this group's instructions it was easy then I bought EVM and learned Yocto SDK Linux building at that time if I had questions answers were in the SDK off tutorial and E2E forum would support me. Their board their SDK. Don't feel bad every month someone asks the same questions you did. they say "I found this PRU example in the SDK can I run this on Debian?" I say yes it will work what you are attempting. but I can't help you when Linux doesn't run your code and gets errors and when you ask for help in this group I expect you will be told use the Cookbook examples. Do yourself a favor make a choice again I give you 3 choices 1) install sdk on Ubuntu box build code for ARM and PRU use SDK Linux on SD card to test this example code. Or 2) use Debian and cookbook examples. Or best solution in my opinion 3) do #1 first get it working correctlybuy 2nd SD card put Debian on itthen try the binaries you build from #1 on Debian Everybody asks to mix both solutions your asking for trouble and wasted time trust me. Always Use the recommended linux host to build SDK or Debian and the SDK. To ignore instructions that describe host then ask for help is insane If you want grief use Fedora virtual machine on win 3 pc to build Debian and ask in this group why it doesn't work. You will get silence or be sent in 100 directions at once 藍 Mark Sent from Yahoo Mail on Android On Fri, Apr 30, 2021 at 8:10 PM, Cheng Chen wrote: Hey Dennis, Thanks for the reply. It makes a lot sense for cross-compiler. Thanks for the explanation. I am pretty sure I am running on 4.19.x-ti kernel. uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo I don't have any problem running other PRU examples. I also noticed that the original firmware is not running at first. But once it is loaded, it seems ok. I tried creating /dev/rpmsg by using "echo hello > /dev/rpmsg_pru30" before running example code. But it would leads to program freeze. I am also exploring direct memory access method to save acquired values in shared memory, but I haven't got any results yet. I think I will investigate into the device tree issue as you suggested. Thanks! Regards,Cheng 在2021年4月30日星期五 UTC-4 下午8:45:57 写道: On Fri, 30 Apr 2021 13:09:02 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Cheng Chen wrote: >My BBB wireless can compile pru code successfully because I installed >PRU_CGT compiler
Re: [beagleboard] TI PRU_ADC_onChip example
Cheng I'm actually using the SDK now so be careful about generic advisethe instructions are for Ubuntu not Debian'Since I had questions myself right now I realized this PRU code you have just a small part of the SDKMy point was you never read the SDK quick startPlease do so here is the doc tarball'12. Documentation Tarball — Processor SDK RTOS Documentation If you search the group on X15 and DSP Jeff Aused the SDK and ran the binary on Debian(For the DSP with remore proc) So yes you can use Debian to load the PRU firmware you need a corresponding ARM binary for that code. Jeff used the SDK to build that I dont know where you read to compile SDK examples on BBB its not something I read So use Ubuntu box as instructions tell you too OR wait to see if Jeff Andlich can tell you if its feasable to attempt to install the SDK on the board itself and compile the code that doesn't sound right to me OR create an account on E2E ask the people who designed the SDK especially if your confused I can answer CCS JTAG barebone ARM questiion about SDK not interested in Linux Please read the tarball in the link Regard' On Friday, April 30, 2021, 03:09:09 PM CDT, Cheng Chen wrote: Hi all, I am practicing PRU skills through some TI examples. I am playing with PRU_ADC_onChip example and ran into a few questions. I wonder if you can help me with. The nice thing about this example is it has a README.txt with all the procedures. The idea is to use rpmsg to communicate between arm and pru module and read out ADC value. I am using a Beaglebone Black wireless.Here is the basic procedures. FILE STRUCTUREPRU_ADC | |--pru_adc_firmware.c firmware loaded into PRU0 | |--pru_adc_userspace |--pru_adc_userspace.c userspace code that interacts with PRU0 BUILD FIRMWARE & USERSPACE CODE$ cd /examples/am335x/PRU_ADC_onChip/$ make clean$ make$ cd pru_adc_userspace/$ make clean$ make My BBB wireless can compile pru code successfully because I installed PRU_CGT compiler. But it is unable to compile ARM code. I think that is because ARM_CCT cross-compiler toochain environment is missing, in another word, I need to install processor-sdk-am335x My first questions is can I install processor-sdk-am335x into Debian system I currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a little confused about the relationship between this SDK and Debian system. Why is the tutorial asking me to compile pru_adc_userspace.c in the Beaglebone. I thought it is supposed to be executed in a cross-compilation environment. I ended up installing processor-sdk-am335x on my linux desktop and compiled successfully. Then I copied the generated file back to BBB wireless. But when I tried to run the program, it shows the following error. Reading voltage at ADC Channel: 5/dev/rpmsg_pru30 could not be opened.Trying to initialize PRU using sysfs interface.ERROR: Could not open /dev/rpmsg_pru30 Attached is the excerpt where the problem happened. Could anyone help me with some hints of what is going on here? Much appreciated. struct shared_struct message; /* use character device /dev/rpmsg_pru30 */ char outputFilename[] = "/dev/rpmsg_pru30"; /* test that /dev/rpmsg_pru30 exists */ FILE *ofp; uint16_t returnedVoltage; ofp = fopen(outputFilename, "r"); if (ofp == NULL) { printf("/dev/rpmsg_pru30 could not be opened. \n"); printf("Trying to initialize PRU using sysfs interface.\n"); FILE *sysfs_node; char firmware[] = "/sys/class/remoteproc/remoteproc1/firmware"; char firmwareName[] = "PRU_ADC_onChip.out"; sysfs_node = fopen(firmware, "r+"); if (sysfs_node == NULL) { printf("cannot open firmware sysfs_node"); return EXIT_FAILURE; } fwrite(, sizeof(uint8_t), sizeof(firmwareName), sysfs_node); fclose(sysfs_node); char pruState[] = "/sys/class/remoteproc/remoteproc1/state"; char start[] = "start"; sysfs_node = fopen(pruState, "r+"); if (sysfs_node == NULL) { printf("cannot open state sysfs_node"); return EXIT_FAILURE; } fwrite(, sizeof(uint8_t), sizeof(start), sysfs_node); fclose(sysfs_node); /* give RPMSG time to initialize */ sleep(3); ofp = fopen(outputFilename, "r"); if (ofp == NULL) { printf("ERROR: Could not open /dev/rpmsg_pru30\n"); exit(EXIT_FAILURE); } } -- 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/1d43aa7b-0e94-4431-9e31-13545213940bn%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
Re: [beagleboard] TI PRU_ADC_onChip example
Hello I know the code. It's all explained in the SDK documention. I also like these examples.Your asking questions about an SDK that's supported by Texas Instruments. You do understand this .org group you posted in may contain TI employees but is NOT TI support it's Beagle board Debian. I think if you read the documents you will understand the answers I'm sure you could compile this with some work the sdk instructions talk about This. Hypothetical question ❓If the instructions told you a virtual box build was not supported and not recommended would you use one anyway and then ask the person who told you not too do this why it doesn't work. I'm struggling to be nice in this reply. I remember asking questions as a young engineer that clearly showed I made zero effort to research anything. Then one day I got some really critical replies about my skills. Do some reading then if stuck ask questions Or better yet follow what the sdk instructions suggest. If you found this code on internet and don't have a TI account or are not eligible for ITAR restrictions to download the sdk you have a big problem. I see you have a Gmail account Sent from Yahoo Mail on Android On Fri, Apr 30, 2021 at 3:09 PM, Cheng Chen wrote: Hi all, I am practicing PRU skills through some TI examples. I am playing with PRU_ADC_onChip example and ran into a few questions. I wonder if you can help me with. The nice thing about this example is it has a README.txt with all the procedures. The idea is to use rpmsg to communicate between arm and pru module and read out ADC value. I am using a Beaglebone Black wireless.Here is the basic procedures. FILE STRUCTUREPRU_ADC | |--pru_adc_firmware.c firmware loaded into PRU0 | |--pru_adc_userspace |--pru_adc_userspace.c userspace code that interacts with PRU0 BUILD FIRMWARE & USERSPACE CODE$ cd /examples/am335x/PRU_ADC_onChip/$ make clean$ make$ cd pru_adc_userspace/$ make clean$ make My BBB wireless can compile pru code successfully because I installed PRU_CGT compiler. But it is unable to compile ARM code. I think that is because ARM_CCT cross-compiler toochain environment is missing, in another word, I need to install processor-sdk-am335x My first questions is can I install processor-sdk-am335x into Debian system I currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a little confused about the relationship between this SDK and Debian system. Why is the tutorial asking me to compile pru_adc_userspace.c in the Beaglebone. I thought it is supposed to be executed in a cross-compilation environment. I ended up installing processor-sdk-am335x on my linux desktop and compiled successfully. Then I copied the generated file back to BBB wireless. But when I tried to run the program, it shows the following error. Reading voltage at ADC Channel: 5/dev/rpmsg_pru30 could not be opened.Trying to initialize PRU using sysfs interface.ERROR: Could not open /dev/rpmsg_pru30 Attached is the excerpt where the problem happened. Could anyone help me with some hints of what is going on here? Much appreciated. struct shared_struct message; /* use character device /dev/rpmsg_pru30 */ char outputFilename[] = "/dev/rpmsg_pru30"; /* test that /dev/rpmsg_pru30 exists */ FILE *ofp; uint16_t returnedVoltage; ofp = fopen(outputFilename, "r"); if (ofp == NULL) { printf("/dev/rpmsg_pru30 could not be opened. \n"); printf("Trying to initialize PRU using sysfs interface.\n"); FILE *sysfs_node; char firmware[] = "/sys/class/remoteproc/remoteproc1/firmware"; char firmwareName[] = "PRU_ADC_onChip.out"; sysfs_node = fopen(firmware, "r+"); if (sysfs_node == NULL) { printf("cannot open firmware sysfs_node"); return EXIT_FAILURE; } fwrite(, sizeof(uint8_t), sizeof(firmwareName), sysfs_node); fclose(sysfs_node); char pruState[] = "/sys/class/remoteproc/remoteproc1/state"; char start[] = "start"; sysfs_node = fopen(pruState, "r+"); if (sysfs_node == NULL) { printf("cannot open state sysfs_node"); return EXIT_FAILURE; } fwrite(, sizeof(uint8_t), sizeof(start), sysfs_node); fclose(sysfs_node); /* give RPMSG time to initialize */ sleep(3); ofp = fopen(outputFilename, "r"); if (ofp == NULL) { printf("ERROR: Could not open /dev/rpmsg_pru30\n"); exit(EXIT_FAILURE); } } -- 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/1d43aa7b-0e94-4431-9e31-13545213940bn%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] Re: Beaglebone Black [BBB] Read Shared memory from PRU
Are you sure /dev/mem isn't there? I think it's required. bone$ *ls -ls /dev/mem* 0 crw-r- 1 root kmem 1, 1 Apr 14 09:11 /dev/mem bone$ *groups* debian adm *kmem* dialout cdrom floppy audio dip video plugdev users systemd-journal input bluetooth netdev i2c remoteproc eqep pwm cloud9ide xenomai weston-launch tisdk docker iio spi admin gpio You should be in the kmem group by default so sudo isn't needed. --Mark On Thursday, April 29, 2021 at 3:17:16 PM UTC-4 wal...@edenconceptsllc.com wrote: > Here's the code too. Sorry, should have included it. > > int fd; > printf("Setting up pru0 memory access.\n"); > > fd = open ("/dev/mem", O_RDWR | O_SYNC); > if (fd == -1) { > printf ("ERROR: could not open /dev/mem.\n\n"); > return 1; > } > > > When I look for /dev/mem it doesn't exist whether logged in as debian or > root > > > > On Thursday, April 29, 2021 at 3:15:10 PM UTC-4 Walter Cromer wrote: > >> Mark - I'm integrating the concepts from the PRUCookbook so I can send >> some control parameters entered by the user in the host side program and >> pass them over to the PRU0 firmware. >> >> I'm getting this error when I try to compile the code. >> >> Setting up pru0 memory access. >> ERROR: could not open /dev/mem. >> >> Any ideas? >> >> I'm running a BBB Wireless with video and audio disabled. >> >> Here's the output of version.sh >> >> debian@beaglebone:/var/lib/cloud9$ sudo /opt/scripts/tools/version.sh >> [sudo] password for debian: >> git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46] >> eeprom:[A335BNLTBWA52027BBWG0227] >> model:[TI_AM335x_BeagleBone_Black_Wireless] >> dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06] >> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot >> 2019.04-2-g07d5700e21]:[location: dd MBR] >> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot >> 2018.03-2-gac9cce7c6a]:[location: dd MBR] >> UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts] >> UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0] >> UBOOT: Loaded Overlay:[BB-ADC-00A0] >> UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0] >> UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0] >> UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231] >> UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2] >> kernel:[4.19.94-ti-r61] >> nodejs:[v10.15.2] >> /boot/uEnv.txt Settings: >> uboot_overlay_options:[enable_uboot_overlays=1] >> >> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo] >> uboot_overlay_options:[disable_uboot_overlay_video=1] >> uboot_overlay_options:[disable_uboot_overlay_audio=1] >> >> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo] >> uboot_overlay_options:[enable_uboot_cape_universal=1] >> uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo] >> pkg check: to individually upgrade run: [sudo apt install --only-upgrade >> ] >> pkg:[bb-cape-overlays]:[4.14.20210401.0-0~buster+20210401] >> pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322] >> pkg:[kmod]:[26-1] >> pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327] >> pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305] >> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video >> plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc >> admin spi iio docker tisdk weston-launch xenomai cloud9ide] >> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 >> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M >> net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet] >> dmesg | grep remote >> [ 69.927418] remoteproc remoteproc0: wkup_m3 is available >> [ 70.105672] remoteproc remoteproc0: powering up wkup_m3 >> [ 70.105706] remoteproc remoteproc0: Booting fw image >> am335x-pm-firmware.elf, size 217148 >> [ 70.106000] remoteproc remoteproc0: remote processor wkup_m3 is now up >> [ 72.319951] remoteproc remoteproc1: 4a334000.pru is available >> [ 72.335870] remoteproc remoteproc2: 4a338000.pru is available >> [ 564.302719] remoteproc remoteproc1: powering up 4a334000.pru >> [ 564.303391] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, >> size 118908 >> [ 564.316303] remoteproc remoteproc1: registered virtio0 (type 7) >> [ 564.316324] remoteproc remoteproc1: remote processor 4a334000.pru is >> now up >> [ 590.322924] remoteproc remoteproc1: stopped remote processor >>
Re: [beagleboard] TI Programmable Real-time Unit software support package issues
Have you looked at libruio? it fix everything. free support as well in group by TJ. Sent from Yahoo Mail on Android On Fri, Apr 23, 2021 at 4:31 PM, pierrick.ra...@gadz.org wrote: Have you check M Yoder PRU cookbook? Pierrick Rauby On 23 Apr 2021, at 16:56, Cheng Chen wrote: Hi all, I am new learner of Beaglebone Black and I was trying to follow the examples of Programmable Real-time Unit software support package from TI. I think there was a tutorial website previously but now it's obsolete. I wonder if anybody knows where those materials is available? The reason I asked is I am not able to successfully run any examples except PRU_gpioToggle. In particular I am interested in RPMsg transfer between ARM and PRU. For example, PRU_ADC_onChip, after I built the firmware and userspace code, and run ./pru_adc_userspace -c 5. It just shows error messages. Reading voltage at ADC Channel: 5/dev/rpmsg_pru30 could not be opened.Trying to initialize PRU using sysfs interface.ERROR: Could not open /dev/rpmsg_pru30 I think it should be just some minor issues like driver missing and such. But I don't know where to start debugging. It would be nice that if anybody knows where the tutorial is. I feel like I'm just trying in the dark. Thanks. Regards,Cheng -- 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/b0dc4e7b-edd7-45f7-b54b-28a9cedd6a2an%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/585CFD31-D22E-4C60-A444-378EB8E47288%40gadz.org. -- 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/712155500.28019.1619213877110%40mail.yahoo.com.
Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG
Clock cycle's good subject. Seems some thinks everything PRU does is one clock cycle ( 5ns) perhaps assembler instructions are. Also confusion about actual speed of control loops.A 100ns control loop runs every 100ns and does input, decisions and output that fast. Lastly the PRU has small codes size and any fast control loop running on ARM must get the data from PRU quickly. I know you understand these concept. My solution to the original question Walter posted is now working.I used bare metal on arm in system mode. CCS and JTAG to debug the ARM samples ADC. Input to ARM control loop comes from GUI on PC. No delays took about 8 hour's coding. No IPC. Your project sound's interesting I will be watching for an ARM to PRU ADC examples using libruio and current Linux provided by this group. Just downloaded and go Sent from Yahoo Mail on Android On Thu, Apr 22, 2021 at 2:26 AM, TJF wrote: For all who want to learn: Walter is formating a human readable number in the PRUSS code (function ltoa). How much PRU cycles does a four digit number need? And how much are necessary for a one digit number? Note: The PRUSS are fine for realtime solutions (if your code allows that). @Walter Welcome to rproc/rpmsg - you completely lost track. -- 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/11b35216-030c-42c5-8ec2-5a1a1c41d40dn%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/320986334.2848196.1619111409800%40mail.yahoo.com.
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 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 overflow immediately and start counting in the main processing sequence at 0. In my case, my next step, also borrowed from their examples, was to reset the overflow event flag. Which, of course was immediately set back high because the counter incremented AFTER this reset instruction and not before. So when I issued the overflow event reset, the counter was still at 0x which caused an immediate overflow event. Ugh. Live and learn. On Wednesday, April 21, 2021 at 12:28:14 PM UTC-4 Walter Cromer wrote: 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 seem to correctly check the overflow bit in IEP_TMR_GLB_STS. I would bit 0 would be 1 if there has been an overflow but even at startup, when the counter only has maybe 1000 counts in it, the bit is 1 when I read it. Maybe I'm not reading it correctly? On Monday, January 9, 2017 at 12:45:08 AM UTC-5 justin@gmail.com wrote: On Thu, Jan 5, 2017 at 5:30 PM, Justin Pearson wrote: Thanks Charles, that's very helpful. I didn't know about the IEP timer. TRM section 4.4.3.1 says I can hook up the IEP clock source to either iep_clk or ocp_clk. Which one of those clocks drives the PRU cycle counter? Maybe a better question is: Can the PRU read the IEP clock as deterministically as it reads its own cycle counter (always 1 cycle)? Or does it access the IEP clock over some bus that introduces non-deterministic delays due to contention issues (like accessing the 512MB RAM)? I'm concerned because I'm using the cycle counter for time-stamping sensor and actuator measurements. If I switch to the IEP clock, I'd like to know I'll have the same timing guarantees. Thanks,Justin Thanks,Justin On Thu, Dec 22, 2016 at 1:43 PM, Charles Steinkuehler wrote: On 12/22/2016 10:45 AM, Justin Pearson wrote: > I have the same question. > > I'm using the PRU's 200 MHz cycle counter to timestamp sensor measurements. At > 200 MHz, this 32-bit counter overflows in 20 seconds. I would like to notify > a C > program running on the 1GHz host ARM processor as soon as it overflows. > > *Is it possible to configure the PRU cycle counter to trigger an interrupt in > the host ARM when it overflows?* Do you mean the Cycle register (offset 0x0C in the PRU_ICSS_PRU_CTRL register bank)? If so, this counter doesn't even wrap around (it automatically stops when it hits 0x) much less generate an interrupt. > I know how to write PRU code to make the PRU trigger an interrupt in the host, > but that's not quite what I want, since my PRU will be busy doing other > things. > I would like the cycle counter to trigger an interrupt automatically, without > the PRU having to check if it has overflowed. Try using the IEP timer. It will wrap automatically, and you can even setup a configurable period by using compare register zero and setting the CMP0_RST_CNT_EN bit. You can also route an IEP timer event (pr1_iep_tim_cap_cmp_pend) to the ARM core to generate an interrupt. -- Charles Steinkuehler cha...@steinkuehler.net -- 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...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3e1b910f-6ec3-06d1-ab1c-fd10dd3c7856%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout. -- 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/fc0c68cb-7308-44ce-bef6-8f476f4b6b78n%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
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 saw a list of actual PRU cycle times perhaps in same pdf. What ever I looked at everything is not done in one clock cycle on PRU but I've looked at so many doc's I may be mistaken Your question about clock source can be probably be best understood my reading the TRM clock section and looking at the the clicking sub system block diagram. Then maybe some code examples. My guess is what you have is fastest for time stamps since the IRQ capability doesn't exist like Charles said that question about clock source became don't care. Sent from Yahoo Mail on Android On Wed, Apr 21, 2021 at 11:28 AM, Walter Cromer wrote: 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 seem to correctly check the overflow bit in IEP_TMR_GLB_STS. I would bit 0 would be 1 if there has been an overflow but even at startup, when the counter only has maybe 1000 counts in it, the bit is 1 when I read it. Maybe I'm not reading it correctly? On Monday, January 9, 2017 at 12:45:08 AM UTC-5 justin@gmail.com wrote: On Thu, Jan 5, 2017 at 5:30 PM, Justin Pearson wrote: Thanks Charles, that's very helpful. I didn't know about the IEP timer. TRM section 4.4.3.1 says I can hook up the IEP clock source to either iep_clk or ocp_clk. Which one of those clocks drives the PRU cycle counter? Maybe a better question is: Can the PRU read the IEP clock as deterministically as it reads its own cycle counter (always 1 cycle)? Or does it access the IEP clock over some bus that introduces non-deterministic delays due to contention issues (like accessing the 512MB RAM)? I'm concerned because I'm using the cycle counter for time-stamping sensor and actuator measurements. If I switch to the IEP clock, I'd like to know I'll have the same timing guarantees. Thanks,Justin Thanks,Justin On Thu, Dec 22, 2016 at 1:43 PM, Charles Steinkuehler wrote: On 12/22/2016 10:45 AM, Justin Pearson wrote: > I have the same question. > > I'm using the PRU's 200 MHz cycle counter to timestamp sensor measurements. At > 200 MHz, this 32-bit counter overflows in 20 seconds. I would like to notify > a C > program running on the 1GHz host ARM processor as soon as it overflows. > > *Is it possible to configure the PRU cycle counter to trigger an interrupt in > the host ARM when it overflows?* Do you mean the Cycle register (offset 0x0C in the PRU_ICSS_PRU_CTRL register bank)? If so, this counter doesn't even wrap around (it automatically stops when it hits 0x) much less generate an interrupt. > I know how to write PRU code to make the PRU trigger an interrupt in the host, > but that's not quite what I want, since my PRU will be busy doing other > things. > I would like the cycle counter to trigger an interrupt automatically, without > the PRU having to check if it has overflowed. Try using the IEP timer. It will wrap automatically, and you can even setup a configurable period by using compare register zero and setting the CMP0_RST_CNT_EN bit. You can also route an IEP timer event (pr1_iep_tim_cap_cmp_pend) to the ARM core to generate an interrupt. -- Charles Steinkuehler cha...@steinkuehler.net -- 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/3e1b910f-6ec3-06d1-ab1c-fd10dd3c7856%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout. -- 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/5fb26840-0eed-47ba-9b21-3fa5ddd52ae4n%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
Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG
Dump or print the quantity pointed at if you're intrigued to see if it's correct. Sent from Yahoo Mail on Android On Wed, Apr 21, 2021 at 8:13 AM, Walter Cromer wrote: I'm working on that very thing. I fairly certain what is printing is an address although it doesn't seem to correspond to anything I'd expect. On Tuesday, April 20, 2021 at 9:35:54 PM UTC-4 gbcs...@comcast.net wrote: Try changing the %n in the print statement to print out a 32 bit value. I think you will see that it is an address in the PRU address space. Graham From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] On Behalf Of Walter Cromer Sent: Tuesday, April 20, 2021 10:34 AM To: BeagleBoard Subject: [beagleboard] Strange behavior of value returned from PRU with RPMSG I am using a Beaglebone Black and C to read analog inputs with PRU0 and return the data to a host program using RPMSG. Basically, I read the data from FIFO0 fine, strip the step id from it and copy it into an element of a character array in the PRU code. Data = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFODATA(0)); if ((Data & 0x000F) == 0) { // checking the step id tag for step 0 // if step == 0, strip off the step and put the data in array DetBSample DetBSample[sampleno] = Data & 0xFFF; memcpy(payload, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 24); // this came from TI's sample code, best I can tell it just preloads and end of string character in the whole string. ltoa((long)DetBSample[sampleno], payload); // put the value in DetBSample[sampleno] in the character string payload // now send the payload to the host pru_rpmsg_send(, dst, src, payload, 24); This code compiles and runs fine. On the host side, I do this when I'm kicked by the PRU. (This is a snippet so brackets may not match!) /* Poll until we receive a message from the PRU and then print it */ result = read(pollfds[0].fd, readBuf, MAX_BUFFER_SIZE); if (result > 0) { Volts = atof(readBuf)*ADC_Res; printf("Message %d received from PRU:%s or %x\n", i, readBuf, readBuf); printf("Volts read: %.3f\n",Volts); The output is strange though (snippet below). The message #, string value of readBuf and Volts are all correct. But when I output readBug as hex, it never changes. I thought it might be the address of readBuf but it doesn't appear to be. The voltage matches the input we're providing from a bench power supply and the decimal value is correct. It's just that this hex value doesn't change. Message 97 received from PRU:3742 or 4b50b0 Volts read: 1.644 Message 98: Sent to PRU Message 98 received from PRU:3744 or 4b50b0 Volts read: 1.645 Message 99: Sent to PRU Message 99 received from PRU:3743 or 4b50b0 Volts read: 1.645 Received 100 messages, closing /dev/rpmsg_pru30 -- 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...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/784129ee-1cf5-4438-881e-7ac6621e7aben%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/e1e0cd85-ed1d-4de8-983f-c787d4edfb7dn%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/926669601.2542478.1619012469767%40mail.yahoo.com.
Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG
Hello Walter Not dumb you have done well I'm taking credit藍 for your sucess just kidding.I saw a bunch of good examples somewhere maybe SDK.What was cool was they had PRU code that used every peripheral possible from the PRU. Excellent starting point the TI examples combined with Cookbook you have something going!!! and choices. I'm off trying to run something similar on the ARM using CCS and starterware and JTAG on a beaglebone white. I realize that's unrelated to your goals but I also got up to speed quickly you inspired me to refresh my skills.Thank you!!! Cheers Mark Sent from Yahoo Mail on Android On Tue, Apr 20, 2021 at 4:15 PM, Walter Cromer wrote: Here is the definition char readBuf[MAX_BUFFER_SIZE]; MAX_BUFFER_SIZE = 512 I think I may have just realized why this is occurring. When %s refers to readBuf it will output the value in the character array. But %x is outputting the address of it. Duh...not the first dumb mistake I've made today. On Tuesday, April 20, 2021 at 4:59:35 PM UTC-4 lazarman wrote: Hello Walter I didn't see your definition of readBuf.why you expecting an address to change? I am glad you found the TI examples helpful. Mark Sent from Yahoo Mail on Android On Tue, Apr 20, 2021 at 12:33 PM, Walter Cromer wrote: I am using a Beaglebone Black and C to read analog inputs with PRU0 and return the data to a host program using RPMSG. Basically, I read the data from FIFO0 fine, strip the step id from it and copy it into an element of a character array in the PRU code. Data = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFODATA(0)); if ((Data & 0x000F) == 0) { // checking the step id tag for step 0// if step == 0, strip off the step and put the data in array DetBSampleDetBSample[sampleno] = Data & 0xFFF; memcpy(payload, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 24); // this came from TI's sample code, best I can tell it just preloads and end of string character in the whole string.ltoa((long)DetBSample[sampleno], payload); // put the value in DetBSample[sampleno] in the character string payload// now send the payload to the host pru_rpmsg_send(, dst, src, payload, 24); This code compiles and runs fine. On the host side, I do this when I'm kicked by the PRU. (This is a snippet so brackets may not match!) /* Poll until we receive a message from the PRU and then print it */result = read(pollfds[0].fd, readBuf, MAX_BUFFER_SIZE); if (result > 0) { Volts = atof(readBuf)*ADC_Res; printf("Message %d received from PRU:%s or %x\n", i, readBuf, readBuf); printf("Volts read: %.3f\n",Volts); The output is strange though (snippet below). The message #, string value of readBuf and Volts are all correct. But when I output readBug as hex, it never changes. I thought it might be the address of readBuf but it doesn't appear to be. The voltage matches the input we're providing from a bench power supply and the decimal value is correct. It's just that this hex value doesn't change. Message 97 received from PRU:3742 or 4b50b0Volts read: 1.644Message 98: Sent to PRUMessage 98 received from PRU:3744 or 4b50b0Volts read: 1.645Message 99: Sent to PRUMessage 99 received from PRU:3743 or 4b50b0Volts read: 1.645Received 100 messages, closing /dev/rpmsg_pru30 -- 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...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/784129ee-1cf5-4438-881e-7ac6621e7aben%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/34361932-cafb-46a7-b31c-c962fe3bda89n%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/143772072.2118322.1618954223137%40mail.yahoo.com.
Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG
Hello Walter I didn't see your definition of readBuf.why you expecting an address to change? I am glad you found the TI examples helpful. Mark Sent from Yahoo Mail on Android On Tue, Apr 20, 2021 at 12:33 PM, Walter Cromer wrote: I am using a Beaglebone Black and C to read analog inputs with PRU0 and return the data to a host program using RPMSG. Basically, I read the data from FIFO0 fine, strip the step id from it and copy it into an element of a character array in the PRU code. Data = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFODATA(0)); if ((Data & 0x000F) == 0) { // checking the step id tag for step 0// if step == 0, strip off the step and put the data in array DetBSampleDetBSample[sampleno] = Data & 0xFFF; memcpy(payload, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 24); // this came from TI's sample code, best I can tell it just preloads and end of string character in the whole string.ltoa((long)DetBSample[sampleno], payload); // put the value in DetBSample[sampleno] in the character string payload// now send the payload to the host pru_rpmsg_send(, dst, src, payload, 24); This code compiles and runs fine. On the host side, I do this when I'm kicked by the PRU. (This is a snippet so brackets may not match!) /* Poll until we receive a message from the PRU and then print it */result = read(pollfds[0].fd, readBuf, MAX_BUFFER_SIZE); if (result > 0) { Volts = atof(readBuf)*ADC_Res; printf("Message %d received from PRU:%s or %x\n", i, readBuf, readBuf); printf("Volts read: %.3f\n",Volts); The output is strange though (snippet below). The message #, string value of readBuf and Volts are all correct. But when I output readBug as hex, it never changes. I thought it might be the address of readBuf but it doesn't appear to be. The voltage matches the input we're providing from a bench power supply and the decimal value is correct. It's just that this hex value doesn't change. Message 97 received from PRU:3742 or 4b50b0Volts read: 1.644Message 98: Sent to PRUMessage 98 received from PRU:3744 or 4b50b0Volts read: 1.645Message 99: Sent to PRUMessage 99 received from PRU:3743 or 4b50b0Volts read: 1.645Received 100 messages, closing /dev/rpmsg_pru30 -- 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/784129ee-1cf5-4438-881e-7ac6621e7aben%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/1193630117.2417515.1618952361396%40mail.yahoo.com.
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
Here's a job they used to use TI chips but I see they now use NXP. I like NXP chips and the support is good they have ARM based chips this old old Freescale architecture. Linux support Job Ad embedded system OS device drivers Software development experience with designs featuring modern ARM SoC packages (e.g. Board support packages, driver development, and/or JTAG Emulation) Software development experience with the NXP i.MX SoC family is desirable Development experience with the Linux OS is desirable Ability to interpret hardware schematics, circuit designs, and datasheets Proficiency with C, C++ Proficiency with multi-threaded, multi-core design and/or real-time operating systems My message here is if you can't get answers from a vendor buy from someone else who listens. This assumes you have some leverage and buy chips in quantity. Again this forum is good for hobbyists the problem is these hobbyists go to TI E2E forum asking for source code for proprietary software and have zero intention of buying chips in bulk. These are same low caliber engineers who come to this group with a board and Free Linux asking questions like. It no works kindly revert to me a solution 螺浪來樂 They want CCS and JTAG on resume perhaps you can hire them on next project they use Linux because it's free. Only one problem you need to train them at work and pay them too. They also use this group for training purposes they demand solution's, tutorial and source code. Uhmm Okay I go back to documenting issues I finding on Eval boards I purchased and wasting time on tool's that are deprecated so I can waste my time in this group educating on tool's that are needed by hiring manager but not on resumes. Maybe Walter will need help on CCS but doubtful at least I'm aware of the state of development Mark Sent from Yahoo Mail on Android On Mon, Apr 19, 2021 at 11:22 AM, 'Mark Lazarewicz' via BeagleBoard wrote: Hello Thomas My experience is not only way We pick the processor then the tools ( RTOS,JTAG. Compiler/ IDE if the stuff doesn't work or if vendor's don't support properly we don't use their product( I determine this usually). Like you I expect answers 鸞 So pick chip, OS then architecture then FINALLY from Hardware System's engineer document IO is assigned and documented in table and layed out in board Low level Coder starts pin muxing coding and Interrupt and drivers. Application is divided in to tasks or threads by software architect at same time I do board support so JTAG for me is something I insist on. ( New hardware). I like IDE one that allows RTOS awareness Greenhills has one of the Best I have used CCS maybe a dozen time's projects used their DSP I am familiar with CCS but have worked where you build by command line and make files. These are huge fortune 200 companies so money is no problems for tools. One big Medical company my title was tool's software. I played around. I'm a mercenary hired gun. If I don't like their approach and they lie or waste my time I tactfully explain bad ideas. A few times I know there design approach will fail I mention to them at beginning then I do what I'm told. then it fails they get angry 藍 What's a$$ backwards to you is ( your last email) is normal. For what you do linux makes sense buy hardware don't need JTAG or CCS. here in lies the flaw when you use free software the approach to IPC may be less than ideal but getting it fixed no one cares with an RTOS it costs $50K you get support and attention. or Else In open source you get ignored and runaround in circles and your support is this group which isn't support. This approach is for hobbyists with big dreams and no budget. I will say many jobs are using Linux I see them daily doesn't mean I have to. There are free alternative but why bother if Linux works for you and this IPC is flawed you have my attention. This is another part of my job. Improve RTOS supplied BSP driver's add new ones and find the crap that's not hard real time flawed. An example Green Hill's Integrity BSP for omapl138 had examples code of IPC between ARM and DSP given to customer as I mentioned the PhD design fast queues didn't use it improved it made it fast like what your doing. Now TI had driver's and code and .h files and Green Hills had their own .c .h files doing same thing. I think TI did custom first stage loader not sure.It did what about and mlo does on Linux but much better. There's no one way to design thing's perhaps you can share what's flawed in Rpmsg in details if that's true so you don't get sued call it RP Don't Worky nice.藍羅 and bring attention to it's limitations. You sound like smart Guy maybe it's true. In closing these dev board's or hobby boards serve a purpose. The EVM ones the HW design was very good but I have issues with long term support I'm not going to mention in this group ( poor practice) the early .org boards by Gerald very nice he's gone. The open source community won't
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
Hello Thomas My experience is not only way We pick the processor then the tools ( RTOS,JTAG. Compiler/ IDE if the stuff doesn't work or if vendor's don't support properly we don't use their product( I determine this usually). Like you I expect answers 鸞 So pick chip, OS then architecture then FINALLY from Hardware System's engineer document IO is assigned and documented in table and layed out in board Low level Coder starts pin muxing coding and Interrupt and drivers. Application is divided in to tasks or threads by software architect at same time I do board support so JTAG for me is something I insist on. ( New hardware). I like IDE one that allows RTOS awareness Greenhills has one of the Best I have used CCS maybe a dozen time's projects used their DSP I am familiar with CCS but have worked where you build by command line and make files. These are huge fortune 200 companies so money is no problems for tools. One big Medical company my title was tool's software. I played around. I'm a mercenary hired gun. If I don't like their approach and they lie or waste my time I tactfully explain bad ideas. A few times I know there design approach will fail I mention to them at beginning then I do what I'm told. then it fails they get angry 藍 What's a$$ backwards to you is ( your last email) is normal. For what you do linux makes sense buy hardware don't need JTAG or CCS. here in lies the flaw when you use free software the approach to IPC may be less than ideal but getting it fixed no one cares with an RTOS it costs $50K you get support and attention. or Else In open source you get ignored and runaround in circles and your support is this group which isn't support. This approach is for hobbyists with big dreams and no budget. I will say many jobs are using Linux I see them daily doesn't mean I have to. There are free alternative but why bother if Linux works for you and this IPC is flawed you have my attention. This is another part of my job. Improve RTOS supplied BSP driver's add new ones and find the crap that's not hard real time flawed. An example Green Hill's Integrity BSP for omapl138 had examples code of IPC between ARM and DSP given to customer as I mentioned the PhD design fast queues didn't use it improved it made it fast like what your doing. Now TI had driver's and code and .h files and Green Hills had their own .c .h files doing same thing. I think TI did custom first stage loader not sure.It did what about and mlo does on Linux but much better. There's no one way to design thing's perhaps you can share what's flawed in Rpmsg in details if that's true so you don't get sued call it RP Don't Worky nice.藍羅 and bring attention to it's limitations. You sound like smart Guy maybe it's true. In closing these dev board's or hobby boards serve a purpose. The EVM ones the HW design was very good but I have issues with long term support I'm not going to mention in this group ( poor practice) the early .org boards by Gerald very nice he's gone. The open source community won't support or don't care about JTAG at least in this group but TI does.You really have no choices in this group beyond Linux. Barebones and RTOS on these boards isn't a concern on this group so I'm wasting my time but it's sometimes good reading. BTW good luck even if you demonstrate this IPC isn't ideal because that's not the Agenda here. It's marketing getting student to Love Linux and this board. Unfortunately that's not the Real world not ever be used in Missles,Satellites or air. Boeing and Lockheed have the best engineering in United States. Both of these company uses TI DSP chips they don't use Linux my friend. Linux is good but not a fix all for everything and getting ignored is something big company won't tolerate just the hobbyists they have no choices the dire hard open source will save the world fanatic are attracted to all the glamour like sheep. Then one day they show up in this group posting it don't Worky help me LoL Great group it's focus is easy building of mainstream linux and keep buying more boards. What's the next board coming? Was nice when Gerald was onboard nice guy very talented and always had time for questions you see the best engineer don't feel threatened by questions and are willing to help there's some exception some of the best are over worked micro managed by manager's who have no technical skill and want to advance in company. Good engineer's leave those environments. Mark Sent from Yahoo Mail on Android On Mon, Apr 19, 2021 at 12:46 AM, TJF wrote: Hi Mark, let me first point out that this discussion isn't in my mother tongue. Sometimes I read your statements several times still not understanding what exactly you mean. Mark Lazarewicz schrieb am Sonntag, 18. April 2021 um 16:49:22 UTC+2: who you want to believe Texas Instrumentr or TJF? I believe none of them. The hardware is reality. I make experiments (ask the hardware) to find out
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
TJF* I Dont* agree and neither do companies that have sold 10k products that sounds finished to me unfortunately CCS doesnt support Basic language so I can see why your worried and I wish you the best of luck getting libpruio inluded in the kernel sincerely. Linux is great I just dont use it for hard realtime I an in line with TI marketing see below link. The reason the PRU is there is to allow linux as a gateway and hard realtime is done on the PRU. The original poster's project IS NOT hard REAL Time perhaps you can help him get his project working on ARM since thats all you understand. * Ensuring real-time predictability* https://www.ti.com/lit/pdf/spry264 The fact that TI also supports QNX , Intergrity and Nucleeus see here https://www.ti.com/tool/TMDSSK3358 shows TI knows what real customers want besides Linux I wont insult you like you attempted to do to me as I consider the source someone who does not develop just pays for solutions you have zero credibility. Anyway my code is up and running and for the group I will offer another path the AM335X has touch screen and onboard FTDI jtag and isntructions for using CCS on it and Beagle Bone Black. Add up the cost of a JTAG and touch screen its actually reasonable its here https://www.ti.com/lit/ug/sprw236b/sprw236b.pdf I repeat again from TI a great company with great engineers read this its actually related to the posters original question unlike this angry uncalled for post . who you want to believe Texas Instrumentr or TJF? BTW Rproc and RPMsg is supported by TI in Linux kernel and TI RTTOS its also documented well not Doxygen comments lifted from code Some real latencies and exact access times in block diagram no snake oil https://www.ti.com/lit/ug/sprw236b/sprw236b.pdf CCS/JTAG is an option not for everyone but recommended for board bring up you know the real work that engineers do. not some bean counter who doesn't actually do the work The user can make his own choices I'm just trying to be helpful Mark On Sunday, April 18, 2021 at 1:09:43 AM UTC-5 TJF wrote: > Hi Mark, > > you're the master of reversed order! You want to code a main loop before > IO is working. You want to CCS/JTAG variables before your first LOC is > running. Did you ever finish a project? > > When a subsystem is off (not clocked) the PRU can still read or write its > registers. Readings are always zero and writings go to Nirvana, no error > message, no exeption. How should a debugger help in this case? > > Mark Lazarewicz schrieb am Sonntag, 18. April 2021 um 03:13:10 UTC+2: > >> Anyway Linux is not required for CCS and its slow and inferior to Windows >> 10 version > > > LINUX is stable and reliable. Anyway, CSS is not required for PRU > development. Since I aim to open up the full PRUSS power (I've payed for), > I continue ignoring all that CSS bloat (!! a linker for a 2k instruction > space !!). > > Regards > -- 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/60fb316a-c523-4d88-a3b1-afc598e8af83n%40googlegroups.com.
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
<Add Files but < We're designing it the way you suggested. The nice thing is that > basically the control logic has already been written in C on the ARM side. > Now, I just need to get it ported to the PRUs and create the communications > between the PRUs and a new ARM app that supervises everything from the > user's point of view. Meaning, taking inputs like start, stop and giving > feedback by turning LEDs on and off. And it needs to take in some basic > system configuration data from the cloud periodically that the PRU will > consume to adjust it's operation. > > I am making progress. Part of my problem was using Cloud9 for > development. That's where all my ARM development has been so far. I have > CCS installed on my Windows 10 machine and started working through TI's PRU > Hands On Labs. Unfortunately, the very first one doesn't work because > their document is written for CCS running on Linux. Step 6 says to delete > the linker file and add it back with Project->Add Files but that's grayed > out. I've asked TI about that. But I got it to compile by writing on the > Beagle using nano and compiling it there. I've ready a lot of TI > documentation today and learned a lot. > > Here's one more thing I am struggling with though. It's a mental block I > think. I'm used to controlling GPIOs on the ARM side using sysfs. It > appears that on the PRU, we use __R30 instead but I don't understand how > that works. I read through it this morning and it still isn't sinking in. > If anyone can help make this clearer, I'd appreciate it. > > On Tuesday, April 13, 2021 at 11:25:08 AM UTC-4 lazarman wrote: > >> Walter >> >> Your best bet. >> >> Run your whole control loop on the PRU that's as realtime as you get. Use >> a foreground background loop. Use the ARM like a PC with Linux to access >> the system via ethernet. >> >> You could also run control on ARM without linux but this way you have all >> the resources of Linux to access the system. >> >> This assumes your output's from control loop are accessable from PRU. >> >> The point is Linux can only run slow control loops and this way you don't >> have to debug the delay. >> >> This wasn't obvious to me before as all the hard realtime systems I work >> on run an RTOS on ARM it has all the resources of Linux but cost $. >> >> In our system we did that on the DSP the PID did the math on a fast DSP. >> >> ARM is just a gateway to outside world. >> >> Myself I'd debug the PRU with JTAG and CCS you can see exactly what's >> going on and dump these registers from CCS. >> >> Some people like printf but with a PRU based system you are essentially >> doing barebones. >> >> There's videos on PRU development doing this online. >> >> Loading code via rproc and using printf is like burning and erasing an >> eeprom to test your changes. You wait 45 minutes for it to erase try your >> code and do it again. >> >> Not for me. >> >> Mark >> >> >> Sent from Yahoo Mail on Android >> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature> >> >> On Tue, Apr 13, 2021 at 9:54 AM, Dennis Lee Bieber >> wrote: >> >> On Mon, 12 Apr 2021 13:08:48 -0700 (PDT), in >> gmane.comp.hardware.beagleboard.user Walter Cromer >> wrote: >> >> >What's really throwing me is the + between what looks like two macro >> >values. Normally, we see the + on the right sign of the equals, right? >> >Or am I forgetting something I used to know!? >> > >> >> Why? Take into account the ()s. >> >> From what I can tell, this is adding the ADC register offset to the >> base address of the (?) wakeup register block, which is passed as >> parameter >> to HWREG (no doubt some macro that sets up actual access to the SoC >> registers and returns a pointer or some such), and then assigns 0x02 into >> the register so indicated. >> >> >> -- >> Dennis L Bieber >> >> -- >> 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+unsub...@googlegroups.com. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/44cb7gtf6pl4d4j3e6oqo57g5n0hobi29c%404ax.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/65260523-1937-4b4f-9ce4-173253452517n%40googlegroups.com.
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
Sorry Chrome browser on windows this works for me https://groups.google.com/g/beagleboard/c/-WlvGEaqrKU/m/EatslVHvCwAJ On Friday, April 16, 2021, 01:51:00 PM CDT, 'Mark Lazarewicz' via BeagleBoard wrote: Hi Jeff I have it open on my PC in gmail I'll send you a link to your personal email. Strange stuff going on in my Yahoo client. And searching the group on Google group's took me a few tries to find this so no your not crazy Jeff. Key words seem important I'd imagine this group's archive is huge. Give me 5 minutes and check your email. I'm at the point where I can't offer much help without doing some actual work with CCS and JTAG mainly as a refresher for myself Cheers Mark Sent from Yahoo Mail on Android On Fri, Apr 16, 2021 at 1:40 PM, jeff@gmail.com wrote: Really interesting post!! But I can't seem to find this thread on the new Beaglebone forums webpage over here: https://forum.beagleboard.org/ Am I missing something or just loosing my mind? On Friday, April 16, 2021 at 1:36:16 PM UTC-4 Dennis Bieber wrote: On Thu, 15 Apr 2021 09:35:20 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Walter Cromer wrote: >So if I had an application that had a sensor A that needs to be read every >10ms and sensor B that only needs to be read every minute, I could wire >channel 1 to sensor A and assign it to step 1 and wire channel 2 to sensor >B and assign it to step 2. > >Then at startup, when I want to read both sensors, I enable steps 1 and 2 >but not 3-16. This saves time on the read as channels 3-7 aren't needed >and steps 3-16 aren't needed so I don't use them. Then after the initial >read when I don't need to read sensor B until a minute passes, I can change >STEPENABLE so only step 1 is enabled and execute a read every 10 ms. Only >sensor A would be read. Then at one minute intervals, I change STEPENABLE >so steps 1 & 2 are enabled and when read is triggered, sensors A and B are >read. > Seems like a lot of fiddling around with step enables, and assumes ADC reading is a one-shot operation. I'd likely just create a process loop with major frame of 1 minute, minor frame of 10ms (use a "frame counter" that you increment after every read), and read both sources each time -- but only report the one-minute source at top of major frame; counter at 6 if my calculations are right). The ADC configurations supports continuous mode in which, after all enabled steps are processed, it loops back to the top and restarts the step sequence. Note: " 12.3.4 One-Shot (Single) or Continuous Mode When the sequencer finishes cycling through all the enabled steps, the user can decide if the sequencer should stop (one-shot), or loop back and schedule the step again (continuous). If one-shot mode is selected, the sequencer will take care of disabling the step enable bit after the conversion. If continuous mode is selected, it is the software’s responsibility to turn off the step enable bit. " ... if doing one-shot, you don't have to turn off the second step enable... You have to, instead, turn ON the steps you want active before doing the reads -- every time. Also pertinent -- as soon as any step is enabled, the ADC goes out of IDLE to handle enabled steps. There is a master Enable in the CTRL register -- to synchronize the reads, you'd likely have to set it to 0, program the steps, then set it to 1 to start the ADC. -- Dennis L Bieber -- 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/4c5b55c6-c1be-4c39-adbe-ff2a6339ffc0n%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/375946152.1674261.1618599048305%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/1137219829.1685121.1618599543253%40mail.yahoo.com.
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
Hi Jeff I have it open on my PC in gmail I'll send you a link to your personal email. Strange stuff going on in my Yahoo client. And searching the group on Google group's took me a few tries to find this so no your not crazy Jeff. Key words seem important I'd imagine this group's archive is huge. Give me 5 minutes and check your email. I'm at the point where I can't offer much help without doing some actual work with CCS and JTAG mainly as a refresher for myself Cheers Mark Sent from Yahoo Mail on Android On Fri, Apr 16, 2021 at 1:40 PM, jeff@gmail.com wrote: Really interesting post!! But I can't seem to find this thread on the new Beaglebone forums webpage over here: https://forum.beagleboard.org/ Am I missing something or just loosing my mind? On Friday, April 16, 2021 at 1:36:16 PM UTC-4 Dennis Bieber wrote: On Thu, 15 Apr 2021 09:35:20 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Walter Cromer wrote: >So if I had an application that had a sensor A that needs to be read every >10ms and sensor B that only needs to be read every minute, I could wire >channel 1 to sensor A and assign it to step 1 and wire channel 2 to sensor >B and assign it to step 2. > >Then at startup, when I want to read both sensors, I enable steps 1 and 2 >but not 3-16. This saves time on the read as channels 3-7 aren't needed >and steps 3-16 aren't needed so I don't use them. Then after the initial >read when I don't need to read sensor B until a minute passes, I can change >STEPENABLE so only step 1 is enabled and execute a read every 10 ms. Only >sensor A would be read. Then at one minute intervals, I change STEPENABLE >so steps 1 & 2 are enabled and when read is triggered, sensors A and B are >read. > Seems like a lot of fiddling around with step enables, and assumes ADC reading is a one-shot operation. I'd likely just create a process loop with major frame of 1 minute, minor frame of 10ms (use a "frame counter" that you increment after every read), and read both sources each time -- but only report the one-minute source at top of major frame; counter at 6 if my calculations are right). The ADC configurations supports continuous mode in which, after all enabled steps are processed, it loops back to the top and restarts the step sequence. Note: " 12.3.4 One-Shot (Single) or Continuous Mode When the sequencer finishes cycling through all the enabled steps, the user can decide if the sequencer should stop (one-shot), or loop back and schedule the step again (continuous). If one-shot mode is selected, the sequencer will take care of disabling the step enable bit after the conversion. If continuous mode is selected, it is the software’s responsibility to turn off the step enable bit. " ... if doing one-shot, you don't have to turn off the second step enable... You have to, instead, turn ON the steps you want active before doing the reads -- every time. Also pertinent -- as soon as any step is enabled, the ADC goes out of IDLE to handle enabled steps. There is a master Enable in the CTRL register -- to synchronize the reads, you'd likely have to set it to 0, program the steps, then set it to 1 to start the ADC. -- Dennis L Bieber -- 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/4c5b55c6-c1be-4c39-adbe-ff2a6339ffc0n%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/375946152.1674261.1618599048305%40mail.yahoo.com.
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
I spent most of yesterday reading TI's documentation and the Beaglebone Black SRM in detail and believe I have a much better handle on how this works now. My plan is to allocate memory space in pru0's RAM for the data storage and then have an ARM program read it from there Thanks for link Ignore my question about missing posts its my Android Tablet from Samsung email client That SRM doesn't talk about "allocate memory space in pru0's RAM for the data storage and then have an ARM program read it from there" Did you read something that describes doing this? Also that SRM says TI doesn't support PRU rather wierd. Your statement lead my to believe some TI docs gave you an *epiphany* can you explain? If there are any docs like this in my experience they come from E2E not .org Ive got several boards at home and a jtag and a fresh ccs install I plan on revisting this soon Thx Mark On Thursday, April 15, 2021 at 9:13:19 AM UTC-5 wal...@edenconceptsllc.com wrote: > I think this is a better version. Than what I posted a few minutes ago ( > Ideleted that post). > > > https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual > > > > On Thursday, April 15, 2021 at 9:55:41 AM UTC-4 lazarman wrote: > >> Beaglebone Black SRM >> >> Have not seen this can you share a link >> >> Thanks >> >> Mark >> >> Sent from Yahoo Mail on Android >> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature> >> >> On Thu, Apr 15, 2021 at 8:15 AM, Walter Cromer >> wrote: >> >> I'm sticking with remoteproc for now. I spent most of yesterday reading >> TI's documentation and the Beaglebone Black SRM in detail and believe I >> have a much better handle on how this works now. >> My plan is to allocate memory space in pru0's RAM for the data storage >> and then have an ARM program read it from there.Our production solution >> does not need to share this data with the ARM side. We only need this >> during R so I'm not worried about the two sides clobbering each other on >> the production system. >> >> But, now, of course, nothing that used to work is working! I had started >> out with the PRUCookbook and had P9_11 blinking an LED. Now, nothing. >> dmesg shows the PRU starting and stopping and the firmware file in >> /lib/firmware is new based on ls -l output so I'm fairly certain that the >> code got compiled and copied over to the right directory. The PRUCookbook >> example that blinks USR3 works and I can change the blinking frequency and >> change it to blink USR2 instead and all that works. But the example to >> blink P9_11 won't and neither will another one to blink P9_27. The only >> thing I know I changed is that the PRUCookbook directories were all owned >> by root and group root. They weren't originally like that but got changed >> somehow. Yesterday I did a *chown -R debian:debian* on PRUCookbook to >> change them so Debian could edit files in those directories. I wouldn't >> think this would matter since all the real remoteproc action happens in >> other directories. >> >> I also started working with CCS some and trying to get it going. >> Somewhere along the way, something deleted all the files and folders in my >> local WIndows machine's Documents folder. I'm running anti-virus and >> anti-malware on the WIndows box. >> >> Just when I thought I was going to start really moving forward!!! >> >> On Thursday, April 15, 2021 at 2:24:55 AM UTC-4 TJF wrote: >> >> lazarman schrieb am Donnerstag, 15. April 2021 um 07:55:39 UTC+2: >> >> I thought he had an unacceptable delay reading ADC from ARM? >> Just trying to understand how libpruio fixes this and if it did why even >> bother with PRU? >> >> >> In RB mode libpruio fetches ADC data at accurate timing (no delays) in to >> a ring buffer. The ARM can read/evaluate the data later. >> >> @Walter >> Inspired by lazarman, just another thought: perhaps you don't need a PRU >> mainloop at all. Perhaps you can meet your needs by ARM code using the >> libpruio trigger features in MM mode. >> >>1. Configure your trigger event (up to four events can get chained >>up). >>2. Open valves. >>3. Start MM mode, synchronously waiting for trigger. >>4. Close valves. >>5. ?Perhaps evaluate pre-trigger values? >>6. Repeat from step 2. >> >> -- >> >> For more options, visit http://beagleboard.org/discus
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
Hello Walter I think so nice novel approach. Since the 2nd PRU is started manualy from command line in Linux you shouldnt get clobbered as thats what that memory is for the PRU code and Resource Tables from my reading. Id guess address translation is required. shared RAM could be used as well I know that works thinks are much simpler when ARM is in supervisor mode no userland but I digress.I saw your latest post I think that issue has come up before maybe search the group I might be wrong maybe poke around in the OCP dir see whats there. How these directories get created should be documented perhaps in some Linux readme none of this tribal knowledge exists in barebone arm its straight C code muxing. Searching E2E I saw a thread blaming Linux for CCS/JTAG issues on PRU theres definately many angry confused users out there I appreciate the difficulty in supporting a complex chip but sorting all this can be daunting. I installed CCCS 10 Win10 for a TI simple Link radio project and Im seeing grayed out feature Id rather avoid CCS on Linux. I've installed CCS on at least a dozen projects on windows never had issues I am still confused as at one point some features and Processors were not free. These wikis in the past have been very helpful I see some migration going on with that documentation a bit scary. Lastly I found some PRU examples digging in E2E Im more apt to start with those vs cookbook they mention CCS6. If I delve into Linux/PRU it would be the RPMsg examples and I have a sneaky hunch the command line build example may work fine using sdk linux but from past experience the CCS/JTAG require xml and gel files to hold the ARM core off and do muxing and low level setup of memory. Hopefully I can share something useful. Does Cookbook have RPMsg examples? Mark On Friday, April 16, 2021, 07:49:22 AM CDT, Walter Cromer wrote: As I get a better understanding and experience this may change, but right now I don't think it can handle the volume of data we need to move between systems. And, that volume is only needed during R The production system will not need to keep that data. So, my plan is to instance arrays on the ARM side and use RPMSG to pass the addresses to the PRU. The PRU code will translate that to ARM addresses. As the data is collected it will be stored in arrays local to the PRUs (in the 8k or 12k memory spaces). When the time-sensitive data collection is completed, the PRU array will contain the data. Then we'll just copy it over the ARM addresses. My assumption is that since the ARM instances the arrays in memory, Linux will not overwrite those locations so they'll be 'safe'. I'll probably use RPMSG to alert ARM that the data is going to be transferred and wait on an 'ack' from the ARM before copying it over. Seems like it should work. On Friday, April 16, 2021 at 3:01:56 AM UTC-4 lazarman wrote: Hello TJF Looks very powerful and code is very generic and well thought out. I thought you couldn't code?藍 I'm on tablet forgive my laziness where are the ADC examples located in c language if possible Looks like you support multiple languages nice. I'm guessing below reference you mentioned is the am335x TRM or are you referring to the ARM intellectual property for ADC? It's also possible to directly write to the step configuration in AdcSet::St_p by writing to the member variables Confg and Delay. See ARM Reference Guide, chapter 12 for details on ADC configurations. Thanks. Did you write this library? It's quite a bit to wrap ones mind around. How long dis this take to develop. I've got a basic understanding of how RPMSG works I'd like to understand how libpruio handles the data exchange. I'm wondering why Walter isn't using RPMSG he's talking about using the other unused PRU memory to store data and have ARM read it. I'm trying to see if that's doable for my own understanding. Certainly would not be good if that PRU loaded code from ARM. The Linux part I'm unfamiliar with. From my reading it sounds like starting PRU is manually done from linux command line. Loading and debugging PRU code seems to me to be slow and time consuming compared to jtag. Lastly in the unlikely event a modified libpruio example crashes what is the debug mechanisms beyond dmsg saying dude you crashed go recompile and reload. Are console output echoed back. Thanks in advance also any data sharing examples in libpruio?Mark Sent from Yahoo Mail on Android On Fri, Apr 16, 2021 at 12:47 AM, TJF wrote: wal...@edenconceptsllc.com schrieb am Donnerstag, 15. April 2021 um 18:35:20 UTC+2: So, STEPENABLE lets me enable the steps that I want to be executed. (I missed that concept before.) So if I had an application that had a sensor A that needs to be read every 10ms and sensor B that only needs to be read every minute, I could wire channel 1 to sensor A and assign it to step 1 and wire channel 2 to sensor B and assign it to step 2
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
Hello TJF Looks very powerful and code is very generic and well thought out. I thought you couldn't code?藍 I'm on tablet forgive my laziness where are the ADC examples located in c language if possible Looks like you support multiple languages nice. I'm guessing below reference you mentioned is the am335x TRM or are you referring to the ARM intellectual property for ADC? It's also possible to directly write to the step configuration in AdcSet::St_p by writing to the member variables Confg and Delay. See ARM Reference Guide, chapter 12 for details on ADC configurations. Thanks. Did you write this library? It's quite a bit to wrap ones mind around. How long dis this take to develop. I've got a basic understanding of how RPMSG works I'd like to understand how libpruio handles the data exchange. I'm wondering why Walter isn't using RPMSG he's talking about using the other unused PRU memory to store data and have ARM read it. I'm trying to see if that's doable for my own understanding. Certainly would not be good if that PRU loaded code from ARM. The Linux part I'm unfamiliar with. From my reading it sounds like starting PRU is manually done from linux command line. Loading and debugging PRU code seems to me to be slow and time consuming compared to jtag. Lastly in the unlikely event a modified libpruio example crashes what is the debug mechanisms beyond dmsg saying dude you crashed go recompile and reload. Are console output echoed back. Thanks in advance also any data sharing examples in libpruio?Mark Sent from Yahoo Mail on Android On Fri, Apr 16, 2021 at 12:47 AM, TJF wrote: wal...@edenconceptsllc.com schrieb am Donnerstag, 15. April 2021 um 18:35:20 UTC+2: So, STEPENABLE lets me enable the steps that I want to be executed. (I missed that concept before.) So if I had an application that had a sensor A that needs to be read every 10ms and sensor B that only needs to be read every minute, I could wire channel 1 to sensor A and assign it to step 1 and wire channel 2 to sensor B and assign it to step 2. Then at startup, when I want to read both sensors, I enable steps 1 and 2 but not 3-16. This saves time on the read as channels 3-7 aren't needed and steps 3-16 aren't needed so I don't use them. Then after the initial read when I don't need to read sensor B until a minute passes, I can change STEPENABLE so only step 1 is enabled and execute a read every 10 ms. Only sensor A would be read. Then at one minute intervals, I change STEPENABLE so steps 1 & 2 are enabled and when read is triggered, sensors A and B are read. There're 17 steps, one charge step and 16 sample steps. Each step configures not only the multiplexer (chanel 0-7), but also an open delay and a sample delay, as well as an avaraging number. That's explained at AdcUdt::setStep(), including a hint where to find further information in the ARM TRM. In order to write to the STEPENABLE register you've to stop the sequencer, write the new value and restart the sequencer again. This is 3 times L3 operation, which need at least 3 PRU cycles each (perhaps more in case of heavy travel). How do you what to ensure accurate ADC timing? The outnumber of step registers isn't thought of macroscopic asymmetry (in your case sample channel A and B at 10 ms and ignore the B value for a minute). It's made for microscopic asymmetry, ie when you want to sample A twice as often as B. -- 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/def726b2-31f2-469b-a9fc-70fc429ffa59n%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/806450037.1554779.1618556494588%40mail.yahoo.com.
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
Beaglebone Black SRM Have not seen this can you share a link Thanks Mark Sent from Yahoo Mail on Android On Thu, Apr 15, 2021 at 8:15 AM, Walter Cromer wrote: I'm sticking with remoteproc for now. I spent most of yesterday reading TI's documentation and the Beaglebone Black SRM in detail and believe I have a much better handle on how this works now. My plan is to allocate memory space in pru0's RAM for the data storage and then have an ARM program read it from there. Our production solution does not need to share this data with the ARM side. We only need this during R so I'm not worried about the two sides clobbering each other on the production system. But, now, of course, nothing that used to work is working! I had started out with the PRUCookbook and had P9_11 blinking an LED. Now, nothing. dmesg shows the PRU starting and stopping and the firmware file in /lib/firmware is new based on ls -l output so I'm fairly certain that the code got compiled and copied over to the right directory. The PRUCookbook example that blinks USR3 works and I can change the blinking frequency and change it to blink USR2 instead and all that works. But the example to blink P9_11 won't and neither will another one to blink P9_27. The only thing I know I changed is that the PRUCookbook directories were all owned by root and group root. They weren't originally like that but got changed somehow. Yesterday I did a chown -R debian:debian on PRUCookbook to change them so Debian could edit files in those directories. I wouldn't think this would matter since all the real remoteproc action happens in other directories. I also started working with CCS some and trying to get it going. Somewhere along the way, something deleted all the files and folders in my local WIndows machine's Documents folder. I'm running anti-virus and anti-malware on the WIndows box. Just when I thought I was going to start really moving forward!!! On Thursday, April 15, 2021 at 2:24:55 AM UTC-4 TJF wrote: lazarman schrieb am Donnerstag, 15. April 2021 um 07:55:39 UTC+2: I thought he had an unacceptable delay reading ADC from ARM?Just trying to understand how libpruio fixes this and if it did why even bother with PRU? In RB mode libpruio fetches ADC data at accurate timing (no delays) in to a ring buffer. The ARM can read/evaluate the data later. @Walter Inspired by lazarman, just another thought: perhaps you don't need a PRU mainloop at all. Perhaps you can meet your needs by ARM code using the libpruio trigger features in MM mode. - Configure your trigger event (up to four events can get chained up). - Open valves. - Start MM mode, synchronously waiting for trigger. - Close valves. - ?Perhaps evaluate pre-trigger values? - Repeat from step 2. -- 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/11c39bb9-4891-4271-8374-ae76f00f9e17n%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/582729532.1375228.1618494919152%40mail.yahoo.com.
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
- learn to read ADC values in RB mode (first from ARM side, then from PRU) - learn to exchange data between ARM and PRU - finally put all together in your PRU mainloop (perhaps test on ARM before) Hello TJFI thought he had an unacceptable delay reading ADC from ARM?Just trying to understand how libpruio fixes this and if it did why even bother with PRU? Sent from Yahoo Mail on Android On Thu, Apr 15, 2021 at 12:00 AM, TJF wrote: wal...@edenconceptsllc.com schrieb am Mittwoch, 14. April 2021 um 17:58:31 UTC+2: So I looked over the libpruio page and it looks great. My head's spinning a bit between remoteproc, uio, and libpruio options but I'd like to try libpruio. I don't want to break remoteproc if I set up to use libpruio. Will that happen? libpruio will never run under rproc, since rproc isn't powerful enough (same issue with maschinekit). Only uio_pruss driver will meet its needs. Also, I'm running Buster (version.sh) at the bottom of this post The instructions refer to Jessie. Are the Debian packages referred to compatible with Buster? Here's what I am referring to. The easy way to benefit from libpruio is to install the Debian packages. They're not in mainline, yet. RobertCNelson started to add the packages in mainline years ago. Ask him why he never finished. For kernel 4.19 you'll have to add a symlink, since a sysfs path changed. (Compiling from source may be a good option.) Start your project by a working example. Then add features step by step. You cannot test your PRU mainloop before you got hardware IO running. - install libpruio - get pruss_toggle example running - add a second output - learn to read ADC values in RB mode (first from ARM side, then from PRU) - learn to exchange data between ARM and PRU - finally put all together in your PRU mainloop (perhaps test on ARM before) Regards -- 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/7f8b9988-b6bf-4ae5-885b-818f1be0664bn%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/1604609652.1312043.1618466117801%40mail.yahoo.com.
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
That reference Dennis provided especially the block diagram showing everything about both PRU have access to is essential and a good thing to really consume. Note each PRU has instruction ram and data RAM. Instruction ram is where a debugger or rproc loads your pru program. Keep in mind any ADC register you used on ARM has a different address on PRU if you're porting code from ARM be careful. That document Dennis linked to also explains the ARM does muxing. That's defined ar setting a pins function as in GPIO or ADC etc etc. So PRU can access the ADC register direct as in those Macro's you were asking about. Lastly the memory map shows shared RAM I'm almost positive that's the area the ARM can access so that's your gateway between the PRU and ARM. Be careful rproc may be using a chunk of that but theoretically you could write your results and ARM could read it but you need a queue and a Way to ensure only one side is accessing the Data. This can be done many ways unless you're really comfortable you might look for something else to transfer data. I know the rproc for x15 carves out shared memory and all this done I think in the device tree. Here's the magic area | 0x0001_ | Data 12KB RAM 2 (Shared) | I'd start with a PRU cookbook ADC working example get that running then start asking about alternatives. Maybe send back your ADC values to ARM while you change voltage input. Dice the job up into manageable chunk's Keep in mind you have no OS on PRU a main.c program will run once and exit. Start getting familiar with every address important in your application on PRU and that document and exactly what you have to debug when PRU crashesPrintf etc etc Baby steps Warren the tortoise slow and steady always wins the race. Sent from Yahoo Mail on Android On Wed, Apr 14, 2021 at 3:20 PM, Dennis Lee Bieber wrote: On Wed, 14 Apr 2021 08:03:30 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Walter Cromer wrote: > The TSC_ADC only has 8 channels. So why are there 16 STEP registers? So far as I can make out, since each step config includes the input/channel, it means one can sample the same channel multiple times during a sequence. -- Dennis L Bieber -- 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/i1je7g5lji264tiuae2ftumvb1e3mauicv%404ax.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/539829544.1070839.1618433959578%40mail.yahoo.com.
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
Walter Just trying to be a guiding light. Why not get the control loop working on PRU first.? Your being pulled into to many directions. I know how that feels I've been there. Once the ADC and output works worry about getting Data over to ARM. Too many new things will kill you. Master the PRU coding first and on second thought forget the CCS JTAG suggestions I gave. I'm getting dizzy reading all the suggestions you received. What's working what's the architecture? Too many chef's the soup will boil away. Thanks Mark Sent from Yahoo Mail on Android On Wed, Apr 14, 2021 at 10:58 AM, Walter Cromer wrote: So I looked over the libpruio page and it looks great. My head's spinning a bit between remoteproc, uio, and libpruio options but I'd like to try libpruio. I don't want to break remoteproc if I set up to use libpruio. Will that happen? Also, I'm running Buster (version.sh) at the bottom of this post The instructions refer to Jessie. Are the Debian packages referred to compatible with Buster? Here's what I am referring to. The easy way to benefit from libpruio is to install the Debian packages. They're not in mainline, yet. So you have to add a PPA (Personal Package Archive) to your package management sources. On the default Debian operating system, edit the file sudo nano /etc/apt/sources.list and add the lines: deb http://beagle.tuks.nl/debian jessie/deb-src http://beagle.tuks.nl/debian jessie/ Then grep the keyring by (mind the '-' character at the end) wget -qO - http://beagle.tuks.nl/debian/pubring.gpg | sudo apt-key add - Once prepared, you can update your package manager database sudo apt-get update debian@beaglebone:/$ sudo opt/scripts/tools/version.shgit:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]eeprom:[A335BNLT00C04417BBBK1847]model:[TI_AM335x_BeagleBone_Black]dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2019.04-2-g07d5700e21]:[location: dd MBR]bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2018.03-2-gac9cce7c6a]:[location: dd MBR]UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]UBOOT: Loaded Overlay:[BB-ADC-00A0]UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]kernel:[4.19.94-ti-r61]nodejs:[v10.15.2]/boot/uEnv.txt Settings:uboot_overlay_options:[enable_uboot_overlays=1]uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]uboot_overlay_options:[enable_uboot_cape_universal=1]uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]pkg check: to individually upgrade run: [sudo apt install --only-upgrade ]pkg:[bb-cape-overlays]:[4.14.20210401.0-0~buster+20210401]pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]pkg:[kmod]:[26-1]pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc admin spi iio docker tisdk weston-launch xenomai cloud9ide]cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]dmesg | grep remote[ 66.835497] remoteproc remoteproc0: wkup_m3 is available[ 67.240120] remoteproc remoteproc0: powering up wkup_m3[ 67.240151] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217148[ 67.240404] remoteproc remoteproc0: remote processor wkup_m3 is now up[ 69.894313] remoteproc remoteproc1: 4a334000.pru is available[ 69.907897] remoteproc remoteproc2: 4a338000.pru is available[15549.657580] remoteproc remoteproc1: powering up 4a334000.pru[15549.665009] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 30880[15549.665035] remoteproc remoteproc1: header-less resource table[15549.675909] remoteproc remoteproc1: Boot failed: -22[15602.811891] remoteproc remoteproc1: powering up 4a334000.pru[15602.812184] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 30880[15602.812202] remoteproc remoteproc1: header-less resource table[15602.823804] remoteproc remoteproc1: Boot failed: -22[15801.464252] remoteproc remoteproc1: powering up 4a334000.pru[15801.464540] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 30880[15801.464559] remoteproc remoteproc1: header-less resource table[15801.475947] remoteproc remoteproc1: Boot failed: -22[15835.561165] remoteproc remoteproc1: powering up 4a334000.pru[15835.561459] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 30880[15835.561478
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
Walter Your best bet. Run your whole control loop on the PRU that's as realtime as you get. Use a foreground background loop. Use the ARM like a PC with Linux to access the system via ethernet. You could also run control on ARM without linux but this way you have all the resources of Linux to access the system. This assumes your output's from control loop are accessable from PRU. The point is Linux can only run slow control loops and this way you don't have to debug the delay. This wasn't obvious to me before as all the hard realtime systems I work on run an RTOS on ARM it has all the resources of Linux but cost $. In our system we did that on the DSP the PID did the math on a fast DSP. ARM is just a gateway to outside world. Myself I'd debug the PRU with JTAG and CCS you can see exactly what's going on and dump these registers from CCS. Some people like printf but with a PRU based system you are essentially doing barebones. There's videos on PRU development doing this online. Loading code via rproc and using printf is like burning and erasing an eeprom to test your changes. You wait 45 minutes for it to erase try your code and do it again. Not for me. Mark Sent from Yahoo Mail on Android On Tue, Apr 13, 2021 at 9:54 AM, Dennis Lee Bieber wrote: On Mon, 12 Apr 2021 13:08:48 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Walter Cromer wrote: >What's really throwing me is the + between what looks like two macro >values. Normally, we see the + on the right sign of the equals, right? >Or am I forgetting something I used to know!? > Why? Take into account the ()s. From what I can tell, this is adding the ADC register offset to the base address of the (?) wakeup register block, which is passed as parameter to HWREG (no doubt some macro that sets up actual access to the SoC registers and returns a pointer or some such), and then assigns 0x02 into the register so indicated. -- Dennis L Bieber -- 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/44cb7gtf6pl4d4j3e6oqo57g5n0hobi29c%404ax.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/1399018227.882946.1618327492314%40mail.yahoo.com.
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
Look for a registrer similar name to ADC clk Ctrl in TRM under the ADC section. That's looks like a C macro and it's writing 0x02 to that register. Macro Probably defined in a header file. the registers will have different offsets depending on ARM or PRU access Perhaps revisit init code on ARM you had working and document every bit that's important in ADC set-up and compare that to this PRU code. Remember getting the Data out of PRU to ARM timings are important. I see you asked me about rproc that I don't use Linux that was TJ comments. I'm afraid the PRU was marketed to you as the answer by people that don't understand your timing requirement. Lot's of script kiddies and cookbook reader's in this group few system engineer that actually read your intial post Good luck Sent from Yahoo Mail on Android On Mon, Apr 12, 2021 at 3:08 PM, Walter Cromer wrote: I'm working through this and learning a lot. But also realizing how much I have either forgotten or just never knew. So, can I get a quick primer on what this line of C code is doing? HWREG(SOC_CM_WKUP_REGS + CM_WKUP_ADC_TSC_CLKCTRL) = 0x02; Thanks! On Monday, April 12, 2021 at 10:53:22 AM UTC-4 Walter Cromer wrote: I'll look at that. I thought remoteproc was the way of the future so I was heading down that path. And if in production I don't need to do a lot of data transfer, does it make sense to use uio_pruss/libpruio ( I don't know much about these, it's probably evident that I don't know much about remoteproc either) ? On Saturday, April 10, 2021 at 2:17:26 PM UTC-4 lazarman wrote: Hello TJF Drop rproc, and use uio_pruss driver instead. Then data exchange is pretty easy. Ie use DRam[0,1] for PRU-writing and SRam for ARM-writing. A simple and effective concept to avoid writing collisions (and pretty fast as well). uio_pruss driver provides pointers to that memory, while using rproc you've to find a solution by yourself. Sent from Yahoo Mail on Android On Sat, Apr 10, 2021 at 4:47 AM, TJF wrote: Hi Walter! A further "old dog" here. Sometimes I'm still working on my old Hades computer with 68060 CPU (loving that box). In my house I'm using a BBB for a solar system running 24/7. It also controlls two valves (on/off, and four AC pumps in 16 power levels), connected to WLAN by an external USB-Stick. Most temperatures are comming from 1-wire sensors, but ADC is used to fetch samples from a high-temperature sensor on the roof/collector. You should know that the onboard TSC_ADC_SS sometimes hangs, due to electromagnetical noice. In that case it allways measures/serves the same voltage, regardless of the changing input. There's a way to unblock the subsystem by software. But the better solution is to spend some effort in a decoupled input circruitry. In a new project I start the controller development on ARM, doing measurements by libpruio. Once the prove of concept is done, I migrate the controller loop to the other PRU for hard real-time capability. libpruio is perfect for that concept, since the measurements are available from both sides, ARM and PRU. All setup is coded only once (on ARM), and only the inner controller loop needs adaption (from ARM to PRU). In that adaption the controller usually gets much better, since you won't repeat the bugs and pitfalls from the POC phase. The most important initial decision is concerning the kernel driver to use. Drop rproc, and use uio_pruss driver instead. Then data exchange is pretty easy. Ie use DRam[0,1] for PRU-writing and SRam for ARM-writing. A simple and effective concept to avoid writing collisions (and pretty fast as well). uio_pruss driver provides pointers to that memory, while using rproc you've to find a solution by yourself. Regards -- 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...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/d715b191-d95b-4b86-8fae-eb618c74ddc5n%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/90e0f287-b0b3-41af-9f1e-36fcd06f8dc2n%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
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
Hello TJF Drop rproc, and use uio_pruss driver instead. Then data exchange is pretty easy. Ie use DRam[0,1] for PRU-writing and SRam for ARM-writing. A simple and effective concept to avoid writing collisions (and pretty fast as well). uio_pruss driver provides pointers to that memory, while using rproc you've to find a solution by yourself. Sent from Yahoo Mail on Android On Sat, Apr 10, 2021 at 4:47 AM, TJF wrote: Hi Walter! A further "old dog" here. Sometimes I'm still working on my old Hades computer with 68060 CPU (loving that box). In my house I'm using a BBB for a solar system running 24/7. It also controlls two valves (on/off, and four AC pumps in 16 power levels), connected to WLAN by an external USB-Stick. Most temperatures are comming from 1-wire sensors, but ADC is used to fetch samples from a high-temperature sensor on the roof/collector. You should know that the onboard TSC_ADC_SS sometimes hangs, due to electromagnetical noice. In that case it allways measures/serves the same voltage, regardless of the changing input. There's a way to unblock the subsystem by software. But the better solution is to spend some effort in a decoupled input circruitry. In a new project I start the controller development on ARM, doing measurements by libpruio. Once the prove of concept is done, I migrate the controller loop to the other PRU for hard real-time capability. libpruio is perfect for that concept, since the measurements are available from both sides, ARM and PRU. All setup is coded only once (on ARM), and only the inner controller loop needs adaption (from ARM to PRU). In that adaption the controller usually gets much better, since you won't repeat the bugs and pitfalls from the POC phase. The most important initial decision is concerning the kernel driver to use. Drop rproc, and use uio_pruss driver instead. Then data exchange is pretty easy. Ie use DRam[0,1] for PRU-writing and SRam for ARM-writing. A simple and effective concept to avoid writing collisions (and pretty fast as well). uio_pruss driver provides pointers to that memory, while using rproc you've to find a solution by yourself. Regards -- 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/d715b191-d95b-4b86-8fae-eb618c74ddc5n%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/1677204224.333560.1618078629290%40mail.yahoo.com.
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
I believe you will Walter I just thought it prudent to mention doing some designs validation coding first. I do think the the through put coding could be done quickly on ARM . If you're doing the other code functions on PRU you mentioned your going to face the learning curve anyway you asked about. So you might then try some tests using ADC PRU. Otherwise I'd do the ARM part first Usually there's always away to shoe horn something. Regards Mark Sent from Yahoo Mail on Android On Fri, Apr 9, 2021 at 2:00 PM, Walter Cromer wrote: It's a fairly simple application really and that's what makes it frustrating! We'll get there! I learn something every day and that's just fine with me. On Friday, April 9, 2021 at 2:54:55 PM UTC-4 lazarman wrote: Plenty of data Walter thanks. You could write some linux code that reads Data from from PRU ram( I'm not sure if there's several ways to get Data beyond remote messaging and reading the shared ram directly) factor in delay for new sample's to be updated from ADC at least you could ensure that works in your time frame. If that seems OK Then use examples for PRU I'm skeptical about needing to use assembler it's not the PRU read time that's a bottleneck. I'd be interested in seeing that PRU to ARM transfer rate it should not take alot of time but if Linux is still interfering beyond your needed specific time period you will only have one choice but to find what's exactly doing this delay and mitigation of that will be your only hope. Typically a proof of concept fesigh verification like this is always wise. If using this chip is your only option you'd have one option left but I don't think you would like it. And I'm already well known for suggestioning that option on ARM so I'm not going to mention it. I do understand the value of having a feature rich OS on ARM that's royalty free but I've been lucky on the 50 or so projects I've worked on this wasn't the issue. Another project was a Diesel engine controller they did a DVT phase first. Design verification Test I wish I could help on Linux side but I can't there's plenty of people in here using Linux so I think you can get more ideas and help. Not Sure how many have used Linux in actual hard realtime systems. Your application doesn't sound extremely hard realtime so be interested in seeing this have a happy ending. Sent from Yahoo Mail on Android On Fri, Apr 9, 2021 at 1:16 PM, Walter Cromer wrote: Thanks Dennis. That is in sync with my research. On Friday, April 9, 2021 at 2:00:07 PM UTC-4 Dennis Bieber wrote: On Fri, 9 Apr 2021 09:30:53 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Walter Cromer wrote: >We are still experimenting but our preliminary calculations lead us to >believe a reading every 50 microseconds will be sufficient. We can probably >get by with 100 microseconds if we have to but I think the BBBw can easily >sample at this rate, right? Well, the SoC reference (SPRS717J) indicates that the ADC should be capable of 200K samples per second. If I haven't flubbed the math, that appears to come down to one sample every 5us. As I recall, the PRU runs on a 200MHz clock, and PRU instructions, for the most, run in one clock cycle. Should be enough cycles per sample to handle processing Of course, it may matter how you have the ADC programmed. -- Dennis L Bieber -- 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...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/44d5f47f-973d-4b08-bcdb-d93e0e6c3f70n%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/1c1af0c5-207f-47fe-9c47-e97b563bbcecn%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/289459220.203354.1617996778556%40mail.yahoo.com.
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
Plenty of data Walter thanks. You could write some linux code that reads Data from from PRU ram( I'm not sure if there's several ways to get Data beyond remote messaging and reading the shared ram directly) factor in delay for new sample's to be updated from ADC at least you could ensure that works in your time frame. If that seems OK Then use examples for PRU I'm skeptical about needing to use assembler it's not the PRU read time that's a bottleneck. I'd be interested in seeing that PRU to ARM transfer rate it should not take alot of time but if Linux is still interfering beyond your needed specific time period you will only have one choice but to find what's exactly doing this delay and mitigation of that will be your only hope. Typically a proof of concept fesigh verification like this is always wise. If using this chip is your only option you'd have one option left but I don't think you would like it. And I'm already well known for suggestioning that option on ARM so I'm not going to mention it. I do understand the value of having a feature rich OS on ARM that's royalty free but I've been lucky on the 50 or so projects I've worked on this wasn't the issue. Another project was a Diesel engine controller they did a DVT phase first. Design verification Test I wish I could help on Linux side but I can't there's plenty of people in here using Linux so I think you can get more ideas and help. Not Sure how many have used Linux in actual hard realtime systems. Your application doesn't sound extremely hard realtime so be interested in seeing this have a happy ending. Sent from Yahoo Mail on Android On Fri, Apr 9, 2021 at 1:16 PM, Walter Cromer wrote: Thanks Dennis. That is in sync with my research. On Friday, April 9, 2021 at 2:00:07 PM UTC-4 Dennis Bieber wrote: On Fri, 9 Apr 2021 09:30:53 -0700 (PDT), in gmane.comp.hardware.beagleboard.user Walter Cromer wrote: >We are still experimenting but our preliminary calculations lead us to >believe a reading every 50 microseconds will be sufficient. We can probably >get by with 100 microseconds if we have to but I think the BBBw can easily >sample at this rate, right? Well, the SoC reference (SPRS717J) indicates that the ADC should be capable of 200K samples per second. If I haven't flubbed the math, that appears to come down to one sample every 5us. As I recall, the PRU runs on a 200MHz clock, and PRU instructions, for the most, run in one clock cycle. Should be enough cycles per sample to handle processing Of course, it may matter how you have the ADC programmed. -- Dennis L Bieber -- 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/44d5f47f-973d-4b08-bcdb-d93e0e6c3f70n%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/1517715866.191478.1617994477895%40mail.yahoo.com.
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
Hi ??but I think the BBBw can easily sample at this rate, right? Asking about ARM/linux side ? or PRU side Polling or Interrupt? Explain you delay details at least delay duration and what your app does with data would help. The calculation I mentioned seeing people reply about were on the PRU. Keep in mind there's overhead to get Data from PRU to ARM. The timing becomes critical when you need to react from the data you read quickly. If that's not the case your just talking about how many sample's you use to control right? That's why I would expand a bit on your application. I've worked on stuff that read and reacted in 10 microseconds closed loop plastic pressing for example that was easily achieved in 1988 microprocessor speeds I've also worked on control loops that ran faster than 1 micro second on a similar processor OMAP L138 in that case the code ran on the DSP I forget the clock speed. In this case the motor control ran every 100 nanosecond I believe but it's used TI RTOS. If the delay on Linux isn't acceptable add some details I mentioned hopefully the two guys who calculated PRU latencies will reply or I will find that post if possible. Again it's probably highly likely even a polled PRU app can read Data quickly dependant on conversation rates time I'm assuming you need the ARM to get Data in 100 microseconds? I'm not sure the transfer rate between PRU and ARM us determistic if linux is used . Hopefully this makes sense if not ask but I'd follow up with more detail Mark From: "beagleboard@googlegroups.com" on behalf of Walter Cromer Reply-To: "beagleboard@googlegroups.com" Date: Friday, April 9, 2021 at 12:29 PM To: BeagleBoard Subject: Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it? Thanks, I'll check that out! On Friday, April 9, 2021 at 11:19:47 AM UTC-4 pierric...@gadz.org wrote: Hi, I believe there are some simple ADC-read example directly in the image under /var/lib/cloud9/Techlab/.challenges, or here: https://github.com/beagleboard/cloud9-examples/blob/master/PocketBeagle/TechLab/.challenges/analogIn.pru0.c They are labeled for PocketBeagle but it's the same ti-am335x chip so they should work easily on the BBB. Hope it helps! Pierrick Le vendredi 9 avril 2021 à 10:57:32 UTC-4, wal...@edenconceptsllc.com a écrit : Understood. Our application won't require FAA or FDA approval but it definitely needs the more deterministic performance of a bare bones app so I'm heading in the direction of the ADC being read by a PRU program and communicating back to the ARM for other processes (UI, reading other non-time-sensitive inputs, etc.). On Friday, April 9, 2021 at 10:23:26 AM UTC-4 lazarman wrote: 1) Linux is not a real-time operating system (OS) in and of itself. ... “The idea is to run critical applications like the control loop on VxWorks and then run non-deterministic analytics on Linux. Hard realtime apps like closed loop positioning used in pressing plants,automation,fighter planes etc etc don't use Linux. Determinism required by safety critical systems certified by FAA would require you found delay measured it to calculate worst case as well as validated software. https://www.automationworld.com/products/control/blog/13318614/clarifying-the-linux-real-time-issue#:~:text=Linux%20is%20not%20a%20real,OS)%20in%20and%20of%20itself.=%E2%80%9CThe%20idea%20is%20to%20run,non%2Ddeterministic%20analytics%20on%20Linux. What makes the Linux scheduler seem unpredictable? | | | | | | | | | | | What makes the Linux scheduler seem unpredictable? The question refers to the output of a multi-threaded application, where each thread merely prints its ID (user assigned number) on the standard output. Here all threads have equal priority and com... | | | | 2) I say no depends on how much delay is acceptable there are buses between shared memory etc it will improve over using ARM. Ideal situation is a barebone app designed with minimal interrupt latency followed by an RTOS that's guaranteed to meet latency specs especially one certified by FAA or FDA of course these are expensive Sent from Yahoo Mail on Android On Fri, Apr 9, 2021 at 8:23 AM, TJF wrote: wal...@edenconceptsllc.com schrieb am Freitag, 9. April 2021 um 14:41:00 UTC+2: I'm looking at some example code and there references to ADC_TSC. I realize this is a reference to the Touchscreen controller which provides the ADC functionality. And I suspect this refers to the base memory address of the chip but I cannot find where that is defined in any header files anywhere. It would help me to follow these examples if I knew where that reference was. Find high-level code (FreeBASIC) in files src/pruio/pruio_adc.[bas|bi] and low level code (assembler) in file s
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
I'd share your timing requirement needs I've seen people get help in here before after doing this. search group. That way you don't spend time trying to meet a goal not attainable on PRU. Sent from Yahoo Mail on Android On Fri, Apr 9, 2021 at 10:19 AM, pierric...@gadz.org wrote: Hi, I believe there are some simple ADC-read example directly in the image under /var/lib/cloud9/Techlab/.challenges, or here: https://github.com/beagleboard/cloud9-examples/blob/master/PocketBeagle/TechLab/.challenges/analogIn.pru0.cThey are labeled for PocketBeagle but it's the same ti-am335x chip so they should work easily on the BBB. Hope it helps! Pierrick Le vendredi 9 avril 2021 à 10:57:32 UTC-4, wal...@edenconceptsllc.com a écrit : Understood. Our application won't require FAA or FDA approval but it definitely needs the more deterministic performance of a bare bones app so I'm heading in the direction of the ADC being read by a PRU program and communicating back to the ARM for other processes (UI, reading other non-time-sensitive inputs, etc.). On Friday, April 9, 2021 at 10:23:26 AM UTC-4 lazarman wrote: 1) Linux is not a real-time operating system (OS) in and of itself. ... “The idea is to run critical applications like the control loop on VxWorks and then run non-deterministic analytics on Linux. Hard realtime apps like closed loop positioning used in pressing plants,automation,fighter planes etc etc don't use Linux. Determinism required by safety critical systems certified by FAA would require you found delay measured it to calculate worst case as well as validated software. https://www.automationworld.com/products/control/blog/13318614/clarifying-the-linux-real-time-issue#:~:text=Linux%20is%20not%20a%20real,OS)%20in%20and%20of%20itself.=%E2%80%9CThe%20idea%20is%20to%20run,non%2Ddeterministic%20analytics%20on%20Linux. What makes the Linux scheduler seem unpredictable? | | | | || | | | | | What makes the Linux scheduler seem unpredictable? The question refers to the output of a multi-threaded application, where each thread merely prints its ID (user assigned number) on the standard output. Here all threads have equal priority and com... | | | | 2) I say no depends on how much delay is acceptable there are buses between shared memory etc it will improve over using ARM. Ideal situation is a barebone app designed with minimal interrupt latency followed by an RTOS that's guaranteed to meet latency specs especially one certified by FAA or FDA of course these are expensive Sent from Yahoo Mail on Android On Fri, Apr 9, 2021 at 8:23 AM, TJF wrote: wal...@edenconceptsllc.com schrieb am Freitag, 9. April 2021 um 14:41:00 UTC+2: I'm looking at some example code and there references to ADC_TSC. I realize this is a reference to the Touchscreen controller which provides the ADC functionality. And I suspect this refers to the base memory address of the chip but I cannot find where that is defined in any header files anywhere. It would help me to follow these examples if I knew where that reference was. Find high-level code (FreeBASIC) in files src/pruio/pruio_adc.[bas|bi] and low level code (assembler) in file src/pruio/pruio_adc.p. Unfortunately, too, the examples are Python and I'm not a Python programmer. I work in C. So I'm having to dig through this and learn some Python at the same time. Not a bad thing but time consuming! Python examples are in folder src/python. FreeBASIC examples are in folder src/examples. And C examples are in folder src/c_examples. Find an overview at https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html Regards -- 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...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/04caf3a3-cd8c-449e-9fd7-9ed6df33f99en%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/55b15f32-c44a-4977-8390-e91615c5e788n%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
Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?
1) Linux is not a real-time operating system (OS) in and of itself. ... “The idea is to run critical applications like the control loop on VxWorks and then run non-deterministic analytics on Linux. Hard realtime apps like closed loop positioning used in pressing plants,automation,fighter planes etc etc don't use Linux. Determinism required by safety critical systems certified by FAA would require you found delay measured it to calculate worst case as well as validated software. https://www.automationworld.com/products/control/blog/13318614/clarifying-the-linux-real-time-issue#:~:text=Linux%20is%20not%20a%20real,OS)%20in%20and%20of%20itself.=%E2%80%9CThe%20idea%20is%20to%20run,non%2Ddeterministic%20analytics%20on%20Linux. What makes the Linux scheduler seem unpredictable? | | | | || | | | | | What makes the Linux scheduler seem unpredictable? The question refers to the output of a multi-threaded application, where each thread merely prints its ID (user assigned number) on the standard output. Here all threads have equal priority and com... | | | | 2) I say no depends on how much delay is acceptable there are buses between shared memory etc it will improve over using ARM. Ideal situation is a barebone app designed with minimal interrupt latency followed by an RTOS that's guaranteed to meet latency specs especially one certified by FAA or FDA of course these are expensive Sent from Yahoo Mail on Android On Fri, Apr 9, 2021 at 8:23 AM, TJF wrote: wal...@edenconceptsllc.com schrieb am Freitag, 9. April 2021 um 14:41:00 UTC+2: I'm looking at some example code and there references to ADC_TSC. I realize this is a reference to the Touchscreen controller which provides the ADC functionality. And I suspect this refers to the base memory address of the chip but I cannot find where that is defined in any header files anywhere. It would help me to follow these examples if I knew where that reference was. Find high-level code (FreeBASIC) in files src/pruio/pruio_adc.[bas|bi] and low level code (assembler) in file src/pruio/pruio_adc.p. Unfortunately, too, the examples are Python and I'm not a Python programmer. I work in C. So I'm having to dig through this and learn some Python at the same time. Not a bad thing but time consuming! Python examples are in folder src/python. FreeBASIC examples are in folder src/examples. And C examples are in folder src/c_examples. Find an overview at https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html Regards -- 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/04caf3a3-cd8c-449e-9fd7-9ed6df33f99en%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/1474043620.109834.1617978184496%40mail.yahoo.com.
Re: [beagleboard] Re: BBB Setting up the Interrupt Vector Table
One last pointer. If another interrupts can preempt your ISR you have to make your code reentrant. Typically disabling all interrupts in your ISR should be done only if required to complete something that needs to be atomic as in a buffer pointer that someone else can read. Most peripheral you just clear interrupts not disable seems odd you have to reeenable an interrupt at end. Glad everything is working now you have all the tools to write good ISR which is needed if you go to a preemptive multitasking RTOS like FreeRtos or your own. Sent from Yahoo Mail on Android On Wed, Mar 10, 2021 at 1:15 PM, Josh Cole wrote: Oh good call, that was the issue. Thank you! I had to disable interrupts on the peripheral. Clear them. Then enable again after servicing the interrupt. Also it looks like I needed to reset the timer to the value I wanted manually. By default it looks like it might have been loading 0 instead of my designated reload value. Probably I have more work to do to configure the timer correctly so it reloads towards the end (and thus, triggers an interrupt sooner). At any rate, it's completely working now! Thanks for all the assistance. ~Josh On Tue, Mar 9, 2021 at 2:37 PM Graham Stott wrote: If the interrupt is a level interrupt, your interrupt handling procedure needs to start clearing the interrupt starting at the source of the interrupt otherwise the interrupt will trigger again. Graham From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of Josh Cole Sent: Tuesday, March 09, 2021 9:27 AM To: BeagleBoard Subject: Re: [beagleboard] Re: BBB Setting up the Interrupt Vector Table Thank you everyone! I appreciate the responses. After days of trial and error I managed to setup the IVT and configure one of the timers to fire an interrupt on overflow. For me, I found this resource pretty helpful: https://android.googlesource.com/kernel/lk/+/upstream-master/platform/am335x - it appears to be the embedded android kernel ported to the beaglebone. They have some good interrupt stuff in there, as well as device-specific peripheral drivers. I'm struggling now with "de-triggering" an interrupt after it fired. So my timer fires one interrupt and then the IRQSTATUS_RAW keeps its value, no matter how many ways I try to reset it. So I am only handling it once. I feel I'm close though. Hopefully the resources shared + the anrdoid kernel I found will shed some light on how to correctly process an interrupt. Cheers! On Monday, March 8, 2021 at 8:23:10 AM UTC-8 lazarman wrote: Yes I agree. Make sure to look at startup assembler language file many times vectors are in it. Start or start-up. Asm Sent from Yahoo Mail on Android On Mon, Mar 8, 2021 at 9:56 AM, Graham Stott wrote: You could look at the TI starterware code for examples of setting up the interrupt table and the code at the tables. Graham From: 'Mark Lazarewicz' via BeagleBoard [mailto:beagl...@googlegroups.com] Sent: Sunday, March 07, 2021 12:30 PM To: beagl...@googlegroups.com Subject: Re: [beagleboard] Re: BBB Setting up the Interrupt Vector Table Your handler needs the keyword interrupt to save the registers so when the vector occurs whatever was running isn't corrupted Besides interrupt vector table don't forget exceptions they need a vector as well as in bus error or address error Here's a brief reference you should look for interrupt code to verify and the correct arm programming guide https://community.arm.com/developer/tools-software/tools/f/armds-forum/13621/need-interrupt-handling-code-for-arm-cortex-a9 Sent from Yahoo Mail on Android On Sun, Mar 7, 2021 at 12:01 PM, Josh Cole wrote: Update! I've solved my own problem and thought I'd share for any lost soul in the future who seeks these answers. If you look at the technical reference manual for the am355x section 26-3 it shows an interrupt vector table which exists wildly far away from your application entrypoint. Upon closer inspection, I realized some entries are listed twice. This is because the interrupt vector table is actually a bunch of indirection. If you want to set the IRQ branch address you specify the address at location 0x4030_CE38 If you want to set the pre-fetch abort address you specify the address at location 0x4030_CE2C Example code: // Set the IRQ handler to the entrypoint of the application + 24 bytes *(0x4030_CE38 as *mut u32) = 0x402F_0400 + 0x18; I assumed I needed to write an actual branch instruction to those locations. Which is where my confusion started. So if you are building a low-level kernel and are working with interrupts, just remember that the vector table can be updated by simply writing the correct address to your handler based on the vector table in the reference manual (not an actual branch instruction). On Friday, March 5, 2021 at 6:12:00 AM UTC-8
RE: [beagleboard] Re: BBB Setting up the Interrupt Vector Table
Yes I agree. Make sure to look at startup assembler language file many times vectors are in it. Start or start-up. Asm Sent from Yahoo Mail on Android On Mon, Mar 8, 2021 at 9:56 AM, Graham Stott wrote: #yiv6656868029 #yiv6656868029 -- _filtered {} _filtered {}#yiv6656868029 #yiv6656868029 p.yiv6656868029MsoNormal, #yiv6656868029 li.yiv6656868029MsoNormal, #yiv6656868029 div.yiv6656868029MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:New serif;}#yiv6656868029 a:link, #yiv6656868029 span.yiv6656868029MsoHyperlink {color:blue;text-decoration:underline;}#yiv6656868029 a:visited, #yiv6656868029 span.yiv6656868029MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv6656868029 p {margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:New serif;}#yiv6656868029 span.yiv6656868029EmailStyle18 {font-family:sans-serif;color:#1F497D;}#yiv6656868029 .yiv6656868029MsoChpDefault {font-family:sans-serif;} _filtered {}#yiv6656868029 div.yiv6656868029WordSection1 {}#yiv6656868029 You could look at the TI starterware code for examples of setting up the interrupt table and the code at the tables. Graham From: 'Mark Lazarewicz' via BeagleBoard [mailto:beagleboard@googlegroups.com] Sent: Sunday, March 07, 2021 12:30 PM To: beagleboard@googlegroups.com Subject: Re: [beagleboard] Re: BBB Setting up the Interrupt Vector Table Your handler needs the keyword interrupt to save the registers so when the vector occurs whatever was running isn't corrupted Besides interrupt vector table don't forget exceptions they need a vector as well as in bus error or address error Here's a brief reference you should look for interrupt code to verify and the correct arm programming guide https://community.arm.com/developer/tools-software/tools/f/armds-forum/13621/need-interrupt-handling-code-for-arm-cortex-a9 Sent from Yahoo Mail on Android On Sun, Mar 7, 2021 at 12:01 PM, Josh Cole wrote: Update! I've solved my own problem and thought I'd share for any lost soul in the future who seeks these answers. If you look at the technical reference manual for the am355x section 26-3 it shows an interrupt vector table which exists wildly far away from your application entrypoint. Upon closer inspection, I realized some entries are listed twice. This is because the interrupt vector table is actually a bunch of indirection. If you want to set the IRQ branch address you specify the address at location 0x4030_CE38 If you want to set the pre-fetch abort address you specify the address at location 0x4030_CE2C Example code: // Set the IRQ handler to the entrypoint of the application + 24 bytes *(0x4030_CE38 as *mut u32) = 0x402F_0400 + 0x18; I assumed I needed to write an actual branch instruction to those locations. Which is where my confusion started. So if you are building a low-level kernel and are working with interrupts, just remember that the vector table can be updated by simply writing the correct address to your handler based on the vector table in the reference manual (not an actual branch instruction). On Friday, March 5, 2021 at 6:12:00 AM UTC-8 Josh Cole wrote: Hi everyone, I'm working on a low-level kernel for the Beaglebone Black. I've gotten to a point in my project where I want to specify an IRQ handler and enable interrupts. According to the technical reference manual (section 26.1.4), there are two primary locations you can load a disk image to. The first is what they call "Public ROM" which seems pretty straightforward. You load your image to address 0x2 and the interrupt vector table is the first thing which gets encountered. The second location you can load an image is "Public RAM" (which I'm using). This starts executing at 0x402F0400 and you get 109kb of space for your application. The weird part is, the interrupt vector table appears to be located super far away from the entrypoint, at location 0x4030CE00. This is more than 109kb away, so it can't be included in the image which gets flashed to the device. I am at a loss about how to get an instruction to that particular location in memory since my image fundamentally can't be that size. Any guidance on how to setup the IVT for Public RAM would be greatly appreciated. Thank you for your time! -- 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/b63bc711-fcda-497b-b4e5-ee35c0081176n%40googlegroups.com . -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to t
Re: [beagleboard] Re: BBB Setting up the Interrupt Vector Table
Your handler needs the keyword interrupt to save the registers so when the vector occurs whatever was running isn't corrupted Besides interrupt vector table don't forget exceptions they need a vector as well as in bus error or address error Here's a brief reference you should look for interrupt code to verify and the correct arm programming guide https://community.arm.com/developer/tools-software/tools/f/armds-forum/13621/need-interrupt-handling-code-for-arm-cortex-a9 Sent from Yahoo Mail on Android On Sun, Mar 7, 2021 at 12:01 PM, Josh Cole wrote: Update! I've solved my own problem and thought I'd share for any lost soul in the future who seeks these answers. If you look at the technical reference manual for the am355x section 26-3 it shows an interrupt vector table which exists wildly far away from your application entrypoint. Upon closer inspection, I realized some entries are listed twice. This is because the interrupt vector table is actually a bunch of indirection. If you want to set the IRQ branch address you specify the address at location 0x4030_CE38If you want to set the pre-fetch abort address you specify the address at location 0x4030_CE2C Example code:// Set the IRQ handler to the entrypoint of the application + 24 bytes*(0x4030_CE38 as *mut u32) = 0x402F_0400 + 0x18; I assumed I needed to write an actual branch instruction to those locations. Which is where my confusion started. So if you are building a low-level kernel and are working with interrupts, just remember that the vector table can be updated by simply writing the correct address to your handler based on the vector table in the reference manual (not an actual branch instruction). On Friday, March 5, 2021 at 6:12:00 AM UTC-8 Josh Cole wrote: Hi everyone, I'm working on a low-level kernel for the Beaglebone Black. I've gotten to a point in my project where I want to specify an IRQ handler and enable interrupts. According to the technical reference manual (section 26.1.4), there are two primary locations you can load a disk image to. The first is what they call "Public ROM" which seems pretty straightforward. You load your image to address 0x2 and the interrupt vector table is the first thing which gets encountered. The second location you can load an image is "Public RAM" (which I'm using). This starts executing at 0x402F0400 and you get 109kb of space for your application. The weird part is, the interrupt vector table appears to be located super far away from the entrypoint, at location 0x4030CE00. This is more than 109kb away, so it can't be included in the image which gets flashed to the device. I am at a loss about how to get an instruction to that particular location in memory since my image fundamentally can't be that size. Any guidance on how to setup the IVT for Public RAM would be greatly appreciated. Thank you for your time! -- 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/b63bc711-fcda-497b-b4e5-ee35c0081176n%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/1482309015.269358.1615148982352%40mail.yahoo.com.
Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1
. If I understand Lucas correctly and you look at the zip file he provided the support is limited as to drivers and he needs to recompile that and add to it.That's the only reason he can't use the binary. >From your response it appears you didn't need to modify this. I would guess the x15 BSP is more inclusive and mature but doubt it provided loading c6x DSP code or Cortex M4 code but it's not relevant to Lucas. Your experience with support below < wrote: Old product used QNX 6, had long (6 months~1 year) trial licence for 7.0, I think I was able to build the file-system image, but could not get the driver for vector graphics processor to recognize the hardware, so the tiger demo did not work on AM5728 BB X15. (This is probably because GC320 is a compositor, not vector-graphics like GC355.) We did not have gold level support, questions often take days to be answered and often direct you to documentation and someone who can program it for you at a cost. It might be non paying users only had community support, if you are trying to sell QNX, you need to make it easy as pie to switch from something free. QNX development works well, once hardware and software development is setup, I would say it is easier to develop and debug communicating multi-process applications on QNX than Windows, Linux or RTOS (QNX IPC coincided with what I learned at uni); if you don't try to do it the Linux way. RTOS probably has the closest IPC ability to QNX, but way cruder; QNX has lovely variable length message passing. Technical and library problems seemed often like Windows: you know what you want to do, and you found a function which seems like it would do what you want, but the documentation says something like "setWombat( x ) sets the wombat to x" and you find you have spent hours/days finding how it works. Some drivers were based on Linux version, using QNX version Linux and RTOS are free, process isolation with separate processors is cheapish, but takes up PCB space. I think Qt sold infotainment, QNX would useful for process isolation on one (multi-core) processor, so you could isolate the infotainment application from the air-bag monitor. On Thu, 4 Mar 2021 at 18:41, 'Mark Lazarewicz' via BeagleBoard wrote: Hi Robert That's good to know I saw the x15 7.0 BSPWhere you able to rebuild BSP sources ?And do they actually respond to support questions for educational users? Looks like most of their revenue comes from automobile infotainmen at least the people hiring recently Mark Sent from Yahoo Mail on Android On Thu, Mar 4, 2021 at 12:35 PM, robert.sty...@gmail.com wrote: 7.0 worked on X15 except vector graphics On Thursday, 4 March 2021 at 17:51:42 UTC lazarman wrote: Page 15 of the pdf you sent we need that document . Please refer to the QNX SDP 6.6.0 BSPs guide, availableas part of the QNX Software Development Platform OS Core Components documentation I also need you to see if you can get the latest BSP referenced in my previous post I think it was 7.0 I have uncovered at least 5 problems with your original posting its a QXX documentation mismatch not you. I am concerned this stuff you started with is very old and probally not supported by Blackberry You have to start simple and slowly and logically so be patient before we start with 7.0 we need the document above On Wednesday, March 3, 2021, 12:58:16 PM CST, 'Mark Lazarewicz' via BeagleBoard wrote: These commands you entered are where? uboot? --> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100 Why not automate these commands ? << On Wednesday, March 3, 2021, 09:03:22 AM CST, Lucas SOLDA wrote: Mark, I have a BeagleBone Black REV C.There was nothing on the SD before. I did not touch to the EMC so I think there is nothing inside.My company has a QNX 6.5.0 SP1 licence and here is the list of the tools installed on my computer: First, I formated my SD card in FAT32, I made it active by using diskpart and I copied the MLO and then the u-boot files. I took them from here : https://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/TiAm335BeagleboneBootloader modules# --> "Click here to download the MLO and u-boot binaries for the new Beaglebone Black platform. " After that, I downloaded the BSP files: QNX Neutrino 6.5.0 SP1# --> Download Project Downloads --> bsp-nto650-ti-beaglebone-sp1-trunk-201209071340.zip(I attach MLO, u-boot and BSP to this mail)After extracting, I copied the file "prebuilt-bsp-ti-beaglebone.ifs" in the "image" folder to my sdcard and I could succesfully launch QNX on my BBB by typing these commands :--> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100 That worked perfectly. When I try to compile the image by myself it gets complicated. if I compile the BSP without modifying anything, I should get the prebuilt image, right ?Th
Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1
The file system isn't the BSP. This part supplies all architecture specific(ASP) functions like Cache,MMU and the board specific drivers for on chip peripherals on all cores. If I understand Lucas correctly and you look at the zip file he provided the support is limited as to drivers and he needs to recompile that and add to it.That's the only reason he can't use the binary. >From your response it appears you didn't need to modify this. I would guess the x15 BSP is more inclusive and mature but doubt it provided loading c6x DSP code or Cortex M4 code but it's not relevant to Lucas. Your experience with support below < wrote: Old product used QNX 6, had long (6 months~1 year) trial licence for 7.0, I think I was able to build the file-system image, but could not get the driver for vector graphics processor to recognize the hardware, so the tiger demo did not work on AM5728 BB X15. (This is probably because GC320 is a compositor, not vector-graphics like GC355.) We did not have gold level support, questions often take days to be answered and often direct you to documentation and someone who can program it for you at a cost. It might be non paying users only had community support, if you are trying to sell QNX, you need to make it easy as pie to switch from something free. QNX development works well, once hardware and software development is setup, I would say it is easier to develop and debug communicating multi-process applications on QNX than Windows, Linux or RTOS (QNX IPC coincided with what I learned at uni); if you don't try to do it the Linux way. RTOS probably has the closest IPC ability to QNX, but way cruder; QNX has lovely variable length message passing. Technical and library problems seemed often like Windows: you know what you want to do, and you found a function which seems like it would do what you want, but the documentation says something like "setWombat( x ) sets the wombat to x" and you find you have spent hours/days finding how it works. Some drivers were based on Linux version, using QNX version Linux and RTOS are free, process isolation with separate processors is cheapish, but takes up PCB space. I think Qt sold infotainment, QNX would useful for process isolation on one (multi-core) processor, so you could isolate the infotainment application from the air-bag monitor. On Thu, 4 Mar 2021 at 18:41, 'Mark Lazarewicz' via BeagleBoard wrote: Hi Robert That's good to know I saw the x15 7.0 BSPWhere you able to rebuild BSP sources ?And do they actually respond to support questions for educational users? Looks like most of their revenue comes from automobile infotainmen at least the people hiring recently Mark Sent from Yahoo Mail on Android On Thu, Mar 4, 2021 at 12:35 PM, robert.sty...@gmail.com wrote: 7.0 worked on X15 except vector graphics On Thursday, 4 March 2021 at 17:51:42 UTC lazarman wrote: Page 15 of the pdf you sent we need that document . Please refer to the QNX SDP 6.6.0 BSPs guide, availableas part of the QNX Software Development Platform OS Core Components documentation I also need you to see if you can get the latest BSP referenced in my previous post I think it was 7.0 I have uncovered at least 5 problems with your original posting its a QXX documentation mismatch not you. I am concerned this stuff you started with is very old and probally not supported by Blackberry You have to start simple and slowly and logically so be patient before we start with 7.0 we need the document above On Wednesday, March 3, 2021, 12:58:16 PM CST, 'Mark Lazarewicz' via BeagleBoard wrote: These commands you entered are where? uboot? --> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100 Why not automate these commands ? << On Wednesday, March 3, 2021, 09:03:22 AM CST, Lucas SOLDA wrote: Mark, I have a BeagleBone Black REV C.There was nothing on the SD before. I did not touch to the EMC so I think there is nothing inside.My company has a QNX 6.5.0 SP1 licence and here is the list of the tools installed on my computer: First, I formated my SD card in FAT32, I made it active by using diskpart and I copied the MLO and then the u-boot files. I took them from here : https://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/TiAm335BeagleboneBootloader modules# --> "Click here to download the MLO and u-boot binaries for the new Beaglebone Black platform. " After that, I downloaded the BSP files: QNX Neutrino 6.5.0 SP1# --> Download Project Downloads --> bsp-nto650-ti-beaglebone-sp1-trunk-201209071340.zip(I attach MLO, u-boot and BSP to this mail)After extracting, I copied the file "prebuilt-bsp-ti-beaglebone.ifs" in the "image" folder to my sdcard and I could succesfully launch QNX on my BBB by typing these commands :--> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100
Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1
This time ask new vendor about BSP source code cost and if support is included for your board. You never told us if your product was using custom hardware or incorporating the beaglebone board. If you know boss has no money tell him Linux藍 is free https://marketplace.windriver.com/index.php?bsp=list=architecture=ARM INTEGRITY Real-time Operating System | | | | || | | | | | INTEGRITY Real-time Operating System The flagship of Green Hills Software operating systems, the INTEGRITY RTOS is built around a partitioning architecture that enables embedded developers to ensure their applications meet the highest possible requirements for security, reliability, and | | | | Virtualization & RTOS Solutions | Lynx Software Technologies | | | | || | | | | | Virtualization & RTOS Solutions | Lynx Software Technologies Lynx provides software frameworks, hypervisors, and RTOS technologies for mission critical platforms in aerospace & defense, industrial IoT, enterprise, and automotive markets. | | | | Sent from Yahoo Mail on Android On Thu, Mar 4, 2021 at 2:59 PM, 'Mark Lazarewicz' via BeagleBoard wrote: Lucas If you need a Unix like RTOS see if lynxos supplies BSP source code Then reply to the QNX sales guy saying great thanks we are going to use lynxos But make sure your boss agrees. Sadly too many manager's think BSP is free. This gas been happening for 30 year's. Or go Linux it's free. My favorite commercial RTOS is GreenHills they support TI hardware. If I was you think real hard how to explain to boss so he doesn't think it's your fault after all most bosses think Linux is free I'll hire a young engineer save $10k fee for BSP should take him 1 week. It's even worse the new trend is when someone needs help you tell them wait till the Google Summer project's If Boss doesn't understand this is bad approach send your resume out ASAP make sure he's not reading this drinking scotch though. In all seriousness your a smart guy an engineer think this through carefully so Lucas is first. Then also drink some scotch Regards Sent from Yahoo Mail on Android On Thu, Mar 4, 2021 at 2:17 PM, 'Mark Lazarewicz' via BeagleBoard wrote: I'm afraid their reply tells me everything. Their website says they have it and they asked for $$$ for it so it's not free. In theory you could continue to try to build 6.5 missing out on features and bug fixes. This isn't the first time I have seen the binary works BUT source code of BSP doesn't work marketing ploy. Again in theory if you had BSP experience you could roll your own after figuring out why the 6.5 BSP crashes but people make careers of BSP the best work for commercial RTOS vendor's and do what you are trying to do. Let me translate this below < wrote: I don't know where to find the document on page 15... There are so much references about it on google.I can't get QNX 7.0. When I asked for it they sent me a 10 000+ € quotation...Moreover there is no BSP for beaglebone black for QNX 7.0, they stopped supporting it after QNX 6.6 : Le jeudi 4 mars 2021 à 18:51:42 UTC+1, lazarman a écrit : Page 15 of the pdf you sent we need that document . Please refer to the QNX SDP 6.6.0 BSPs guide, availableas part of the QNX Software Development Platform OS Core Components documentation I also need you to see if you can get the latest BSP referenced in my previous post I think it was 7.0 I have uncovered at least 5 problems with your original posting its a QXX documentation mismatch not you. I am concerned this stuff you started with is very old and probally not supported by Blackberry You have to start simple and slowly and logically so be patient before we start with 7.0 we need the document above On Wednesday, March 3, 2021, 12:58:16 PM CST, 'Mark Lazarewicz' via BeagleBoard wrote: These commands you entered are where? uboot? --> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100 Why not automate these commands ? << On Wednesday, March 3, 2021, 09:03:22 AM CST, Lucas SOLDA wrote: Mark, I have a BeagleBone Black REV C.There was nothing on the SD before. I did not touch to the EMC so I think there is nothing inside.My company has a QNX 6.5.0 SP1 licence and here is the list of the tools installed on my computer: First, I formated my SD card in FAT32, I made it active by using diskpart and I copied the MLO and then the u-boot files. I took them from here : https://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/TiAm335BeagleboneBootloader modules# --> "Click here to download the MLO and u-boot binaries for the new Beaglebone Black platform. " After that, I downloaded the BSP files: QNX Neutrino 6.5.0 SP1# --> Download Project Downloads --> bsp-nto650-ti-beaglebone-sp1-trunk-201209071340.zip(I attach MLO, u-boot and BSP to
Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1
Lucas If you need a Unix like RTOS see if lynxos supplies BSP source code Then reply to the QNX sales guy saying great thanks we are going to use lynxos But make sure your boss agrees. Sadly too many manager's think BSP is free. This gas been happening for 30 year's. Or go Linux it's free. My favorite commercial RTOS is GreenHills they support TI hardware. If I was you think real hard how to explain to boss so he doesn't think it's your fault after all most bosses think Linux is free I'll hire a young engineer save $10k fee for BSP should take him 1 week. It's even worse the new trend is when someone needs help you tell them wait till the Google Summer project's If Boss doesn't understand this is bad approach send your resume out ASAP make sure he's not reading this drinking scotch though. In all seriousness your a smart guy an engineer think this through carefully so Lucas is first. Then also drink some scotch Regards Sent from Yahoo Mail on Android On Thu, Mar 4, 2021 at 2:17 PM, 'Mark Lazarewicz' via BeagleBoard wrote: I'm afraid their reply tells me everything. Their website says they have it and they asked for $$$ for it so it's not free. In theory you could continue to try to build 6.5 missing out on features and bug fixes. This isn't the first time I have seen the binary works BUT source code of BSP doesn't work marketing ploy. Again in theory if you had BSP experience you could roll your own after figuring out why the 6.5 BSP crashes but people make careers of BSP the best work for commercial RTOS vendor's and do what you are trying to do. Let me translate this below < wrote: I don't know where to find the document on page 15... There are so much references about it on google.I can't get QNX 7.0. When I asked for it they sent me a 10 000+ € quotation...Moreover there is no BSP for beaglebone black for QNX 7.0, they stopped supporting it after QNX 6.6 : Le jeudi 4 mars 2021 à 18:51:42 UTC+1, lazarman a écrit : Page 15 of the pdf you sent we need that document . Please refer to the QNX SDP 6.6.0 BSPs guide, availableas part of the QNX Software Development Platform OS Core Components documentation I also need you to see if you can get the latest BSP referenced in my previous post I think it was 7.0 I have uncovered at least 5 problems with your original posting its a QXX documentation mismatch not you. I am concerned this stuff you started with is very old and probally not supported by Blackberry You have to start simple and slowly and logically so be patient before we start with 7.0 we need the document above On Wednesday, March 3, 2021, 12:58:16 PM CST, 'Mark Lazarewicz' via BeagleBoard wrote: These commands you entered are where? uboot? --> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100 Why not automate these commands ? << On Wednesday, March 3, 2021, 09:03:22 AM CST, Lucas SOLDA wrote: Mark, I have a BeagleBone Black REV C.There was nothing on the SD before. I did not touch to the EMC so I think there is nothing inside.My company has a QNX 6.5.0 SP1 licence and here is the list of the tools installed on my computer: First, I formated my SD card in FAT32, I made it active by using diskpart and I copied the MLO and then the u-boot files. I took them from here : https://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/TiAm335BeagleboneBootloader modules# --> "Click here to download the MLO and u-boot binaries for the new Beaglebone Black platform. " After that, I downloaded the BSP files: QNX Neutrino 6.5.0 SP1# --> Download Project Downloads --> bsp-nto650-ti-beaglebone-sp1-trunk-201209071340.zip(I attach MLO, u-boot and BSP to this mail)After extracting, I copied the file "prebuilt-bsp-ti-beaglebone.ifs" in the "image" folder to my sdcard and I could succesfully launch QNX on my BBB by typing these commands :--> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100 That worked perfectly. When I try to compile the image by myself it gets complicated. if I compile the BSP without modifying anything, I should get the prebuilt image, right ?The problem is that, when I do that, I have the message I gave in the first post and it says that I compile with QNX 6.5.0 and not with QNX 6.5.0 SP1 (whereas it is installed). "I'm guessing you have no support forum or no ones replying at QNX?" I don't have support anymore and the only thing the told me is that I don't use QNX 6.5.0 SP1 I don't know what to do anymore and the QNX SDP is not on my computer so I can't use it whenever I want Le mercredi 3 mars 2021 à 15:03:47 UTC+1, lazarman a écrit : Let's start with some history about what rev board you have , what was on SD before and whats in the emc now and details about tools you installed to build BSP and QNX and exactly the BSP file's you are compiling as well as your goals. Ar
Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1
I'm afraid their reply tells me everything. Their website says they have it and they asked for $$$ for it so it's not free. In theory you could continue to try to build 6.5 missing out on features and bug fixes. This isn't the first time I have seen the binary works BUT source code of BSP doesn't work marketing ploy. Again in theory if you had BSP experience you could roll your own after figuring out why the 6.5 BSP crashes but people make careers of BSP the best work for commercial RTOS vendor's and do what you are trying to do. Let me translate this below < wrote: I don't know where to find the document on page 15... There are so much references about it on google.I can't get QNX 7.0. When I asked for it they sent me a 10 000+ € quotation...Moreover there is no BSP for beaglebone black for QNX 7.0, they stopped supporting it after QNX 6.6 : Le jeudi 4 mars 2021 à 18:51:42 UTC+1, lazarman a écrit : Page 15 of the pdf you sent we need that document . Please refer to the QNX SDP 6.6.0 BSPs guide, availableas part of the QNX Software Development Platform OS Core Components documentation I also need you to see if you can get the latest BSP referenced in my previous post I think it was 7.0 I have uncovered at least 5 problems with your original posting its a QXX documentation mismatch not you. I am concerned this stuff you started with is very old and probally not supported by Blackberry You have to start simple and slowly and logically so be patient before we start with 7.0 we need the document above On Wednesday, March 3, 2021, 12:58:16 PM CST, 'Mark Lazarewicz' via BeagleBoard wrote: These commands you entered are where? uboot? --> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100 Why not automate these commands ? << On Wednesday, March 3, 2021, 09:03:22 AM CST, Lucas SOLDA wrote: Mark, I have a BeagleBone Black REV C.There was nothing on the SD before. I did not touch to the EMC so I think there is nothing inside.My company has a QNX 6.5.0 SP1 licence and here is the list of the tools installed on my computer: First, I formated my SD card in FAT32, I made it active by using diskpart and I copied the MLO and then the u-boot files. I took them from here : https://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/TiAm335BeagleboneBootloader modules# --> "Click here to download the MLO and u-boot binaries for the new Beaglebone Black platform. " After that, I downloaded the BSP files: QNX Neutrino 6.5.0 SP1# --> Download Project Downloads --> bsp-nto650-ti-beaglebone-sp1-trunk-201209071340.zip(I attach MLO, u-boot and BSP to this mail)After extracting, I copied the file "prebuilt-bsp-ti-beaglebone.ifs" in the "image" folder to my sdcard and I could succesfully launch QNX on my BBB by typing these commands :--> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100 That worked perfectly. When I try to compile the image by myself it gets complicated. if I compile the BSP without modifying anything, I should get the prebuilt image, right ?The problem is that, when I do that, I have the message I gave in the first post and it says that I compile with QNX 6.5.0 and not with QNX 6.5.0 SP1 (whereas it is installed). "I'm guessing you have no support forum or no ones replying at QNX?" I don't have support anymore and the only thing the told me is that I don't use QNX 6.5.0 SP1 I don't know what to do anymore and the QNX SDP is not on my computer so I can't use it whenever I want Le mercredi 3 mars 2021 à 15:03:47 UTC+1, lazarman a écrit : Let's start with some history about what rev board you have , what was on SD before and whats in the emc now and details about tools you installed to build BSP and QNX and exactly the BSP file's you are compiling as well as your goals. Are you trying to eventually modify the BSP source?I'm guessing you have no support forum or no ones replying at QNX?I need a clear picture of what you did exactly installing tools as in did you install multiple times etc etc I'll look at the pdf you supplied and ponder whether it worthwhile and practical to find my Beagleboard,Whites,blacks or even Pandaboard.power supplies may be hard to match I've moved a lot. I guess a black would be easy for me to find but may be in storage. Also maybe they will let me reeducate myself as I'm not working on a commercial product and give me access otherwise it's harder to help. Hopefully I can get you on the right path Mark Sent from Yahoo Mail on Android On Wed, Mar 3, 2021 at 1:15 AM, Lucas SOLDA wrote: I can send you the files if you don't have an account. I use the MLO and u-boot files for beaglebone black from this link : "Click here to download the MLO and u-boot binaries for the new Beaglebone Black platform.". The fact you pointed is troubling. I don't understand why the BSP is
Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1
Hi Robert That's good to know I saw the x15 7.0 BSPWhere you able to rebuild BSP sources ?And do they actually respond to support questions for educational users? Looks like most of their revenue comes from automobile infotainmen at least the people hiring recently Mark Sent from Yahoo Mail on Android On Thu, Mar 4, 2021 at 12:35 PM, robert.sty...@gmail.com wrote: 7.0 worked on X15 except vector graphics On Thursday, 4 March 2021 at 17:51:42 UTC lazarman wrote: Page 15 of the pdf you sent we need that document . Please refer to the QNX SDP 6.6.0 BSPs guide, availableas part of the QNX Software Development Platform OS Core Components documentation I also need you to see if you can get the latest BSP referenced in my previous post I think it was 7.0 I have uncovered at least 5 problems with your original posting its a QXX documentation mismatch not you. I am concerned this stuff you started with is very old and probally not supported by Blackberry You have to start simple and slowly and logically so be patient before we start with 7.0 we need the document above On Wednesday, March 3, 2021, 12:58:16 PM CST, 'Mark Lazarewicz' via BeagleBoard wrote: These commands you entered are where? uboot? --> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100 Why not automate these commands ? << On Wednesday, March 3, 2021, 09:03:22 AM CST, Lucas SOLDA wrote: Mark, I have a BeagleBone Black REV C.There was nothing on the SD before. I did not touch to the EMC so I think there is nothing inside.My company has a QNX 6.5.0 SP1 licence and here is the list of the tools installed on my computer: First, I formated my SD card in FAT32, I made it active by using diskpart and I copied the MLO and then the u-boot files. I took them from here : https://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/TiAm335BeagleboneBootloader modules# --> "Click here to download the MLO and u-boot binaries for the new Beaglebone Black platform. " After that, I downloaded the BSP files: QNX Neutrino 6.5.0 SP1# --> Download Project Downloads --> bsp-nto650-ti-beaglebone-sp1-trunk-201209071340.zip(I attach MLO, u-boot and BSP to this mail)After extracting, I copied the file "prebuilt-bsp-ti-beaglebone.ifs" in the "image" folder to my sdcard and I could succesfully launch QNX on my BBB by typing these commands :--> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100 That worked perfectly. When I try to compile the image by myself it gets complicated. if I compile the BSP without modifying anything, I should get the prebuilt image, right ?The problem is that, when I do that, I have the message I gave in the first post and it says that I compile with QNX 6.5.0 and not with QNX 6.5.0 SP1 (whereas it is installed). "I'm guessing you have no support forum or no ones replying at QNX?" I don't have support anymore and the only thing the told me is that I don't use QNX 6.5.0 SP1 I don't know what to do anymore and the QNX SDP is not on my computer so I can't use it whenever I want Le mercredi 3 mars 2021 à 15:03:47 UTC+1, lazarman a écrit : Let's start with some history about what rev board you have , what was on SD before and whats in the emc now and details about tools you installed to build BSP and QNX and exactly the BSP file's you are compiling as well as your goals. Are you trying to eventually modify the BSP source?I'm guessing you have no support forum or no ones replying at QNX?I need a clear picture of what you did exactly installing tools as in did you install multiple times etc etc I'll look at the pdf you supplied and ponder whether it worthwhile and practical to find my Beagleboard,Whites,blacks or even Pandaboard.power supplies may be hard to match I've moved a lot. I guess a black would be easy for me to find but may be in storage. Also maybe they will let me reeducate myself as I'm not working on a commercial product and give me access otherwise it's harder to help. Hopefully I can get you on the right path Mark Sent from Yahoo Mail on Android On Wed, Mar 3, 2021 at 1:15 AM, Lucas SOLDA wrote: I can send you the files if you don't have an account. I use the MLO and u-boot files for beaglebone black from this link : "Click here to download the MLO and u-boot binaries for the new Beaglebone Black platform.". The fact you pointed is troubling. I don't understand why the BSP is unchanged between beagleboard and BBB. "Perhaps if you disassemble the binary and look at the bone memory map and the linker map and the u boot load address for QNX there's a mismatch do you have access to BSP users guide? " I will try to do that but I'm not an expert. I have access to the user guide yes... Le mercredi 3 mars 2021 à 08:09:38 UTC+1, Lucas SOLDA a écrit : @lazarman, in fact I'm not a student and I have a company acc
Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1
Hi Robert If my memory is correct support told him not to work with SP1Too many discrepancies going on. Tool mismatches I'm also not sure if he's got paid support or if that exist.? I'm not surprised QNX left working binaries anybody can get that working and that's pretty typical his issue is he needs to rebuild BSP sources and he can't I recommend he uses 7.0 if he's licensed he should have access and they should answer questions if not at least he's using latest BSP I saw you mentioned paths to SDP to me he's got something incorrect and if I was doing this I would start clean with the latest BSP not something 7 year's old. Mark Sent from Yahoo Mail on Android On Thu, Mar 4, 2021 at 11:22 AM, robert.sty...@gmail.com wrote: Also Working with a BSP http://www.qnx.com/developers/docs/6.5.0SP1.update/com.qnx.doc.neutrinrebuild source codeo_building/bsp.html On Thursday, 4 March 2021 at 17:09:40 UTC lazarman wrote: The read me for the BSP zip files you attached go look at itIt says it's a QNX 6.50 BSP.See if you can get the latest BSP 7.0 Sent from Yahoo Mail on Android On Thu, Mar 4, 2021 at 10:49 AM, Lucas SOLDA wrote: I think the guide refers to this : http://www.qnx.com/developers/docs/6.6.0.update/#com.qnx.doc.bsp_update.guide/topic/bsp_660_structure.html Le jeudi 4 mars 2021 à 17:16:54 UTC+1, lazarman a écrit : The BSP pdf you sent references another BSP user's guide can you find it? Sent from Yahoo Mail on Android On Thu, Mar 4, 2021 at 1:20 AM, Lucas SOLDA wrote: Yes I entered these commands in u-boot, I could have automated them but I prefer to write them for the moment. "In theory if you have a license BUT some RTOS companies dont supply BSP source code unless you paid fees So do you need to modify BSP" Yes in theory I agree. I will need to modify the BSP because I want Isagraf so I have to install the drivers (to make the beaglebone black a target I can load through IsaGraf) In fact I'm very lost with all of these thingsLe mercredi 3 mars 2021 à 19:50:58 UTC+1, lazarman a écrit : These commands you entered are where? uboot? --> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100 Why not automate these commands ? << On Wednesday, March 3, 2021, 09:03:22 AM CST, Lucas SOLDA wrote: Mark, I have a BeagleBone Black REV C.There was nothing on the SD before. I did not touch to the EMC so I think there is nothing inside.My company has a QNX 6.5.0 SP1 licence and here is the list of the tools installed on my computer: First, I formated my SD card in FAT32, I made it active by using diskpart and I copied the MLO and then the u-boot files. I took them from here : https://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/TiAm335BeagleboneBootloader modules# --> "Click here to download the MLO and u-boot binaries for the new Beaglebone Black platform. " After that, I downloaded the BSP files: QNX Neutrino 6.5.0 SP1# --> Download Project Downloads --> bsp-nto650-ti-beaglebone-sp1-trunk-201209071340.zip(I attach MLO, u-boot and BSP to this mail)After extracting, I copied the file "prebuilt-bsp-ti-beaglebone.ifs" in the "image" folder to my sdcard and I could succesfully launch QNX on my BBB by typing these commands :--> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100 That worked perfectly. When I try to compile the image by myself it gets complicated. if I compile the BSP without modifying anything, I should get the prebuilt image, right ?The problem is that, when I do that, I have the message I gave in the first post and it says that I compile with QNX 6.5.0 and not with QNX 6.5.0 SP1 (whereas it is installed). "I'm guessing you have no support forum or no ones replying at QNX?" I don't have support anymore and the only thing the told me is that I don't use QNX 6.5.0 SP1 I don't know what to do anymore and the QNX SDP is not on my computer so I can't use it whenever I want Le mercredi 3 mars 2021 à 15:03:47 UTC+1, lazarman a écrit : Let's start with some history about what rev board you have , what was on SD before and whats in the emc now and details about tools you installed to build BSP and QNX and exactly the BSP file's you are compiling as well as your goals. Are you trying to eventually modify the BSP source?I'm guessing you have no support forum or no ones replying at QNX?I need a clear picture of what you did exactly installing tools as in did you install multiple times etc etc I'll look at the pdf you supplied and ponder whether it worthwhile and practical to find my Beagleboard,Whites,blacks or even Pandaboard.power supplies may be hard to match I've moved a lot. I guess a black would be easy for me to find but may be in storage. Also maybe they will let me reeducate myself as I'm not working on a commercial product and give me access otherwise it's harder t
Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1
The read me for the BSP zip files you attached go look at itIt says it's a QNX 6.50 BSP.See if you can get the latest BSP 7.0 Sent from Yahoo Mail on Android On Thu, Mar 4, 2021 at 10:49 AM, Lucas SOLDA wrote: I think the guide refers to this : http://www.qnx.com/developers/docs/6.6.0.update/#com.qnx.doc.bsp_update.guide/topic/bsp_660_structure.html Le jeudi 4 mars 2021 à 17:16:54 UTC+1, lazarman a écrit : The BSP pdf you sent references another BSP user's guide can you find it? Sent from Yahoo Mail on Android On Thu, Mar 4, 2021 at 1:20 AM, Lucas SOLDA wrote: Yes I entered these commands in u-boot, I could have automated them but I prefer to write them for the moment. "In theory if you have a license BUT some RTOS companies dont supply BSP source code unless you paid fees So do you need to modify BSP" Yes in theory I agree. I will need to modify the BSP because I want Isagraf so I have to install the drivers (to make the beaglebone black a target I can load through IsaGraf) In fact I'm very lost with all of these thingsLe mercredi 3 mars 2021 à 19:50:58 UTC+1, lazarman a écrit : These commands you entered are where? uboot? --> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100 Why not automate these commands ? << On Wednesday, March 3, 2021, 09:03:22 AM CST, Lucas SOLDA wrote: Mark, I have a BeagleBone Black REV C.There was nothing on the SD before. I did not touch to the EMC so I think there is nothing inside.My company has a QNX 6.5.0 SP1 licence and here is the list of the tools installed on my computer: First, I formated my SD card in FAT32, I made it active by using diskpart and I copied the MLO and then the u-boot files. I took them from here : https://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/TiAm335BeagleboneBootloader modules# --> "Click here to download the MLO and u-boot binaries for the new Beaglebone Black platform. " After that, I downloaded the BSP files: QNX Neutrino 6.5.0 SP1# --> Download Project Downloads --> bsp-nto650-ti-beaglebone-sp1-trunk-201209071340.zip(I attach MLO, u-boot and BSP to this mail)After extracting, I copied the file "prebuilt-bsp-ti-beaglebone.ifs" in the "image" folder to my sdcard and I could succesfully launch QNX on my BBB by typing these commands :--> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100 That worked perfectly. When I try to compile the image by myself it gets complicated. if I compile the BSP without modifying anything, I should get the prebuilt image, right ?The problem is that, when I do that, I have the message I gave in the first post and it says that I compile with QNX 6.5.0 and not with QNX 6.5.0 SP1 (whereas it is installed). "I'm guessing you have no support forum or no ones replying at QNX?" I don't have support anymore and the only thing the told me is that I don't use QNX 6.5.0 SP1 I don't know what to do anymore and the QNX SDP is not on my computer so I can't use it whenever I want Le mercredi 3 mars 2021 à 15:03:47 UTC+1, lazarman a écrit : Let's start with some history about what rev board you have , what was on SD before and whats in the emc now and details about tools you installed to build BSP and QNX and exactly the BSP file's you are compiling as well as your goals. Are you trying to eventually modify the BSP source?I'm guessing you have no support forum or no ones replying at QNX?I need a clear picture of what you did exactly installing tools as in did you install multiple times etc etc I'll look at the pdf you supplied and ponder whether it worthwhile and practical to find my Beagleboard,Whites,blacks or even Pandaboard.power supplies may be hard to match I've moved a lot. I guess a black would be easy for me to find but may be in storage. Also maybe they will let me reeducate myself as I'm not working on a commercial product and give me access otherwise it's harder to help. Hopefully I can get you on the right path Mark Sent from Yahoo Mail on Android On Wed, Mar 3, 2021 at 1:15 AM, Lucas SOLDA wrote: I can send you the files if you don't have an account. I use the MLO and u-boot files for beaglebone black from this link : "Click here to download the MLO and u-boot binaries for the new Beaglebone Black platform.". The fact you pointed is troubling. I don't understand why the BSP is unchanged between beagleboard and BBB. "Perhaps if you disassemble the binary and look at the bone memory map and the linker map and the u boot load address for QNX there's a mismatch do you have access to BSP users guide? " I will try to do that but I'm not an expert. I have access to the user guide yes... Le mercredi 3 mars 2021 à 08:09:38 UTC+1, Lucas SOLDA a écrit : @lazarman, in fact I'm not a student and I have a company account with a QNX 6.5.0 SP1 licence. I have also already
Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1
The BSP pdf you sent references another BSP user's guide can you find it? Sent from Yahoo Mail on Android On Thu, Mar 4, 2021 at 1:20 AM, Lucas SOLDA wrote: Yes I entered these commands in u-boot, I could have automated them but I prefer to write them for the moment. "In theory if you have a license BUT some RTOS companies dont supply BSP source code unless you paid fees So do you need to modify BSP" Yes in theory I agree. I will need to modify the BSP because I want Isagraf so I have to install the drivers (to make the beaglebone black a target I can load through IsaGraf) In fact I'm very lost with all of these thingsLe mercredi 3 mars 2021 à 19:50:58 UTC+1, lazarman a écrit : These commands you entered are where? uboot? --> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100 Why not automate these commands ? << On Wednesday, March 3, 2021, 09:03:22 AM CST, Lucas SOLDA wrote: Mark, I have a BeagleBone Black REV C.There was nothing on the SD before. I did not touch to the EMC so I think there is nothing inside.My company has a QNX 6.5.0 SP1 licence and here is the list of the tools installed on my computer: First, I formated my SD card in FAT32, I made it active by using diskpart and I copied the MLO and then the u-boot files. I took them from here : https://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/TiAm335BeagleboneBootloader modules# --> "Click here to download the MLO and u-boot binaries for the new Beaglebone Black platform. " After that, I downloaded the BSP files: QNX Neutrino 6.5.0 SP1# --> Download Project Downloads --> bsp-nto650-ti-beaglebone-sp1-trunk-201209071340.zip(I attach MLO, u-boot and BSP to this mail)After extracting, I copied the file "prebuilt-bsp-ti-beaglebone.ifs" in the "image" folder to my sdcard and I could succesfully launch QNX on my BBB by typing these commands :--> fatload mmc 0 0x8100 prebuilt-bsp-ti-beaglebone.ifs--> go 0x8100 That worked perfectly. When I try to compile the image by myself it gets complicated. if I compile the BSP without modifying anything, I should get the prebuilt image, right ?The problem is that, when I do that, I have the message I gave in the first post and it says that I compile with QNX 6.5.0 and not with QNX 6.5.0 SP1 (whereas it is installed). "I'm guessing you have no support forum or no ones replying at QNX?" I don't have support anymore and the only thing the told me is that I don't use QNX 6.5.0 SP1 I don't know what to do anymore and the QNX SDP is not on my computer so I can't use it whenever I want Le mercredi 3 mars 2021 à 15:03:47 UTC+1, lazarman a écrit : Let's start with some history about what rev board you have , what was on SD before and whats in the emc now and details about tools you installed to build BSP and QNX and exactly the BSP file's you are compiling as well as your goals. Are you trying to eventually modify the BSP source?I'm guessing you have no support forum or no ones replying at QNX?I need a clear picture of what you did exactly installing tools as in did you install multiple times etc etc I'll look at the pdf you supplied and ponder whether it worthwhile and practical to find my Beagleboard,Whites,blacks or even Pandaboard.power supplies may be hard to match I've moved a lot. I guess a black would be easy for me to find but may be in storage. Also maybe they will let me reeducate myself as I'm not working on a commercial product and give me access otherwise it's harder to help. Hopefully I can get you on the right path Mark Sent from Yahoo Mail on Android On Wed, Mar 3, 2021 at 1:15 AM, Lucas SOLDA wrote: I can send you the files if you don't have an account. I use the MLO and u-boot files for beaglebone black from this link : "Click here to download the MLO and u-boot binaries for the new Beaglebone Black platform.". The fact you pointed is troubling. I don't understand why the BSP is unchanged between beagleboard and BBB. "Perhaps if you disassemble the binary and look at the bone memory map and the linker map and the u boot load address for QNX there's a mismatch do you have access to BSP users guide? " I will try to do that but I'm not an expert. I have access to the user guide yes... Le mercredi 3 mars 2021 à 08:09:38 UTC+1, Lucas SOLDA a écrit : @lazarman, in fact I'm not a student and I have a company account with a QNX 6.5.0 SP1 licence. I have also already registered to the" QNX Software Development Platform 6.5.x (registration)" link that you gave me. The problem is not the fact that I can't download and install the SDP but the fact that when I build the image thanks to the BSP, I don't have the same result as the prebuilt image Le mercredi 3 mars 2021 à 00:24:34 UTC+1, lazarman a écrit : Hi Robert I think Lucas is saying he's only trying to build the BSP
Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1
Let's start with some history about what rev board you have , what was on SD before and whats in the emc now and details about tools you installed to build BSP and QNX and exactly the BSP file's you are compiling as well as your goals. Are you trying to eventually modify the BSP source?I'm guessing you have no support forum or no ones replying at QNX?I need a clear picture of what you did exactly installing tools as in did you install multiple times etc etc I'll look at the pdf you supplied and ponder whether it worthwhile and practical to find my Beagleboard,Whites,blacks or even Pandaboard.power supplies may be hard to match I've moved a lot. I guess a black would be easy for me to find but may be in storage. Also maybe they will let me reeducate myself as I'm not working on a commercial product and give me access otherwise it's harder to help. Hopefully I can get you on the right path Mark Sent from Yahoo Mail on Android On Wed, Mar 3, 2021 at 1:15 AM, Lucas SOLDA wrote: I can send you the files if you don't have an account. I use the MLO and u-boot files for beaglebone black from this link : "Click here to download the MLO and u-boot binaries for the new Beaglebone Black platform.". The fact you pointed is troubling. I don't understand why the BSP is unchanged between beagleboard and BBB. "Perhaps if you disassemble the binary and look at the bone memory map and the linker map and the u boot load address for QNX there's a mismatch do you have access to BSP users guide? " I will try to do that but I'm not an expert. I have access to the user guide yes... Le mercredi 3 mars 2021 à 08:09:38 UTC+1, Lucas SOLDA a écrit : @lazarman, in fact I'm not a student and I have a company account with a QNX 6.5.0 SP1 licence. I have also already registered to the" QNX Software Development Platform 6.5.x (registration)" link that you gave me. The problem is not the fact that I can't download and install the SDP but the fact that when I build the image thanks to the BSP, I don't have the same result as the prebuilt image Le mercredi 3 mars 2021 à 00:24:34 UTC+1, lazarman a écrit : Hi Robert I think Lucas is saying he's only trying to build the BSP not QNX. I did this 10 years ago and I also had the latest BSP guides I tried getting these and you need a customer login. It says it's free for education but again BlackBerry bought this. What's funny is this link below takes you to another page which says we support these processors. It also says you should lose the latest version's QNX SDP 7.0 BSP for Texas Instruments AM335x (Beaglebone Black) https://blackberry.qnx.com/en/support/qnx-board-support-packages Clicking on the above link next to the BSP you see another page saying The QNX Software Center enables you to download and manage QNX Software Development Platform version 7.x and related products. PDF documentation and Licensing information relating to QNX SDP 7 and related products can also be found here. IMPORTANT: SDP 7.x licenses are initially delivered within the myQNX License Manager and MUST be assigned to users via the license manager in order for them to access the product. And no code just a login. That BSP Lucas references is over 6 year's old. Even 10 year's ago you needed a valid company domain and email address for QNX I know GreenHills and maybe WindRiver as well wouldn't even reply to a free email domain and definitely won't give you a 30 day level license key that the license manager needed Lucas is this for education ?? I know it's frustrating you might have to reach out them about -- 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/1278493211.71215.1614780213005%40mail.yahoo.com.
Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1
I can't get in without an account if you got the binaries from these links you must have an account. I forgot to mention when I was successful I used a Beagle Board. Interesting the BSP images are different if this comments are correct that implies perhaps uboot changed between bone revs I wonder if the top link is for a beaglebone white perhaps Click here to download the MLO and u-boot binaries for the original Beaglebone platform. Click here to download the MLO and u-boot binaries for the new Beaglebone Black platform. The release notes below imply no changes to the BSP source code QNX Neutrino 6.5.0 Change History# July 10, 2013# - MLO, u-boot, and release note for Beaglebone Black support added (BSP is unchanged) I can't access any links without registering It looks like QNX got loaded and jumped to what's troubling is that version of QNX was from 2010 that date there was no bone just the Beagleboard. Shutdown[0,0] S/C/F=11/1/11 C/D=fe01c68c/fe099ff4 state(c0)= now lockQNX Version 6.5.0 Release 2010/07/09-14:26:46EDT Perhaps if you disassemble the binary and look at the bone memory map and the linker map and the u boot load address for QNX there's a mismatch do you have access to BSP users guide? . Sent from Yahoo Mail on Android On Tue, Mar 2, 2021 at 5:24 PM, 'Mark Lazarewicz' via BeagleBoard wrote: Hi Robert I think Lucas is saying he's only trying to build the BSP not QNX. I did this 10 years ago and I also had the latest BSP guides I tried getting these and you need a customer login. It says it's free for education but again BlackBerry bought this. What's funny is this link below takes you to another page which says we support these processors. It also says you should lose the latest version's QNX SDP 7.0 BSP for Texas Instruments AM335x (Beaglebone Black) https://blackberry.qnx.com/en/support/qnx-board-support-packages Clicking on the above link next to the BSP you see another page saying The QNX Software Center enables you to download and manage QNX Software Development Platform version 7.x and related products. PDF documentation and Licensing information relating to QNX SDP 7 and related products can also be found here. IMPORTANT: SDP 7.x licenses are initially delivered within the myQNX License Manager and MUST be assigned to users via the license manager in order for them to access the product. And no code just a login. That BSP Lucas references is over 6 year's old. Even 10 year's ago you needed a valid company domain and email address for QNX I know GreenHills and maybe WindRiver as well wouldn't even reply to a free email domain and definitely won't give you a 30 day level license key that the license manager needed Lucas is this for education ?? I know it's frustrating you might have to reach out them about You end up here QNX Software Center | | | | || | | | | | QNX Software Center This page provides an overview of QNX's software downloads and binary files, such as PDFs. QNX realtime RTOS - Operating systems, development tools, realtime operating system software and services for connected embedded systems | | | | If you click on Documents on left side of above page you go here http://www.qnx.com/developers/docs/index.html Which says Choose from the following product versions: (Note: Some PDF links may require login and product registration to function.) Clicking on the Document you need ie SP1 takes you here. QNX Software Systems | | | | || | | | | | QNX Software Systems This page provides access to your personal account information. QNX realtime RTOS - Operating systems, development tools, realtime operating system software and services for connected embedded systems | | | | It was that way 10 year's ago I registered with a my company email. Sorry I can't be more helpful How did you get the images?? Mark Sent from Yahoo Mail on Android On Tue, Mar 2, 2021 at 5:52 AM, robert.sty...@gmail.com wrote: It is a long time since I did any of this, so please forgive any errors and omissions. You build a file system image from folders of existing (binary) components and folders of freshly created (binary) components. All guided by a script and/or configuration file. The build process will not build and replace existing components. I found it very difficult to know which version of component was in the file system image. IIRC, Any component specified by the script/configuration is search for in the:- existing folder -- left over rubbish? - QNX target folder -- correct PATH? - freshly created folder -- actually built? On Tuesday, 2 March 2021 at 07:25:37 UTC lucas...@gmail.com wrote: The setup I use should be correct since this is the one provided by QNX directly (MLO first, u-boot and image). Moreover, if my setup was incorrect, the prebuilt image could not work. Yes i rebuilt
Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1
Hi Robert I think Lucas is saying he's only trying to build the BSP not QNX. I did this 10 years ago and I also had the latest BSP guides I tried getting these and you need a customer login. It says it's free for education but again BlackBerry bought this. What's funny is this link below takes you to another page which says we support these processors. It also says you should lose the latest version's QNX SDP 7.0 BSP for Texas Instruments AM335x (Beaglebone Black) https://blackberry.qnx.com/en/support/qnx-board-support-packages Clicking on the above link next to the BSP you see another page saying The QNX Software Center enables you to download and manage QNX Software Development Platform version 7.x and related products. PDF documentation and Licensing information relating to QNX SDP 7 and related products can also be found here. IMPORTANT: SDP 7.x licenses are initially delivered within the myQNX License Manager and MUST be assigned to users via the license manager in order for them to access the product. And no code just a login. That BSP Lucas references is over 6 year's old. Even 10 year's ago you needed a valid company domain and email address for QNX I know GreenHills and maybe WindRiver as well wouldn't even reply to a free email domain and definitely won't give you a 30 day level license key that the license manager needed Lucas is this for education ?? I know it's frustrating you might have to reach out them about You end up here QNX Software Center | | | | || | | | | | QNX Software Center This page provides an overview of QNX's software downloads and binary files, such as PDFs. QNX realtime RTOS - Operating systems, development tools, realtime operating system software and services for connected embedded systems | | | | If you click on Documents on left side of above page you go here http://www.qnx.com/developers/docs/index.html Which says Choose from the following product versions: (Note: Some PDF links may require login and product registration to function.) Clicking on the Document you need ie SP1 takes you here. QNX Software Systems | | | | || | | | | | QNX Software Systems This page provides access to your personal account information. QNX realtime RTOS - Operating systems, development tools, realtime operating system software and services for connected embedded systems | | | | It was that way 10 year's ago I registered with a my company email. Sorry I can't be more helpful How did you get the images?? Mark Sent from Yahoo Mail on Android On Tue, Mar 2, 2021 at 5:52 AM, robert.sty...@gmail.com wrote: It is a long time since I did any of this, so please forgive any errors and omissions. You build a file system image from folders of existing (binary) components and folders of freshly created (binary) components. All guided by a script and/or configuration file. The build process will not build and replace existing components. I found it very difficult to know which version of component was in the file system image. IIRC, Any component specified by the script/configuration is search for in the:- existing folder -- left over rubbish? - QNX target folder -- correct PATH? - freshly created folder -- actually built? On Tuesday, 2 March 2021 at 07:25:37 UTC lucas...@gmail.com wrote: The setup I use should be correct since this is the one provided by QNX directly (MLO first, u-boot and image). Moreover, if my setup was incorrect, the prebuilt image could not work. Yes i rebuilt all by following this https://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/Bsp_650InstallationNotes but that does not workWhy does it say that I use QNX 6.5.0 (2010) whereas I compile with QNX 6.5.0 SP1 (2012) ? I don't understand, we have been working on this for 3 weeks Le lundi 1 mars 2021 à 19:07:16 UTC+1, robert.sty...@gmail.com a écrit : I assumed you did rebuild all <https://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/Bsp_650InstallationNotes> On Monday, 1 March 2021 at 17:02:25 UTC lazarman wrote: I remember sd card setup was important on Beagle board. your probably following old or incorrect instructions. What was on this board could be important. What instructions as well.They used to have a forum before Blackberry bought them. Sent from Yahoo Mail on Android On Mon, Mar 1, 2021 at 10:52 AM, robert.sty...@gmail.com wrote: I vaguely remember the SP install being two manual steps, one being copying files from one place to another On Monday, 1 March 2021 at 16:02:15 UTC lucas...@gmail.com wrote: Hello, I would like to use QNX on my BeagleBone Black. I have downloaded the QNX Neutrino 6.5.0 SP1 BSP here: https://community.qnx.com/sf/wiki/do/viewPage/projects.bsp/wiki/TiAm335Beaglebone When I load the prebuilt image, it starts perfectly but when I try to build the BSP by mys
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 build wiki so I think that's a weak point in getting users to use x15 or AI. Here's the link for thae AM57x Linux IPC If you dig around in this document you see some messages being displayed for normal loads and rpmsg and it discusses changing resource table. Also look at the details involved in getting complicated examples working in CCS. Again the Am35 build may be set up to handle most PRU examples and while I could envision debugging it's PRUs with printf I can't imagine trying complex DSP or a M4 without CCS and JTAG to debug for exactly the reasons you point out the documents are scarce. Buts just me. Here's the 57x document as you can see in it the DSP and M4 have MMU on the interconnect between the ARM Host. http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_IPC.html#ipc-for-am57xx If anything this overview should give you more confidence deciphering what your original question was and still remains. My understanding is hazy but the carvout and increasing of any shared memory sizes is where you need to change this table and I've seen no other documents discuss this for. I suspect the existing working PRU on Am35x examples are very simple in nature as you said in last post simple demos work. You mentioned using interrupts that's probably a faster way to get Data to the Host. To me what good is a determistic fast IO processor if the Data needs to be acted on quickly as in a hard realtime control theory loop.The other cores the DSP and M4 have edma also on the interconnect not sure about PRU. It's all described in the document below. Your simple example comment bthat's what caught my eye I think your right 樂. Most people use the PRU for dedicated offloading I doubt many use every function available for IO like a normal processor application I might be wrong but I do know the DSP and M4 share many peripheral with the ARM so full blown applications on those cores can and will be designed eventually.I know this as I have seen product that's in field doing so. How those engineer's deciphering questions like yours I don't know I suspect they had dedicated engineer's at TI assigned to the company as they were buying large quantities of chips then and in the past. With open source it's kind of like the book I'm reading about Google and Stanford students. The professor assigns summer projects to their PHD candidate's 浪來 and in the case of the Google Co-founders they crashed the University computer and we're nicely ask to leave the campus but told they could come back anytime if Google didn't work out.And they paid the tuition. Sorry for detour there but I think this is were Google's Summer projects are inspired from Stanford. Keep us updated if you find more details Mark Sent from Yahoo Mail on Android On Tue, Mar 2, 2021 at 5:09 AM, Fisher Grubb wrote: 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 receive the interrupts.Plus, as you mentioned, more chips are multi-architecture. We're spoilt for choice with dual core M4 and C6000 DSP in the AI, and they need to be used properly to take advantage of this chip.I think too many people likely use it like a Raspberry Pi which defeats the point, as the Pi is multi-core Cortex A just for Linux, while the BeagleBone AI and Black have less Linux CPU power, but excel in using the PRUs and M3/M4 etc. Thanks a lot for the documentation link, I've only more recently returned to programming, so have had to refresh myself in not just C and C++, but also micro controller architecture and compile options with Makefiles. Ya, I'll look over the documentation you sent a little later, thankfully that documentation framework exists, as documentation is the last thing programmers want to do. I'm currently sorting out the IEP timer use so a simple real-time scheduler can run using it. It will run state-machines. I'll document all I've done in the end, my supervisor should want to go through and replicate what I've done to confirm the steps are correct, and then people will have more of a guide. Fisher On Tuesday, 2 March 2021 at 10:48:04 UTC+10 lazarman wrote: 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