Puma board for FreeEMS

[jharvey]

The digital I/O pinout can be left for a while (not forever, tough), but I took the liberty of reallocate the analog inputs. I consider that that pinout can be easily configured in software, while it was pain to route according to Jared's schematic. I hope you agree on that one.

One suggestion that would make it easier to reroute on the fly, or at least would allow some potential flexibility, is to make most IO routed through two vias, such that if it's discovered that some pins need to change, you can literally tear up a trace between the two vias, and replace it with a wire. This would allow that wire to route to another pin if so desired.

[Fred]

I'll keep the capacitors on the outputs as long as they don't add significant lags.

Why? You're just coupling your CPU references to the external connection on the other side of those caps, ie, you're generating noice that you don't need to. Ditch them on outputs IMO. I mean, fuck, input capacitance is one of the parameters upon which you CHOOSE various driver chips (bjts, fets, etc) by putting caps there on purpose youre screwing that up unnecessarily.

That switch on blip (damn, it took me a while to figure what it means :P), would happen only on the startup... if we keep the microcontroller constantly powered on the blip won't happen every time (btw, is the blip mentioned in the datasheet?)
I'm thinking about how often I have to reconfigure the radio clock, that would be the same frequency of pin blips, or am I wrong?

You could be right about that, yes. Radio clock, perhaps, yes. It's more about what happens if there is a cylinder with a good AFR mix in it when that happens, BANG, and at what crank angle? :-/

The 74hc parts would be of some time of enable/disable design such as the tri state buffer chips. The idea being that we can force control of all pins with a single other output pin that is known to behave predictably. The other part of the equation is that the pin state at default not running MUST be the same as when reset is held down or when the serial monitor is running, ie, during firmware load. If something gets inverted across these states then it spells fire/burned coils/injectors.

There is an early draft of the hardware compliance docs here, totally unfinished, though.

http://github.com/fredcooke/freeems-van ... ndards.odt
http://github.com/fredcooke/freeems-van ... ndards.pdf

I intend that every aspect be covered with recommendations, requirements, hints, etc.

The digital I/O pinout can be left for a while (not forever, tough), but I took the liberty of reallocate the analog inputs. I consider that that pinout can be easily configured in software, while it was pain to route according to Jared's schematic. I hope you agree on that one.

I may be able to be convinced, but right now if you asked me, I'd say no. I see quite a lot of value in having a standard set of pins that need to be connected to a standard set of sensors. I see a configurable IO to variable system for the core items as another way for noobs to be idiots and screw stuff up. I realise that we'll need code like that for the spare pins sooner or later, but even then, I don't know if allowing CHT to be on adc1.0 or adc0.1 by configuration is a good idea. You could convince me, though. Esp if we hide it in some advanced tab or something and it doesn't interfere with speed of running etc.

Fred, I want the board to be "FreeEMS compliant", so I'll agree on most of your recommendations. Just let me argue on some points, I need to know everything happening in the board.

Argue on anything, man :-) If I disagree, I won't cry, I'll just tell you why.

See me as a member of the team, I want to see FreeEMS completed. My problems are a not-so-vast experience, not much free time, and a crappy slow english, I hope you can bear with that.

Mate, glad to have you here, always have been :-)

Fred.

[jharvey]

I'll keep the capacitors on the outputs as long as they don't add significant lags.

Why? You're just coupling your CPU references to the external connection on the other side of those caps, ie, you're generating noice that you don't need to. Ditch them on outputs IMO.

It's kind if interesting that your concerned with the noise generated by digital signals routed through a 10 ohm driven 100nF cap. If it's a concern, they don't have to be populated.

[Fred]

10 ohm? what for? odd.

[nitrousnrg]

I'll keep the capacitors on the outputs as long as they don't add significant lags.

Why? You're just coupling your CPU references to the external connection on the other side of those caps, ie, you're generating noice that you don't need to. Ditch them on outputs IMO.

It's kind if interesting that your concerned with the noise generated by digital signals routed through a 10 ohm driven 100nF cap. If it's a concern, they don't have to be populated.

Thats why I didn't argue a lot about the capacitors... I don't think I would populate them in my first prototype.

That switch on blip (damn, it took me a while to figure what it means :P), would happen only on the startup... if we keep the microcontroller constantly powered on the blip won't happen every time (btw, is the blip mentioned in the datasheet?)
I'm thinking about how often I have to reconfigure the radio clock, that would be the same frequency of pin blips, or am I wrong?

