Daily WTF

[MotoFab]

That is more like it! Maybe we can be friends afterall.

Now, the 8 control lines from the router processor also need limiting as well. But - there is simply no more room left on the board for 8 resistors. So, we are using a little trick. The HCS12 processor ports can be configured as inputs or outputs, and there are internal 50K pullup resistors (really current sources). So what is done is to run the HCS12 in "open-drain" mode. What is done is to set the output register to zero. Next, the pull ups are enabled. Then the data-direction register on the HCS12 is used to control the output. For a logic zero, the port is configured as an output, and since there is a zero in the data register the output is a zero. For a logic one, the data direction register sets the processor port as an *input*, so there is no drive - but the pullup resistors raise the output port to 5V. The pullup resistors limit the current flowing into the CPLD, and we are good.

There are NO resistors between the 8 outputs and the CPLD inputs. The inputs are 3.3V and the outputs 5V. The software is configured to be in pullup/input mode to control these pins. In the event of the software being misconfigured to output mode again by a well meaning programmer there will be at the very least excessive heat from both cores and at the worst, both cores will lose a pin to over current.

The ignition and control lines from the two C32 processors are 5V, and just hooking them up to the CPLD would not be good. The CPLD has internal body diodes that will sink/source current if the input is below 0 volts or above 3.3V. Feeding 5V into the 3.3V input would turn the body diodes on and without any current limiting the Altera would overheat from the free-flowing current. So, the two ignition channels from the MSII processor route thru series resistors to limit current, and to keep the risetimes short.

This is what I was replying to.

- Jim

[Fred]

Now, the 8 control lines from the router processor also need limiting as well. But - there is simply no more room left on the board for 8 resistors. So, we are using a little trick. The HCS12 processor ports can be configured as inputs or outputs, and there are internal 50K pullup resistors (really current sources). So what is done is to run the HCS12 in "open-drain" mode. What is done is to set the output register to zero. Next, the pull ups are enabled. Then the data-direction register on the HCS12 is used to control the output. For a logic zero, the port is configured as an output, and since there is a zero in the data register the output is a zero. For a logic one, the data direction register sets the processor port as an *input*, so there is no drive - but the pullup resistors raise the output port to 5V. The pullup resistors limit the current flowing into the CPLD, and we are good. until someone puts a logic 1 in the data register or similar.

And this is what I was referring to ^

Fred.

[MotoFab]

And this is what I was referring to ^

Yea I see that. That 'open drain' configuration is about as common of a voltage level shift method as anything. Without using discrete components that is. Maybe they'll be room on your board to use discrete resistors.

[Fred]

And this is what I was referring to ^

Yea I see that. That 'open drain' configuration is about as common of a voltage level shift method as anything. Without using discrete components that is. Maybe they'll be room on your boards to use discrete resistors.

Fixed it for ya :-)

Fred.

[AbeFM]

Finally - all this time I had no idea what this whole thing was about.

Yeah, saying we did it wrong because there wasn't room doesn't make it right. If it's super well documented, maybe it's ok, but so far most things you're supposed to "know" not to do in the MS world are secrets only those in the inner circle know about. I've run across these issues myself, many times. It's not a good practice to have something on the verge of breaking like that.

Of course, when it's your design, your code, and all closed source, you do whatever you want. If it were me, I'd relay out the board again and again till I got it. Make the board bigger, cut the size of other components, use a multi-resistor chip.... I'd rather lift pins on the cpu and install small resistors below each pin than ship something like that as "user programmable".

Or, I'd test it and show that it doesn't burn up. Maybe a heat sink will do you.

[MotoFab]

Yeah, saying we did it wrong because there wasn't room doesn't make it right. If it's super well documented, maybe it's ok, but so far most things you're supposed to "know" not to do in the MS world are secrets only those in the inner circle know about. I've run across these issues myself, many times. It's not a good practice to have something on the verge of breaking like that.

