It is currently Mon May 21, 2018 7:00 am



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 100 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
 Post subject: Re: Standardizing the math
PostPosted: Tue Jul 23, 2013 1:30 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
mk e wrote:

Now to load everything up, test the 1d part of the lookup, then test the actual engine control part of the FW.


The 1d tables appear to be working just fine so that's good news. I still need to key the data into most of them which will take a bit of time, then on to checking outputs...but it looks like we are nearly fully functioning again but with standardized floating point math now :)


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Wed Jul 24, 2013 8:22 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
I'm finding a lot more stuff related to the float change that needs to be fixed or should be cleaned-up....hopefully I'll be able to get though it all and get testing today.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Wed Jul 24, 2013 11:23 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
I seem to have done something BAD yesterday that has TS not wanting to write the flash now........I hate when this happens.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Thu Jul 25, 2013 12:36 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
mk e wrote:
I seem to have done something BAD yesterday that has TS not wanting to write the flash now........I hate when this happens.


It looks to me that all I did was key in data and what is going on is that TS is burning the page, then rejecting what it just did as a change to data that it is considering read-only? The error always happens at a 1d curve so I'm thinking it's a TS problem not an o5e issue so I'm on hold until I hear back from Phil I guess.

I THINK I found and fixed the remaining float conversion issues but I won't know until I can test :(


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Thu Jul 25, 2013 1:22 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
mk e wrote:

It looks to me that all I did was key in data and what is going on is that TS is burning the page, then rejecting what it just did as a change to data that it is considering read-only? The error always happens at a 1d curve so I'm thinking it's a TS problem not an o5e issue so I'm on hold until I hear back from Phil I guess.



Phil confirmed it's coming from his end and got me a work-a-round so I"m back up and running.

For anyone else playing, you need to go
options>preferences> unselect "Perform difference report on connect"

then to load the data whihc was happening automatically after the difference report you

File>open Tune > select current tune


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Fri Jul 26, 2013 3:44 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
At this point I've tested it and it looks like the fuel and spark pulses and all their corrections are once again being calculated right...now to get the etpu to set the signals out.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Sat Jul 27, 2013 10:50 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
mk e wrote:
At this point I've tested it and it looks like the fuel and spark pulses and all their corrections are once again being calculated right...now to get the etpu to set the signals out.



It 's now working but what should be a 10ms signal is coming out 3.67 even when I hard code 10 into the etpu......it looks like a clock setup has gotten buggered somewhere that I'll need to find.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Sat Jul 27, 2013 7:58 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
Well, part of the problem was me moving fuel 1 to etpu5 so it would flash on the led and them leaving my scope on 6 where I moved spark 4......but I'm still not seeing a number I like :(


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Sat Jul 27, 2013 8:17 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
mk e wrote:
Well, part of the problem was me moving fuel 1 to etpu5 so it would flash on the led and them leaving my scope on 6 where I moved spark 4......but I'm still not seeing a number I like :(



That's all better...still some weirdness getting the user stuff passed in I need to sort but it's close.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Sat Jul 27, 2013 11:30 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:52 am
Posts: 304
Location: Over here, doing 'over here' things.
If I were there, I'd serve you up a nice black and tan, with a little McClelland's whisky floating on top.

Cheers!

_________________
/me goes off to the corner feeling like Jerry Springer with a mullet.

My O5E candidate: 1982 Honda CX500TC motorcycle.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Sun Jul 28, 2013 9:36 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
abecedarian wrote:
If I were there, I'd serve you up a nice black and tan, with a little McClelland's whisky floating on top.

Cheers!


Then I'd never take anything fix! :o

This would go a lot faster if someone who actually knows what the h*ll they're doing would jump in and help :oops:

The angles all seem right and the correct fuel pulse is coming out with the exception of dead (compensation)time which I'm looking at now.....close.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Sun Jul 28, 2013 10:02 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
mk e wrote:

.... with the exception of dead (compensation)time which I'm looking at now.....close.


That was an easy one, I like those.

I think Fuel is now working right again.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Sun Jul 28, 2013 10:17 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
Spark is working right now too.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Sun Jul 28, 2013 10:30 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
Something is not quite right in toothgen.....were close


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Mon Jul 29, 2013 1:04 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
mk e wrote:
Something is not quite right in toothgen.....were close


I pushed up the changes and new TS project and I think everything is working right again and this project is closed.

Try it and let me know if you find anything wrong.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Mon Jul 29, 2013 1:47 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
I forgot this kind of important piece.....

You need TS v2.2.31 to us the FW in mark_5634 and you need to turn off the difference check or TS will explode......but v2.2.31 is not yet publicly available and I"m not sure I have permission to share it. I'll post when I get an answer.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Mon Jul 29, 2013 1:55 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
mk e wrote:
I forgot this kind of important piece.....

You need TS v2.2.31 to us the FW in mark_5634 and you need to turn off the difference check or TS will explode......but v2.2.31 is not yet publicly available and I"m not sure I have permission to share it. I'll post when I get an answer.


