Any updates?
Maybe a recap?
| gemellocattivo.com http://gemellocattivo.com/forum/ |
|
| TMS570 based ecu? http://gemellocattivo.com/forum/viewtopic.php?f=22&t=301 |
Page 4 of 5 |
| Author: | essess [ Thu May 25, 2017 9:00 am ] |
| Post subject: | Re: TMS570 based ecu? |
It has begun! |
|
| Author: | mk e [ Thu May 25, 2017 9:21 am ] |
| Post subject: | Re: TMS570 based ecu? |
Are you still thinking fuel and spark in the het? If not are there enough timers elsewhere? |
|
| Author: | essess [ Thu May 25, 2017 1:54 pm ] |
| Post subject: | Re: TMS570 based ecu? |
I'll try to fit 16x of fuel, 16x of spark in one HET (32 independent one-shot timers) I'll leave the other alone completely as 'expansion' as needed. |
|
| Author: | essess [ Mon Jun 19, 2017 8:46 pm ] |
| Post subject: | Re: TMS570 based ecu? |
Nothing to report other than: still here, still working on it. I'll keep chipping away through summer. |
|
| Author: | mk e [ Fri Jun 23, 2017 2:31 pm ] |
| Post subject: | Re: TMS570 based ecu? |
I've been so distracted......the good news is it's distracted confirm g the control logic does in fact work so yay! |
|
| Author: | essess [ Thu Jul 20, 2017 9:53 pm ] |
| Post subject: | Re: TMS570 based ecu? |
still chipping away .. setting up a (state machine) model based arch where someone can use this tool to modify the model, generate the code, and then build it. I've used it in products before. It's not as glorious as simulink .. but I think it'll do the job good enough (and provide a nice documentation source). I just don't have the time anymore to do all of this manually. Maybe someday we can transition to scikit+xcos, but that's too 'heavy' for now. |
|
| Author: | abecedarian [ Tue Aug 08, 2017 3:14 pm ] |
| Post subject: | Re: TMS570 based ecu? |
Any updates? Maybe a recap?
|
|
| Author: | essess [ Tue Aug 08, 2017 6:29 pm ] |
| Post subject: | Re: TMS570 based ecu? |
Umm. Not much. I'll have more free time after the end of this week. In short, I'm not sure the non-HET crank decode is an optimal solution. Because the HET timebase and crank/cam input timebases are separate there is .... problems ... which impact accuracy. I really like the 570, but disappointed that the HET isn't the cure-all I'd like it to be. I also spoke to the TI rep and he was giving me weird vibes on its future availability. So then I asked (quite directly and w/followups) if this device was NRD and he's not interested in a direct answer. With that said, this was the first time I've ever used a TI controller and I'm impressed. I'm going to look to them in the future too. It's probably back to the 56xx since that's all I have time for. I'm considering an fpga too. Any modeling can move forward independently of those decisions. |
|
| Author: | abecedarian [ Thu Aug 10, 2017 1:21 pm ] |
| Post subject: | Re: TMS570 based ecu? |
No worries, I suppose. Curiosity though... and not sure some will make sense.... Are you considering 360 or 720 degrees as a loop? What if the N2HET was used only to decode trigger wheels and initiate ignition / injection events, leaving main-core timers to handle duration and event termination? What if decoding triggers used, say, 6 teeth total instead of 60 (for a 60-2 for instance), and did a sliding window thing, stepping through a structure of sorts representing a whole trigger wheel? This could possible shrink the loop requirements a bit, I think - my head goes off in odd directions sometimes. Anyhow, it's a bit of a let down to think that N2HET isn't up to the task some at TI said it should handle with ease, even with software angle generation. Also sad to see that after this long they still don't have HWAG documentation available. |
|
| Author: | essess [ Thu Aug 10, 2017 3:20 pm ] |
| Post subject: | Re: TMS570 based ecu? |
A loop was 360 .. decoding of cam would be a simple single-edge (to mimick eTPU as a baseline) where determining phase is cake. Could even be handled outside of the HET. The HET works. SWAG works. But to reach 1/10 of a degree resolution on the angle clk is not possible. That was the requirement, and I don't think it's unreasonable at all (up to max 20k and 60 teeth). With HWAG and 60 teeth at 1/10 resolution resulted in about an 8k limit, if I remember right. Not bad. But that leaves no room for anything else and depending on undocumented hardware doesn't leave a good feeling when it comes to getting support. It'd be pulling teeth for a one-man show like myself. I had to contact the rep under my work email just to get the hwag doc. Quote: What if the N2HET was used only to decode trigger wheels and initiate ignition / injection events ... My math was based on this bare-bones case of doing only decode (as you mention). There just wasn't enough time in a loop to even do that. There's also a clk divisor issue where you run the core clk at 300MHz, but you can't run the HET at full speed. It doesn't matter, because the HET couldn't run fast enough to handle the resolution requirement anyways. I still love their setup, but it doesn't meet my requirement. I'd relax the requirement, but I don't think it's unreasonable. Probably back to the 56xx since I don't ever see having time to 'go for' the final solution and just use an FPGA. With more thought around this, I bet there is a way. I just wish I had multiple people to bounce ideas off of and brainstorm. It's so easy to get stuck in old/non-original thinking when it's only yourself. Rusefi seems to avoid this ... maybe I go camp out at his house for a while and see things from another perspective. |
|
| Page 4 of 5 | All times are UTC - 5 hours [ DST ] |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|