Use an LM1949 to Drive a FET?

[MotoFab]

Yes, use it to drive a FET instead of a bipolar. Have you guys tried it?

If so, what happened? I think it can be made to work.

[Fred]

If it was in PWM mode, and it could be made to work, it might be a good idea. I suggested this a looooooonnnnnnnnnnggggggggg time ago and was shot down by others. I guess it depends on the V and I that the output pin can provide, and little else, if you're talking about nice protected logic FETs.

What made you decide it was worthy of a post? Your other posts recently have paled in comparison to this one.

Fred.

[jharvey]

He e-mailed me about power FET issues, looks like he's more comfortable posting here. I agree with that, as it allows others to learn from the experience.

Last I recall, the primary one that shot you down was jbperf in this thread viewtopic.php?f=9&t=378&start=0

I seem to recall the high gain of MOSFET's and IGBT's were not intended to work with the LM chip, and it had problems that one wouldn't expect by reading the datasheet. Besides if you PWM it, why not just do that via MCU pin. Each pulse would be less than the peak time, so you can technically do it now, if one so choose.

[Fred]

Besides if you PWM it, why not just do that via MCU pin. Each pulse would be less than the peak time, so you can technically do it now, if one so choose.

No, no you can't. Not with our architecture, and not with any intelligent well focussed architecture. This won't ever happen on the main MCU and for many many many good reasons, so if you want, you could stop wasting your breath suggesting it ;-) Creating a stand alone solution using some other cheap low end MCU is a great idea, though. Back to the on topic stuff...

[jharvey]

One way to do it, as implemented in StingrayIII is to have one PWM that drives a resistor. This resistor is connected to the IGBT/MOSFET/LM1949 gate. The gate is also direct (or nearly direct) connected to the gate. Such that when the MCU drive high, the gate is full on. When switched to high impedance, the PWM signal drives the gate, and when driven low, it turns off.

Another way to do it, is to DMA rake a piece of memory across a GPIO pin. Such that you draw any series of pulses you want, across that pin, and you do it when you trigger the DMA to start raking. This allows you to draw any wave form you want.

It's really up to Marco to decide if either of the above, might be implemented, or if he might come up with some other solution. I believe he's currently planning to keep the LM1949, which I understand can't directly drive a MOSFET or IGBT.

[Fred]

One way to do it, as implemented in StingrayIII is to have one PWM that drives a resistor. This resistor is connected to the IGBT/MOSFET/LM1949 gate. The gate is also direct (or nearly direct) connected to the gate. Such that when the MCU drive high, the gate is full on. When switched to high impedance, the PWM signal drives the gate, and when driven low, it turns off.

That's a neat solution, provided that your MCU pin can directly both sink and source sufficient current to overcome the resistor PWM AND that the resistor PWM sinks and sources enough current to properly switch the FET quickly. That seems unlikely with ours, plus it would require a different style of output drive than what we have adding unacceptable complexity to a critical area of the code for a minority group of people.

You'd also have to be careful to not end up in a situation where the injector got PWMed by default, power the PWM by the same output as the fuel pump relay drive or some such thing.

Another way to do it, is to DMA rake a piece of memory across a GPIO pin. Such that you draw any series of pulses you want, across that pin, and you do it when you trigger the DMA to start raking. This allows you to draw any wave form you want.

Google brought up no hits for your term, in my search. All GPIO is DMA in our chip, but you either need a peripheral module or some code to effect a change on a pin, both of which we won't be spending on this type of approach. I wouldn't try to carry 2 cubic meters of topsoil in a Ferrari either.

It's really up to Marco to decide if either of the above, might be implemented

No, it is absolutely not up to Marcos, at all. It's solely up to me, and I can tell you, that this will not ever be included in FreeEMS sources. This is a software decision, not a hardware one. It has been made for all the right reasons, a long time ago. A hardware solution is required to support this. LM1949 is one option, there are others. The main MCU won't be doing this task, period.

Fred.

[MotoFab]

No, it is absolutely not up to Marcos, at all. It's solely up to me, and I can tell you, that this will not ever be included in FreeEMS sources. This is a software decision, not a hardware one. It has been made for all the right reasons, a long time ago. A hardware solution is required to support this. LM1949 is one option, there are others. The main MCU won't be doing this task, period.

Are you saying you won't include it in the code that you in particular write? Or do you mean that you are the only one that will ever have a vote? I'm sure I don't understand the nuances of Open Source and that the answers to those questions are obvious.

Re the LM1949 w/FET, I'll contact jbperf (Jean) and maybe we can try a couple of things.

- Jim

[MotoFab]

Another way to do it, is to DMA rake a piece of memory across a GPIO pin. Such that you draw any series of pulses you want, across that pin, and you do it when you trigger the DMA to start raking. This allows you to draw any wave form you want.

I don't understand the term 'rake' either. Do you mean rotate the piece the memory, but have only one particular bit appear on the output pin? If that is what you mean, that method could be applied across a full 8 bit port.

- Jim

[jharvey]

I don't understand the term 'rake' either.

Thanks for the clarity in your reply. Rake was a term used by an ARM sales rep. Basically you setup a pointer to a section of memory. Then you set a DMA channel from that memory to the GPIO. The DMA controller can be set to increment the input memory location on each clock cycle, such that the next bit in memory is directly pushed to the GPIO pin. I understand that an ARM can also auto reset, making the input memory a circular buffer. Also also, the DMA can have a clock signal that is independent of the MCU, so if the MCU locks up, it would still run in a limp home kind of mode, as long as the RPM signal is still feeding the DMA clock controller, that is.

This sequence is kind of like raking your yard, as you are moving your pointer in a circular fashion pushing bits (instead of leaves) to a known location. I've also heard people use the term comb, instead of rake, however comb is less descriptive as it doesn't typically push something, somewhere. Comb typically just arranges things.

[Fred]

Are you saying you won't include it in the code that you in particular write? Or do you mean that you are the only one that will ever have a vote? I'm sure I don't understand the nuances of Open Source and that the answers to those questions are obvious.

You're right, they're obvious. No such code will be included in my, root-source, upstream, master source for FreeEMS. This decision, like all others, was made by community consultation, and the result was that the vast majority of users, at the time, agreed that it was a poor choice to implement this in the MCU. That remains true. Only people with sufficient understanding of all aspects involved should carry an opinion on this decision. I fit that bill.

Jared, I'm still lost on the raking. Can you please provide a link to a credible (the internet is full of non-credible sources...) source for this information (to save you time re-explaining something that is already explained on the net). It certainly sounds off-topic, anyway. Talk of ARM-specific hardware features in the Puma specific forum section, when Puma is a design that runs FreeEMS, and FreeEMS is a design that does not run on ARM architectures. If there is something non-hardware specific in the raking stuff, get it out, so we can discuss it, if the raking thing is purely ARM-specific, then it's not relevant here.