A simple oversight in an area of my PRU code (I was sending the whole 
rpunit struct back as the payload, rather than just the first member of the 
struct, a single char representing the command) now has the characters 
coming back into my userspace program. However, I can only manage 3x 
command exchanges before something locks up... nothing in dmesg... I'm 
using the file-duplex package which I found on npm to handle the duplex 
stream, perhaps the bug is in here...?

On Saturday, 28 October 2017 17:20:54 UTC+1, Nahuel Greco wrote:
>
> you don't need that, you can use a single  /dev/rpmsg_pruXX for 
> bidirectional communication with a single PRU. Try running the Texas echo 
> example from command line (first doing an "echo xxx > dev/rpmsg_pruXX", and 
> then "cat /dev/rpmsg_pruXX"),then try to use that from node. That will 
> discard if the problem is in your PRU code.
>
> Saludos,
> Nahuel Greco.
>
> On Fri, Oct 27, 2017 at 5:30 PM, Hugh Frater <[email protected] 
> <javascript:>> wrote:
>
>> I know the stream is transmitting OK, my PRU code reacts as expected to 
>> the messages I'm sending over. I'm going to look at the data in more detail 
>> over this weekend, I've been off this project for 10 days or so.
>>
>> I'm beginning to wonder if I fudge around this by using shared memory 
>> between the 2x PRUs and then use one /dev entry for commands to and one 
>> /dev entry for commands from - I'd rather not though.
>>
>> On Friday, 27 October 2017 18:36:35 UTC+1, Nahuel Greco wrote:
>>>
>>> Smells like the problem is at the nodejs side, maybe you can try not 
>>> running the node program and cat'ing the device to see if the characters 
>>> are shown. What's the value of the 'data' received in the callback?
>>>
>>>
>>> Saludos,
>>> Nahuel Greco.
>>>
>>> On Fri, Oct 27, 2017 at 11:05 AM, Hugh Frater <[email protected]> 
>>> wrote:
>>>
>>>> Hi Nahuel,
>>>>
>>>> You can't cat the device file because linux doesn't allow concurrent 
>>>> access to the device file descriptor from more than one userspace program, 
>>>> and we need to open that device file from within our node.js program to 
>>>> write to the PRU. I do have a hardware UART looped back from the PRU into 
>>>> userspace, so I could use that for the communication back into userpace, 
>>>> but I would rather persevere and get the rpmsg subsystem working in a 
>>>> bi-directional mode.
>>>>
>>>>
>>>> On Thursday, 26 October 2017 21:57:02 UTC+1, Nahuel Greco wrote:
>>>>>
>>>>> doing "cat /dev/rpmsg_pruXX" shows any data? do you have a github repo 
>>>>> with a complete sample?
>>>>>
>>>>> Saludos,
>>>>> Nahuel Greco.
>>>>>
>>>>> On Mon, Oct 9, 2017 at 1:11 PM, Hugh Frater <[email protected]> 
>>>>> wrote:
>>>>>
>>>>>> Does anyone have any experience of working with /dev/rpmsg_pruXX 
>>>>>> files from within Node.Js/Bonescript? I've been playing around with the 
>>>>>> file-duplex package and have data going into the PRU just fine, but I'm 
>>>>>> having an issue getting data back into my userspace program. I've got 
>>>>>> the 
>>>>>> stream.on('data', function(data)) picking up that a data has been pushed 
>>>>>> into the rpmsg file from the PRU side, but I can't get any meaningful 
>>>>>> data 
>>>>>> into my program. I'm sending single character ascii characters as my 
>>>>>> data.
>>>>>>
>>>>>> Am I missing the 'proper' way to do this?
>>>>>>
>>>>>> -- 
>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>> --- 
>>>>>> You received 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 [email protected].
>>>>>> To view this discussion on the web visit 
>>>>>> https://groups.google.com/d/msgid/beagleboard/666d2c51-fa4f-464b-83db-ffc7a158fecf%40googlegroups.com
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/beagleboard/666d2c51-fa4f-464b-83db-ffc7a158fecf%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>> 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 [email protected].
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/beagleboard/07c3768b-461a-456f-aecd-f31600184ec7%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/beagleboard/07c3768b-461a-456f-aecd-f31600184ec7%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> 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 [email protected] <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/85cd0b2a-75af-461b-ad88-5f5907f8d104%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/85cd0b2a-75af-461b-ad88-5f5907f8d104%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> 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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cde7b6bd-be2a-4d75-9b86-cf4ae49644e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to