dinuxbg / pru-gcc-examples

Simple example projects for PRU-GCC
49 stars 12 forks source link

Ultrasonic sensor code #11

Closed deebot closed 4 years ago

deebot commented 4 years ago

Similarly for the ultrasonic sensor code. I modified the code to toggle a LED connected to a pin configured in the pruout mode whenever a interrupt happens and wrote my toggle code inside handle_mailbox_interrupt() function. But pin doesnot toggle. However the ultrasonic sensor is giving correct value. In further investigation i tried to run you basic blinkingled code on PRU1 but again no blinking. I think there is some issue. May be you can suggest something.
In your ultrosonic sensor example you are running halt code on PRU0 and rpmsg code on PRU1. So after having this issue. I thought lets reverse it and i tried running rpmsg code on PRU 0 and halt code on PRU1 by changing the copy commands as following sudo cp out/pru-halt.elf /lib/firmware/am335x-pru1-fw sudo cp out/hc-sr04-range-sensor.elf /lib/firmware/am335x-pru0-fw // reversed the am335x-pru(n)-fw

Also made the change in

define HOST_INT ((uint32_t) 1 << 31)

define TO_ARM_HOST 18

define FROM_ARM_HOST 19

define CHAN_NAME "rpmsg-pru"

define CHAN_DESC "Channel 31"

define CHAN_PORT 31

to

define HOST_INT ((uint32_t) 1 << 30)

define TO_ARM_HOST 16

define FROM_ARM_HOST 17

define CHAN_NAME "rpmsg-pru"

define CHAN_DESC "Channel 30"

define CHAN_PORT 30

But now after loading the firmware and starting the prus using remoteproc i dont see the rpmsg_pru31 or rpmsg_pru32 driver loaded when i do ls -l | grep rpmsg_pru.

If i dont edit the code and load them in the prus as you have instructed in the README. I get the rpmsg_pru31 in the /dev after starting the PRU.

Any pointers

EDIT:

dmesg log , might be useful

[ 5920.357985] remoteproc remoteproc2: powering up 4a338000.pru [ 5920.358177] remoteproc remoteproc2: Booting fw image am335x-pru1-fw, size 2964 [ 5920.358210] remoteproc remoteproc2: remote processor 4a338000.pru is now up [ 5957.270664] remoteproc remoteproc1: powering up 4a334000.pru [ 5957.271056] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 49380 [ 5957.276517] pruss 4a300000.pruss: configured system_events[63-0] = 00000000,000c0000 [ 5957.276536] pruss 4a300000.pruss: configured intr_channels = 0x0000000a host_intr = 0x0000000a [ 5957.281331] pruss_intc_irq_set_affinity: event 16 not configured: ch = -1, host = -1 [ 5957.301511] virtio_rpmsg_bus virtio0: rpmsg host is online [ 5957.301712] remoteproc remoteproc1: registered virtio0 (type 7) [ 5957.301723] remoteproc remoteproc1: remote processor 4a334000.pru is now up

dinuxbg commented 4 years ago

Similarly for the ultrasonic sensor code. I modified the code to toggle a LED connected to a pin configured in the pruout mode whenever a interrupt happens and wrote my toggle code inside handle_mailbox_interrupt() function. But pin doesnot toggle.

The HC-SR04 example firmware for PRU toggles the SoC GPIOs, not the PRU GPIOs. Carefully check your pinmux settings and wiring.

But now after loading the firmware and starting the prus using remoteproc i dont see the rpmsg_pru31 or rpmsg_pru32 driver loaded when i do ls -l | grep rpmsg_pru.

You also need to update the resource table. I remember pru_intc_map is different between PRU cores, maybe there was something else. See:

https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/am335x/PRU_RPMsg_Echo_Interrupt0/resource_table_0.h

https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/am335x/PRU_RPMsg_Echo_Interrupt1/resource_table_1.h

deebot commented 4 years ago

The HC-SR04 example firmware for PRU toggles the SoC GPIOs, not the PRU GPIOs. Carefully check your pinmux settings and wiring.

Yes i understand that i removed the calls to ultrasonic sensor and added a blink LED code in the handler function. such that whenever interrupt happens a led blinks. Now i tested with pin P1.35 which can be controlled by the PRU core 1. the led blinks each time i get a interrupt and handler function is called.

You also need to update the resource table. I remember pru_intc_map is different between PRU cores, maybe there was something else. See:

However as i mentioned earlier i want to move the code to pru0 as it has alot more enhanced pru pins which are exposed on the headers on pocketbeagle. So i added the resource_table_0.h instead of resourse_table_1.h in my code. but when i compile i get the following error

main1.c:153:12: error: ‘resourceTable’ undeclared (first use in this function); did you mean ‘resource_table’? 153 | status = &resourceTable.rpmsg_vdev.status; Here is the complete code https://pastebin.com/5pTYfvB8

Edit: Probably found the issue. The resourse table0 dint had the interrupts defined will add them and test.

deebot commented 4 years ago

So today i did some more investigation and with the links to the resource file you gave i copied and renamed the resource_table_1.h as resource_table_0.h and edited the following lines.

struct ch_map pru_intc_map[] = { {16, 2}, {17, 0}, }; moved the rpmsg code to main0.c and made the changes in the values and channels as suitable for pru0 in the main0.c. Further put in the halt code in main1.c. I can compile the code without error. But the rpmsg_30 driver is not getting loaded in the /dev when i start the code using remotproc. When i checked dmesg i get https://pastebin.com/LmTYn4BE

[32920.988912] pruss_intc_irq_set_affinity: event 16 not configured: ch = 2, host = -1 This line seems to be the culprit. Any pointers , what am i missing? Here is your ultrasonic sensor code with my modifications https://github.com/deebot/Beaglebone-BidirectionBus/tree/master/ExtraDebug/RPmsgPRU0Ultrasonic

dinuxbg commented 4 years ago

You have not updated the Channel-to-host mapping. Please do:

-                         HOST_UNUSED, 1, HOST_UNUSED, 3, HOST_UNUSED,
+                        0, HOST_UNUSED, 2, HOST_UNUSED, HOST_UNUSED,
deebot commented 4 years ago

Thanks it worked. Would you like to merge a new example if i further modify the code and add a userspace c code that sends a 1 or 0 to the PRU and depending on the value turns on and off a LED connected to one of the PRU pins. I think real use of rpmsg is with PRU0 as all the enhanced PRU i/o which can be accessed on the P1,P2 headers belongs to PRU0.