You could be right about that, yes. Radio clock, perhaps, yes. It's more about what happens if there is a cylinder with a good AFR mix in it when that happens, BANG, and at what crank angle? :-/

The 74hc parts would be of some time of enable/disable design such as the tri state buffer chips. The idea being that we can force control of all pins with a single other output pin that is known to behave predictably. The other part of the equation is that the pin state at default not running MUST be the same as when reset is held down or when the serial monitor is running, ie, during firmware load. If something gets inverted across these states then it spells fire/burned coils/injectors.

I think this could be solved, someway.
For example, I see 3 situations where this can happen:
* When you connect the EMS to the battery.
* When there is a reset, or debug, or anything invoked from the PC through the serial communications.
* When you flash the microcontroller

Correct me if I am wrong, but I'm putting a constant 12v supply to the micro, and everything else is powered from a switchable supply. I mean, the mosfets drains will only see 12v if the switchable supply is switched on. I suppose that those switched 12v are present when the key is in the ON position.

So,
* When you connect the EMS to the battery:
You shouldn't have the key in "ON"!!
* When there is a reset, or debug, or anything invoked from the PC through the serial communications:
We could sense those 12v. If they are present, then it is not safe to perform a bootload/debug/reset. Ask the user to turn off the key.
* When you flash the microcontroller:
The bootloader flash should happen once, and again, there is no reason the have the ignition key in ON. (I'm not sure about the key naming in english, lock,park,on(?),start...).
I don't know what could I do to dodge this when the reset is hold down (btw, I don't have a reset button, put that in the compliance doc if you want one)

There is an early draft of the hardware compliance docs here, totally unfinished, though.

http://github.com/fredcooke/freeems-van ... ndards.odt
http://github.com/fredcooke/freeems-van ... ndards.pdf

I intend that every aspect be covered with recommendations, requirements, hints, etc.

Hey, that is important!
There are some hardware recommendations that could be put there, like the schottkys for the AN pins, or automotive regulators (LM29xx). But... in order to help on the pin out decisions, I need to take a closer look to the datasheet.

I may be able to be convinced, but right now if you asked me, I'd say no. I see quite a lot of value in having a standard set of pins that need to be connected to a standard set of sensors. I see a configurable IO to variable system for the core items as another way for noobs to be idiots and screw stuff up. I realise that we'll need code like that for the spare pins sooner or later, but even then, I don't know if allowing CHT to be on adc1.0 or adc0.1 by configuration is a good idea. You could convince me, though. Esp if we hide it in some advanced tab or something and it doesn't interfere with speed of running etc.

And, there is no need to change a single input pin. A more reasonable way would be to select which version of hardware you are using, so you are automagically changing all the pinout, in a single click. The hardware developer is in charge of distribute the correct pinout. Anyway, I wasn't thinking in the users, but in the guys who could make their own hardware. Really, its quite hard to route a random set of pins, at least when you intend to have a big, nice analog ground plane.

Btw, I almost ask "The" professor about the mosfet gate isolation, but the guy went home earlier today ¬¬

[nitrousnrg]

Fred, this post should/must be moved to another thread:

I started reading the datasheet, looking for those pins that have a non-GPIO function after reset.
If FreeEMS is going to function ONLY in "normal single-chip" mode, then all pins, except 2 (PE4 and PE7) are GPIO inputs. (page 888 of the datasheet).

In the other modes, almost 45 pins are used by default for something else, but:

Page 34:

Modes of operation:
Normal expanded mode, Emulation of single-chip mode and Emulation of
expanded mode are ony available on family members with an external bus
interface in 144-pin LQFP. See Appendix E Derivative Differences for
package options.

So the only mode available is normal single-chip, but I bet you found something else that makes the pins start on an undetermined state. Can you elaborate?

[Fred]

Good reading, but yes, you're right, and I know that stuff. There is already a thread to which I will move these two posts later. I suspected I was pulling some pins high or low during reset causing a temporary other state to ensue before other factors took control.

I've got a reply to your last post half written, it's been half written for a while now. Perhaps I'll complete it tonight, maybe :-/ sorry for the delay responding.

Fred.

[nitrousnrg]

No problem, I've been busy recovering my git repo. Stupid people do stupid things, so I spent the weekend fixing that (I did one "git reset" too much).

