RomRaider

It appears that RR editor ignores float point numbers endian.

It uses "big endian" any time.

Endian="little", endian="big" statements within ecu_defs.htm are completely ignored.

Is there any workaround?

If the float data/values are always big endian then does it matter?
Are you seeing a problem somewhere or are you just pointing out a bug?

I would like to have "little endian" working as promised. Besides 4 byte float 4 byte integer numbers may also be useful.

The reason is that not any microcontroller uses big endians.

Currently I am trying to provide porting ecu and diagnostic tool firmware onto non-Freescale\Hitachi\NXP platform as well.

The idea is to provide ECU realtime tuning capability.

OpenSource software could be very helpful for the project.

Edited:
I have all needed with ecuEdit and ecuFlash. The first one is a commercial project and to be true the second one could not be thought as free without Tactrix cable payed.

I looked at this and found that the "bytes to float" conversion routine is always forced to big endian in the RomRaider code. I could fix this quite easily but current ECU Editor defs would all become invalid. The current defs incorrectly identify float as being little endian.
So there's two solutions:

1) fix this AND release a corrected version of ALL the defs ever created
2) fix this AND add a version attribute to the defs that if set uses the endian as defined in the def, if not set assume an old def and force float to be big endian

Any other suggestions?

You are quite correct about wrong RR definitions.

I think it will reasonable to add a switch (probably a version of the xml format used inside new defs) that force RR to interpret new defs correctly and ignore float conversion settings inside old defs that does not have this switch.

It is also desirable to add new setting to interpret singed integers and long signed \unsigned ones.

I agree that's probably easiest.

I already have modified code for this. It can support int8, int16, uint8 & unit16.
Is there a need for int32 & uint32? This will require more code changes to support.

Who knows what the future holds?
I hope RR can be useful not for only Subaru ecu's.

Another question is related to the support for big\little endian integers/float for ROM editor and logger.

This is supported in the Editor already, not sure about the logger. The logger would need to know the format of the ECU's response to a query. That's not defined anywhere that I can think of, so I assume it assumes big endian right now.

ECU init string specifies parameter availabitlity. For Subaru 2 byte values are big endian.

But.
Extended parameters depend on processor architecture and are big endian for Hitachi\Renesas.
Hardcoded "big endian" for logger may become a restriction for other makes or DIY ecu's.