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.

RM57Lx Fast Read of GIO Pins

Other Parts Discussed in Thread: RM57L843, HALCOGEN

Hello,

I am using the RM57Lx Hercules Launchpad and I need to read 14 GIO pins in less than 100 nano seconds (from an external ADC). The max clock speed of the RM57L is, I understand, 330MHz, and I am currently using the gioGetBit(); method to read pins. However, I see that this method takes ~80 clock cycles every time it is executed (I used the profile clock in CCS to determine this).

Basically, my attempt is the following:

int pin[14];

pin[0] = gioGetBit(gioPORTA, 7);

pin[1] = gioGetBit(gioPORTA, 6);

... and so on.


So my question is the following: is there another faster way to read gio pins? Or in order to read 14 pins from an external ADC in less than 100ns, I need an MCU with clock frequency capabilities higher than 330MHz?

Any advice is appreciated.

Regards

  • Gabriel,

    The RM57Lx LaunchPad isn't capable of this level of IO performance.

    You would need to drop the sample rate to 300ns to be able to do the job with the N2HET.
    It could probably sustain that rate until you fill up the internal SRAM.

    If you want an off the shelf board that *can* keep up with this type of ADC you should look at BeagleBone Black.

    -Anthony
  • Gabriel,

    Another option in the launchpad world might be the TM4C129. That apparently has a parallel port specifically designed for FPGAs and ADCs. You can post on that forum too to get more information.
  • Hi Anthony,

    Thanks for your help. Is there a way or a built-in method to read GIO pins in parallel? Wouldn't this make the reading of the pins much faster?

    Thanks,
    Gabriel
  • Hi Gabriel,

    On the RM57L? Well the N2HET port has > 16 GIO all in one register so you could read them in parallel.
    But it should wind up taking more than 50ns to read an IO port on the RM57. I haven't actually measured this on
    an RM57 so you might want to try it ... make a loop that reads an IO port many times and surround it by PMU reads.
    You'll get a small error due to the PMU overhead which will be reduced by spreading the overhead across many reads.
    (PMU overhead should be 6 cycles or so).

    I think you're going to find it over 50ns and then you need to ask how you know the data you capture is valid versus in transition. If you sample while the pins are changing the result will be junk. So you'll need some sort of sampling of the 'clock' signal and that means sampling probably 4x faster than your actual 100ns sample rate.

    This is really a problem best left to hardware - which is where the TM4C or the BeagleBone would be advantageous because those devices have parallel input ports.
  • Hi Anthony,

    Thanks for your help, I will look into these options. I have one more question, would you know why does it take so many clock cycles to execute the gioGetBit(); method? I got the RM57L launchpad in the first place thinking that reading a pin and saving that value to memory wouldn't take more than 10-20 clock cycles, and that it would therefore be enough to do what I need. I am measuring over 50 clock cycles for this operation (without taking into account the breakpoint overhead using the profile clock on CCS). It seems strange that this simple operation would take so many clock cycles.

    Regards
  • Gabriel C9 said:
    I am measuring over 50 clock cycles for this operation (without taking into account the breakpoint overhead using the profile clock on CCS). It seems strange that this simple operation would take so many clock cycles.

    I haven't measured the performance myself, but some suggestions for optimizations:

    1. Set the Optimization Level for the compiler to "4 Whole Program Optimizations". That can allow the compiler to in-line short functions such as gioGetBit(), which avoid the call / return overhead and potentially also allows other optimizations.
    2. Check that the cache is enabled on RM57L843, which if you are using HALCoGen is under the Cortex-R5 panel on the R5-MPU-PMU tab.
    3. Execute the code from SRAM rather than flash. This is because SRAM is zero wait states, whereas the RM57L843 flash requires 3 wait states at the highest HCLK frequency. Note that if the RM57L843 cache is enabled, not sure if running the code from SRAM rather than flash will result in a speed-up.

      [This suggestion is based upon measurements on Hercules device which didn't have a cache]