It isn't really that they did it wrong, or that it has anything to do with MS code. It more has to do with what you were saying about "things you're supposed to know". Features that are sort of generic to nearly all small controllers.

The practice they used of 'writing to the data direction register' is as old as integrated logic. The practice is sound and proven, and in every controller databook. It may not be spelled out as such, but instead implied by the description of the I/O port architecture. The word 'flour' on a plain white bag implies bread, but only if you know what bread is.

It's good if designers can provide all the information to the user base. And in this case, to me anyway, they did. But every member of a user base doesn't have the same knowledge going in. Because of that it seems like 'information is withheld', even if all the information is given.

Adding and removing, or building in this or that, is the same process with hardware or software isn't it? Documentation can be provided, but if the reader doesn't have various 'core data' then the documentation isn't as useful to the reader.

As far as any particular add-on design goes... If you're free to do another board layout or to use different components, sure, do that. If you're free to rewrite the software, great. Though if an add-on must be designed to fit with existing parts, enclosures, or code, then documentation to explain how it works is as common as bread. It's just like with code, if some parts of the subject aren't well understood then the documentation or comments may not help.

For me, it's that way with higher level languages. My basic understanding of programming logic lets me see the general idea of the program flow, but as to the specifics, like you I do not know if a coder is doing something that makes sense, or is writing a hack.

You fellows are doing a ground-up design that for the moment is still a twinkle in your eye. I feel that. Enjoy the honeymoon. Truly. Don't hate the pimples on the other guy's girl, yours will have them soon enough.

- Jim

(EDIT: Significant rewrite, for clarity.)

[shameem]

I went WTF!!! for a while when i read this -
http://www.msefi.com/viewtopic.php?f=30&t=32038

[Fred]

Don't hate the pimples on the other guy's girl, yours will have them soon enough.

Don't be so sure about that. At least, not from a software or grounding perspective. Those aspects will be done 100% right from the word go. Open design will help ensure this is the case. All things have faults, and all things are compromises, however there are certain areas that should never be compromised significantly. Peer review is VERY powerful in this respect.

(EDIT: Significant rewrite, for clarity.)

Thank you for this note!

I went WTF!!! for a while when i read this -
http://www.msefi.com/viewtopic.php?f=30&t=32038

Curious. I've heard of issues where the MS won't run with the cable plugged in (due to the pins on the db9 being wrongly connected), but not the opposite. Were you wtfing at Matt's resistor values? I was. Those are horrendously low.

The value it needed was pretty large - I'd settled on 160 ohm as a value that usually worked, but it didn't always. IIRC, a 100 ohm resistor wasn't able to communicate with it and a 330 ohm resistor wasn't enough pull-up to avoid the problem.

Hmmmm.
One must wonder if the refusing to work thing is common to all serial setups or not. It seems like it must be constantly interrupting to receive the data which ends up all zeros? However I'd need to look into the docs further to know for sure if there are other possible reasons. Such behaviour *could* affect us the same way if that is how it is happening. Interesting stuff.

Fred.

[Fred]

The MonoDevelop 1.0 Beta 3 release (0.18) has been updated with a couple of minor bug fixes, and re-released as 0.18.1.

Compare that (correct) approach with Ken's :-)

Fred.

[Fred]

Right now for RPM calcs on ms2/extra, we add up all the tooth intervals from the period (90 deg on v8, 120 on v6, 180 on 4 cyl, etc..) and then use the added-up value to calculate RPM so that RPM is calculated once per period. I don't see anything wrong with calculating it using that method, so we'll probably stick with that, making this a non-issue.

Sigh... I have to say, I'm surprised by this. I was expecting that it was done on each known signal location or at least once per ignition event. Certainly that is what we will be doing.

I originally had the code calculating RPM once per tooth, but that caused a pretty large amount of RPM jitter at steady state.

Sigh, isn't the obvious thing to do sample once per firing event? It seems to me like that would give you the best of both worlds!

Fred.