gemellocattivo.com

yep!



yep!!



yep!!! - and hopefully HWAG gets documented in the meantime.

I have a habbit of assuming the worst about things so my thought is the HWAG generator is soooo bad they they don't want to admit its there. Maybe I'm wrong....but I'd focus on a time based solution.

RPM can't physically change very fast so I don't think I'd be too worried about any error that might creep in too much. i think you want to send both a position and an rpm to the spark/fuel funtions. The new position overrides the calculated positon the functions maintain and the rpm resets the rate of change calculations.

Then the only issue I think is how long from when you send the correct position from HET1 to when its picked up in HET2? If that can be sorted then I think it works. Is there a common memory location HET1 can write position too that the spark/fuel fucntions can read?

Each HET can trigger multiple DMA xfers and/or interrupts. So, maybe, when a reminder is 'due' -> 'trip' a data xfer + cause interrupt on completion.

In the int, do an update calc on what was given by HET1 and trip another DMA transfer to write to HET2 the new pulsewidths. We get ~255 cycles (minus latency) per .1 deg in the core (300MHz) to do an update calc.

My budget is 64 instruction/time slots (and some instructions take a couple of time slots). If both HETs can have the same LRP, we can kick them off together and keep the same timebase in-sync (but independent) ... then no need to convert between timebases either. This might be creaky and fragile. Once set/tested/stable/trusted - it's going to be hell to maintain/tweak. m-n may be it --- which would be disappointing.
...

After seeing all this possible work, I'm going to try to track down that SPNU203 doc for the 470 and see if we can circumvent this path entirely. Maybe it's documented more than I think (there's not much to this SWAG thing). If it's not going to help anyways, then back to the above plan.

My thought, and maybe I'm a little off the rails, is that HET1 will know the angle to 0.1 degree at all times but HET2 will be update (told the angle and rpm) at a time rate that could probably be up 10 or maybe even degrees of time because its working in time and counting to the event based on the position last reported and the rpm....rpm can't physically change very fast so there can't be much error I don't think.

I'd be tempted to try to do something where we caclulate a cycle time from rpm, then where we are in the count from position, then update the fuel/spark function with the last info on when they should start/stop. if we give the new info every say 10 degrees there will be core time left to calculate other things too.....of have HET1 send the interput every 10 degrees or how ever fast we can manage it no?

For HET1, using the coarsest divisor of 8, we can get 1.25 deg per 10 deg step in a 36-n. The idea is to have 'reminders' (callbacks) on those coarse divisor values and then try to guess at .1 deg from the closest 1.25 deg 'reminder'. HET2's loop rate is such that we can meet .1 deg spark at <= 18krpm and fuel width to within ~850ns. Technically, our limits are ~15krpm w/36 teeth and get worse with increasing tooth count. Another thing to think about is that .1 deg guessing is only going to be as good as 10 deg edge data because the 1/8th 'steps' of each 10 deg edge is also based strictly off of the same 10 deg edge too.

My request for the SPNU203 HWAG doc is in w/TI --- hopefully it'll have enough insight in it to tell me if HWAG is ultimately going to save me all this work or not. If not - I think I'm done w/this. I'd rather put that work into an FPGA and be able to carry that solution anywhere.

I was misunderstanding and thinking you were done with the angle clock all together?

Its always a guessing game, you know about when a tooth hits and are guessing everything until the next tooth hits....which is why I say for sure we can guess to 10 degrees and probably 30.

Time is what the system runs on....an "angle clock" is just conversions you don't need to thing about nothing more right? I think the only key is being able to share a common time between the 2 HETs.

An angle clock is the solution.
My proposal is effectively a software based angle clock that attempts to extend the SWAG resolution (due to LRP restrictions).

The ultimate idea is that HWAG will be the final solution that allows us to do it right. It pulls the SWAG operations out of the HET, thus decoupling us from the LRP restrictions that plague us. HWAG (as I understand it) runs outside of the HET, but is accesable by the HET --- it's parallel to the HET. The (S)oft(W)are (A)ngle (G)eneration instructions that we have to run (APCNT->SCNT->ACNT) are done is hardware at a higher rate and we should meet our resolution/rev rate specs. 300Hz w/.1deg resolution.

That's a big assumption so I'm going to use that non-public HWAG doc to help me determine, to a higher degree, if it really is a solution. Maybe there is enough in there that I can trust to just do it on the HWAG and be done with it. That's effectively crossing my fingers and I really don't like that. I have huge reservations using undocumented stuff like this though. I'd rather not.



I think what you're asking is angle clock is 'hands off' ? Yes. You just set and forget on angles because the SWAG/HWAG is doing what we're going to have to do manually by shifting work to the core for updates. For fuel, same thing - you just schedule a width and when that angle rolls around it kicks itself off automatically.

I can tolerate a hack on the way to a final proper solution, but if the final solution isn't going to be there, I'm going to go a different path/playground where there is no more of this 'at the mercy of the mfgr' stuff.

lets see what the HWAG is...but I am still not understanding why you'd mess with an "angle clock" that you can't actually share or act on in a very useful way vs working directly in the time domain where you seem to have all the resolution you could ever want?

You know a cyle is 720 degrees
You know the number of teeth some you know the angle
You know the time between teeth
You know the processor clock rate.

With that you can calculate the clock time that every event should occur at. It can be done in formulas so that latteny is not a factor as long as you complete all the calculations before the the next crank tooth is read. I see no need for dorking with the SWAG.

I maybe be doing may math wrong, but with a 36 tooth wheel at 20k rpm I get 1200 teeth/sec, and with the clock speed at 300Mhz, I get 25000 ticks/tooth...which seems like a lot and plenty of time to update the clock times we want events to occure at based on the latest info?

The accuracy is really about having resolution in the number sizes to to fit in the memory locations not actually needing to do calulations every 0.1 sec. There is no point in doing the calulations faster than the next crank tooth because everything between the teeth is an extrapolation and no data changes until the next tooth, so you'll get the same answer everytime you calculate it until the next tooth is read and prodives new data.

I see no actual need to try to work in degrees instead of seconds?

The real key is for HET1, HET2 and the main processor if we're using it for this work to all share a common time base or be able to convert between their individual time bases so equations can be written to calculate event times.

I say ditch their SWAG and effectively create our own and we'll be MUCH better off. What am I missing here?

You bring up a good point.
I'm hooked on using the HET for crank/cam decode ... and using the HET for interpolation .. doing it all in the HET with SWAG/HWAG .. then trying to 'wedge in' the spark/fuel with it.

Well screw that. If we're going to do 12000 edge interrupts/sec for 36-n @ 20krpm, then we might as well do all decoding in the main proc. Forget the HET for decoding. Use the HET's for more generic i/o (like the one-shots, or pwm capture, etc).

I think this works just as well as my proposal. It's probably less code. It's probably cleaner and more explicit in operation (less rigid). It's a much higher interrupt load (at least 36x). It's no different than all of the other existing diy options out there that do decoding in firmware with much less. None of those options have multiple INDEPENDENT i/o channels (which is a MUCH more rigorous restriction for me). We get some i/o flexibility w/the HET .. but sqeezing in a high-res crank decode isn't part of that it looks like.

This is a good idea. I propose your idea as the new proposal! I think the gains from an understanding and maintenance perspective outweight the interrupt load increase.

I still want this done in hardware. This is tolerable until then. Thanks for continuing to push on me.

So....is it done yet?