Below I've pasted an update from Bruce Bowling on the MS-II release. FYI for anyone interested...
==================================================
Update, Oct 9,2004 on MS-II progress:
A) Al is working on the last board revision, which are a few cleanup issues and a few additions:
- Make the stepper Motor driver chip enable pin be under the control of the processor and not hard-wired.
- Bring out some of the unused pins on the C32 processor out on the 40-pin DIP socket.
- Add a output signal for knock windowing control.
- Move the bootloader switch off the board and use the same I/O signal as is used in the original MS (the ADC channel used for monitoring battery voltage). The idea is to have one bootloader switch location. However, since then I have been implementing the Serial Monitor/bootloader code on the device (see below) and I may have Al leave the switch where it is.
- Get one very small prototype board runs made to verify operation once again.
B) Al has the embedded Codewarrior software frozen at V0.9 - it is at a point where it needs testing on operating engines.
C) My task as of late was to implement the bootloader function in the 9S12C32 processor. I am aware of the inherent problems with the existing bootloader in the MS's GP32, where one has to try many different things in order to get it to actually work. The thing about a bootloader is that you get one shot at it, since they are (usually) implemented as protected code in memory so that it will not get erased. The GP32's version left some things to be desired.
Not this time around. I have implemented the Serial Monitor function as outlined in appnote AN2548:
http://www.freescale.com/files/microcon ... AN2548.pdf
This is turning out to be a godsend! Not only does it allow one to upload/download data to/from memory, it allows one to actually debug thru the serial interface. What this means is that one does not have to purchase a BDM cable, they simply plug in the serial cable and off they go. And - Codewarrior has this mode seamlessly implemented, so if one picks the serial monitor mode in CW, the tool connects using the serial port, downloads the code into flash, and allows pretty much all debug capabilities (step/watch/breakpoint/etc). Its pretty slick, and appears to be extremely robust. It sets the serial port at 115,200 baud and the processor core clock frequency to 24 MHz - it can upload 20K of flash code and burn it in under 3 seconds!
The only hiccup is that Al runs his code at 16 MHz and sets the serial port at 9600 baud, so when Al's code sets up the SCI port communications is lost under debug. This does not affect the serial bootloader function, only the debugging, so it is not a major issue, since the vast majority of people will just be using this to upload code and not for detailed code development. But, all I need to do is convince Al to jack up the clock frequency from 16 to 24 MHz and use a 115.2Kbaud serial rate and we are go to go (:twisted
A couple of things: first, now that we have a bootloader function, we need a front-end program running on the PC which serves up the .s19 record file in binary mode. The serial monitor program uses a binary command set - it does not do the s-record parsing, this is left to the PC side to implement. So, no firing up hyperterminal and sending a text file of .s19 format, this is a little more sophisticated. What is needed is a very simple app which reads in the .s19 file and converts this to the required binary command set in order to flash the device. The appnote above outlines what is required. If someone wants to implement this let me know, otherwise it is on my to-do list. Also, rumor has it that such a program exists for free on the Technological Arts site (they use the exact same serial monitor), but I have not checked it out yet. Also, if someone does write this code, I can give them a command dump from Metrowerks showing every command sent over to the serial monitor to load the entire MS-II application, so that they can get a feel for what is really going on.
Second, an idea I have been kicking around. Al's code is getting pretty much complete for pass one. The issue is that it is nearly 20K of flash space (everything, including tables) and this requires an extended Codewarrior license to compile everything (the free license is limited to 12K code generation). But, we now have this nifty bootloader/debugger which can burn flash anywhere (which takes up 2K). So, we have 10K of space left over in a nice block(s) of memory. So, in theory, Al could put in strategic places in his main MS-II code (like several places in the main loop) a simple jsr call to somewhere in this 10K block. Now, the default in this block (uploaded when the main MS-II code is burned) would be to simply do a return - it does nothing. But, a savvy code person could intercept this call and actually put in their own code at this jump location - think of these as "stubs" where one can upload their own code patches in their own flash "playground", independent of the main MS-II code. For instance, right before the MS-II code sets the injector pulsewidths, the main loop code could do a jsr branch to the flash block, and the default would be to simply return. Some could place their own code there and modify/add their own stuff. If they include the same definition of variables as are used in the main code, then this stub code could have access to all variables. The nice thing about this is that one can leave the main MS-II code in place and add their own overriding code if they want to, in their own place. And, they would have enough code generation capability with the freeware version of Codewarrior. Something to think about...
Finally, another indicator that the HCS12 family was the correct processor choice for MS-II - see the new MC9S12NE64:
http://www.freescale.com/webapp/sps/sit ... 468636K100
This is a HCS12 device with a 10/100 ethernet MAC *and* PHY on one chip. All you have to do is provide magnetics and a RJ-45 and you have ethernet connectivity at $9.00. And, there is a freeware port of TCP/IP which is ported to Codewarrior. I have been playing with an eval board with the free TCP/IP stack and this part is indeed sweet. The UDP packet function alone (with DHCP) is enough to implement a nice high-speed communications function for MS. Now that the MS code is ported to the HCS12, changing over the SCI serial data to Ethernet UDP would be possible without a lot of work. This is just FYI....
The new code is out and I have a copy already.
It's posted at:
http://www.bgsoflex.com/ms2/msii_main_v0.8.c
http://www.bgsoflex.com/ms2/hcs12def.h
I'm sure it can be manipulated to make it 8x16 (8 load, 16 speed) points. I'll take a look at that. I agree COP is difficult and semi-reliable. That's why I decided to go EDIS instead. The Ford unit is going to be just fine for me with MSnEDIS/MS-II. The 2 distinct advantages I see with EDIS are:
1) It has a default curve so even if the control box fails, it will still run
2) It's a production Ford part and available at any parts store.
Both items ensure absolute reliability from a limp and replace scenario.
That's just my preference. With the open nature of MS, anything is possible with the right amount of knowledge and work.
It's posted at:
http://www.bgsoflex.com/ms2/msii_main_v0.8.c
http://www.bgsoflex.com/ms2/hcs12def.h
I'm sure it can be manipulated to make it 8x16 (8 load, 16 speed) points. I'll take a look at that. I agree COP is difficult and semi-reliable. That's why I decided to go EDIS instead. The Ford unit is going to be just fine for me with MSnEDIS/MS-II. The 2 distinct advantages I see with EDIS are:
1) It has a default curve so even if the control box fails, it will still run
2) It's a production Ford part and available at any parts store.
Both items ensure absolute reliability from a limp and replace scenario.
That's just my preference. With the open nature of MS, anything is possible with the right amount of knowledge and work.
By joey on Tuesday, October 12, 2004 - 09:58 am:
yep i think i'll grab the MS2 daughter card, i'm holding off building the actual ecu board for this reason..
that is the logical move right? as i understand it, this will piggy back over where the old processor was right?
thanks
By Steve R on Tuesday, October 12, 2004 - 12:58 pm:
You're spot on Joey, it's a drop in fit for the usual MS processor & with a lot more processing power.
By Peter Webb on Tuesday, October 12, 2004 - 01:59 pm:
Yep it's a drop in. Don't let that delay your assembly or even installation/tuning of the system you have. It will all still work with the new CPU. You can get a jump on it now.
-Peter
By Mats on Wednesday, October 20, 2004 - 11:51 am:
Ok, can someone decode for me?
What are the differences between MegaSquirt and MS-II. Didn't understand a whole bunch of that code-monkey talk in the first post.
What does it mean to me as an engine tuner? Extra functionality?
Price and availability?
/Mats
By Steve R on Wednesday, October 20, 2004 - 01:41 pm:
Mats, MS II is basically a processor upgrade for the current MS board, it's a "drop in" replacement for the existing Megasquirt processor. The initial post was some of the tech behind it as noted by the MS "guru's"
Now because MSII is plenty quicker it can support funkier code, like bigger tables for fuel & spark, better rpm resolution plus lots of extra channels for bespoke stuff that the MS crowd like to build (water injection, fan control, idle speed stabilizers, traction launch control, anti-lag etc). Apparently it'll also connect via ethernet rather than serial port so I presume the communication baud rate will be far better giving deeper resolution for datalogging etc.
Note the new processor on it's own doesn't give any new tuning features per se, it's just far more powerful giving additional potential headroom in the system.
Therefore the open source nature of MS plus the bigger/better/faster processor means the MS system will continue to be developed adding all the cool features petrolheads across the world want to build !
By Peter Webb on Wednesday, October 20, 2004 - 01:59 pm:
Per the posting by Al Grippo, the MS-II will have 12x12 tables by default and 4-12 programmable I/Os for external spark and solenoid control.
I like the fact the new code is in 'C' rather than assembler seeing as I'm a 'C' programmer for a living. The new code will be pretty much the same as the UMS from a source perspective. Some of it obviously is commented out for MS-II because it won't have native EDIS support and such.
The UMS will be on the Coldfire processor that has ENET built in. The serial link will be retained in the artwork and it's up to the user to manipulate the bulkhead and get a stack. Remember, Ethernet is a layer 2 protocol and needs a true OSI stack to do anything with.
Head over to www.msefi.com for the complete story. There's plenty written on it there. The source for the new system(s) is at www.megasquirt.info
-Peter
By Mats on Thursday, October 21, 2004 - 08:43 am:
thanks, sounds sweet...
What we really need are for someone to redo the code so we can have TRUE spark control.
I want direct fire goddammit!
Are there possibilities for any more pulse modulated ports?
Hmm, sounds like I'll have to wait a while for the new code (if it evers shows up) to stabilize.
But when it does, It will be sweeeeet!
/Mats
By Zamani on Thursday, October 21, 2004 - 09:12 am:
12x12 table sounds good!
Although I find that it is more critical to have more rpm cells than load cells.
What's the advantage of direct fire? I've seen more 164 coil over plugs fail than Milano distributors.
By Peter Webb on Thursday, October 21, 2004 - 07:24 pm:
The new code is out and I have a copy already.
It's posted at:
http://www.bgsoflex.com/ms2/msii_main_v0.8.c
http://www.bgsoflex.com/ms2/hcs12def.h
I'm sure it can be manipulated to make it 8x16 (8 load, 16 speed) points. I'll take a look at that. I agree COP is difficult and semi-reliable. That's why I decided to go EDIS instead. The Ford unit is going to be just fine for me with MSnEDIS/MS-II. The 2 distinct advantages I see with EDIS are:
1) It has a default curve so even if the control box fails, it will still run
2) It's a production Ford part and available at any parts store.
Both items ensure absolute reliability from a limp and replace scenario.
That's just my preference. With the open nature of MS, anything is possible with the right amount of knowledge and work.
-Peter
yep i think i'll grab the MS2 daughter card, i'm holding off building the actual ecu board for this reason..
that is the logical move right? as i understand it, this will piggy back over where the old processor was right?
thanks
By Steve R on Tuesday, October 12, 2004 - 12:58 pm:
You're spot on Joey, it's a drop in fit for the usual MS processor & with a lot more processing power.
By Peter Webb on Tuesday, October 12, 2004 - 01:59 pm:
Yep it's a drop in. Don't let that delay your assembly or even installation/tuning of the system you have. It will all still work with the new CPU. You can get a jump on it now.
-Peter
By Mats on Wednesday, October 20, 2004 - 11:51 am:
Ok, can someone decode for me?
What are the differences between MegaSquirt and MS-II. Didn't understand a whole bunch of that code-monkey talk in the first post.
What does it mean to me as an engine tuner? Extra functionality?
Price and availability?
/Mats
By Steve R on Wednesday, October 20, 2004 - 01:41 pm:
Mats, MS II is basically a processor upgrade for the current MS board, it's a "drop in" replacement for the existing Megasquirt processor. The initial post was some of the tech behind it as noted by the MS "guru's"
Now because MSII is plenty quicker it can support funkier code, like bigger tables for fuel & spark, better rpm resolution plus lots of extra channels for bespoke stuff that the MS crowd like to build (water injection, fan control, idle speed stabilizers, traction launch control, anti-lag etc). Apparently it'll also connect via ethernet rather than serial port so I presume the communication baud rate will be far better giving deeper resolution for datalogging etc.
Note the new processor on it's own doesn't give any new tuning features per se, it's just far more powerful giving additional potential headroom in the system.
Therefore the open source nature of MS plus the bigger/better/faster processor means the MS system will continue to be developed adding all the cool features petrolheads across the world want to build !
By Peter Webb on Wednesday, October 20, 2004 - 01:59 pm:
Per the posting by Al Grippo, the MS-II will have 12x12 tables by default and 4-12 programmable I/Os for external spark and solenoid control.
I like the fact the new code is in 'C' rather than assembler seeing as I'm a 'C' programmer for a living. The new code will be pretty much the same as the UMS from a source perspective. Some of it obviously is commented out for MS-II because it won't have native EDIS support and such.
The UMS will be on the Coldfire processor that has ENET built in. The serial link will be retained in the artwork and it's up to the user to manipulate the bulkhead and get a stack. Remember, Ethernet is a layer 2 protocol and needs a true OSI stack to do anything with.
Head over to www.msefi.com for the complete story. There's plenty written on it there. The source for the new system(s) is at www.megasquirt.info
-Peter
By Mats on Thursday, October 21, 2004 - 08:43 am:
thanks, sounds sweet...
What we really need are for someone to redo the code so we can have TRUE spark control.
I want direct fire goddammit!
Are there possibilities for any more pulse modulated ports?
Hmm, sounds like I'll have to wait a while for the new code (if it evers shows up) to stabilize.
But when it does, It will be sweeeeet!
/Mats
By Zamani on Thursday, October 21, 2004 - 09:12 am:
12x12 table sounds good!
Although I find that it is more critical to have more rpm cells than load cells.
What's the advantage of direct fire? I've seen more 164 coil over plugs fail than Milano distributors.
By Peter Webb on Thursday, October 21, 2004 - 07:24 pm:
The new code is out and I have a copy already.
It's posted at:
http://www.bgsoflex.com/ms2/msii_main_v0.8.c
http://www.bgsoflex.com/ms2/hcs12def.h
I'm sure it can be manipulated to make it 8x16 (8 load, 16 speed) points. I'll take a look at that. I agree COP is difficult and semi-reliable. That's why I decided to go EDIS instead. The Ford unit is going to be just fine for me with MSnEDIS/MS-II. The 2 distinct advantages I see with EDIS are:
1) It has a default curve so even if the control box fails, it will still run
2) It's a production Ford part and available at any parts store.
Both items ensure absolute reliability from a limp and replace scenario.
That's just my preference. With the open nature of MS, anything is possible with the right amount of knowledge and work.
-Peter
It's here!!!
The MS-II was released and ready for ordering today.
http://www.bgsoflex.com/mspo1.html
-Peter
The MS-II was released and ready for ordering today.
http://www.bgsoflex.com/mspo1.html
-Peter
The true joy of an Alfa Romeo is behind the wheel.
