It is currently Mon May 21, 2018 5:19 am



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 100 posts ]  Go to page 1, 2, 3, 4  Next
Author Message
 Post subject: Standardizing the math
PostPosted: Sat May 25, 2013 7:31 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
Currently the o5e code uses mostly int16 type variables but there are also some uint8 stuff and an occasional int32 with bin point ranging from -2 to 14.

It works but is a bit of a pain to keep track of. It also makes any type of generic function nearly impossible to do.

So, the plan is to standardize.

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?


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Sat May 25, 2013 7:41 am 
Offline
User avatar

Joined: Mon May 13, 2013 7:26 am
Posts: 18
mk e wrote:
Currently the o5e code uses mostly int16 type variables but there are also some uint8 stuff and an occasional int32 with bin point ranging from -2 to 14.

It works but is a bit of a pain to keep track of. It also makes any type of generic function nearly impossible to do.

So, the plan is to standardize.

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?

Now your over my head, I know it has something to do with speed of information transferred but I haven't got a clue.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Sat May 25, 2013 7:59 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
p2164 wrote:
Now your over my head, I know it has something to do with speed of information transferred but I haven't got a clue.


Sorry.

It's about the way information is stored and processed. We currently use ONLY integers, but you want to decimals in on the display and the math wants decimals so we do a bunch of conversions in the tuners and in the code to sort it all out.

I"m suggesting we either use a single standard conversion or we switch to a storage and processing type that allows decimals. Either option USED to need a lot of extra processor work which meant extra time, but in modern processors like the one we use there is no time so I'm wondering why we're making things hard on ourselves.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Sun May 26, 2013 6:52 pm 
Offline
User avatar

Joined: Sun May 26, 2013 6:39 pm
Posts: 14
Use single precision (32-bit) floating point.

The e200z6 scalar SPFP is lightning. Single cycle add/subtract/multiply/compare, 12 cycle divide.

There is also the SPE APU which is a 64-bit vector floating point engine. A bit difficult to use for general purpose math, but it certainly has it's uses.

Patrick


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Sun May 26, 2013 11:12 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:52 am
Posts: 304
Location: Over here, doing 'over here' things.
patrick wrote:
Use single precision (32-bit) floating point.

The e200z6 scalar SPFP is lightning. Single cycle add/subtract/multiply/compare, 12 cycle divide.

There is also the SPE APU which is a 64-bit vector floating point engine. A bit difficult to use for general purpose math, but it certainly has it's uses.

Patrick
Looks like the z3 and z6 cores are fairly equal with regards to FPU, right?

_________________
/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 May 26, 2013 11:15 pm 
Offline
User avatar

Joined: Sun May 26, 2013 6:39 pm
Posts: 14
abecedarian wrote:
Looks like the z3 and z6 cores are fairly equal with regards to FPU, right?


I believe so, however I have never used the z3.

Patrick


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Sun May 26, 2013 11:24 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:52 am
Posts: 304
Location: Over here, doing 'over here' things.
patrick wrote:
abecedarian wrote:
Looks like the z3 and z6 cores are fairly equal with regards to FPU, right?


I believe so, however I have never used the z3.

Patrick

I was just reading about it; your previous post piqued my curiosity.

The z3 and z6 are apparently binary compatible, with the primary differences being the z6 has 32K L1 cache and a seven stage pipeline versus the z3 not having any L1 and a four stage pipeline.

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

My O5E candidate: 1982 Honda CX500TC motorcycle.


Last edited by abecedarian on Sun May 26, 2013 11:31 pm, edited 1 time in total.
spelling. :(


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Mon May 27, 2013 7:19 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
patrick wrote:
Use single precision (32-bit) floating point.

The e200z6 scalar SPFP is lightning. Single cycle add/subtract/multiply/compare, 12 cycle divide.

There is also the SPE APU which is a 64-bit vector floating point engine. A bit difficult to use for general purpose math, but it certainly has it's uses.

Patrick



You think 32 or 16?

The reason I ask is that is twice as much transfer to and from the tuner.

Also being I'm very new to all this is there anythign I need to now about converting the code to floating from integer other than add "float" to the defines and remove the bin shifts?


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Mon May 27, 2013 11:03 pm 
Offline
User avatar

Joined: Sun May 26, 2013 6:39 pm
Posts: 14
mk e wrote:
You think 32 or 16?

The reason I ask is that is twice as much transfer to and from the tuner.

Also being I'm very new to all this is there anythign I need to now about converting the code to floating from integer other than add "float" to the defines and remove the bin shifts?


Trust me, you won't have any performance issues with fp32 as long as you keep your code sensible (i.e. some standard floating point library functions can be slow, but you shouldn't need any of those).

