Unsupported engine platforms (what is there?)

[AbeFM]

Seemed useful, Fred, do you want to continue on this one a bit when you have time?

(12:45:54 PM) AbeFM: speaking of which, what's wrong with 200 teeth, you just need the processor to deal with it - i.e. don't you think that's ideal co-processor (XGATE?) territory?

(01:20:29 PM) Fred : nah, the vr chips don't like the extra speed either... and xgate doesn't help you all that much when you need accurate inputs.

(01:30:46 PM) AbeFM: Oh, you think the VR chip is the limiting factor on number of teeth? I worry a lot about the tooth shape
What's wrong with the xgate? You're surprising me here

(01:38:46 PM) Fred : nothing is wrong with it, but you still only have so much accuracy when you aren't using a hardware timer to do your reading. It's that simple.
(01:38:49 PM) Fred : bed time.

(01:39:16 PM) AbeFM: They don't have access to the timers? Mostly I was looking for something to, on interupt:
1) Record the time of the tooth arrival
2) Update the tooth count
3) If tooth count greater mod 10 = 0, trigger main cpu intterupt

[thebigmacd]

Yeah I don't get why the XGATE is seen to be inferior for timing tasks...

The XGATE runs at twice the frequency of the MCU bus and is, therefore, a CPU with twice the bus clock
frequency. Most of the XGATE instructions take one clock cycle to complete, thus getting optimal
performance from the faster bus access. The XGATE CPU also has optimized instructions and a register
configuration to suit execution of very short routines with strong focus on efficient bit and byte
manipulation, so its performance for these types of interrupt handling tasks can be higher than the host
CPU. Indeed, in a like-for-like measurement of typical word, byte and bit manipulation operations,
performance is around 8 MIPS (million instructions per second) for the CPU12X (40 MHz bus) and 13
MIPS for the XGATE (80 MHz clock) — the co-processor has better execution performance than the main
CPU.

Many motor control applications require continuous input from position and velocity sensors. A
quadrature decoder may provide position feedback and can generate tens of thousands of pulses
(interrupts) per second, for small, rapidly spinning electric motors. This would be an ideal XGATE
function, as it can handle the interrupt event on each of the two sensors, to provide direction and position
changes, with no load being placed the main CPU.

The XGATE can provide a low-level driver function for many serial communications.
SPI operation in master mode is easy to achieve, as the clock and data are fully driven by the XGATE, and
only a timer is required to provide the baud rate.

I don't see how there is a disadvantage to xgate other than having to program it in assembly due to lack of free C compiler. It was intended for high frequency timing applications.

All input capture and timer interrupts can be configured to route to the Xgate.

[Fred]

(08:41:49) AbeFM: Mostly I was looking for something to, on interupt:
1) Record the time of the tooth arrival
2) Update the tooth count
3) If tooth count greater mod 10 = 0, trigger main cpu intterupt
(16:50:50) Fred: sure, if that is the only thing that is being done, but eventually it won't be
(16:50:56) Fred: comms are definitely going on there
(16:51:01) Fred: maybe other stuff too

The aren't inferior for timing, equal or better than the main cpu, but for input stuff there is zero point. You need to do something with that input when you get it and they DO suck at math with 16 or 32 bits.

Output/comms = yes, later
Input = not really

A big part of the point of this project is to keep it comprehensible to ordinary people at a code level. Wherever possible that should be the case. Good code is easy to understand, period. Easy to understand code in assembly is near impossible to write ESP when you have to code complex memory sharing routines etc without the compiler dealing with it for you.

[GrowlingandBiffo]

60-2 is best for lower rpm engines, for really high spinners 36-1 is a better choice. high/low boundary = 8k or so I guess.

Is it really down to a GM (60-2) vs Ford (36-1) situation?

If this is so why have not the Ford MotorSport apps gone this route?

The early Cosworth used the Weber/Magniti Marrelli IAW System 4-1 and then went to EECV which used 36-1.

No benefit is found 'tween the two Ford systems on the track or the dyno.

So if we cannot measure it...

[Fred]

Is it really down to a GM (60-2) vs Ford (36-1) situation?

No, only down to events pre crank rev required to get good accuracy and certainty during dynamic conditions.

No benefit is found 'tween the two Ford systems on the track or the dyno.

The majority of the time esp in higher gears and on dynos where load is fairly static by requirement you would not see a difference. It is under dynamic conditions that you need the accuracy, and dynamic covers first gear on many high performance street cars.

So if we cannot measure it...

You are right, ms1 works sweet, why have this site at all, I'll shut it down at the end of the week. Thanks for playing.

More seriously, why should I not strive to be the best? Not doing so is a poor way to live.

Fred.

[WTDeuce]

The 60-2 wheel is probably the smartest way to go, I've thought about it for my car as well.

Unfortunately the cheapest kit is $250 I think, plus the sensor. Price goes up from there for other kits.... Hence the overall desire for something thats compatible with the stock sensors.

[AbeFM]

