• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 436 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.

RM48L952 NHETS

Tammy Noergaard
Genius 3665 points
Other Parts Discussed in Thread: HALCOGEN, RM48L952

Hello,

We are using the RM48L952ZWT board. For NHET1 and NHET2, we understand that an NHET be configured as PWM, GIO, Input Capture or Edge Detection.

- Does this mean that  any NHET in 1 or 2 can be programmed as PWM (if it's terminal has not been multiplexed for another purpose), or are only certain NHET terminals allowed to be programmed as PWMs? 

- With the multiplexing of i.e., EMIF, etc. -- we lose some of the NHETs because their terminals must be used for another function. Are there any additional NHETs available on the EM48L952ZWT not shown in the datasheet? 

Thank you.

  • 0
    TI__Guru 68920 points

    Tammy,

    - Does this mean that  any NHET in 1 or 2 can be programmed as PWM (if it's terminal has not been multiplexed for another purpose), or are only certain NHET terminals allowed to be programmed as PWMs? 

    Yes, through HalCoGen there is a control to select the pin, and if you write your own HET program you can use a .equ statement to map symbolic pin names to hard-coded pin numbers.   You can then use they symbolic name in your code and relocate the pin simply by changing the .equ.

    - With the multiplexing of i.e., EMIF, etc. -- we lose some of the NHETs because their terminals must be used for another function. Are there any additional NHETs available on the EM48L952ZWT not shown in the datasheet? 

    From the standpoint of the blackbox driver, no.  If you can't find the HET pin in the pinmux then you won't be able to use it.

    From the standpoint of 'custom' code, if you use one of the hi-res sharing modes, then you can make use of the 'logical' odd pin of a pair (0/1, 2/3, 4/5) assuming the even pin is available.    Because your logical pin in the sharing mode will actually perform a second function (capture a 2nd edge, or drive a 2nd output) on the even pin that is available.

    EDIT: 

    The above is a probably pessimistic with respect to the blackbox driver.  You can actually configure the ANDSHARE, XORSHARE, and HRSHARE on the pin tab of HalCoGen's HET driver tab.  So you can actually use the logical odd pin in the PWM or CAP tab,  but have it perform a 2nd function on the even pin in the pair. The pins tab shows you graphically how the pairing is organized.. 

    Should also make it clear that these sharing modes don't get you any more physical pins on the chip, but they let you use more 'pins' in the HET program and therefore do more work per physical pin than you might be able to do otherwise.

  • 0 in reply to Anthony F. Seely
    Genius 3665 points
    Hi. Thank you. Great.
    - What do you mean by "hi-res sharing modes" if we wanted to try writing the custom code to have the paired additional pins behave as PWM?
    - For HET Pins that are not on the PINMUX in HalCoGen, are there still a total of 32 x 2 = 64 total HET pins on the RM48952ZWT total? -- Can we use any paired pins on the RM48L952 that are not being used for another purpose, or is there a limitation that they have to be a HET pin? For the pair, do these paired odd/even pins have to be in chronological order or can the hardware engineers have a choice as long as one pin is an even pin and the other is an odd pin(i.e., 1/2, 3/4, 10/11 versus 1/4, 3/12, 15/32)? Thank you again.
  • 0 in reply to Tammy Noergaard
    TI__Guru 68920 points

    Tammy,

    You can find the details about the N2HET's pin sharing modes in section 20.2.5 of the TRM (SPNU503B).

    Pin sharing is used mainly to extend the number of operations per pin, per loop resolution period, from one to two.

    This mainly makes sense for instructions with hr_lr = High.


    If the N2HET pin is not selectable in pinmux,  or if it is not the only function on a pin (and therefore does not need to be configured in pinmux) then you can't really use the pin to get an extra PWM or input capture.   You can however use the pin's high-resolution timing logic to get one more action per loop resolution period on it's companion pin.

    A good example of this is measuring duty cycle and period of the same physical pin, say NHET1[0].

    You would use the PCNT instruction to measure duty cycle and period, with one PCNT configured to measure 'RISE2FALL' on pin 0 and another to measure "RISE2RISE' on pin 0.   The first gives you the duty cycle, the 2nd the period.

    Now the rules of N2HET say you can only have one of these two instructions configured with hr_lr=high.

    So you can't normally measure both duty and period at high resolution.

    HRSHARE provides a loophole around this limitation.   When you enable HRSHARE for a pair of pins,  the HET gets inputs for both 'logical' pins from the even number pin.   

    So now you write your program to PCNT on pin 0 for duty, and PCNT on pin 1 for period.  Both are allowed to be hi-res instructions because they are separate logical pins.  But with HRSHARE turned on, both 'pin0' and 'pin1' are looking at the signal on device pin NHET1[0].   
    Now the downside is that since you've used pin0 and pin1 in your program but only have used NHET1[0] on the device,  NHET1[1] as a physical pin is limited in use.  You can still operate on it through the GIO register of  the N2HET, or you can configure it out in pinmux if that option is available.  But you can't do something like create a PWM on this pin with N2HET because you've already used it up in your N2HET program for PCNT'ing ...

    AND-SHARE and XOR-SHARE are the 'output' version of pin sharing.  Let's say you have a very long period (multiple loop resolution periods) for a pin but want a duty cycle that can go down to 1 hr clock and you also want the pulse to be symmetrically aligned (centered) within the period.

    This may result in a case where you need a 1 cycle pulse in the middle of an loop resolution period.    A single N2HET output instruction (like PWCNT) isn't capable of both setting a pin high and then setting it low again within the same loop resolution period,  unless one of the edges is the 'opposite action' which means it has to be anchored on a loop resolution boundary.   So with just one PWCNT you may not be able to create this type of signal.

    But if you think about this, you can create the turn on edge with a PWCNT operating on 'pin=0' and the turn off edge with a second PWCNT operating on 'pin=1' and then using the XORSHARE function combine the two PWCNTs onto pin NHET1[0] so that your single cycle output pulse is place arbitrarily anywhere within the period and located with high resolution. 

    In this case you also wind up using the logic for pins 0 and 1 in the HET program,  but at the device you are only creating a signal on N2HET1[0].  So again N2HET1[1] is of limited use in this case,  you can use it as a GIO or pinmux it out with another function, but you can't create another separate PWM on this pin with the same N2HET program.

    So to summarize, the sharing is about getting an extra operation (either in our out) on a physical pin within a short (< 1 LRP) time.   You wind up using the resources of 2 N2HET pins to act on one physical pin.

    The good news here is that your N2HETs on the RM48 have the hi-res resources for 32 pins each,  so you have the hi-res resources of 64 pins at your disposal even if you  cannot use the pin due to bonding or pinmuxing constraints.