As far as transferring from the tuner, 1024 floats is 4k. At 100Hz this is 400KiB/s. I wouldn't be concerned. Are you planning on using Ethernet?

Writing the code in floating point is far easier in many ways. You don't need to worry about overflows or bit shifting, so converting your code should be fairly straight forward.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Tue May 28, 2013 6:06 am 
Offline
User avatar

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

As far as transferring from the tuner, 1024 floats is 4k. At 100Hz this is 400KiB/s. I wouldn't be concerned. Are you planning on using Ethernet?



Maybe some day but today its serial and the tuner moves it in blocks of 256.....so 32bit will take twice as long. It's not a big deal on actual tuning stuff but it does limit what can be done with data logging.

I'm not worried about the code itself too much....the 5634 is a bit ram challenged and tables are moved to ram while tuning them but It should be fine.

Then the biggest issue is ok course the code base is finished and all it was supposed to need is some optional stuff....now it needs a rewrite :(


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Tue May 28, 2013 12:16 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
hmmmm.....I'm not so sure TS supports floating point variables. I'm on hold until I hear back from Phil I guess.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Tue May 28, 2013 3:55 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:52 am
Posts: 304
Location: Over here, doing 'over here' things.
Poke, poke... EMStudio ... poke, poke.

_________________
/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: Wed May 29, 2013 8:13 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
abecedarian wrote:
Poke, poke... EMStudio ... poke, poke.


Don't poke me, you need to poke Mike ;)

I confirmed there is no floating point support in TS, but it looks like there is a decent chance of getting it added.....more to come.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Wed May 29, 2013 8:46 am 
Offline
User avatar

Joined: Sun May 19, 2013 8:32 pm
Posts: 12
Wouldn't be difficult to implement, just adding another possible "type" to the incoming data.

I assume you're talking about transfering the floats over the wire in IEEE 754 format? (Just straight taking the 4 bytes of memory the float occupies and sending them over)

The only issue with that is endianness, which is easily taken care of.

Are you talking about switching EVERYTHING over to 32bit floating point? Seems like a huge waste of memory, since there are a great many things that don't need that kind of accuracy (TPS, MAP, most of your sensors). I understand using floating point for the calculations, but to store the data as floating point seems a bit wasteful.

When you're looking at it in terms of simplicity and program structure rather than performance, think of it this way: Would you do it on a desktop pc application?


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Wed May 29, 2013 11:34 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
All good questions.
malcom2073 wrote:
I assume you're talking about transfering the floats over the wire in IEEE 754 format? (Just straight taking the 4 bytes of memory the float occupies and sending them over)


Yes, just a straight 4 bytes over the wire is the thought.


malcom2073 wrote:
Are you talking about switching EVERYTHING over to 32bit floating point? Seems like a huge waste of memory, since there are a great many things that don't need that kind of accuracy (TPS, MAP, most of your sensors). I understand using floating point for the calculations, but to store the data as floating point seems a bit wasteful.


EVERYTHING is a big word.....most things is probably a better.

The ADC spits out a 14 bin result (although they only promise 12 good bits). So that can be stored in:
int16 and up
floating 32 and up (1/2 number, 1/2 floating point overhead)

If we want to use that data or data like RPM and or crank angle (0-72000) DIRECTLY without conversions the options are
Floating 32
int32 bin 14 (now this becomes 1/2 number, 1/2 waste caused by the standard bin point)

A standard will waste memory about 1/2 the memory we end up using, no question about that...but my question then becomes what do I care more about :
1)memory management
2)ease of use/lines of code

Given that we are only using about 2% of the memory in the 5634 which is about the bottom end chip but we're nearly out of lines of code the free compiler will deal with I'm thinking the answer is burn memory and make the code easier/smaller.

Does that make sense or am I looking at it all wrong?


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Wed May 29, 2013 12:33 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:52 am
Posts: 304
Location: Over here, doing 'over here' things.
mk e wrote:
....
Given that we are only using about 2% of the memory in the 5634 which is about the bottom end chip but we're nearly out of lines of code the free compiler will deal with I'm thinking the answer is burn memory and make the code easier/smaller.

Does that make sense or am I looking at it all wrong?

How much of the compiler limit is used by variable assignments and such?

Would it be possible to have things set up so that:
1) Firmware is burned to the system;
2) Initial setup information is transferred via tuning software.
???

Maybe I'm over my head? :mrgreen:

