290 hp gm ecm tune - confirmed - Page 25 - Saturn Sky Forums: Saturn Sky Forum
Saturn Sky Redline Discussion Forum for discussion of aspects of the anticipated hi-performance version of the Saturn Sky.

User Tag List

 
LinkBack Thread Tools Display Modes
post #361 of 986 (permalink) Old 10-01-2008, 09:51 PM
Senior Member
 
fr0stb1t3's Avatar
 
Join Date: Jul 2008
Location: Highland Park, Texas
Posts: 509
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Send a message via AIM to fr0stb1t3
Quote:
Originally Posted by BlueSkyRL View Post
No disrespect, but writing the code for 255kpa to 300/350kpa for me would be the easy part...just saying OK
I apologize for snapping off a bit earlier about the ECU, you are right about the actual hardware itself; so I gave myself a little break from the forums.

Although the software that is on it is currently VERY limited. Changing the inputs etc would be easy, it's going back and adding rows/columns to the tables. Adding columns to the boost also means adding to fuel tables, torque request tables... etc. Essentially you end up with the entire OS rewritten just to handle some new columns on one table.
fr0stb1t3 is offline  
post #362 of 986 (permalink) Old 10-01-2008, 10:23 PM
First 2000 Sr. Member
 
BlueSkyRL's Avatar
 
Join Date: Jun 2006
Location: Up North!
Posts: 991
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Quote:
Originally Posted by fr0stb1t3 View Post
I apologize for snapping off a bit earlier about the ECU, you are right about the actual hardware itself; so I gave myself a little break from the forums.

Although the software that is on it is currently VERY limited. Changing the inputs etc would be easy, it's going back and adding rows/columns to the tables. Adding columns to the boost also means adding to fuel tables, torque request tables... etc. Essentially you end up with the entire OS rewritten just to handle some new columns on one table.
No Problem...I'd forgotten all about GM is using a RTOS (Real Time Operating System) from Freescale/Metrowerks named OSEK and Codewarrior for the C code/compiler. They also use some sizable array's for their maps and "tables" so most of the tables can be modified without any real major code rewrite...if'n you have the source code You are correct in that the tables/columns(never thought of them that way before) need to be increased or different values, but the "if/elses, functions, class's, etc" wouldn't change.

Midnight Blue RL - Automatic
Rust proofed & Undercoated
Painted calipers and lettering
Painted engine cover, fuse box, rearend
Third brake light decal
Opel Gt antenna
3" Magnaflow exhaust
CTI hard pipes
Dejon Intercooler
BlueSkyRL is offline  
post #363 of 986 (permalink) Old 10-01-2008, 10:42 PM
Member
 
Join Date: Mar 2006
Posts: 2,602
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 5 Post(s)
Quote:
Originally Posted by BlueSkyRL View Post
No Problem...I'd forgotten all about GM is using a RTOS (Real Time Operating System) from Freescale/Metrowerks named OSEK and Codewarrior for the C code/compiler. They also use some sizable array's for their maps and "tables" so most of the tables can be modified without any real major code rewrite...if'n you have the source code You are correct in that the tables/columns(never thought of them that way before) need to be increased or different values, but the "if/elses, functions, class's, etc" wouldn't change.
So, are ya sayin we're just a typedef or two and a "make" away from S/W support, assuming storage wasn't already oversized already? Just as a lark, I gotta ask. Do we actually know current S/W's data mapping can't presently accept the wider range of values?


Edit: Trying question more directly. Yeah, RTOS needs to be tight, but are we assuming storage is of ints rather than long ints. Maybe that's apparent within HPT or to the HPT folks and this is a silly question which someone can dismiss straight off.

Last edited by cerberus; 10-01-2008 at 10:52 PM.
cerberus is offline  
post #364 of 986 (permalink) Old 10-01-2008, 11:08 PM
Senior Member
 
fr0stb1t3's Avatar
 