For the record: I changed a few things, the FT232BT is now a FT232RL, because it don't need an oscillator or external pull-ups. One thing to note: this IC can't stand 125°C while powered as the rest of the ICs. I'll make it take VCC from the usb, so it remains powered off if the USB cable is not connected. That way the board still can stand 125°, and there is one less thing to feed from the 5v regulator. I'm assuming that no one is going to plug the USB cable if everything is that hot.

The ignition circuit changed too:



The red capacitor is the result of my talk with the most experienced engineer we have at the university. It is a parasitic capacitance, and as a result of it, high frequency, high amplitude spikes can pass from the drain to the gate. He suggested me to isolate the IO pin, but as I can't find a 6-channel optocoupler, I'm putting a 6-channel RF isolator (yeah, I know, it is horribly wrong, but I wanted to see the board populated with something). If I can, I'll isolate the entire ignition circuit. I'll ask him if clamping is not enough. After all, automotive ignition drivers are clamped inside.

[jharvey]

Good note about the cap.

I know that IGBT's are commonly used for inductive drives because the duel layered construction offers both high current and high isolation voltage. So it's a kind of double fail safety device. A fatigue crack typically won't allow high voltage to propagate back through the device.

However the MOSFET's discussed in other threads, have Over Voltage (OV) protection that turns on the drain very much like the above noted cap. This OV protection also removes several problems caused by that "flyback diode"/"freewheel diode"/"snubber device"/"choose your terminology". When the collector to drain V exceeds a specific voltage, it drains a bit of current to the gate opening the channel. I believe this OV circuit has a fairly fast turn on time, so I would expect higher frequencies would pass, but I haven't tested them to see how they preform at higher frequencies. This cap may increase the response time of the higher frequency of a spike.

Did he have a suggested cap size, or design philosophy for selecting a component? I'm guessing it would be a fairly high voltage rating, with a fairly low capacitance. I would think the capacitance/construction style would want to be matched to the switching response of the MOSFET. I can also see some potential oscillation issues as MOSFET's are a high gain device. So I'd recommend some through testing of the circuit.

Adding pads for the cap certainly won't hurt anything, so I'm all for it, it allows tunning options and features.

[nitrousnrg]

I should explain it a bit better. The cap is inside the device, as a parasitic capacitance that appears when you make the model for the device. In a perfect world, that capacitance would be zero.
My questions were always started from a transistor driver, he said what should I do to avoid the problem, and then I asked what if the device would be a MOSFET or IGBT? Always, the answers were that with an IGBT I'd have better results but that I must isolate the logic anyway.

However the MOSFET's discussed in other threads, have Over Voltage (OV) protection that turns on the drain very much like the above noted cap.

Yes, but the gate impedance is quite high, all the current passing through the cap will go to gnd, or towards the IO pin.

This OV protection also removes several problems caused by that "flyback diode"/"freewheel diode"/"snubber device"/"choose your terminology". When the drain to source V exceeds a specific voltage, it drains a bit of current to the gate opening the channel. I believe this OV circuit has a fairly fast turn on time, so I would expect higher frequencies would pass, but I haven't tested them to see how they preform at higher frequencies. This cap may increase the response time of the higher frequency of a spike.

I don't think I want a device that under high voltage passes the problem to the coil. That would lead to a performance issue hard to spot out (IMO this couldn't burn the coil). The higher frequencies is an interesting test to do, I expect them to pass too, but I have no idea about how bad in magnitude they could be.

Did he have a suggested cap size, or design philosophy for selecting a component? I'm guessing it would be a fairly high voltage rating, with a fairly low capacitance. I would think the capacitance/construction style would want to be matched to the switching response of the MOSFET. I can also see some potential oscillation issues as MOSFET's are a high gain device.

Are you talking about the cap? I'm talking about the mosfet/igbt: The capacitor is bad, so the smaller the better, and the voltage rating, yes, it has to be high. In the classes, he usually uses a % of margin, but is application-specific. I'll ask him how many Volts this thing has to stand. The guy made an ignition controller based in logic gates and transistors, when the microcontroller wasn't invented yet(!), with temperature and load corrections, so he is quite insane in some ways. I hope I'm not getting the wrong idea from some of his concepts.

So I'd recommend some through testing of the circuit.

Yep, the plan A is to finish the board design, import the components, TEST the circuits, and then make and assemble the board.