• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 83 subscribers
  • Views 1049 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28069M: Using eCap feature and 5 ultrasonic sensors

Andrew Wenaus
Intellectual 675 points
Part Number: TMS320F28069M


Hello!

I'm currently working on an autonomous robot's collision detection feature, and I would like to use feedback from 5 ultrasonic sensors to do it.

The sensors work by sending a pulse of decreasing width as objects get closer to the sensor, so I've been able to use the eCap feature to measure the pulse and act based on its duration. 

My problem comes from the fact that the launchpad only has eCap1, eCap2, and eCap3. I understand that I could have the rising and falling edge of two pulses go to a single eCap as 4 events, but if I overlap the signals I receive from the sensors, it gets too noisy to use. If I use multiple eCap1 pins the signals will still overlap so that the rising edge of the second signal happens before the falling edge of the first. Is there any way I can send multiple signals to the same eCap so that I can monitor 5 sensors with the 3 available eCaps?

  • 0
    TI__Mastermind 42195 points

    Andrew,

    depending on your system requirements you should have a solution. Does the sensor output a pulse at the beginning and end of a measurement or does the sensor's output stay high during the measurement(ie. rising edge to start measuring and a falling edge to stop measuring)?

    1. Configure 3 eCAPs and 2 HRCAPs.
      1. Pros: You can sample all 5 signals without complexity
      2. Cons: the HRCAP module can be difficult to use.
    2. Connect 2 sensors to eCAP1 on different pins.
      1. This will allow you to switch between sensorA and sensorB in software. the process would be something like:
        1. Read sensor A
        2. Switch the Mux configuration
        3. Reset eCAP
        4. Read Sensor B
        5. Switch the Mux configuration
        6. Reset eCAP
        7. Read sensor A
        8. (repeat)
    3. Connect 2 sensors to 2 of the eCAPS on the same pin(use an 'or' gate or something similar)
      1. This will only work if you have a deterministic ordering of pulses
      2. This will only work if the sensor outputs pulse to start/stop measuring and does not remain "high" for the length of the measurement. 

    Regards,
    Cody 

  • 0 in reply to Cody Watkins
    Prodigy 40 points
    Hey Cody! we've configured it to match your 2nd solution, and thank you for the idea!

    We're using an Epwm timers to cycle between the sensors, giving 50ms between switching sensors, which we found to be enough time such that the signals will never overlap!

    We set it all up, but we only have Ecap2 working (and it works great). We ended up staying late to get the one working, and called it a day after it was functioning, so I haven't had a detailed look at what might be going on. I just have a quick question before I leave for school, where in a couple hours, I can get back to it.

    Should Ecap 1, 2 and 3 have identical register configurations, other than the interrupt enable vector? And the IER |= 0x0008 will enable the entire vector group, so that should only be set once. I definitely will have a closer look tonight, and I havent provided nearly enough detail for your assistance, but I'd just like to ask if theres anything that comes to your mind that I just look into first!

    Anyways, thanks Cody, you've been quite the help throughout this semester, and the project should be done by next Wednesday!

    Thanks again!
  • 0 in reply to Kurtis Archibald
    TI__Mastermind 42195 points

    Kurtis,

    That's awesome! I'm glad you got it working. I expect that eCAP2 and eCAP3 should require the same setup as long as the sensors are the same. You may want to change the stop/wrap value for the eCAP that only has one sensor connected...however it may work fine without changes, that depends on your system/setup.

    Yesterday I forgot to mention that the HRCAP can be setup in "Normal Capture Mode" which makes it function more like an eCAP...not exactly the same but reasonably similar if you would like to try that implementation. (I assume if you've got a working solution already you'll probably stick to that)


    I'de love to hear about the project as a whole, if you have any presentations or a summary of what your systems is doing I'de love to see it!

    Regards,
    Cody 

  • 0 in reply to Cody Watkins
    Intellectual 675 points
    Hey Cody! We'll definitely send you a video + our report once we're finished! It's been a lot of fun!

    Regarding the Ecap module:
    We've managed to get Ecap2 and Ecap3 working, but we cannot get Ecap1 to work. This is the Ecap which has the 3 sensors rotating between their use. We've set it up like this:

    Turn on Ecap MUX for Sensor1
    Wait 100ms -> In this time, we should get a value from Ecap
    Turn off Ecap Mux for Sensor1
    Delay 1us
    Turn on Ecap MUX for Sensor2
    and repeat.

    We don't get interrupted by Ecap1, but we have the registers set up in the same manner as our Ecap2 and Ecap3 (each of these just have 1 sensor). We've tested it with just 1 sensor, and multiple pins connecting to Ecap1 using that sensor, but still nothing!

    Would you have any ideas on how to test this going forward? (We have another F28069M Launchpad coming on thursday, so we can check if the functionality is broken then).
  • 0 in reply to Andrew Wenaus
    Intellectual 675 points
    Hey Cody!

    I think it's an EALLOW; EDIS; problem. I just thought about that, i'll test it when I get to the lab.. the revised code will be:

    EALLOW;
    Turn on Ecap MUX for Sensor1
    EDIS;
    Wait 100ms -> In this time, we should get a value from Ecap
    EALLOW;
    Turn off Ecap Mux for Sensor1
    EDIS;
    Delay 1us
    EALLOW;
    Turn on Ecap MUX for Sensor2
    EDIS;
    and repeat.
  • 0 in reply to Andrew Wenaus
    TI__Mastermind 42195 points

    Andrew,

    I don't think you have damaged the device. You can check by configuring the pin as an output and toggling it, then configure it as an input and verifying that you can pull it low/high.

    The GPxMUXy registers are EALLOW protected, so it may be causing an issue!

    I would have probably put 2 sensors on eCAP1, 2 sensors on eCAP2, and 1 on eCAP3. If you put 3 on eCAP1 then it will add to the latency of getting sensor input on those three sensors. However, it could make sense if you have 2 high priority sensors and 3 lower priority sensors.

    Regards,
    Cody 

  • 0 in reply to Cody Watkins
    Intellectual 675 points
    Hey Cody! We managed to get the Ecap1 working except we don't have it shared between sensors.
    We're now having a look at HRCAP for our last two sensors, and we seem to be getting random values in the example.

    We're looking to just measure the pulse width (Rising Edge to Falling Edge) provided by these sensors. It's not a periodic signal.
    We've read HRCAP and followed the code, the example works great, but we can't get it to work with our sensors.

    Here is the key points behind what we believe should work. All the Sysctrl, GPIO pins, and setup have been sorted. It seems pretty simple! We're following HRCap_Capture_Pwm

    void HRCAP1_Config(void)
    {
    EALLOW;
    HRCap1Regs.HCCTL.bit.SOFTRESET = 1;
    HRCap1Regs.HCCTL.bit.HCCAPCLKSEL = 1; // HCCAPCLK = PLL2CLK x 2
    HRCap1Regs.HCCTL.bit.RISEINTE = 0; // Disable Rising Edge Capture Event Interrupt
    HRCap1Regs.HCCTL.bit.FALLINTE = 1; // Enable Falling Edge Capture Event Interrupt
    HRCap1Regs.HCCTL.bit.OVFINTE = 0; // Disable Interrupt on 16-bit Counter Overflow Event
    }

    __interrupt void HRCAP1_Isr (void)
    {
    HRCap1Regs.HCCTL.bit.FALLINTE = 0; // Disable rising edge interrupts

    PULSEWIDTH = HRCap1Regs.HCCAPCNTFALL0; //should reset timer on rising edge, and then this should be our pulsewidth?

    HRCap1Regs.HCICLR.all = 0x001F; // Clear all HRCAP interrupts
    HRCap1Regs.HCCTL.bit.FALLINTE = 1; // Re-enable rising edge interrupts

    HRCap1Regs.HCICLR.bit.INT=1; // Clear HRCAP interrupt flag
    PieCtrlRegs.PIEACK.bit.ACK4=1; // Acknowledge PIE Group 4 interrupts.
    EDIS;
    }

    As i'm typing this, I realized that weird EAllow; Edis; situation where its set in the HRCAP_1_Config and then cleared at the end of the ISR.
    Could this be an issue?

    The values we're receiving seem to be all over the place, but generally under a count of 50. Sometimes we'll see a spike up to 45000, but only briefly. We're expecting to see numbers north of 90000, as that is the case with the Ecap module (though this example is set for 60Hz).

    Would you happen to see a problem?
  • 0 in reply to Andrew Wenaus
    TI__Mastermind 42195 points

    OK, the HRCAP example is going to use HR mode. I don't think you need that, so you should be able to use Normal Capture Mode.  

    But one problem is: If i remember correctly the HRCAP module only has 16bit registers not 32bit registers, its designed to measure shorter pulses and will overflow before you reach 90000.

    I think using one eCAP to measure multiple sensors may be easier.

    In a pinch the QEP module can be used to measure longer pulse widths, but that has some draw backs too.

    Regards,
    Cody 

  • 0 in reply to Cody Watkins
    Intellectual 675 points
    Hey Cody! We're in a pinch! We just need 2 more ultrasonic sensors to work, then we are 100% done our project! It is due wednesday, so it is in a deliverable state at the moment, but if we could add these 2 sensors, it would be way better!

    We can't seem to dynamically mux on/off the Ecaps, and the HR register is too small!

    Which QEP example project could I follow to use the QEP to measure the high pulse-width? Also, if you could maybe give a quick explanation on how they work, or if theres anything we should know before we try to get this working! We basically have to have this implementation go as smooth as possible, as really any hiccup, we gotta call it off!

    We're expecting a pulse-width of about 150,000 clock cycles! All the details you can provide would be a huge help!

    Thanks for all your time! We reeaaaallly do appreciate it! We are super happy with our project!

    We have the report due next wednesday, and Ill send you the report and some videos of the robot in action!

    Thanks again!
  • 0 in reply to Andrew Wenaus
    TI__Mastermind 42195 points
    Andrew,
    sorry I don't think one of eQEP examples will work for this purpose without significant modification.(this is a very atypical use) The best starting point would probably be eqep_freqcal, I wish I could provide more details, however I have never implemented this use case myself.

    Trying to keep as many options open for you as possible: For the multiple sensors connected to different eCAP mux positions... I would configure the eCAP to trigger an interrupt immediately after the end of the first pulse, read out the values, reconfigure the mux to the next sensor, reset the eCAP module then ack and return from the interrupt. There should be no special hardware setup, I assume the sensor takes an input pulse to trigger the measurement, so be sure that you are sending the start of measurement signal to the correct sensor.

    Sorry I cant be of more help.

    Best of luck,
    Cody
  • 0 in reply to Cody Watkins
    TI__Mastermind 42195 points
    What method did you end up using?

    Regards,
    Cody