ababkin wrote:BTW, since you bring up the topic of compilers and xgate, (and i hope i don't hurt anyone's feelings) but a local friend of mine, who designed many many embedded applications in past 20yrs of his career for cars and other stuff (he's one of the most known tuners in bmw world), strongly recommended me to just spend the measly $100 (or whatever it costs) on the codewarrior license instead of futzin' around with the gcc and other open source tools. He argues that the value of CW much exceeds the price diff between the opensource and CW license. He also approved our choice of a Freescale MCU for our purpose.
I haven't really tried CW, but his argument was quite compelling.
A while back I asked about keeping the main code gcc and using CW to compile xgate code and then "put them together". I think we would need a feature/function comparison of gcc/cw to really figure out if we're futzin....... Buy looking around on the net, besides lacking xgate support the gcc-tool chain seems very functional. It would seem that the xgate code would be very specific(once complete) and deving it on CW wouldn't "close" the project, since most mods/features could be done in the gcc portion. I have a feeling we may need to continue this post as a new thread
I'd go one step further than that and say that code warrior is a obscenely obese and highly buggy tool that is a resource hog and has some serious issues when it comes to asm generation that both Myself, James and Ken prefer to avoid.
Code warrior is only welcome here for Xgate, and only if the perl assembler can not be made to work, or James' and others GCC ports fail to reach completion in time.
There are dozens of IDEs to choose from, and from my personal experience with it, I would rather soak my right hand in sodium hydroxide before using it again.
'nuff said?
Besides, I think you'll find its not as cheap as you think.
Although, the free version supports unlimited asm anyway, so that can be used for generation of xgate code right out to the 512k mark if required (good luck writing that much asm).
heh. Wow. that's a lot of teeth. I sort of agree, it would see you want to know crank position that well, and cam position only so much.
Somehow to me it seems you could back off a step, use hardware to get a count-rate and a total count out of it. Interupt on the 4-8 teeth per engine cycle.
Maybe get instantaneous count rate at the count timing on each major tooth but not interupt on each minor?
8InchesFlacid wrote:Somehow to me it seems you could back off a step, use hardware to get a count-rate and a total count out of it. Interupt on the 4-8 teeth per engine cycle.
Maybe get instantaneous count rate at the count timing on each major tooth but not interupt on each minor?
Having owned and operated a nissan rb20de with one of these in it for a long time, I can tell you that they have their downsides. The thing is that because they have so much resolution and its not on the crank, any play and wobble is really noticed by the ECU and acted upon. I traced a dodgy idle to my CAS bearings! replaced the bearings and bingo, perfectly smooth motor. i.e. reading instantaneous rpm during only the 8 windows from the outer rings will likely do more harm than good.
I'm really looking forward to Sean's findings though!
8InchesFlacid wrote:heh. Wow. that's a lot of teeth. I sort of agree, it would see you want to know crank position that well, and cam position only so much.
They are the same thing, the only down side to having the wheel on the cam like admin said(good findings by the way) is slop. BTW admin, did your nissan have chain or belt driven valve train?
Belt driven, but in good condition and properly tensioned. The issue was caused by the bearings grabbing at one point and taking up the direct slack in the mechanical drive from the cam shaft, and the freeing up and rushing forward to the other extreme of the play only to seize again and rush back. If you understand what I'm saying, it was the bearing and drive that caused the issue, not the cam belt (at least, I don't think so) as they are heavily fibre reinforced and not prone to short term stretch much at all.
The point was to illustrate how sensitive to "random" speed variations such accurate devices become because they watch something that isn't moving consistently too closely. having the slots spaced further apart causes two (one?) things :
An averaging effect over the distance
The same error to be a much smaller percentage of the total measurement.
I'm investigation a couple options and I need some feed back from the more experienced. As said before there is a concern about having too many teeth and thus creating too much CPU load. I would like to devise a way to divide the number of teeth counted, hopefully with in the firmware if not using some sort of IC.
My question is, what's a good number of teeth/crank revolution? I thought about doing 360/4 which equals 45 per crank rev. One down side to this would be the absence high resolution pulses durning a low res pulse for low res windows shorter than 4, but as long as I can figure out a way that it sync's somewhere on the wheel, we should be good to go.
and note high going edge of main pulse, reset counter, and on low going, compare count with table, it is only 10 instructions per interrupt if you do it like that. Should work.
