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.

PWM on HET or ePWM module

Other Parts Discussed in Thread: TMS570LS1115, HALCOGEN
I have a question for the capacities of the n2het module...
i will implement 12 PIs for 12 different motors on the tms570ls1115 mcu. and i saw a post about changing the duty cycle of the pwm on the het... and i saw on the page 765 of the reference manual a code about doing the same with the epwm module
so my question is this one:
What would you recommend me to do? using the ePWM module or using the HET? I think, and maybe Im wrong, that.. since the PI will be a function I will create as a task, it would be better to use the code on the ref. manual page and modify the lines i need... like the period and the duty... so i can have the HET dedicated only for the encoders. oh and one last question... the HET could make a count up to 720 (max) counts per encoder (12 encoders in total) and then send the data to the cpu when a timer flag rises or when i tell it to do so? 
And I have another question.... the VCLK4... how do you configure it? I have been looking for the registers and i cant find them.... I hope you can help me... 
best regards!!
  • Miguel,

    If you have a choice between ePWM and N2HET, and ePWM can do exactly what you want, then it (edit ePWM) might be better because you wouldn't have as much a learning curve (hopefully) and the N2HET is more flexible so you'd 'save' it for a harder task that comes up.  If you start having to make tradeoffs with ePWM then you might flip and go to N2HET.

    The other consideration is what you think you might need to do within the Hercules family.  Right now the LS111x is probably the lowest end part w. the ePWMs - the very lowest part that we have is the LS03xx (with Cortex R5) and it only has N2HET and an eQEP -- no ePWMs.  Conversely if you need to move up to the LS3xxx series this also doesn't have ePWM so you would need to move up to the LC4357 if you have some unrelated problem - say you need more memory than the LS1xxx family has.  Just another consideration.

    VCLK4 should be easy to configure if you look at the clock module screen in HalCoGen:

  • Hi Anthony

    about the LS and the ePWM, i think is better to use the module, as you said, i could use the n2het for better propuses. So i will continue with the ls1111x

    and about the timer... There is no way to configure it without halcogen? Because i will program the ePWM as the reference manual says and the N2het with the idle and all is going to be at the FreeRTOS so i dont know how would that be... 

    Im not sure im clear enough... Mmmm the halcogen gives me a code per periferal no? or is just a single file that i will upload to the compiler and then write my code around that file? 

    And how will it work with the FreeRTOS?

    Thanks for the answer :)

    best regards!!

  • Miguel,

    Hi, have you tried HalCoGen before?  It sounds like maybe you haven't tried it out based on the questions.  So I'll try to give a quick summary.

    HalCoGen will generate peripheral driver code, and it includes some FreeRTOS ports.

    Generally for each peripheral, in HalCoGen you will setup the registers and modes - then HalCoGen will generate initialization code for each peripheral according to how you have configured them in the GUI.  There are tabs in HalCoGen for the LS111x where you can configure all of the e* timer peripherals as well as the N2HET.  

    In addition to the init function, HalCoGen will generate a header file and API support functions as well as register headers for the peripherals.  So it includes basic functions for you to do things like change the duty cycle in your program in addition to setting an initial duty cycle in the init() function.

    I am speaking very generally - the best thing for you to do is fire the program up and explore both the configuration tabs as well as the generated header and .c files (where you can see the runtime API functions available to your program). 

    You might have to do some additional programming of the peripheral registers directly if you can't find the options in the halcogen functions - as the peripherals sometimes have a *lot* of possible combinations of operating modes and HalCoGen doesn't support every last one - but you should be able to get very close and if you do need to do anything custom there are places in the HalCoGen generated code where you can insert custom steps that will be maintained through regeneration -- and you also have the benefit of having all the header files at your disposal.

    The e* peripherals and the N2HET really do not interact w. FreeRTOS.  FreeRTOS uses the RTI timer for it's tick and this is independent of these control oriented timers we're talking about.   So you don't have to worry about anything you do in the e* or N2HET timers breaking FreeRTOS.

  • I was asking about the timers because im more familiar with pic18 MCU than TI and I wantd to do the code by myself but... is easier the way you said. About the PWM I will use the example code on the User Manual so I dont have the problem you told me on other post about changing the fixed duty cycle from the HalCoGen for a variable. I can write it in the main accompanied with the rest of the code. I normally program that way: function prototype, functions, and the main, with all the initializations of the peripherals... but if the HalCoGen can do the initializations for me, I will take advantage of that. 

    I have been playing on the HalCoGen to see how it works but... Im not sure which files I will need. I saw that it gives me a lot of files, one per peripheral, kind of, so I suppose I include them as libraries on the code or copying the code I need. 

    One of my biggest problems so far is looking for information on the HTU, because I will ask for the data from the N2HET every X time to actualize the shaft position. But I guess I can configure it on the HalCoGen... something like... "every 100ms (sampling period from the PIs) asking the positions, askng the data from the different values from each encoder "