The aren't inferior for timing, equal or better than the main cpu, but for input stuff there is zero point. You need to do something with that input when you get it and they DO suck at math with 16 or 32 bits.

Output/comms = yes, later
Input = not really

A big part of the point of this project is to keep it comprehensible to ordinary people at a code level. Wherever possible that should be the case. Good code is easy to understand, period. Easy to understand code in assembly is near impossible to write ESP when you have to code complex memory sharing routines etc without the compiler dealing with it for you.

-------------------------
More seriously, why should I not strive to be the best? Not doing so is a poor way to live.

Fred.

I'm still not seeing why it's not better to use the XGATE, for every reason save the assembly which I'm nearly on the fence about (but got at least one foot firmly on the ground on the C-ONLY side)....

But as to being inappropriate for counting high numbers of teeth? Why NOT have lots of teeth? You're talking cake-and-eat-it-too.

My little 4 tooth wheel is PLENTY for your average 4 cyl. You really only need two teeth, and then prediction is minimal. You know how fast the motor was going, and you know if it's accelerating or decelerating, and you know a few degrees before firing where you are.

And if you make the argument you need more teeth, then why not 100 + teeth? The *only* argument against more teeth is the computational load - since you know on most of those teeth you won't do anything. What you need is a high speed, RISC processor for going "how many teeth are there", and check one or two simple conditions, and go tell the main CPU what to do when something important happens.

There's no 948 bit floating point infinite sums in asking "are we 5 teeth or 6 teeth from the last time I called you?". There's not a lot of higher math in "is the time between the last two teeth greater or less than the time between the previous pair?"....


For code integrity, I could see not wanting to use XGATE. What does the non-free compiler cost? For that matter, is it one of those "it's no cost, but not free" things? I don't want to piss on anyone's parade, but it might be worth examining. If someone wants to SELL freeEMS, they'd have to pony up. If not, use what's out there? That gets philosophical.

Anyway, if it's truely that you think the XGATE will be worse at counting teeth and passing decisions along than the main CPU, please talk to that point. If it's a decision based on language or ethics, note that as well, then we can stop worrying about the technical validity of the approach.


Fred, I think this warrants a topic split? As far as engines with funky patterns, I'd still like to cover the topic of using the locator pin to block a signal to make an N-1 toothed wheel. (or perhaps N/M - 1 tooth)

[Fred]

I've posted about all this way too many times before. It's all around to read. To that end, so are threads for this purpose, dig one up and link it, no need for a split just yet.

I will say one thing (also already on the board), the non-free compiler is a bag of shlt no matter what the price tag. Much like windows costs $300 or so and is totally fcuking shlt whereas linux is free and is rock solid and fast and efficient and versatile and configurable and secure and and and and. Open source has huge advantages in many ways. Just look at mysql. That's commercial and yet fully open source. There is a reason for that.

Sorry for not engaging you, but I'm sure you understand. If not read the post in announcements.

[Einar]

Please plan on supporting odd-fire V6.

I acquired the VEMS hardware and used a lot of time to figure out how to handle this engine. In my case a Maserati V6. Then I found the platform was not open source anymore and the hardware landed in the junkbox. End of project!

Now I'll just watch this project and see where it heads. I will not at the moment invest my time in code. Ben there, done that, and got disappointed.

But I will engage in exchange of my meager knowledge on the odd requirements of the odd-fire V6, of which there are (was) several.

In short the ignition events are not evenly spaced. This is because the engine is a 90 degree engine with 3 crank throws of 120 degrees. Later designs got skewed crank throws so they can be "less odd-firing" but still not even-fire.

[Fred]

Please plan on supporting odd-fire V6.

That should be totally simple. As far as I can tell there is nothing special about odd fire engines other than the odd fireness. A good design up front takes care of such issues.

I acquired the VEMS hardware and used a lot of time to figure out how to handle this engine. In my case a Maserati V6. Then I found the platform was not open source anymore and the hardware landed in the junkbox. End of project!

When did you buy it? VEMS as such has never been truly open source. MSAVR was public domain (not licensed at all) but heavily infringed on B&G IP. It sounds like you didn't do your research very well. True open source can't go backwards. IE, I can never take away the right for someone who has my code with a GPL stamp on it to change and distribute that. The license the early vems stuff was under was pretty closed up...

Now I'll just watch this project and see where it heads.

Most welcome. It should be obvious after 10 months that it's no overnight fizzer though.

I will not at the moment invest my time in code. Ben there, done that, and got disappointed.

Sounds a bit sulky! Sounds a bit selfish too. If you were only doing it for a result you were destined to be disappointed. You need to be in it for it. Coding for the fun and satisfaction available.

But I will engage in exchange of my meager knowledge on the odd requirements of the odd-fire V6, of which there are (was) several.

That's what this thread is for :-) Start a VEMS sulk story in the lounge or non-free section if you want, or just lay out the specs required for it here and don't waste your time on that.

I hope you enjoy your stay :-)

Fred.