permission granted
https://open5xxxecu.googlecode.com/file ... 2.2.31.exe


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Thu Aug 08, 2013 7:39 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
I have no reports of issues with the float stuff so I'm going to push it up to development and master before I take mark_5634 back off-line for the user config upgrade work.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Thu Aug 08, 2013 8:52 pm 
Offline
User avatar

Joined: Thu May 30, 2013 1:11 am
Posts: 54
You have been busy! Sorry I couldn't help more with debugging this.

You mention earlier that you thought there was a problem in one corner of the table? Has that been fixed? If not, what corner?


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Thu Aug 08, 2013 10:04 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
clcorbin wrote:
You have been busy! Sorry I couldn't help more with debugging this.

You mention earlier that you thought there was a problem in one corner of the table? Has that been fixed? If not, what corner?


What you did was a huge help and I think it's all working properly now, but if you have time absolutely another set of eyes testing stuff would be GREAT!


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Fri Aug 16, 2013 10:26 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
mk e wrote:
mk e wrote:
I forgot this kind of important piece.....

You need TS v2.2.31 to us the FW in mark_5634 and you need to turn off the difference check or TS will explode......but v2.2.31 is not yet publicly available and I"m not sure I have permission to share it. I'll post when I get an answer.


permission granted
https://open5xxxecu.googlecode.com/file ... 2.2.31.exe



TS v2.3.00 is out and seems to have all stuff we need from v2.2.31 so I'd say use it and I'm going to take the the older version off our download page.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Tue Aug 20, 2013 2:14 pm 
Offline
User avatar

Joined: Fri Aug 16, 2013 12:04 pm
Posts: 57
Location: Jersey City, NJ
mk e wrote:
The 2 front runners are:
1) int32 bin 14. Almost everything we currently do will work with this other than times and the processor is fastest using 32 bit stuff I'm told. The down sides are we still need to watch bin points and there is more data to transfer to TS so loading tables and data logging slow down.

2)16 bit Floating point. The 5xxx processors have a floating point module so are as or nearly as fast at floating calculations. This keep s the data tranfer as is but requires a bit more re-writing.

I"'m leaning toward #2 but thoughts?


Why 16 bit floats? Why not 32 bit floats?

I am now looking at the set_spark method implementation and this whole "* 100" and "* Inverse100" looks like unnecessary clutter. I am sure there is a reason for that which I am missing though :)

I think if all tables and most variables were 32b floats overall code readability would improve.

_________________
another open ecu


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Tue Aug 20, 2013 2:43 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
russian wrote:
I think if all tables and most variables were 32b floats overall code readability would improve.


That's what was finally settled on and implemented.

russian wrote:
I am now looking at the set_spark method implementation and this whole "* 100" and "* Inverse100" looks like unnecessary clutter. I am sure there is a reason for that which I am missing though :)


For the FW it's definitely clutter and unneeded.....but it allows standardized variables that make sense to the user to be used directly by tuner.

The goal here was to get us to where this would work correctly:

viewtopic.php?f=13&t=34


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Tue Aug 20, 2013 7:39 pm 
Offline
User avatar

Joined: Fri Aug 16, 2013 12:04 pm
Posts: 57
Location: Jersey City, NJ
mk e wrote:
For the FW it's definitely clutter and unneeded.....but it allows standardized variables that make sense to the user to be used directly by tuner.


I guess it boils to what comes first - firmware code readability or tuning API. Please excuse me I am a bit of a code quality nazi. That's now a bit offtopic but I would love to chat about it a bit.

Did you consider migrating the values coming from TS before you use them? I mean let TS give you values in whatever format TS can provide values, but you convert them into your own internal representation (pure float in this case) before they get to the actual core firmware code.

_________________
another open ecu


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Wed Aug 21, 2013 11:02 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
russian wrote:
mk e wrote:
For the FW it's definitely clutter and unneeded.....but it allows standardized variables that make sense to the user to be used directly by tuner.


I guess it boils to what comes first - firmware code readability or tuning API. Please excuse me I am a bit of a code quality nazi. That's now a bit offtopic but I would love to chat about it a bit.

Did you consider migrating the values coming from TS before you use them? I mean let TS give you values in whatever format TS can provide values, but you convert them into your own internal representation (pure float in this case) before they get to the actual core firmware code.


To me, the answer is different. The code is a means to an end and we kind of lost track of that a little bit early on and that's caused some problems were trying to sort out now.

I think the first thing we need to do is be clear about what the finished system is supposed to be able to do....then put the pieces in place to make it happen. We certainly want the very best possible code that can accomplish the goals, but at the end of the day "form needs to follow function" and the function may require code that is not the simplest possible solution to 1 piece of the puzzle.


But that said, yes lets find time to chat and figure out if there are better ways to do what needs to be done then what we're currently doing.....and I suspect there are.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 100 posts ]  Go to page Previous  1, 2, 3, 4

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Theme designed by stylerbb.net © 2008
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
All times are UTC - 5 hours [ DST ]