subject:"RE\: \[beagleboard\] Strange behavior of value returned from PRU with RPMSG"

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

2021-04-22 Thread TJF

wal...@edenconceptsllc.com schrieb am Donnerstag, 22. April 2021 um 
21:00:03 UTC+2:

> You are correct to mention this TJF.  In production, I won't bother to do 
> convert it to a human-readable number.   It helps with debugging right now 
> though.


And for debugging purposes, is it a good idea to convert at PRU side? From 
my point of view the CCS and rproc/rpmsg concepts are dangerously 
misleading. 
 

-- 
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/0e11d218-d8ec-41a8-bebb-338e0f99366fn%40googlegroups.com.

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

2021-04-22 Thread Walter Cromer

You are correct to mention this TJF.  In production, I won't bother to do 
convert it to a human-readable number.   It helps with debugging right now 
though.


On Thursday, April 22, 2021 at 3:26:12 AM UTC-4 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/4b2a19f7-00eb-418d-9c45-8e0fc6c23673n%40googlegroups.com.

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

2021-04-22 Thread '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] Strange behavior of value returned from PRU with RPMSG

2021-04-22 Thread TJF

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.

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

2021-04-21 Thread '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

2021-04-21 Thread Walter Cromer

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.

RE: [beagleboard] Strange behavior of value returned from PRU with RPMSG

2021-04-20 Thread Graham Stott

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: beagleboard@googlegroups.com [mailto:beagleboard@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+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/002701d7364e%24a2ff0550%24e8fd0ff0%24%40comcast.net.

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

2021-04-20 Thread '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

2021-04-20 Thread Walter Cromer

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 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/34361932-cafb-46a7-b31c-c962fe3bda89n%40googlegroups.com.

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

2021-04-20 Thread '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] Strange behavior of value returned from PRU with RPMSG

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

RE: [beagleboard] Strange behavior of value returned from PRU with RPMSG

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

10 matches

Site Navigation

Mail list logo

Footer information