Re: [beagleboard] Re: Debug serial console not working

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

#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

['Mark Lazarewicz' via BeagleBoard]

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.

RE: [beagleboard] Re: BeagleBone Black (C) USB based touch not working

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

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, 

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

['Mark Lazarewicz' via BeagleBoard]

 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

['Mark Lazarewicz' via BeagleBoard]

 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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

 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

['Mark Lazarewicz' via BeagleBoard]

 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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: [beagleboard] Re: PRU Messaging

['Mark Lazarewicz' via BeagleBoard]

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 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send 

Re: [beagleboard] Re: PRU Messaging

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

@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 seen as "bone-debian..." in "testing") 

RE: [beagleboard] Re: Reducing Boottime in Beaglebone Black

['Mark Lazarewicz' via BeagleBoard]

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 archive_log.service 
> 1.839s keyboard-setup.service 
> 1.548s rsyslog.service 
> 

Re: [beagleboard] Re: PRU Messaging

['Mark Lazarewicz' via BeagleBoard]

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.

['Mark Lazarewicz' via BeagleBoard]

#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.

['Mark Lazarewicz' via BeagleBoard]

#  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) = 40206B00

  

00 00 00 00 00 00

00 00 00 00 

Re: [beagleboard] Re: Shared PRU Memory and beyond

['Mark Lazarewicz' via BeagleBoard]

 #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

['Mark Lazarewicz' via BeagleBoard]

@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, read, store, notify
host logic.

>> Does the second 

Re: [beagleboard] Weird C problem: PRU doesn't respond to host if two variables aren't initialized in loop

['Mark Lazarewicz' via BeagleBoard]

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&= ~VacValve;

__delay_cycles(4000);  // put this delay cycle here 

Re: [beagleboard] Re: Shared PRU Memory and beyond

['Mark Lazarewicz' via BeagleBoard]

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.

['Mark Lazarewicz' via BeagleBoard]

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 

Re: [beagleboard] Re: unexpected "low speed" of PRU 1

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

 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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

 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

['Mark Lazarewicz' via BeagleBoard]

 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

['Mark Lazarewicz' via BeagleBoard]

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...@googlegroups.com.
To view this discussion 

Re: [beagleboard] unexpected "low speed" of PRU 1

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

 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

['Mark Lazarewicz' via BeagleBoard]

 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/ && print 
$$1') \
 --filter 

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

 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

['Mark Lazarewicz' via BeagleBoard]

 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 slight difference between Debian 
system 

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

 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

['Mark Lazarewicz' via BeagleBoard]

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 but 

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

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 the PRU code 

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

#  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 a lot 

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

 << 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 *sysfs_node; char firmware[] = 

Re: [beagleboard] Re: TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

 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_CGT compiler. But it is unable to 

Re: [beagleboard] Re: TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

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. But it is unable to compile 

Re: [beagleboard] TI PRU_ADC_onChip example

['Mark Lazarewicz' via BeagleBoard]

 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

['Mark Lazarewicz' via BeagleBoard]

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 

Re: [beagleboard] TI Programmable Real-time Unit software support package issues

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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?

['Mark Lazarewicz' via BeagleBoard]

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?

['Mark Lazarewicz' via BeagleBoard]

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?

['Mark Lazarewicz' via BeagleBoard]

 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?

['Mark Lazarewicz' via BeagleBoard]

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?

['Mark Lazarewicz' via BeagleBoard]

 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?

['Mark Lazarewicz' via BeagleBoard]

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?

['Mark Lazarewicz' via BeagleBoard]

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?

['Mark Lazarewicz' via BeagleBoard]

   
   - 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?

['Mark Lazarewicz' via BeagleBoard]

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?

['Mark Lazarewicz' via BeagleBoard]

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?

['Mark Lazarewicz' via BeagleBoard]

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?

['Mark Lazarewicz' via BeagleBoard]

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?

['Mark Lazarewicz' via BeagleBoard]

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?

['Mark Lazarewicz' via BeagleBoard]

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?

['Mark Lazarewicz' via BeagleBoard]

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?

['Mark Lazarewicz' via BeagleBoard]

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 src/pruio/pruio_adc.p.
 
  
 

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