Join Date: Jul 2008
Location: Highland Park, Texas
Posts: 509
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Send a message via AIM to fr0stb1t3
Quote:
Originally Posted by BlueSkyRL View Post
No Problem...I'd forgotten all about GM is using a RTOS (Real Time Operating System) from Freescale/Metrowerks named OSEK and Codewarrior for the C code/compiler. They also use some sizable array's for their maps and "tables" so most of the tables can be modified without any real major code rewrite...if'n you have the source code You are correct in that the tables/columns(never thought of them that way before) need to be increased or different values, but the "if/elses, functions, class's, etc" wouldn't change.
Yeah, everything you do in HPT is set up in tables, so that's how I think of them. You can simply drop them in Excel and it mkes it easier to visualize. And you are correct the functions of the programming wouldn't change, but I do believe for some reason (I have no explanation as to why, just conjecture from others) that there is a little more work then simply extending the current tables, in which case Cerberus may very well be on the right track.


Quote:
Originally Posted by cerberus View Post
So, are ya sayin we're just a typedef or two and a "make" away from S/W support, assuming storage wasn't already oversized already? Just as a lark, I gotta ask. Do we actually know current S/W's data mapping can't presently accept the wider range of values?


Edit: Trying question more directly. Yeah, RTOS needs to be tight, but are we assuming storage is of ints rather than long ints. Maybe that's apparent within HPT or to the HPT folks and this is a silly question which someone can dismiss straight off.

According to HPT they simply cannot do it without a pretty serious rewrite which they are unwilling to do. I'm sure BTF has more information than I do, he's pretty tight with those guys
fr0stb1t3 is offline  
post #365 of 986 (permalink) Old 10-02-2008, 12:33 AM
First 2000 Sr. Member
 
JeffInDFW's Avatar
 
Join Date: Dec 2005
Posts: 481
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
I'm hoping that since the LNF is being used in the Cobalt SS and HHR SS that the aftermarket will be willing to invest more in the motor since it will be in a lot more vehicles now.

2006 Deep Solstice NA...Traded in for:
2009 Sky Redline Ruby Red Limited Edition
5 speed manual/rear spoiler added/6 disc/Monsoon
GMPP Tune/MBRP Charge Pipes/DDM Backbone & Probeam/K&N Drop in/HIDs
*Thank You Bob Lutz* And Wilmington UAW 435
JeffInDFW is offline  
post #366 of 986 (permalink) Old 10-02-2008, 10:48 AM
Member
 
elahz's Avatar
 
Join Date: May 2008
Location: MIAMI
Posts: 55
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Send a message via AIM to elahz
Quote:
Originally Posted by BlueSkyRL View Post
No Problem...I'd forgotten all about GM is using a RTOS (Real Time Operating System) from Freescale/Metrowerks named OSEK and Codewarrior for the C code/compiler. They also use some sizable array's for their maps and "tables" so most of the tables can be modified without any real major code rewrite...if'n you have the source code You are correct in that the tables/columns(never thought of them that way before) need to be increased or different values, but the "if/elses, functions, class's, etc" wouldn't change.
i think i might be a little harder then just add a table, i have no idea of the way programmed. but from what ive gathered up our ecu reads kpa heres the question on how easy or hard it might be to reprogram the OS, did they use 2 bit intergers? can they stuff 4 bit intergers w/o hitting size limitations. blindly guessing if the ecu sees FF value (255kpa) it sends itself to safemode. i see two things happening. kpa isnt going to be used or GM engnieers make it 4 bit integers and recode how it reads everything from the DB. i wish hptuners would have a say on this since they're writing right into database files the OS computes its things.

if the aftermarket had the source for this ecu.... OMG we'll have kids like myself writing limitless applications ie. launch control, more traction control profiles, more "modes" like timer on the DIC to see your 0-60 1/8 1/4 mile. built in turbo timer. overboost/racing mode etc. we'll be limited to our imagination and space
elahz is offline  
post #367 of 986 (permalink) Old 10-02-2008, 10:53 AM
Member
 
elahz's Avatar
 
