Hi,
I am very much interested in the 2.0 release version. Basically I am just starting tuning with the B&G MS2 code. But I am sure I´d appreciate the closed-loop IAC funtion a lot. In fact that would be the main argument for me to swap.
Now, from time to time I read in the threads that the processor´s memory is limited and the code has to be "squeezed and altered" to fit in.
So - when I install windows software some programs ask me if I want standard or user-defined installation. The latter way let´s me choose the options I´d like to use. And while I would only need the EDIS igniton code lines in my installation, space could be gained by omitting all the other ignition options.
It IS important the the other options are programmed by you just as it is important to be able to power any motor with MS, but in my case the processor would carry alot of "ballast code". And this accounts for every other user too, so everybody might make her/his choice. This is no way ment to be an attack on the developing work, I wish to emphasize this as I admire the work quite a bit and hope you´ll keep up with it.
I have no idea if this is possible. Or practical. But AFAIK this idea wasn´t mentioned before.
MS2x Firmware - what about a user-dependent installation ?
Moderators: jsmcortina, muythaibxr
MS2x Firmware - what about a user-dependent installation ?
Range Rover Classic
-
6040solder
- Experienced MS/Extra'er
- Posts: 307
- Joined: Mon Oct 22, 2007 7:15 am
- Location: Auckland, New Zealand
-
muythaibxr
- Site Admin
- Posts: 8230
- Joined: Thu Oct 14, 2004 12:48 pm
What would be the point of all the extra space? You can't use it unless you intend to write a bunch of your own code.
Also, while doing something like this is possible, It really provides no benefit. When a feature is not in use, it doesn't increase execution time or anything like that, so there's no real point to doing what you're saying.
Doing what you're saying would also require us to build a huge number of s19's, or make the firmware installer compile in/out features that you select...
So while it's possible, it's not really that practical, nor does it gain you anything.
Ken
Also, while doing something like this is possible, It really provides no benefit. When a feature is not in use, it doesn't increase execution time or anything like that, so there's no real point to doing what you're saying.
Doing what you're saying would also require us to build a huge number of s19's, or make the firmware installer compile in/out features that you select...
So while it's possible, it's not really that practical, nor does it gain you anything.
Ken
-
6040solder
- Experienced MS/Extra'er
- Posts: 307
- Joined: Mon Oct 22, 2007 7:15 am
- Location: Auckland, New Zealand
It would save you massive amounts of runtime config if done right. Runtime config is huge for all MS variants I've seen. Less settings, more tunability I say :-)
Also, you often say "no space left for that" including features, wheel modes etc. if it was trimmed to be wheel specific, then there would be more space for stuff you haven't done yet because you didn't have enough space. larger tables on flash at least etc.
Also, you often say "no space left for that" including features, wheel modes etc. if it was trimmed to be wheel specific, then there would be more space for stuff you haven't done yet because you didn't have enough space. larger tables on flash at least etc.
-
muythaibxr
- Site Admin
- Posts: 8230
- Joined: Thu Oct 14, 2004 12:48 pm
Problem is, it would be an absolute nightmare because we're not running low on space for code, we're running low on space for settings.
If we start removing various settings on a compile-time basis, then we could potentially have issues where 2 features can't be enabled at the same time, etc.. I don't see how that'd be any better than what we have now.
We'd also have to have a custom ini file for every .s19.
We have 128k of flash, the problem is that a lot of it is banked. We could figure out a way to use it, but it's a bit of a pain if we start sticking settings in banked memory. Then you run into situations where you can't just directly access a setting, you have to put the code that accesses the settings in the same page as the settings themselves (where now, code in any banked flash can still access settings since they're in non-banked flash).
In other words, it is possible to do, but not practical.
The runtime configuration (which we've already cut down significantly for the basic features) isn't really that large. Sure the extra settings must be written whether you're using them or not, but that only takes extra time when loading or saving an msq.
Ken
If we start removing various settings on a compile-time basis, then we could potentially have issues where 2 features can't be enabled at the same time, etc.. I don't see how that'd be any better than what we have now.
We'd also have to have a custom ini file for every .s19.
We have 128k of flash, the problem is that a lot of it is banked. We could figure out a way to use it, but it's a bit of a pain if we start sticking settings in banked memory. Then you run into situations where you can't just directly access a setting, you have to put the code that accesses the settings in the same page as the settings themselves (where now, code in any banked flash can still access settings since they're in non-banked flash).
In other words, it is possible to do, but not practical.
The runtime configuration (which we've already cut down significantly for the basic features) isn't really that large. Sure the extra settings must be written whether you're using them or not, but that only takes extra time when loading or saving an msq.
Ken