['Mark Lazarewicz' via BeagleBoard]

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?

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

.
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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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 to help.
Hopefully I can get you on the right path 
Mark

Sent from Yahoo Mail on 

Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1

['Mark Lazarewicz' via BeagleBoard]

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 registered to the" QNX Software 
Development Platform 6.5.x (registration)" link that you gave me. The 

Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1

['Mark Lazarewicz' via BeagleBoard]

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 not QNX.
I did this 10 years ago and I also had the latest  BSP guides I tried getting 
these and you need a 

Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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

['Mark Lazarewicz' via BeagleBoard]

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 


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 myself, I 

Re: [beagleboard] Re: PRU RemoteProc documentation

['Mark Lazarewicz' via BeagleBoard]

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 

Re: [beagleboard] Re: PRU RemoteProc documentation

['Mark Lazarewicz' via BeagleBoard]

Hello Fischer 

This file looks like it's processing the resource table 
https://docs.huihoo.com/doxygen/linux/kernel/3.7/remoteproc__core_8c_source.html




* 804  * take a firmware and boot a remote processor with it. 805  */ 806 
static int rproc_fw_boot(struct rproc *rproc, const struct firmware *fw) 807 {


I'm no kernel internals guy but I'm pretty sure dev_info below in a working 
load gets displayed look at the output in Linux to DSP IPC SDK documents. Have 
you seen it? It's helped me if you have not let me know it also discussed M3 I 
know you are doing OUR

817  dev_info(dev, "Booting fw image %s, size %zd\n", name, fw->size);
Perhaps what you need is to recompile kernel with debug level for appropriate 
driver verbose mode.I'm sure it's possible but I'm not the right guy maybe it's 
a defconfigoption.

You'd want to make sure dev_dbg below spits out useful info is my guess 
If unable to actually talk to somebody who writes code like this us mere 
mortals are left to study the source code.
I been there I feel your pain. Have you located the file Din pointed to and the 
corresponding c files ???
701  /* make sure table isn't truncated */ 702  if (avail < 0) { 703  
dev_err(dev, "rsc table is truncated\n"); 704  return -EINVAL; 705  } 706  707  
dev_dbg(dev, "rsc: type %d\n", hdr->type); 708  709  
I remember that IPC document also talking about disabling interrupts in an 
example as well.
And lastly I've got the sneaky feeling that this whole remoteoroc falls apart 
rather quickly when the DSP, M3 or PRU examples get complex.My interest is DSP 
I need more modern HW or I'd be in there with you deciphering what it takes to 
use complex example on the DSP only my interest is using JTAG.
That L3 message looks like the ones the kernel spits out processing the image 
but again Im not a Linux guy.
 Also that IPC DSP doc lists addresses for all the cores you should be able to 
find At Address: 0x00806664 


[ 2393.327706] remoteproc remoteproc6: Booting fw image PRU_ucfsm.out, size 
370028[ 2393.327762] [ cut here ][ 2393.327782] 
WARNING: CPU: 0 PID: 1810 at drivers/bus/omap_l3_noc.c:147 
l3_interrupt_handler+0x368/0x3a4[ 2393.327790] 4400.ocp:L3 Standard Error: 
MASTER PRUSS2 PRU1 TARGET PCIE1 (Read): At Address: 0x00806664 : Data Access in 
Supervisor mode during Functional access


Keep us posted I'm interested if you find more data I think we will be seeing 
many more questions about remoteproc once people start running DSP and M4 code 
especially about resource tables 
Mark 






Sent from Yahoo Mail on Android 
 
  On Sun, Feb 28, 2021 at 11:46 PM, Fisher Grubb wrote: 
  Hi all,
I solved my issue in the end of it not booting, or causing errors with 
"L3_main" in the title from remoteProc to dmesg.
The issue turned out to be both having interrupts from the IEP timer, and that 
C++ needs .init_array in the linker command file to actually initialise the 
constructors.The linker did add the .init_array section at the end of the 
binary, but I don't think actually got the code to jump to the needed addresses 
without that section specifically put into the linker file.
I assume the interrupt issue may be been due to using an empty resource_table, 
so the kernel module didn't set anything up to receive them on the Linux side, 
but then the timer sent them.I'm not fully sure about that because I believe 
I've also left them enabled, and not had dmesg errors.
I still can't find any RemoteProc documentation of the possible config options, 
or how to get extra info out of the kernel modules, such as what it's doing as 
it processes the resource_table.
Fisher

On Friday, 12 February 2021 at 02:29:00 UTC+10 din...@gmail.com wrote:

The error message is emitted from the system bus driver 
(drivers/bus/omap_l3_noc.c ). 

I interpret it as a bug in your PRU firmware. When issue occurs, please try to 
inspect the PRU state. See 
https://zeekhuge.me/post/ptp_docs_commands_and_tools/ , or use JTAG.
Regards,DimitarOn Thursday, February 11, 2021 at 7:30:58 AM UTC+2 Fisher Grubb 
wrote:

Hi Dimitar,
Thanks for your reply, yes, I don't understand that as its code to flash 
lights.  Its built with different states, which makes it more complicated, but 
only flashes LEDs.
How can I know what the kernel module is doing so I can see more details and 
know where to look?  Such as, is this happening when the firmware is being 
processed by the module, or is this the module giving the error once the code 
is trying to run on the PRU?
Thanks,Fisher
On Thursday, 11 February 2021 at 02:58:57 UTC+10 din...@gmail.com wrote:

Looks like PRU attempts to access PCIE1 address space. I suspect it's a bug in 
your PRU firmware.

MASTER PRUSS2 PRU1 TARGET PCIE1 (Read): At Address: 0x00806664

TI has tutorials how to use JTAG to debug PRU. Another option is 
https://markayoder.github.io/PRUCookbook/04debug/debug.html

Regards,Dimitar

On Wednesday, February 10, 2021 at 2:27:01 PM UTC+2 Fisher Grubb wrote:

Re: [beagleboard] Re: BeagleBone Black QNX 6.5.0 SP1

['Mark Lazarewicz' via BeagleBoard]

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 myself, I have this : 
Jumping to QNX
System page at phys:80011000 user:fc404000 kern:fc404000Starting next program 
at vfe046604cpu_startnext: cpu0 -> fe046604VFPv3: 
fpsid=410330c3coproc_attach(10): replacing fe07601c with 
fe0758bccoproc_attach(11): replacing fe07601c with fe0758bcWelcome to QNX 
Neutrino 6.5.0 SP1 on the Texas Instruments BeagleBone (ARMv7 Cortex-A8 core) - 
Board
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[0]PID-TID=1-6? P/T 
FL=00019001/0502 "proc/boot/procnto-instr"[0]ASPACE PID=2 PF=8012armle 
context[effe8f4c]:: 8ffb2000 8ffb2000 8ffb2c01 0181 effccbf8 0100 
 fc004020: fc004000 effdf47c 01072fff 0008  effe8f90 
fe046878 fe040e0c0040: 6013instruction[fe040e0c]:06 30 98 e7 1c 20 94 e5 11 
00 12 e3 00 70 94 15 18 20 9d 15 07 70 82 11 0c 00stack[effe8f90]:: 
effe8fbc e18a1000  efffb348 effca00c 003f 0a6e e19881600020: 
8ffb2000 f000  0007 0040 effccbf8 fe099ff0 0140: 
00ff efff0090 0073 008d effca6e8 fe044744 effccbf8 fe044ad00060: 
efffb348 fe069bac efffb348 fe071e30 effe9018   ÿ

As we can see, I have this message : QNX Version 6.5.0 Release 
2010/07/09-14:26:46EDTThis means that I try to compile with QNX 6.5.0 and not 
QNX 6.5.0 SP1. I don't understand why i have this message because I have well 
installed QNX 6.5.0 SP1 :


Do I miss something ? Do I have to activate someting somewhere ?
Thank you for your help.


-- 
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/84dc332e-7fc5-4b20-bf82-05224d394938n%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/325596030.536839.1614618117863%40mail.yahoo.com.

Re: [beagleboard] Status - Running TI SDK-Built C66 DSP Example EXE on BB-X15 - Beagleboard Debian

['Mark Lazarewicz' via BeagleBoard]

 My last contribution hopefully I dont want to confuse people but I think this 
is important
No matter which SOC you pick the TI DSP has access to on chip peripherals
Perhaps you been using a PRU UART,SPI,I2C 
The good news is the DSP core can use and access  these peripherals as well. 
Its a much faster processor and while optimized for signal processing many 
companies use TI DSP like a normal microprocessor using home brew OS, bare 
metal or TI RTOS.
Perhaps you never used a TI DSP like this or have only used Linux device 
drivers or PRU based peripherals
You need to refer to your SOC block diagram to validate this BUT ...
M3 and CC6C or cc74 depending on the SOC all have access to the SOC peripherals
DSP cores are good for audio and video codecs so maybe you need to process 
Audio or video and get it off chip or maybe into the SOC
As part of your learning to use the DSP maybe you want a UART for debig or SPI 
or I2C you need drivers
The drivers are stashed in the Processor Dev Kit (PDK) heres an example and I 
will post an example directory  for L138 SDK below 
I'd strongly suggest trying this on a single core DSP Soc as the conflict in 
muxing pins occurs from the host so things will get try quick on a complicated 
SOC BUT Not so if you have a JTAG you can remove the host sd card and connect 
to the DSP and work on a UART example 
Here a DSP RTOS I2c  example 
6.1. CSL — Processor SDK RTOS Documentation


| 
| 
|  | 
6.1. CSL — Processor SDK RTOS Documentation


 |

 |

 |


here are the drivers provided in source code as starting points this for the 
L138 the AM

C:\ti\pdk_omapl138_1_0_11\packages\ti\drv

AND The x15
C:\ti\pdk_am57xx_1_0_17\packages\ti\drv

So Jeff and I have given a a huge amount of choices we expect it will take time 
to digest this all we hope this was helpful
Good Luck read the docs and have fun  playing on your board
Mark





   





.
  

-- 
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/1417610762.805053.1614033851223%40mail.yahoo.com.

Re: [beagleboard] Status - Running TI SDK-Built C66 DSP Example EXE on BB-X15 - Beagleboard Debian

['Mark Lazarewicz' via BeagleBoard]

 To Debug and Test a DSP app on OMAP L138 dev kit using CCS and Jtag I used the 
following guide.
Only one DSP core so its much easier to get up and running I used below

10.3.12. OMAP-L137/C6747 EVM Hardware Setup Guide

10.1. Target — Processor SDK RTOS Documentation


| 
| 
|  | 
10.1. Target — Processor SDK RTOS Documentation


 |

 |

 |





.

-- 
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/252648650.784538.1614029952299%40mail.yahoo.com.

Re: [beagleboard] Status - Running TI SDK-Built C66 DSP Example EXE on BB-X15 - Beagleboard Debian

['Mark Lazarewicz' via BeagleBoard]

 Update for TI Soc using the DSP coreThe .TI DSP's are optomized for Signal 
Processing very good skillset for industry used in military and medical and 
avionics
The Omap  L138 is another option to the Beagle X15 I tested the  TEXAS 
INSTRUMENTS OMAP-L138/C6748 LCDK-PCB-004 DSP+ARM Development
yesterday I successfully loaded a DSP image using CCS/JTAG While an older 
platform its fully supported for JTAG and CCS THIS IS VERY IMPORTANT!!!It is 
supported in the SDK RTOS and is a great way to Focus on using TI DSP a very 
popular DSP in industry I saw Digikey had ads not sure about stock and I saw a 
used one on ebay about $100 
TEXAS INSTRUMENTS OMAP-L138/C6748 LCDK-PCB-004 DSP+ARM Development | eBay


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
TEXAS INSTRUMENTS OMAP-L138/C6748 LCDK-PCB-004 DSP+ARM Development | eBay

Find many great new & used options and get the best deals for TEXAS INSTRUMENTS 
OMAP-L138/C6748 LCDK-PCB-004 DSP...
 |

 |

 |


TMDSLCDK138 Development kit | TI.com


| 
| 
|  | 
TMDSLCDK138 Development kit | TI.com

View the TI TMDSLCDK138 Development kit description, features, development 
resources and supporting documentatio...
 |

 |

 |





.

-- 
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/469284722.686027.1614012544461%40mail.yahoo.com.