MS2 code and available memory
Moderators: jsmcortina, muythaibxr
MS2 code and available memory
This is just spitballing from the cheap seats; I have no idea if what I'm about to suggest is possible / practicable, and I would certainly have no useful suggestions as to how to go about implementing it.
The fact that the MS2 chip is running out of room has been a topic for occasional discussion for rather some time. In the past few days, a user reported an overflow error caused by the processor slamming hard into the limits of the device's memory. Something Must Be Done (tm).
From what I can tell, the single greatest waste of space is having all the wheel decoders loaded at once. No matter what trigger type you are using, your processor also has the EDIS, Renix 44-2-2, and the YZF1000 patterns, and and and ... The suggestion was made several weeks ago about stripping out the trigger patterns, and only including the pattern you wanted in the compiler build. This was rejected as it would require EVERY MS2 user to understand how to install and operate the compiler, which is a fairly non-trivial task and an unsuitable expectation.
Is it possible, and how hard would it be, to modify the code such that the main compiled .s19, when loaded and run, gives you the option of loading one of a selection of precompiled 'special' .s19 trigger modules? The standard load would be Basic Trigger and Toothed Wheel, but you would have the option of loading "Honda VTR1000", or "Subaru 6/7", or "UJM 1 long+3 short" (*ahem* *ahem* ) from a menu in TS.
Is this possible? Is it practical?
A simpler, more brute force method might be to simply divide the list of trigger modules in half; MS2/Extra_pre3.3.2beta9(A) has first ... 17 ..., while MS2/Extra_pre3.3.2beta9(B) has the other 16 trigger modules, all compiled and ready to load. I have no idea what the compiled memory size of the trigger modules are, but I have to assume this would free up a fair amount of memory - particularly when the code is so desperately poor for memory. "Rollin' dimes for gas money poor," as the man said ...
Thoughts? Comments?
The fact that the MS2 chip is running out of room has been a topic for occasional discussion for rather some time. In the past few days, a user reported an overflow error caused by the processor slamming hard into the limits of the device's memory. Something Must Be Done (tm).
From what I can tell, the single greatest waste of space is having all the wheel decoders loaded at once. No matter what trigger type you are using, your processor also has the EDIS, Renix 44-2-2, and the YZF1000 patterns, and and and ... The suggestion was made several weeks ago about stripping out the trigger patterns, and only including the pattern you wanted in the compiler build. This was rejected as it would require EVERY MS2 user to understand how to install and operate the compiler, which is a fairly non-trivial task and an unsuitable expectation.
Is it possible, and how hard would it be, to modify the code such that the main compiled .s19, when loaded and run, gives you the option of loading one of a selection of precompiled 'special' .s19 trigger modules? The standard load would be Basic Trigger and Toothed Wheel, but you would have the option of loading "Honda VTR1000", or "Subaru 6/7", or "UJM 1 long+3 short" (*ahem* *ahem* ) from a menu in TS.
Is this possible? Is it practical?
A simpler, more brute force method might be to simply divide the list of trigger modules in half; MS2/Extra_pre3.3.2beta9(A) has first ... 17 ..., while MS2/Extra_pre3.3.2beta9(B) has the other 16 trigger modules, all compiled and ready to load. I have no idea what the compiled memory size of the trigger modules are, but I have to assume this would free up a fair amount of memory - particularly when the code is so desperately poor for memory. "Rollin' dimes for gas money poor," as the man said ...
Thoughts? Comments?
Temporarily shut down - back soon!
QuadraMAP Sensor Module -- PWM-to-Stepper Controller -- Dual Coil Driver
Coming soon: OctoMAP Sensor Module
TTR Ignition Systems
QuadraMAP Sensor Module -- PWM-to-Stepper Controller -- Dual Coil Driver
Coming soon: OctoMAP Sensor Module
TTR Ignition Systems
-
- Super MS/Extra'er
- Posts: 9130
- Joined: Sun May 02, 2004 6:51 am
- Location: Quebec, Canada
- Contact:
Re: MS2 code and available memory
While there has been discussions about memory limitations on the flash side, the overflow error you mention is in the RAM. Changing the number of trigger patterns would have no impact on this.
Jean
Jean
-
- Site Admin
- Posts: 39620
- Joined: Mon May 03, 2004 1:34 am
- Location: Birmingham, UK
- Contact:
Re: MS2 code and available memory
As Jean says, it is RAM that is presently exhausted (and I have a plan for that.) There are still a number of kilobytes of flash free.
James
James
I can repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk
My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
-
- Helpful MS/Extra'er
- Posts: 121
- Joined: Thu Sep 04, 2008 10:09 pm
Re: MS2 code and available memory
Interesting. Any clues about this plan for the insatiably curious?jsmcortina wrote:As Jean says, it is RAM that is presently exhausted (and I have a plan for that.) There are still a number of kilobytes of flash free.
James
C|
-
- Site Admin
- Posts: 39620
- Joined: Mon May 03, 2004 1:34 am
- Location: Birmingham, UK
- Contact:
Re: MS2 code and available memory
From my assessment so far, the old version of gcc we use is a bit poor with memory management. All local variable in "main" get permanently allocated stack space. So my aim is to move some of that code into functions so the stack is only allocated as required and then re-used by other functions.
I've actually done that just now and freed up 40 bytes of RAM, however it causes an increase in looptime due to the increased function calling, so I might wind it back a bit. The changes also use up more flash. It is all getting very tight.
James
I've actually done that just now and freed up 40 bytes of RAM, however it causes an increase in looptime due to the increased function calling, so I might wind it back a bit. The changes also use up more flash. It is all getting very tight.
James
I can repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk
My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
Re: MS2 code and available memory
James how difficult would it be to upgrade the main CPU of the MS2 with one with larger RAM? Or easier, use another exact same chip in parallel to divide the work in half?
Miata NBFL 1.6 (EU), GT2560R, MS2Extra, Zeitronix.
Fiesta 1.25 Zetec-SE, N/A mods, MS3, AEM.
Fiesta 1.25 Zetec-SE, N/A mods, MS3, AEM.
Re: MS2 code and available memory
I think that's called an MS3.
Eric Law
1990 Audi 80 quattro with AAN turbo engine: happily running on MS3+MS3X
2012 Audi A4 quattro, desperately in need of tweaking
Be alert! America needs more lerts.
1990 Audi 80 quattro with AAN turbo engine: happily running on MS3+MS3X
2012 Audi A4 quattro, desperately in need of tweaking
Be alert! America needs more lerts.
Re: MS2 code and available memory
*snicker*
Nitroking - the problem is that the code has to remain compatible with all the MS2 cards out there. Code that could only be run on an MS2.5 card (updates to also include bringing out PE0 & PE1 ) can't really be called MS2/Extra.
Nitroking - the problem is that the code has to remain compatible with all the MS2 cards out there. Code that could only be run on an MS2.5 card (updates to also include bringing out PE0 & PE1 ) can't really be called MS2/Extra.
Temporarily shut down - back soon!
QuadraMAP Sensor Module -- PWM-to-Stepper Controller -- Dual Coil Driver
Coming soon: OctoMAP Sensor Module
TTR Ignition Systems
QuadraMAP Sensor Module -- PWM-to-Stepper Controller -- Dual Coil Driver
Coming soon: OctoMAP Sensor Module
TTR Ignition Systems
-
- Helpful MS/Extra'er
- Posts: 121
- Joined: Thu Sep 04, 2008 10:09 pm
Re: MS2 code and available memory
jsmcortina wrote:From my assessment so far, the old version of gcc we use is a bit poor with memory management. All local variable in "main" get permanently allocated stack space. So my aim is to move some of that code into functions so the stack is only allocated as required and then re-used by other functions.
I've actually done that just now and freed up 40 bytes of RAM, however it causes an increase in looptime due to the increased function calling, so I might wind it back a bit. The changes also use up more flash. It is all getting very tight.
James
Mmmm, yes. The eternal tradeoff between memory space and CPU time. At some point you basically hit the wall with the available resources.
C|
-
- Site Admin
- Posts: 39620
- Joined: Mon May 03, 2004 1:34 am
- Location: Birmingham, UK
- Contact:
Re: MS2 code and available memory
Yes, the real answer for more ram and flash is to use MS3. It has 16x RAM and 8x flash and is easily bought.
James
James
I can repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk
My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
Re: MS2 code and available memory
Do you think there will be an upgrade path to ms3 for micro squirt users of DIYPNP/MS2PNP units?jsmcortina wrote:Yes, the real answer for more ram and flash is to use MS3. It has 16x RAM and 8x flash and is easily bought.
James
Also, would there be any benefit of allowing the user to load the firmware with or without canbus support? Thats a feature that I will never use on my car and even when not in use, I'm sure its taking up some ram, right?
-
- Super MS/Extra'er
- Posts: 9130
- Joined: Sun May 02, 2004 6:51 am
- Location: Quebec, Canada
- Contact:
Re: MS2 code and available memory
Having multiple versions of the code with different options will not happen. That would be maintenance and support nightmare.
Moreover, freeing memory by not having CAN bus support would not give anything unless you used the memory for other features. That would then means that those who want/need CAN bus support would not be able to use those features. So that means additional versions, more people complaining, more support issues,...
As for an upgrade path for DIYPNP/MS2PNP units, that's a DIYAutotune question. They would need to build (and get licensing for) a replacement module based on the MS3 CPU that could fit the Microsquirt module pinout and footprint. This doesn't currently exist and, in my personal opinion, will not happen because it doesn't make sense: there are too many constraints for doing such a thing work well.
Jean
Moreover, freeing memory by not having CAN bus support would not give anything unless you used the memory for other features. That would then means that those who want/need CAN bus support would not be able to use those features. So that means additional versions, more people complaining, more support issues,...
As for an upgrade path for DIYPNP/MS2PNP units, that's a DIYAutotune question. They would need to build (and get licensing for) a replacement module based on the MS3 CPU that could fit the Microsquirt module pinout and footprint. This doesn't currently exist and, in my personal opinion, will not happen because it doesn't make sense: there are too many constraints for doing such a thing work well.
Jean
-
- Super MS/Extra'er
- Posts: 17507
- Joined: Thu Apr 16, 2009 8:08 pm
Re: MS2 code and available memory
Another way to do this would be to make an adapter board to connect an MS3-Pro Module to a MicroSquirt Module footprint. That would require no licensing. At present, we don't have any plans do to such a thing, but if there was enough interest, it could happen.racingmini_mtl wrote: As for an upgrade path for DIYPNP/MS2PNP units, that's a DIYAutotune question. They would need to build (and get licensing for) a replacement module based on the MS3 CPU that could fit the Microsquirt module pinout and footprint. This doesn't currently exist and, in my personal opinion, will not happen because it doesn't make sense: there are too many constraints for doing such a thing work well.
Jean
Matt Cramer -1966 Dodge Dart slant six running on MS3X
Re: MS2 code and available memory
Sounds like a great idea. You would be giving the existing MSPNP2/DIYPNP users an potential upgrade path, and could also develop a new generation of MSPNP3 products.Matt Cramer wrote:Another way to do this would be to make an adapter board to connect an MS3-Pro Module to a MicroSquirt Module footprint. That would require no licensing. At present, we don't have any plans do to such a thing, but if there was enough interest, it could happen.racingmini_mtl wrote: As for an upgrade path for DIYPNP/MS2PNP units, that's a DIYAutotune question. They would need to build (and get licensing for) a replacement module based on the MS3 CPU that could fit the Microsquirt module pinout and footprint. This doesn't currently exist and, in my personal opinion, will not happen because it doesn't make sense: there are too many constraints for doing such a thing work well.
Jean
Re: MS2 code and available memory
Can an MS3 Module fit in a PNP enclosure? The M3PM is *slightly* bigger than the uSM, after all ...
Temporarily shut down - back soon!
QuadraMAP Sensor Module -- PWM-to-Stepper Controller -- Dual Coil Driver
Coming soon: OctoMAP Sensor Module
TTR Ignition Systems
QuadraMAP Sensor Module -- PWM-to-Stepper Controller -- Dual Coil Driver
Coming soon: OctoMAP Sensor Module
TTR Ignition Systems
Re: MS2 code and available memory
So I've laid out an adaptor to install a MS3PM where a uSM was installed, but I'm still not sure if it will fit in the various enclosures. I did add a few components besides straight traces running hither and yon; the most important was the ALED / WLED Mosfet driven by Spark C and D, plus the needed pull-up resistors (and a jumper cap to un-select them if they are NOT needed). These extras were needed because if the uSM was not driving Spark C and D, those pins were probably driving something a little heavier than what the MS3PM could handle out of its logic spark pins.
I included a Mini-USB B-connector on the adaptor board, and added a break-out header for the Stepper driver. I wasn't sure what if any other MS3 pins should be added, as most of the existing ECU is going to be straight uSM.
I see no reason why the MS3PM could not be rotated relative to the uSM, but there is a pretty sharp limitation to how much it could be slid side to side.
Thoughts or comments?
I included a Mini-USB B-connector on the adaptor board, and added a break-out header for the Stepper driver. I wasn't sure what if any other MS3 pins should be added, as most of the existing ECU is going to be straight uSM.
I see no reason why the MS3PM could not be rotated relative to the uSM, but there is a pretty sharp limitation to how much it could be slid side to side.
Thoughts or comments?
Temporarily shut down - back soon!
QuadraMAP Sensor Module -- PWM-to-Stepper Controller -- Dual Coil Driver
Coming soon: OctoMAP Sensor Module
TTR Ignition Systems
QuadraMAP Sensor Module -- PWM-to-Stepper Controller -- Dual Coil Driver
Coming soon: OctoMAP Sensor Module
TTR Ignition Systems