_________________
/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: Wed May 29, 2013 1:25 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
Ok, F32 will be in the next TS beta release.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Wed May 29, 2013 1:26 pm 
Offline
User avatar

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

How much of the compiler limit is used by variable assignments and such?

Would it be possible to have things set up so that:
1) Firmware is burned to the system;
2) Initial setup information is transferred via tuning software.
???

Maybe I'm over my head? :mrgreen:


I'm pretty sure a variable is a variable as far as the compiler count is concerned


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Wed May 29, 2013 1:35 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:52 am
Posts: 304
Location: Over here, doing 'over here' things.
mk e wrote:
I'm pretty sure a variable is a variable as far as the compiler count is concerned

I've seen constants and such included within code applied to the code limit.

Just saying.

_________________
/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: Wed May 29, 2013 3:29 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
abecedarian wrote:
mk e wrote:
I'm pretty sure a variable is a variable as far as the compiler count is concerned

I've seen constants and such included within code applied to the code limit.

Just saying.


Fair enough.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Wed May 29, 2013 4:02 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
mk e wrote:
All good questions.
malcom2073 wrote:
I assume you're talking about transfering the floats over the wire in IEEE 754 format? (Just straight taking the 4 bytes of memory the float occupies and sending them over)


Yes, just a straight 4 bytes over the wire is the thought.


malcom2073 wrote:
Are you talking about switching EVERYTHING over to 32bit floating point? Seems like a huge waste of memory, since there are a great many things that don't need that kind of accuracy (TPS, MAP, most of your sensors). I understand using floating point for the calculations, but to store the data as floating point seems a bit wasteful.


EVERYTHING is a big word.....most things is probably a better.

The ADC spits out a 14 bin result (although they only promise 12 good bits). So that can be stored in:
int16 and up
floating 32 and up (1/2 number, 1/2 floating point overhead)

If we want to use that data or data like RPM and or crank angle (0-72000) DIRECTLY without conversions the options are
Floating 32
int32 bin 14 (now this becomes 1/2 number, 1/2 waste caused by the standard bin point)

A standard will waste memory about 1/2 the memory we end up using, no question about that...but my question then becomes what do I care more about :
1)memory management
2)ease of use/lines of code

Given that we are only using about 2% of the memory in the 5634 which is about the bottom end chip but we're nearly out of lines of code the free compiler will deal with I'm thinking the answer is burn memory and make the code easier/smaller.

Does that make sense or am I looking at it all wrong?


I'll add this thought....

int16 has plenty of precision for everything we need to control an engine, but only if we manually set the bin point in both the FW and in TS so we aren't REALLY using 16 bit variables, we're using 16 bit + bin shift code in the FW and 16+ translate+scale in TS.

float 32 give us the 16 bit precision we currently have and automatically packs the other stuff we are currently doing manually in the the 32 bit word. Done with nothing to screw up.

It uses more memory but since we have an fpu it will probably run faster and will certainly be few lines of code, easier to read code, and a whole lot few chances for errors.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Wed May 29, 2013 7:54 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
mk e wrote:
All good questions.
malcom2073 wrote:
I assume you're talking about transfering the floats over the wire in IEEE 754 format? (Just straight taking the 4 bytes of memory the float occupies and sending them over)


Yes, just a straight 4 bytes over the wire is the thought.


There needs to be a big/small endian indicator in the ini too apparently. the 5xxx stuff is big endian.


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Wed May 29, 2013 8:40 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
mk e wrote:
mk e wrote:
All good questions.
malcom2073 wrote:
I assume you're talking about transfering the floats over the wire in IEEE 754 format? (Just straight taking the 4 bytes of memory the float occupies and sending them over)


Yes, just a straight 4 bytes over the wire is the thought.


There needs to be a big/small endian indicator in the ini too apparently. the 5xxx stuff is big endian.


which is of course already in the ini......duh. :oops:


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Thu May 30, 2013 9:13 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
I think Uno is on the flash page size issue.

I guess I'll be most productive rebuilding the ini and varibles.h files......which is a TON or work :(


Top
 Profile  
 
 Post subject: Re: Standardizing the math
PostPosted: Thu May 30, 2013 6:16 pm 
Offline
User avatar

Joined: Sun May 26, 2013 6:39 pm
Posts: 14
mk e wrote:
Given that we are only using about 2% of the memory in the 5634 which is about the bottom end chip but we're nearly out of lines of code the free compiler will deal with I'm thinking the answer is burn memory and make the code easier/smaller.


I'm a bit baffled by this. Exactly which compiler are you using?

I had assumed you were using gcc.


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 1, 2, 3, 4  Next

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 ]