Join Date: May 2008
Location: MIAMI
Posts: 55
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Send a message via AIM to elahz
Quote:
Originally Posted by BlueSkyRL View Post
No Problem...I'd forgotten all about GM is using a RTOS (Real Time Operating System) from Freescale/Metrowerks named OSEK and Codewarrior for the C code/compiler. They also use some sizable array's for their maps and "tables" so most of the tables can be modified without any real major code rewrite...if'n you have the source code You are correct in that the tables/columns(never thought of them that way before) need to be increased or different values, but the "if/elses, functions, class's, etc" wouldn't change.
i think i might be a little harder then just add a table, i have no idea of the way programmed. but from what ive gathered up our ecu reads kpa heres the question on how easy or hard it might be to reprogram the OS, did they use 2 bit intergers? can they stuff 4 bit intergers w/o hitting size limitations. blindly guessing if the ecu sees FF value (255kpa) it sends itself to safemode. i see two things happening. kpa isnt going to be used or GM engnieers make it 4 bit integers and recode how it reads everything from the DB. i wish hptuners would have a say on this since they're writing right into database files the OS computes its things.

if the aftermarket had the source for this ecu.... OMG we'll have kids like myself writing limitless applications ie. launch control, more traction control profiles, more "modes" like timer on the DIC to see your 0-60 1/8 1/4 mile. built in turbo timer. overboost/racing mode etc. we'll be limited to our imagination and space
elahz is offline  
post #368 of 986 (permalink) Old 10-02-2008, 12:41 PM
Senior Member
 
fr0stb1t3's Avatar
 
Join Date: Jul 2008
Location: Highland Park, Texas
Posts: 509
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Send a message via AIM to fr0stb1t3
Boost doesn't really matter to the ECU except in terms of keeping the turbo in certain limits does it? I thought the ECU calculated everything based off Mass Air Flow or am I completely off?
fr0stb1t3 is offline  
post #369 of 986 (permalink) Old 10-02-2008, 01:27 PM
Member
 
elahz's Avatar
 
Join Date: May 2008
Location: MIAMI
Posts: 55
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Send a message via AIM to elahz
Quote:
Originally Posted by elahz View Post
i think i might be a little harder then just add a table, i have no idea of the way programmed. but from what ive gathered up our ecu reads kpa heres the question on how easy or hard it might be to reprogram the OS, did they use 2 bit intergers? can they stuff 4 bit intergers w/o hitting size limitations. blindly guessing if the ecu sees FF value (255kpa) it sends itself to safemode. i see two things happening. kpa isnt going to be used or GM engnieers make it 4 bit integers and recode how it reads everything from the DB. i wish hptuners would have a say on this since they're writing right into database files the OS computes its things.

if the aftermarket had the source for this ecu.... OMG we'll have kids like myself writing limitless applications ie. launch control, more traction control profiles, more "modes" like timer on the DIC to see your 0-60 1/8 1/4 mile. built in turbo timer. overboost/racing mode etc. we'll be limited to our imagination and space


bytes not bits my bad
1 byte = 8bits
255 = 2byte FF max 16bit let me stfu
bits bytes bite.. time to bite this cookie
elahz is offline  
post #370 of 986 (permalink) Old 10-02-2008, 05:40 PM
Senior Member
 
mbeardsley's Avatar
 
Join Date: May 2007
Location: Allen, Texas (just north of Dallas)
Posts: 1,794
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 160 Post(s)
Garage
Quote:
Originally Posted by elahz View Post
if the aftermarket had the source for this ecu.... OMG we'll have kids like myself writing limitless applications ie. launch control, more traction control profiles, more "modes" like timer on the DIC to see your 0-60 1/8 1/4 mile. built in turbo timer. overboost/racing mode etc. we'll be limited to our imagination and space
ummm, yeah. And right after that you'd be seeing your ECU infected with viruses and Viagra adds showing up on your DIC.

I think I'll stick with GM programming...

2008 Red/Red/Redline
Ordered 06/08/07
Built 07/20/07
Delivered 08/07/07
Destroyed 03/02/17
Replaced 03/19/17
mbeardsley is offline  
post #371 of 986 (permalink) Old 10-02-2008, 06:43 PM
Senior Member
 
Join Date: Apr 2008
Posts: 107
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
i'll probably wait now till next spring when the car comes out again to get the new tune unless its out within the next two weeks
saab9-3 is offline  
post #372 of 986 (permalink) Old 10-02-2008, 07:43 PM
First 2000 Sr. Member
 
BlueSkyRL's Avatar
 
