who wants to port to Power Architecture?

[Nobody]

As for what NOBODY said... I'm trying to separate the sarcasm from the factuals.

Yes, that was sarcasm laden LOL.

Oddly every TPU function I’ve worked with to date has worked as advertised. Some require more effort/knowledge to configure correctly than others.

To your other point, without using TPU, yes it’s a bit of a waste. Although the 24 channel, 24 bit eMIOS comes with many benefits. ADC with built in knock detection doesn’t hurt much either.

[kb1gtt]

Have you gotten it to work well with a Hall or VR real world sensor on a single cyl engine?

Have you gotten it to work on a V8 with a 36-1-2 wheel? I don't have any thing close to a 36-1 wheel, so I can't play with the stuff unless I get a dedicated engine, or do very significant modification to an engine that currently has other purposes.

I seem to recall that the 5634 only has 2X ADC's, then it's muxed to several pins. ADC muxing creates many interesting issues, which makes it reasonably hard to get fast or accurate readings.

I agree that with out the eTPU, the 5634 is just another slow and expensive micro. The eTPU's are good as they have low latency IRQ capabilities.

[abecedarian]

As for what NOBODY said... I'm trying to separate the sarcasm from the factuals.

Yes, that was sarcasm laden LOL.

Oddly every TPU function I’ve worked with to date has worked as advertised. Some require more effort/knowledge to configure correctly than others.

To your other point, without using TPU, yes it’s a bit of a waste. Although the 24 channel, 24 bit eMIOS comes with many benefits. ADC with built in knock detection doesn’t hurt much either.

The main (my opinion) benefit of eTPU is that once set, you can mostly forget it unless you need to update something with the angle clock or trigger events type of things. Mostly same with eQADC, where you can set a sample sequence and let it run DMA to other variables you want to work with, or as you mentioned decimate and process for knock detect. However, taking the angle clock away from core timers releases the core to do a lot more. There's something to be said about a timer that can service GPIO and account for crankshaft angular acceleration and deceleration, on its own.

[abecedarian]

Have you gotten it to work well with a Hall or VR real world sensor on a single cyl engine?

Have you gotten it to work on a V8 with a 36-1-2 wheel? I don't have any thing close to a 36-1 wheel, so I can't play with the stuff unless I get a dedicated engine, or do very significant modification to an engine that currently has other purposes.

I seem to recall that the 5634 only has 2X ADC's, then it's muxed to several pins. ADC muxing creates many interesting issues, which makes it reasonably hard to get fast or accurate readings.

I agree that with out the eTPU, the 5634 is just another slow and expensive micro. The eTPU's are good as they have low latency IRQ capabilities.

True that the 5634M has 2 ADC modules, but it also sports ~12 bit accuracy at 1MS/s. So sequenced properly, you can get better than 0.05v accuracy given a 0-5v supply, which is better 'accuracy' than an MPX4230 MAP sensor can claim with 1000x longer latency.

[AndreyB]

Giovanni from Chibios has mailed me http://www.st.com/web/catalog/tools/FM116/SC959/SS1675/PF259196
And it looks like Code Worrier (limited to 128K code edition) is the only free compiler Not great.

[Nobody]

With that board you will need a JTAG programmer, if you choose Freescale toolchain then you’ll have to buy P&E JTAG or similar at about $275, if you go with ST toolchain then JTAG will run about $100. They purposely try to lock you in…

Also 128K gets eaten up quickly, I’m at ~310KB, no data tables are hardcoded and still a ways to go. As an example ~18KB is gone just getting fully loaded TPU configured and running (function set dependent).

[kb1gtt]

XMOS comes with more cores, faster IRQ's, and a free compiler, for a lower cost chip. Why not use an XMOS chip instead of this older FS chip. I would bet chibios would port fairly easily to XMOS.

[AndreyB]

I would bet chibios would port fairly easily to XMOS.

