A little ECU interconnect schematic/drawing I made

[mobyfab]

Hey Guys,

I made a schematic for an ECU a while ago, I'm posting it here in case this helps you with hardware design

https://docs.google.com/drawings/d/11KJt6j751w4kpBhkQMWXHyvrCQrZi3s3k0uUYk5S9fs/edit?usp=sharing

This is the best compromise I could come with, but nothing has been tested, just ideas.
It's designed for a Honda motorcycle.

Feels free to ask me questions.

[AndreyB]

Why did you decide to go with a multi-CPU design?

In my opinion, this over-complicates the system A LOT. We are struggling to implement a single-core implementation, hopefully we would agree that a multi-CPU implementation is 10x times more complicated.

[mobyfab]

I like the idea of a TPU, but I wanted some universal/cheap solution.

I think using a chip dedicated to timing is a good idea, and really not that complicated since the code would be very basic.

You just send the values (ignition advance and dwell, injector pulse lenght) via usart/SPI, and the TPU takes care of it.
All pulses are done using hardware timers so you get the best precision.
You can do all the intensive processing in the other MCU and not affect timing at all.

In the end it's exactly the same as a TPU, except the chip is external.
I think it's by far the best option.

[AndreyB]

"I like the idea" is emotional, but not technical.

Interconnect does not come for free, there should be a specific reason why we would spend time implementing it. Ideally the reason should be measurable. Until we have a single-core implementation which we are unhappy with, I think it would be wrong to look at a multi-CPU option.

[mobyfab]

You're right, it's not something needed in all design cases. It's just the solution I like most.

If I was to design an ECU I would not allow an accuracy below 0.2 degrees at 20K rpm so it would be manadtory to use hardware timers.

Since there are a limited numbers of these, especially 32b ones, using 2 MCU sounds like a good option.

[AndreyB]

I would not allow an accuracy below 0.2 degrees at 20K rpm so it would be manadtory to use hardware timers.

Why?

I am not being an a--hole, I am just trying to figure out real constraints. Here are some of my arguments.
Good news: if we only need 0.2@20K accuracy for some actuators (say, only for ignition) - we probably can use hardware times for some actuators and use less precise timing for actuators with lower timing requirements.