Join Date: Jun 2006
Location: Up North!
Posts: 991
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Quote:
Originally Posted by cerberus View Post
So, are ya saying we're just a typedef or two and a "make" away from S/W support, assuming storage wasn't already over sized already? Just as a lark, I gotta ask. Do we actually know current S/W's data mapping can't presently accept the wider range of values?


Edit: Trying question more directly. Yeah, RTOS needs to be tight, but are we assuming storage is of ints rather than long ints. Maybe that's apparent within HPT or to the HPT folks and this is a silly question which someone can dismiss straight off.
If you look at the table (array) it may give you a hint. for example 8 x 8, 16 x 16 or 32 x 32. Beyond that you get into 3 dimensional arrays or more and yes more memory (lots more) and your structures have to change considerably too. HPT probably has recognized the limits of their code and what would be required to increase everything...fun for me (ya I know I have a strange idea of fun) but very time consuming.

Midnight Blue RL - Automatic
Rust proofed & Undercoated
Painted calipers and lettering
Painted engine cover, fuse box, rearend
Third brake light decal
Opel Gt antenna
3" Magnaflow exhaust
CTI hard pipes
Dejon Intercooler
BlueSkyRL is offline  
post #373 of 986 (permalink) Old 10-02-2008, 07:51 PM
First 2000 Sr. Member
 
BlueSkyRL's Avatar
 
Join Date: Jun 2006
Location: Up North!
Posts: 991
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 1 Post(s)
Quote:
Originally Posted by fr0stb1t3 View Post
Boost doesn't really matter to the ECU except in terms of keeping the turbo in certain limits does it? I thought the ECU calculated everything based off Mass Air Flow or am I completely off?
No, you are pretty much correct. There is a Max value for the boost at any given range, which several people have figured out how to increase that value now. So that's a big reason for the "tunes" out there and the increase in HP/TQ.

Midnight Blue RL - Automatic
Rust proofed & Undercoated
Painted calipers and lettering
Painted engine cover, fuse box, rearend
Third brake light decal
Opel Gt antenna
3" Magnaflow exhaust
CTI hard pipes
Dejon Intercooler
BlueSkyRL is offline  
post #374 of 986 (permalink) Old 10-02-2008, 07:56 PM
Member
 
Join Date: Mar 2006
Posts: 2,602
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 5 Post(s)
Quote:
Originally Posted by BlueSkyRL View Post
If you look at the table (array) it may give you a hint. for example 8 x 8, 16 x 16 or 32 x 32. Beyond that you get into 3 dimensional arrays or more and yes more memory (lots more) and your structures have to change considerably too. HPT probably has recognized the limits of their code and what would be required to increase everything...fun for me (ya I know I have a strange idea of fun) but very time consuming.
Yup. I just had to ask the simple question to wonder if change was even needed, but HPT knows where they found the current values, so know the sizes, so must know that the memory map will change. Then we're right to what you speak of as not only do you have simple contiguous values shift, but the more murky area of array slices moving. Do I have that right? A distant memory, but recall it as a PITA. I can see why HPT would balk, especially for a small subset of a small market, but wanted to understand and pretty much get it out there that as it makes no sense for HPT, the GM tune won't be the avenue for tuners as a start point.
cerberus is offline  
post #375 of 986 (permalink) Old 10-02-2008, 08:12 PM
Member
 
Elff's Avatar
 
Join Date: Jun 2008
Location: Keebler, PA
Posts: 4,356
Mentioned: 2 Post(s)
Tagged: 0 Thread(s)
Quoted: 255 Post(s)
Garage
What's the dealio with this tune?

LUSIFER is Sold!
say hello to
RYUK

I'm not short, I'm concentrated AWESOME
Elff is offline  
Reply

  Saturn Sky Forums: Saturn Sky Forum > Saturn Sky Discussion > Saturn Sky Redline Discussion

Quick Reply
Message:
Options

Register Now



In order to be able to post messages on the Saturn Sky Forums: Saturn Sky Forum forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.

User Name:
Password
Please enter a password for your user account. Note that passwords are case-sensitive.

Password:


Confirm Password:
Email Address
Please enter a valid email address for yourself.

Email Address:
OR

Log-in











Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page
Display Modes
Linear Mode Linear Mode



Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

 
For the best viewing experience please update your browser to Google Chrome