That's the part which I really doubt It's not just the scheduling kernel but also the HAL - hardware abstraction layer.

Here is a random list of RTOSes showing that not all of them have HAL/drivers http://stm32discovery.nano-age.co.uk/stm32-resources-and-links/open-source-real-time-operating-systems-for-the-stm32-and-cortex-m3-mpus

[kb1gtt]

Both are the same ARM core, so most of the HAL should work. You would need to change external peripherals things like GPIO pins and perhaps some stuff with timers / ADC's. However the major parts of the core are very much the same I think. As well I understand that different compilers handle IRQ's differently, so you might need to deal with those low level bits as well.

[Nobody]

.

[clcorbin]

Also the FS provided code is only for wheels like a 36-1, and does not support 36-1-2 or any other wheel.

FS just updated the crank eTPU code recently. I haven't dug into it much at this point, but it does state that it supports user defined tooth patterns. from AN3769:

Support for wide range tooth wheel configurations

• Up to 255 teeth on the wheel are supported
• Between 1 and 3 missing teeth are supported

From AN4907 (the new application note on the new engine control set:

"The original Automotive eTPU Function Set, called set2, was released as AN3768 and AN3768SW at
http://www.freescale.com in 2009. It consists of five eTPU functions.

• Crank and Cam (together as Engine Position driver)
• Fuel
• Spark
• Knock Window
• Tooth Generator (for testing only)

These functions were capable of driving port injection engines. Modern direct injection engines were not supported. Also, the
range of supported crank & cam patterns was limited.

The new Engine Control eTPU Library overcomes these limitations. It aims to serve as ready to use functions for automotive
applications. Moreover, it brings the eTPU code for developers to make them understand or even to modify the code for their
specific needs.

The new Crank and Cam eTPU functions are generally able to synchronize to any crank and cam signal pattern. A crank
wheel with multiple gaps, with an additional tooth instead of a gap, and also multiple cam signals are supported.
The new eTPU function Direct Injection is dedicated to direct solenoid injection drive. The function is able to generate a
pattern of synchronous angle or time based output pulses on several output channels, including common bank channels and
individual injector channels. For a closed loop solenoid current control, this function can provide the timing for either an
external (MC33816) or internal (Reaction Channel) closed loop logic.

The updated functions of Fuel, Spark, and Knock Window are ported to new coding style, which is MISRA compliant, easy
to read, reuse, and modify. The functionality is slightly extended from the original set2 versions."

I haven't dug into using these functions yet. This micro is a long way from the 8-bit AVRs I usually play with, so right now I am working on making a bunch of LEDs flash using the eTPU on my TRK board. But, you might want to look into the new set before you write off the engine control eTPU code.

Clint

[AndreyB]

Clint, thank you for some fresh info and welcome to the forum!

[kb1gtt]

Hello Clint, I think this is long time no speak

Thanks for the content. Do you happen to know how well it handles real world jitter? We had a couple uS or perhaps it was nS of jitter in the real world from the hall sensors self adjustments. This jitter made it very hard to get sync. I fear that this software may work on the bench, but then fail when we go to a real world signal like it did in the past.

I'll try to get some time to read those app notes.

[jedediah_frey]

It looks like they made some major updates to how it worked based on user feedback.

Also the ability to do DI injectors means it may work for my PD TDI project (if I ever get to that).

[kb1gtt]

I found the IO board for the TRK board. If someone is interested in playing with that board I can offer this for dev purposes. It has several injectors, 12V to 5V supply, MAX9926, CAN, and all the typical TPS, MAP, ect sensor inputs. It also has lots of nice jumpers that allow you to do things like connect the generated CAM/Crank to the input CAM/Crank.

[clcorbin]

Hello Clint, I think this is long time no speak

Thanks for the content. Do you happen to know how well it handles real world jitter? We had a couple uS or perhaps it was nS of jitter in the real world from the hall sensors self adjustments. This jitter made it very hard to get sync. I fear that this software may work on the bench, but then fail when we go to a real world signal like it did in the past.

I'll try to get some time to read those app notes.

I haven't played with it at this point. I decided to go back to the basics with the TRK board until I understand how things work in the eclipse/codewarrior world. While I had a decent "feel" for what the code in o5e was doing, that did NOT include all the initialization stuff that was so different from my AVRs. Time to resolve that.

I'm also slowly working on the schematics and board layout for my controller. I've tried to take a middle ground approach and not get quite so sucked up into making everything PERFECT like o5e (which is what killed it). Instead, I'm shooting for "it works in MY application."

As for a nS jitter causing a failure to sync, I have a hard time with that one. At 6000 rpm and with a 60 tooth wheel, you are talking about 166.6 uS between teeth. No way in hell will a 0.001% jitter effect sync. Hell, it won't even be able to SEE that small a jitter as the timers don't have that good of resolution. Even a couple of mS shouldn't impact things much as you are still in the 1% range or so. Engines accelerate and decelerate between engine pulses a LOT as it. Personally, I would be looking at something else causing it.

But, with that being said, not my engine and I wasn't there, so hell, maybe it WAS jitter! I guess the real test would be to put a wheel on a single cylinder engine and see if it can sync that that beast.

Also, I don't plan on using a hall sensor. I really like the MAX9924 VR chip. I played with a little homemade board of mine and a metal lathe. With a 36-1 tooth wheel I built for my XS1100, that damned thing was putting out a perfectly synced square wave signal at 120 rpm! I could barely SEE the sine wave from the VR sensor on scope, but that little chip was locked in. I also had the sensor clamped to the cross slide and had it about 1.5 mm or more from the wheel. It could have been much closer and gotten much high voltages, but there was no need. It just worked. After that experiment, I pulled the pull-up pads off of the PCM schematic as I saw no reason to plan for hall sensors.

Oh, one thing that did help was my wheel was very well made. I made it on a mill using a rotary table, so I have very square, sharp teeth on it. And, it is 3/16" wide, so the teeth have lots of iron in them and it is round to better than a thousandth of an inch (lathe turned blank).


Clint

[AndreyB]

I decided to go back to the basics with the TRK board until I understand how things work in the eclipse/codewarrior world. While I had a decent "feel" for what the code in o5e was doing, that did NOT include all the initialization stuff that was so different from my AVRs. Time to resolve that.

Clint, if you are trying to figure out the board initialization - is there any chance you would want to figure out the settings to run ChibiOS on the TRK dev board? I believe you would need to use the time-limited compiler they currently support, and porting the initialzation to Code Worrier would be the next step. See http://forum.chibios.org/phpbb/viewtopic.php?f=19&t=1655#p16024

[clcorbin]

No promises on when I could get to it. Plus, I have zero experience with ChibiOS as well... But I will take a look at it.

Clint

[Nobody]

ChibiOS does run on TRK board, tested it last year. As mentioned elsewhere on this forum you will need to purchase ST JTAG programmer.

I asked on ST forum about eTPU support, got the we have no plans for it at this time. Also ST SPC5 studio is c and not c++. It had/has issues with e200z335 core, code size is unusually large, they have optimized compiler but not sure if it is completely fixed.

SPC5 drivers are incomplete for 563xM, no eTPU, eMIOS lacking most functionality, ADC also lacking. Basically what you really want that chip for is not directly supported.

[AndreyB]

ChibiOS does run on TRK board, tested it last year. As mentioned elsewhere on this forum you will need to purchase ST JTAG programmer.

Did you have to change anything in the board file? Do you have the board file for TRK?

Also ST SPC5 studio is c and not c++. It had/has issues with e200z335 core, code size is unusually large, they have optimized compiler but not sure if it is completely fixed.

Wow Sounds like Code Worrier port of ChibiOS is really needed.

SPC5 drivers are incomplete for 563xM, no eTPU, eMIOS lacking most functionality, ADC also lacking. Basically what you really want that chip for is not directly supported.

Since SPC support in Chibi is sponsored by ST I hope that there is a chance to get some improvements once there is some audience. But overall you are painting a pretty depressing picture

I want my java on ARM and SPC

[Nobody]

Did you have to change anything in the board file? Do you have the board file for TRK?

I just edited startup code, from memory XTAL PLL startup and few other things needed to be changed. You also need to change JTAG jumpers on the board.

Wow Sounds like Code Worrier port of ChibiOS is really needed.

CodeWarrior for evaluation edition is C and not C++. C++ is payware, but at least you pay once and not 1 year license for SPC5 studio compiler. I have payware versions of both, kinda regret buying SPC5 studio, without doing 30 day trial first (purchased license and JTAG programmer at same time).

Also you if you read license from ST and Freescale, pretty sure you’d be infringing doing what you are proposing because ST paid chibOS for that part of development. Not sure what ST was thinking when they came up with SPC5 studio and no way to support eTPU without Freescale binaries or 3rd party compiler.

Since SPC support in Chibi is sponsored by ST I hope that there is a chance to get some improvements once there is some audience. But overall you are painting a pretty depressing picture

SPC5 studio (V2+) also comes with uOSEK OS. Guessing too many people complained about not having automotive rated/optimized OS.

The biggest issue I have with chibiOS is its dependency on HAL. In my case I need to change eMIOS function on the fly and to my knowledge chibiOS doesn’t or can’t do it.

[Nobody]

SPC5 studio update.

I downloaded V3 about a month ago, but didn’t look at it too closely. Unfortunately nothing major has changes for MPUs with eTPU, as I noticed before. Other lower end units, now have a nice graphical configuration tool. chibiOS has been updated but looks like most of the effort targeted at lower end again. So for B/C/D and P units I’d say it’s a decent environment.

As stated before eMIOS still not complete, ADC missing decimation filter (knock sensing) no eTPU anything. Looks like CAN was improved…

[kb1gtt]

About jitter, I though my notes were lost due to bit rot, but I see it was preserved. From here http://ecu.zeeff.com/viewtopic.php?f=33&t=275&start=37 I posted notes about the jitter we were seeing. The short version was that we were seeing jitter in the .3 degree to .5 degree range. We tried different wheels, ranging from low cost laser cut steal, to OEM wheels.

[puff]

could it be the jitter used to calculate engine load/misfires/etc? I mean, jitter caused by the working cycle of the engine (momentary acceleration and so on)
for me it's difficult to imagine situations where stimulator would be useful. all in all, while on a live engine, changing, say, coolant temperature (both in terms of sensor signal and real engine temperature) would lead to certain outcomes, anyway altering RPM. probably you could predict the direction of that change (i.e. if the motor would slow down or rev up), but it's much more difficult to predict the speed of this change. and besides predicting it you'd need to implement it in the simulator. this makes all this idea pretty much useless (unless you are debugging/perfecting some very narrow parts of the code? so obtaining a test mule is the only true solution - am I mistaken?

[kb1gtt]

I understand the stimulator is mostly for development. Basically you can record a log file, then play it back. This is handy for when you change your code, you can stimulate the board and make sure the outputs are acceptable. Also if someone records an existing engine, a remote tuner can play that file to an engine controller, and tune it until it matches the existing system. Then that tune can be installed on the existing engine and it should be able to run the engine as it was being run. Once that's all done, they they can start playing with it to enhance the tune.

[Nobody]

About jitter, I though my notes were lost due to bit rot, but I see it was preserved. From here http://ecu.zeeff.com/viewtopic.php?f=33&t=275&start=37 I posted notes about the jitter we were seeing. The short version was that we were seeing jitter in the .3 degree to .5 degree range. We tried different wheels, ranging from low cost laser cut steal, to OEM wheels.

First I don’t want this to get contentious… About 2 weeks ago I was traveling for work and storms introduced crazy delays. I used this time to read up on o5e and misc. posts while being stuck at airport.

Some observations;
* They did not configure eTPU correctly.
* They did not understand application notes.
* What they called an exponential relationship, was actually linear. But at least they started looking in correct direction.
* Not sure what auto function set they used but looked like V2 to me. This is what is available now.

Unfortunately for them they tried to write an ECU app without understanding how an engine works (from physics standpoint), most of their equations had fundamental flaws…

Also if I’m not mistaken MS (B&G) tried to use 68332 MPU at first, but got in over their heads… The 68332 had first gen TPU and used on countless vehicles up to about ~2004… Think you see what I’m getting at.

I used a hardware function/arbitrary waveform generator for first round of eTPU testing. This allows you to throw some serious trash at eTPU while observing results with various configs. Round two was my Yamaha FZR waverunner, all worked as expected. No loss of sync, no drama, yes some code optimization, but works as advertised.

So don't blame the MPU/eTPU... Also software can't perform magic if hardware side is lacking.

[kb1gtt]

Which source were you looking at, as there are multiple versions out there, one that is polluted, and one that was from actual developers. You may have looked at the wrong pile of code. I don't remember mention of linear vs exponential in the code. Perhaps that was part of the polluted code after I stopped following it. From what I read in the app notes, and in the code, any fundamental flaws did not jump out at me. Perhaps that's because we couldn't get it to run an engine, and perhaps the flaws would have been more obvious then. Could you elaborate? What parts of the code were wrong?

I ask as the same mistake could likely be made here as well. It would be handy to know what the mistake(s) such that as this get's developed we know the land mines.

[Nobody]

Quote from Mike_e in same thread you referenced.

Here's a news flash on the crank function form my FS contact:

the free FS code has been used in numerous F1 cars just the way they provide it.

hmmmmmm............my issue my very well have bee the changes that were made to the fake_cam wait time.

I think I fixed the potential accel issue with fake_cam last night so I'll need to retest on the engine. Way back when I had the rpm set point hooked up to the on-board pot and could crank it around pretty severely with no issue......I should probably set that back up and see how it works with jitter turned on.

It sounds like you guys went through the trouble of having test wheels cut (laser or waterjet). Why didn’t you create a 720* wheel, what I mean by that is, you could have both cam and crank in one unit. So a 36-1 as an example, would be repeated twice for a revolution, but you would have a cam slot cut inside disk or wheel… This is essentially what I did with Function/arbitrary waveform generator… Oversimplified but kept repeating 720* cycle with noise, shifts, junk trash tossed in, obviously a variable intervals rates (RPM/2).

The eTPU setup was very odd in code I looked at (o5e). Pertinent applications note links already in this thread. Fundamental flaws not limited to eTPU but fuel too. Another thing I remember reading on o5e was they had to re-write Freescale flash routines, odd work fine for me.

I don’t want to turn this in a bash fest, but to me testing methodology was another fundamental flaw.

[clcorbin]

About jitter, I though my notes were lost due to bit rot, but I see it was preserved. From here http://ecu.zeeff.com/viewtopic.php?f=33&t=275&start=37 I posted notes about the jitter we were seeing. The short version was that we were seeing jitter in the .3 degree to .5 degree range. We tried different wheels, ranging from low cost laser cut steal, to OEM wheels.

I don't know what was going on with that test, but I DO know that when I tested my wheel with the MAX VR IC, I had no visible jitter while being spun on the lathe (a VERY GOOD 3-phase metal lathe). The square wave was dead smooth and constant. Unfortunately, I did not take any pics of the output.

[kb1gtt]

When you measured the jitter, I'm think you did it with a scope. How low could you measure the jitter? For example, if you had a 2 or 3 mS square way, it would be hard to see the 40 to 50uS that I was talking about. Do you think you would have been able to see 40 to 50uS of jitter?