8InchesFlacid wrote:First off, to preface, anything is fair. It's your show, and you're perfectly justified in doing anything you want, including not letting loudmouth Americans use it. :-)
Thank you :-) It's only my show until I do less than half of the work though. I have to say, the ...Americans... bit cracked me right up, many of you do have a propensity to talk a lot, but thats a non-issue, it can be quite entertaining. I don't want to exclude anyone in particular from here at all. BTW, the fact that it is GPL, like MegaTune, and MegaTunix means that I have no right to disallow your use of it at all. You can take and change it etc till your heart is content.
Not supporting dizzy as a rule seems a little silly to me, but saying you'd drop it as soon as it compramises the code for the rest of the engines does make a lot of sense.
Exactly.
It's not worth the time, and you're right in that all someone has to do is put a toothed wheel (even just a nib on the cam) to make everything work with the "regular" code.
Exactly.
Re-writing and replacing code seems like a lot of work, and something that will rapidly fall apart. Sure, it sounds good, a community of folks who care, all working together, maintaining releases of code long after they had a baby and sold their opel for a minivan. In reality, I don't think it would happen. Even where it did... you wouldn't want someone like me maintaining code!
If done well, and I will try very hard to do it well, it won't be a lot of work at all. It will be pretty close to a one off code writing exercise to read one or two inputs and generate one to 24 outputs from them. If the interface is fairly complete in the first place then other changes shouldn't affect this at all and its just a matter of compiling and running it on your engine to ensure it still works correctly before releasing your branch. Literally, copy file across to new release, build s19, run on engine, release. Ideally, you would want to check the changes to the rest of the code to ensure that they don't affect your branch, but given that great interface, that should not occur.
To my mind, and I want to strongly preface this by saying I have zero software production experience......that version would be included with all releases until a new one is made.
As Jean said so well up above, if I can't test it, how can I release it with any certainty that it's any good? Therefore someone that can test it ON A CAR should do the release for that branch, EVEN if they dont do anything except configure and build and install and drive. (which should be all that is required most of the time anyway)
it's it's much more accessable to the users. Again, not everyone with a car is also a programmer.
Maybe not, but, this is
DIYEFI.org, not SMDfactoryEFI.org, and all "users" will be expected to pull their weight in some fashion or other. Nothing will come on a plate from here, only from various "distributors" that choose to support a certain type of vehicle/feature/hardware for their own interest and or profit. It's a 5m task for you to configure, compile, install an s19 and take it for a thrash round the block :-) why not you maintaining it? even if I write it?
If they can't click a few things and then go turn a wrench, you're going to take a lot of people out of the running - and perhaps the work to keep them in wouldn't be so bad.
Once again, just because I don't release XYZ code, that doesn't mean that it won't be released and clickable by someone else for someone else an hour after I release... Demand vs. Supply, If there is demand for miata code, someone will step up to the plate :-) Consider all the time you've spent posting about your miata issues (a LOT), consider what might have taken place if you had spent all that time learning the code and trying stuff out yourself on the fly and finding a solution? You would have one, even if it wasn't compatible with the rest of the code... Time better spent? I think so.
The other, unrelated, topic - about staged/banked injection. Banked injection is SO easy to do, there's no reason not to include it. /2 fuel by X, fire injectors X as often.
Most likely yes. Once again though, if it gets in the way... then no. But, it shouldn't.
I think people's comments on updating fueling amounts as the motor runs makes very good sense, just the sort of thing to put the extra processing abilities of this chip into.
I really need to do a thread for you, Alex, and Mops etc about this. Maybe I'll do that now.
Lastly, staged injection, Admin and I discussed this offline.........etc. But independant control of the primary and secondary injectors would be needed!
See next comment :
The easiest way out of this to me is to bank them up in a set of 4 and a set of two.
= special code/config = no, also, sequential or go home :-) see this thread :
http://www.diyefi.org/forum/viewtopic.php?f=8&t=76
Sorry for the long post, I'm not keping up!!
Not a problem, it would have been easy if not for all the others who also got off their arses and had their say :-) Thanks to all of you for that!!
Admin.