Another point: why 0.2@20K anyway? Where is that number coming from? Do we really HAVE to be accurate EVERY time? What is we have 1 event off timer per hour? Per minute? Per second? Why? (if it's about knock - how often is your most efficient timing is located right next to your know timing?)

Bad news: we are so focused on output scheduling precession that we are forgetting - how would we decide when to fire perfectly? We do not have a perfect RPM value - say we only have a 60/2 wheel and constantly changing RPM, with just 120 event points over 360 that's a 3 degree accuracy of input plus some prediction based on what we consider to be current or expected RPM 3 degrees later. I am not sure we have a 0.2 degree accuracy of this precision anyway. With only some precision of planning an event we do not really need a higher precision of executing an event.

[mobyfab]

I never said you were an a-hole, or that you have to do as I say

0.2 is easily achievable with 32b timers. We have those so why not use them?
IMO ignition timing should always be predictable (at least withing a hard range). So 99.9% accuracy from the software point of view. Not a problem with hardware timers and interrupts.
Fuel pulses can drift by a few uS.

For the precision the idea is to setup the pulse timer at the second closest trigger wheel tooth from the event.
You also have to take acceleration and deceleration into account. These do not change so quickly at the scale of an MCU.

It's not because the precision is not perfect from the trigger wheel that we should not try to have the best of it on the processing side. These add up in the end.

[AndreyB]

Why 0.2@20K, not 0.1@20K or 0.4@20K? Why 99.9% accuracy and not 99% or 99.9999% accuracy?

I have a problem with magic random numbers. The sole fact that something is achievable does not seem to be a good reason to spend time on achieving it. I am just trying to stay real, so I am curious what are the real objective constraints and criteria we NEED to achieve. I know it's not a trivial question and there are no easy answers, but we'd rather not substitute it with random answers and random goals, we have enough to take care of in the real needs department.

So far I cannot agree with your idea.

[kb1gtt]

I have mixed feelings about the multi-core architecture. The timing critical chip can boot very quickly, while the higher level chip can boot more slowly. This can be handy for early detection of the crank angle. As well you generally want a monitor chip, so why not make that chip more useful than just killing the primary processor. As I see the schematic now, he's basically proposing using what we have as the timing critical, and separating off the higher level communications, long term tuning, ect into another chip. I see pro's and con's of a single chip solution vs a multi core. If I were to get my idealistic way, I'd use a dedicated FPGA or equiv for the simple time dependent tasks, then I'd use a micro for the higher level stuff. Preferably I'd use one of those chips with an ARM and FPGA in one chip. However that's not likely going to happen. So I have to deal with reality.

Some pro's I see of multi chip include that you probably don't need to validate the full software upon every software change. If you make some minor change to some minor high level code, like streaming of accelerometer information, you don't have to validate and verify that the change is not effecting the timing critical stuff. I also see getting more peripheral resources as a bonus. It seems you're always running out of those bits that are connected to the MCU, like ADC's, or DAC's. Also the high level processing will add a certain level of software jitter, while the timing critical stuff will add a different layer of software jitter. By placing this on a separate chip, you prevent the high level jitter from effecting the time critical software.

Some con's include the syncing of timing information with crank angle information. That's an issue with TPU's as well. How do you make sure that both sides don't access the memory at the same time, ect. This can be a massive problem with many sources of issues and many places for hard to squash bugs. For example, in the timing processor, will require live information and updates that are passed by the higher level MCU. This information will need to be passed to a UART, then the UART will need to store that information into RAM or some kind of memory table that's used by the timing MCU. What happens if an event happens during that UART write to memory period? You're going to be adding some hard to predict jitter. The multi-core option is very complicated and should not be taken lightly. I think this is why russian prefers the single processor option. He would prefer to use a faster chip before he uses multi core. As well the low $ we have has a great amount of capability with the speed it's clocked at now.

For each event let's ball park that it takes 1k cycles to process a timing based event. At 20kRPM 2cyl with 36-1 wheel, you'll have around 13k events in about 3mS. Or you'll need around 4MHz just to process the very simple timed events. That doesn't leave much processing room for calculating wetted wall adjustments, or adjustments due to knock or denotation detection. Let alone other things like communications with TS or gauges. To pump more bits you an add a MCU. You can also use a faster MCU. I think both are do-able possibilities. I would tend to think the multi core has more up-front work, but as things mature multi-core would require less work later in the dev cycle as the higher level stuff is getting more developed and the timing level stuff is not being developed. You wouldn't need to keep checking the timing code.

Any how, I see many options and I feel that the single core approach is a good approach. If you need more clock cycles, it can be ported to a faster MCU fairly easily and for low $. After all we are in an age with GHz processors. It would take around 125 processors running at 8MHz to get the same clock cycles that you would get out of a single 1GHz processor. Most engines can be easily run off an 8MHz MCU, so why not simply use the same everything, but clock the chip a bit faster to get the clock cycles that high reving engines need. The only long term benefit I see is with multi processor, is that you might have a pinch less development later down the road, which to me seems like a minor feature. I think using the single core will produce better short term results as it's easier to program.

Any how I have mixed feelings about the multi-processors architecture.

[mobyfab]

kb1gtt, you did a really nice explanation of the pros/cons.

For the sync, you can use mutexes and sync signals to the host to work around that problem.
The uart uses DMA so you can write to it while the MCU is busy and not lose any data.

Russian, 0.2 because it's the same value as some commercial ECUs and more precision would probably not make any difference. (Old Hondas have .25, AEM EMS has .1 for example)
20K because some bike engines go up to 18K.

I don't see a reason why we should not try to make the best performance possible, given it's not overly complicated or completely useless.

Does your phone needs an ultra HD screen or even faster octa-core processor? Nope.
It's called progress and it's what drives us.

[UnaClocker]

This isn't a contest of who has the best stats. We win by default simply for being a fully open source project. Nobody else has that. .2 degrees at ANY RPM is beyond pointless, besides the already stated point that the trigger wheels don't have that kind of resolution, there's a 3-4 degree window even at peak tq/hp that won't show any power changes on a dyno, if not larger in some places and on some engines. That's one of the steps in dyno tuning, is to find that spot where increasing timing no longer increases power. Then you know you've found the optimal advance for that point on the map.
Comparing to phones is a great example why not to do this. You're right, you don't need a 1080p screen on your phone, Apple explained that several years ago when they came out with the maximum number of pixels per inch that your eye can detect. Beyond that is simply marketing to the people that can't understand physics. Meanwhile, they phone manufacturers neglect truely important things, such as battery size. And that equates to this nicely as well, you'll have us chasing this .2 degree rabbit down it's hole meanwhile we don't have closed loop idle control, or even speed density at this point in time.
It's important to keep real achievable goals in mind. Sure your system might be a great college project or something, but it's only going to sidetrack this particular project.

[kb1gtt]

I agree that the mystical .2 degree desire is a bit elusive and not really very important. What is more important is knowing what it is, then making sure you tune with that in mind. For example, you may have that .000001 degree accuracy at low RPM, but at some point you approach .2 degree then at higher RPM you'll be less accurate. If you discover during tuning that you are approaching detonation before you have peaked the power, you generally look to back away from that detonation barrier by some amount of angle. If you don't back down, you'll find issues like a Fred did with his little red truck in NZ. Basically he was detonating which caused the cyl pressures to get to high and it eventually had an alternator problem. The crank shaft removed the place that the alternator is mounted. Detonation doesn't just burn a hole in a piston, it can do other nasty stuff as well. Lets say you have decided to back down from the detonation barrier by 1 degree. If you know the tolerance of the crank angle is .2 or .5 or what ever, you will probably retard by 1.2 or 1.5 degrees instead of 1 degree as you know the tolerance will violate the desired 1 degree rule. However if you if you tune for 1 degree and it's really .9 degrees, I don't think anyone will care. I use that .2 degree tolerance as the point where I start to care if I should consider that tolerance in tuning. A tolerance of above .2 degree simply means I may have to pay attention to it when tuning. Which is not a big deal.

I see knowing the tolerance as more important than the actual tolerance.

[mobyfab]

This is not the only open source ECU project.

This isn't a contest ... We win

Right... Contradictions?

Just as a reminder, since some people seem to forget:

I made a schematic for an ECU a while ago, I'm posting it here in case this helps you with hardware design

kb1gtt, you get the point
It's also about the confidence of using an accurate system.

When I set 40 degrees of advance I know that my timing will be between 39.9 and 40.1, which is nice when you have to work around detonations.
Now .5 would probably be enough for most people but it's not any harder to do .2 or even .1 with timers, so why not?

[UnaClocker]

Right... Contradictions?

Ahh, you're just a troll. I'm done feeding the troll.

[Rhinoman]

I don't want to fill the Power Supply thread with unnecessary talk. Which Honda motorcycle do you have?

Your schematic reminds me of the old Suzuki Swift ECU which used which used a separate timing processor (UPP) in the days before the integrated TPU.

[mobyfab]

2007 CBR600RR.

I run a 2014 HRC (basically Moto2) ECU for now, it's a lot better than stock but it's still years behind the current production (like 2015 R1) stuff.
There's only fuel/ignition/staging offset tables, engine braking and couple things like pit limiter.

The idea behind this design is to have as much stuff implemented in hardware as possible while still using general purpose MCUs (so that they can be replaced)

Here's a slightly updated design:
https://docs.google.com/drawings/d/11KJt6j751w4kpBhkQMWXHyvrCQrZi3s3k0uUYk5S9fs/edit?usp=sharing

[kb1gtt]

If your goal is 0.2 degree crank angle accuracy. Is that +/- 0.1 or is that +/-0.2?

If you use +/- 0.1, during your tuning you will likely push until you get an issue, then you'll back off by at least 0.2 to guarantee you are safe, then you might decrease by another 0.2 just to give you some safety as you get carbon build up, variable MCU output delays, etc.

I wonder what variation in HP do you get if you back down by 0.1 degree? Then the same question for 0.2 degree, and 0.4 degree's.

[Rhinoman]

I found some pictures of what I think is the OEM ECU here:

http://www.600rr.net/vb/15-general-discussion/296313-ecu-resets-dynos-etc.htm

I don't see any heavy duty load dump protection so you may have a clamping regulator or the time constant of the alternator field coil is quite short.

[Rhinoman]

If your goal is 0.2 degree crank angle accuracy. Is that +/- 0.1 or is that +/-0.2?
If you use +/- 0.1, during your tuning you will likely push until you get an issue, then you'll back off by at least 0.2 to guarantee you are safe, then you might decrease by another 0.2 just to give you some safety as you get carbon build up, variable MCU output delays, etc.
I wonder what variation in HP do you get if you back down by 0.1 degree? Then the same question for 0.2 degree, and 0.4 degree's.

I would think that variability of fuel would be more of an issue.

[mobyfab]

If your goal is 0.2 degree crank angle accuracy. Is that +/- 0.1 or is that +/-0.2?

If you use +/- 0.1, during your tuning you will likely push until you get an issue, then you'll back off by at least 0.2 to guarantee you are safe, then you might decrease by another 0.2 just to give you some safety as you get carbon build up, variable MCU output delays, etc.

I wonder what variation in HP do you get if you back down by 0.1 degree? Then the same question for 0.2 degree, and 0.4 degree's.

There's no real "pushing it" or output delay with hardware timer outputs.
I just have to adjust the timer frequency, and since it's a 32b timer, it can go pretty high in the Mhz range without wrapping at low RPM.

The only change that would have an impact on cpu load is when I set the timer OC register to choose when to trigger the pulse. I don't have to stop the pulse afterwards as HW does it too.
I would need to do that as late (last CKP tooth) as possible to get the best accuracy, but then again with a 72Mhz cpu dedicated to this task, I can make it pretty accurate, especially since I would run these functions from CCM ram.

in the end 0.1 or 0.2, it doesn't matter and can be easily achieved.

I found some pictures of what I think is the OEM ECU here:

http://www.600rr.net/vb/15-general-discussion/296313-ecu-resets-dynos-etc.htm

I don't see any heavy duty load dump protection so you may have a clamping regulator or the time constant of the alternator field coil is quite short.

There are some here as well:
http://ecuhacking.activeboard.com/t48137614/07-600rr-m32r-keihin-hacking/