'What the HET?' do you want to see??? [for an N2HET library]

Anthony,

Thanks for posting this - I would like to see some common libs for some of the more common automotive sensors like RPM, temperature (thermistor and thermocouple), pressure; etc. and the routines that will be the most versatile. I think everyone will benefit.

Thanks!
John W.

We ended up making the N2HET programs dynamic, i.e. you can add them at run time.

We would then call something like:
N2HET_DYN__Add(PWM, PIN_1, INT_ON);

This would add a PWM program onto the instruction stack, configure the IO and Interrupt if needed.

It gave us the freedom to implement something like a PLC without having to compile code.

Not sure the design effort would be worth it for everyone, but it gives us lots of flexibility.

I would like to see an example for two inverse signals, where you can change PWM frequency, duty cycle and dead time.
This could be an easy-to-understand and easy-to-probe example for HET beginners.
And useful for TMS570LS04 controllers that don't have an etPWM module.

(there is an appnote for 3 signals to drive a brush-less motor, but that one expects a decent knowledge before you understand what's happening)

Thanks Jan! I am going to try to put some priority on writing up that 3 ph example. It's difficult to understand and needs a lot of documentation. Also have had requests to put a license on the file (likely we'll use BSD 3-Clause).

Hi Stomp,

WOW! that is something I'd never even have conceived of. Did you implement this by writing all the code and just turning on/off instructions dynamically? Or do you actually have some sort of dynamic code generation inside the driver function?

Hi John,

Do you have a list of protocols for the sensors that you'd like to see implemented? Anything more specialized than say SPI or I2C?
We've had requests for SENT before for example...

Hi Anthony,

We made 'template functions' (like PWM, QEP, Etc) that we have pre-tested but did not use absolute addressing.

When we add functions onto our stack the relative addresses are adjusted within each program based on a counter of the current number of instructions in use, pins/interrupts are set, and we append a branch to instruction 0 at the end before updating the RAM.

We don't change the program during run time, only during the first Init after reset.

Send me a DM if you'd like to review the code for this implementation.

Thanks

Stomp!.

Anthony,

Something else that could be helpful: generating the WDOG sync pulses with the TPS65381 - taking the WD_CLK output (or one of the clocks) out of the DIAG_OUT and inputting that to one of the N2HETs - it would be a nice feature to be able to sync to that pulse and then generate the trigger pulses within the 32 us time out. This would take all of the guess work (seemingly) out of this - and you would have a hardware lock to that pulse.

Something I will get to eventually - but a suggestion that I would think a lot of people could use since if they are using the TPS65381 - hopefully they have tied DIAG_OUT to an I/O that's on a N2HET pin - and using the trigger method.

Thanks,
John W.

Anthony,

How about a fully autonomous WDOG service for the TPS65381? I have that working - and it is quite nice. Once synchronization lock is achieved - 0% RTOS overhead required to keep it going. Nice. This solution would not have been possible without the features of the N2HET. Of course we are talking about Trigger mode here and not Q&A mode.

Regards,
John

Hi John,

That's a good idea - but are you worried that the ARM software might hang yet the HET would keep the watchdog serviced?
That's my worry.

Anthony,

If the trigger had a countdown that never was updated with an ISR - wouldn't the HET keep counting that down - and when it reached zero and no ISR updated it - wouldn't the WDOG kick? That is a way a DEAD MAN condition could be handled - correct?

Regards,
John W.

I followed the link www.ti.com/.../spny009 (in your answer to John's post referenced above) and found a list of Application Notes in it (Table 2, page 3). (Besides, the author mixed up the URLs behind the entries "Triggering ADC" and "Quadrature Encoder".)

I would like to see a more elaborate measurement of quadrature-encoder signals. I have three possible improvements in mind.
1) The current version is counting edges between yet-undetermined moments. The N2HET shall be used to generate these moments (program parameter = reporting period).
2) Apart from counting signal edges, the N2HET program shall also measure the time of their occurrence (may be only for the most recent edge in each reporting period). That would greatly improve the accuracy if the speed may change considerably within a few pulses.
3) For the determination of speed (not direction), counting and timing shall be limited to one type of signal edges (there are four different types of signal edges) (otherwise, they shall be counted and timed independently) to avoid blurred results due to deviations from the 90° phase relations.

Best regards,
Rainald

Hello Anthony,

So, will there be an N2HET lib?

Thanks,
John