This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM5728: PRU Incremental Encoder without eQEP

Part Number: AM5728


Hi,

I am using the AM5728 processor and the TI AM57xx-evm Linux processor. I need multiple separate encoders to be run on PRU (>3). 

Currently, I am just trying to get an RPMsg to send to a device file for each encoder turn, I am uninterested in position or speed, only direction. 

I have mapped the input signals generated from each CLK and DT pin to channel 1 and host 1, to be system events 17 and 20 and the depress functionality on system event 16 for a single encoder. 

Whilst I can generate an interrupt from pressing the encoder, turning either way does not generate an interrupt. I am unsure how to write code that will generate an interrupt for these signals, as they seem to stay high when I attempt to do: if((__R31 & (1<<8)) == (1<<8)) (eg. input mapped to pru0_gpi8). 

I have checked my encoder circuitry with a logic analyser to rule out hardware issues and the encoder responds normally. 

I have also attempted to do a basic implementation of encoder logic that has further been unsuccessful:

currentCLK = (__R31 & (1<<12); //input pin
currentDT = (__R31 & (1<<8); 
        if (currentCLK != lastCLK){
        //  /*If DT and CLK different = clockwise rotation*/
            if(currentDT != currentCLK){
                CW_TRIGGER;
            }
            else{
                CCW_TRIGGER;
            }
        }
        lastCLK = currentCLK;
        lastDT = currentDT;
Is there something specific required for encoder logic, bearing in mind I cannot use eQEP, or regarding the use of multiple system events mapped to a single channel? 
  • Hi Tay,

       I would like to split your problem statement into two parts.

    1. reading PRU GPIs over R31 register to emulate encoder interface for direction detection.

    - check whether you get change on R31 bits when you rotate the encoder. This would confirm that pin-mux and GPIO mode is properly setup. You can check this by starting CCS, connect to PRU and check register R31 content. Alternative is setting software breakpoints when state of input pin changes. e.g. wbs r31, 8 followed by a halt instruction.

    2. Generating an Interrupt to host CPU using INTC

    - INTC has 10 Interrupt outputs. The first two go back to PRU cores. PRUSSn_IRQ_HOST[2:9] are available to generate interrupts to host CPU. So you can setup INTC to take pr1_pru_mst_intr[0]_intr_req (event 16) and map it to channel 2 and IRQ_HOST[2]. Writing 0x20 to R31 generates the pr1_pru_mst_intr[0]_intr_req.

    Pls let me know if that helps.

    BR,

      Thomas

  • Hi Thomas,

    Thanks for the reply. I have currently been writing without CCS but I will set it up and give your advice a go.

    I have been mapping my interrupts to channel 1, similar to how the TI PRU Getting Started Lab 2 shows, is this incorrect for my use?

    Regards

  • I don't believe I will have access to a JTAG emulator to use CCS anytime soon, is there a different way I can check bit change without it?

  • Hi Tay,

    Would accessing registers using devmem2 on linux be helpful?

    Regards,
    Tanmay

  • Hi Tanmay,

    I have looked into doing this, would this be the address of Register 31: 0x80000000? I otherwise am not sure what register to read to check for bit changes.

  • Hi,

    Sorry for the delayed response.

    Is this issue still observed?

    Regards,
    Tanmay