jharvey wrote:I've added two 74HC86's for inversion with 14DIP300 as the footprint. 2 RPM inputs and 6 ignition outputs.
Good call! :-) I like it.
I'm not currently planning on the opto. Thoughts? I'm concerned about variable delays, and don't see what it is needed for. If someone wants to run directly off the coil, rather then off hall, or VR, they can isolate it them selves, as far as I'm concerned.
Yeah, I agree with this, however what about diode protection on the input to the XOR then? It would be nice if a "12v" (up to 15 or so) trigger would "just work" without conditioning it first. BTW, dizzy folk can also write their own decoder as it's a pain to do it well for a poor result at the end... triggering from a coil is a bad plan and should be discouraged anyway.
About the digi protects, I plan on leaving them, as they do make it more rugged. I don't see why parts will need to be populated however. I'll likely jumper across the resistors and leave other components empty. My biggest concerns where with the ignition drivers and isolation.
Fair enough, I guess. Do use a series resistor though, excess current from the CPU pins WILL cause it to lock up, sometimes hard with outputs in random states that are fixed till next reset. 4mA per pin is max continuous.
Fred wrote:Yeah, I agree with this, however what about diode protection on the input to the XOR then? It would be nice if a "12v" (up to 15 or so) trigger would "just work" without conditioning it first.
Scratch scratch? So your saying if you have a hall or similar tach signal that is 12v instead of 5v. Resistor divider comes to mind first.
I'm sure we'll chat about this in the freeEMS thread.
Resistor divider doesn't really cut it though. during cranking you want 50/50 to get 5v from 10v, but during an alternator unloading (switch off the fan or something) you might get momentary 20 and feed the chip 10v...
zener + resistor could work, as could dual diode setup like the others.
Also, those inputs need provision for pull up or down. 5v only should be fine for up I guess.
Can we have a single I/O port software assignable 0 or 1 to feed into 1 port of each 4077 XNOR gates.
nothing complex required just 0 or 1 as set in the tuning software and held in that state until re-configured as a startup setting it must take on its active state immediately or risk burning out coil packs.
The other option is a 3 pin jumper to select rising or falling trigger for the coilpacks, but i thought it would be all the slicker if it could be hardware selected.
Yes, the idea is to use the fuel pump output for this purpose. Basically as long as we can trust the fuel pump pin in all states then we can use that to ensure the ignition pins are in a safe state during reset/bootload. As for configurable polarity, no way, that is the point of this thread. It should be solder selected once and not change in software :-)
A comment: RPM input should be in a interruptable pin, usually configurable as falling/rising edge. So far, in the schematics, RPMinputs are conected to PIT pins; afaik, PITs ony trigger interrupts on timeouts (not useful here), and you need an edge driven interrupt (port H or J, which do have programmable rising/falling edge interrupt) to keep the timing of a missing teeth configuration.
If it's set to interrupt on BOTH edges, then you need software to understand which is which, and if the signal is inverted you need to do the same thing, hence the h/w comments. I forget the agreed outcome, but if you've read the thread to the end you'll be able to educate me.
1. I didn't mean both edges. In this case, you must interrupt either on rising edge or falling edge.
* If you're using the Enhanced Capture Timer (ECT), then you can configure it to interrupt on rising, falling, or both edges. Page 325 of the datasheet.
* If you use port H or J, you can select interrupt polarity too. Not for both edges, but its still useful. Page 872 of the datasheet.
In both cases, there is no software overhead.
2. I think I said this a while ago. Dave suggested the same a long while ago:
We have a problem if ignitors/injectors/fuel pump/whatever becomes energized during bootload/reset. Also, freeems has a separate 12v supply, one for cpu, other for ingnitors, injectors, etc.
So, being sure the key-switched 12v are off, we wouldn't have any unwanted triggering!
Two implementation proposals:
* PC: I wanna use your booloader bro. (reset applies too)
FreeEMS: Ok, I'm ready
or
PC: I wanna use your booloader bro.
FreeEMS: Hell no! Tell your dumbass user that the switched 12v are on. Things can go really bad if he/she performs a bootload/reset right now.
This is useful only if the bootload can be performed from the PC without touching the LOAD/RUN switch. I mean, totally software-based.
if not, the second proposal:
* Big, red warning saying: "Turn off the switched 12v before resetting or switching to (boot)LOAD mode".
Cons I'm aware of:
A. One could forget to switch it off. Maybe warning the user always before a bootload could be a way to go. Or tie the LOAD/RUN to the switched 12v
if(12v_present)
dont_let_the_switch_be_in_load_mode();
(but hardwar-ish, simple pull down or pull up circuit using 2 resistors)
B. Hard resets/failures are hard to dodge. A sustained reset with 12v switched on will blow things up. The reset button could be pulled up just like the LOAD/RUN switch, though.
C. PITs only trigger rising edges.
D. You don't want to let the user configure the ignition polarity by software configuration.
IMO 4 resistors are simpler than one or two XOR ICs.
With respect to 1, for some "wheels" it is unacceptable to only use one edge. Mazda miata for example has four slots, and thus you want to use both edges of all of them to get more frequent position and speed information from it. In that case you either need a software overhead, or a hardware configuration. There are no other choices. I prefer the hardware configuration thing because for any given install you do this ONCE and it only works if it's right. And, for any given install you'll update firmware, mess with settings, save, restore, fiddle, try some branch/fork, etc regularly. IE, the opportunity for trouble is extensive, and ms users have been a great test group for this type of stuff. Where ms failed, we will not, learning from their mistakes.
As for bootload switch stuff, it can't be done without a physical switch. And the dumb user might switch it any time, and we can prevent that from catching fire to stuff pretty easily with hardware polarity selection. So we will, for the fuel pump, it's not required, as always it will be a relay working the same way, but for ign it is, due to different setups. For fuel, not required. For general IO, up to the user/board designer.
I'd really rather have hardware config for RPM/Ignition than the compexity in code for RPM or the fire hazard for ignition. This stuff is going to become part of the FreeEMS compliance document for sure.
And, the secondary 12v supply will probably kill power to all sorts of on board stuff like comms chips etc, anything that isn't the pin that enables the chip to wake up again. That stuff is yet to be designed/finalised, though.
