how would you handle overlapping dwell ?
In the end your original accuracy is still limited by the ecu + the latency of your device which may change from build to build unless you keep close tabs on it. To me, it's not a true offload of responsibility.
Multiple ignition output
Re: Multiple ignition output
Unfortunately it wouldn't free up an ECT timer which is what we need for fuel channels with extreme accuracy. On the other hand maybe some users don't need that much accuracy and can cope with using the timers in a different way with ordinary pins - this should be explored later though.longracing wrote:but this could possibly free up a timer? (Would have to check with Fred)
<snip>
The potential is there to get more ignition outputs but the main reason for doing this would be if it could free up a timer or processing time to add more fuel channels.
Sequential V8 falls into two categories :
1) Let's walk before running/we'll try it later after the normal method works for 1 - 6 cylinder engines (8/10/12 with semi sequential).
2) We'll do it on the XEP chip later instead.
No, I didn't know that, trouble is, it needs to be 500cc per cylinder or less to be a good engine in my eyes, so 6 litre engines should have 12. Take a look at the exotics to confirm this theory ;-)I have to agree the Toyota quad-cam v8 is a well engineered engine. Did you know Holden developed a brilliant 36valve, overhead-cam variation of their V8 before canning it for the LS1. :roll:
As above and posted in other places the v8 sequential thing isn't a never thing, it's a later thing. The ignition stuff that is attempted and unfinished/broken will also work for fueling however we should do that later once normal modes of operation are complete. You are correct that the other "core" is currently unused, that is pretty high up my list of TTD, however be aware that it's not a general purpose CPU like the main one and will be used in quite specific ways. As for online collaboration, blame me for not doing the best meta docs. I've tried to keep the docs in the code where contributors will need it, and written some docs that live in source control with the code in ./docs/ but it's not complete, yet.EssEss wrote:I almost understand Fred's original system well enough (through his code) to know that the towel is not thrown in yet .. I don't see finished (or attempted) code which says that this is a hard restriction yet. Is this the horse before the cart ? I also see the the other core currently unused ?
I'm still reading up and digesting this all, I may have missed something. Online collaboration is proving painful for me :oops:
If you want the latest, always use git/github to get a between-versions snapshot of the code.longracing wrote:Looks like It might make it too complicated (I'm still working my way through the code. I also downloaded 0.0.9 instead of 0.0.19 thinking it was the latest :oops: ).
It will complicate things and it won't free up anything particularly useful by the sounds of it.What I would like to know is if it is going to make the hardware + firmware more complicated it is a bad idea. If it can improve the firmware by freeing up resources for other outputs then it may deserve a bit more thought.
Quite possibly, yes. Good discussion to help comprehension though, and the git thing came up which is also good.Starting to see this as a bad idea, adding too much complexity and not adding that much to the output.
Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!