View The Full Version : How to choose the display 8/16/32 IEEE or Motorola?
As topic, what are the basics to understand/to know which type of view is correct in the file that I'm viewing?
The chart changes a lot depending on what you choose...and reading guides etc...also examples of machines I have seen that is only told to select for example the 16bit motorola and as max 16384 ... but for what reason?
Greetings
it is a question I ask myself too, but given that I am logged in, hoping not to say the heresies, and that the more expert we explain, then, well, a tip I try to't just give you this.
using the ecm, once you have chosen the right driver file ori you of the mapped areas.
when you torovi with the "cursor" inside the area with the map you have no other choice that's the right one.
if you look at the area where you select the display type of the mark black is on one type only and the others are not selectable.
I give for granted that that is the one "right" and I select then for the rest of the file (even if I don't know what to do with the rest of the file). I also like the suggestion and if I have to open a map that I don't have drivers, look before viewing choose ecm for one of the same family and.... I copy
THE display varies depending on the power units.
Factors and practical the advice that I give is:
go to an id apparently known map type pedal
to change the display until it appears visibly correct
so you have the index of the map view.. of course, the story is a little particular but as an index of the beginning I would say that makes the idea
it is a question I ask myself too, but given that I am logged in, hoping not to say the heresies, and that the more expert we explain, then, well, a tip I try to't just give you this.
using the ecm, once you have chosen the right driver file ori you of the mapped areas.
when you torovi with the "cursor" inside the area with the map you have no other choice that's the right one.
if you look at the area where you select the display type of the mark black is on one type only and the others are not selectable.
I give for granted that that is the one "right" and I select then for the rest of the file (even if I don't know what to do with the rest of the file). I also like the suggestion and if I have to open a map that I don't have drivers, look before viewing choose ecm for one of the same family and.... I copy
Is that just tonight I noticed...from the 2d graph as soon as you enter in an area known self-rescala ... but I didn't know if it's reliable or not...also because then taking into the scale...of the times some of the information is cut off in the graphs.
THE display varies depending on the power units.
Factors and practical the advice that I give is:
go to an id apparently known map type pedal
to change the display until it appears visibly correct
so you have the index of the map view.. of course, the story is a little particular but as an index of the beginning I would say that makes the idea
Thanks for the response... but then the map varies as a function of the ecu? ...in the sense of the map the pedal does not always have that view? Or are you telling me that has the same "Layout" curves...but different views ?
You have charts with written or drawn as they should appear some types of maps? Because as I am new to this world, I don't know if I'm looking for an elephant... or a zebra to give you the idea.
Greetings
Is that just tonight I noticed...from the 2d graph as soon as you enter in an area known self-rescala ... but I didn't know if it's reliable or not...also because then taking into the scale...of the times some of the information is cut off in the graphs.
Thanks for the response... but then the map varies as a function of the ecu? ...in the sense of the map the pedal does not always have that view? Or are you telling me that has the same "Layout" curves...but different views ?
You have charts with written or drawn as they should appear some types of maps? Because as I am new to this world, I don't know if I'm looking for an elephant... or a zebra to give you the idea.
Greetings
the map display is "correct" where it is self-imposed by the driver, but generally the view is always 16bit and varies from the ieee to motorola according to the vendor or to release the ecu.
The maps have the brackpoint that give the index to the axes of the curves.
The correct display I from the eprom or the e2p or the microprocessor that are viewing it in the sw of the change...
Not always is 16bit but can be 8-bit,look at the marelli nevertheless, for example, or 32-bit as the denso mounted on the ecu in the Subaru for one thing or can also be in floating point as some maps in ECU Mitsubishi Lancer Evolution..the 2d mode is only a graphical representation of the content of the hex dump of a given component that is always in hexadecimal format...
I'll give it that for the vast majority of those who modify the ECU would be impossible to understand something in a sea of numbers and letters developers of sw editing have implemented the mode 2 and 3d..
But at the dawn of the ecu the only way was to understand the language binary and hex..
The correct display I from the eprom or the e2p or the microprocessor that are viewing it in the sw of the change...
Not always is 16bit but can be 8-bit,look at the marelli nevertheless, for example, or 32-bit as the denso mounted on the ecu in the Subaru for one thing or can also be in floating point as some maps in ECU Mitsubishi Lancer Evolution..the 2d mode is only a graphical representation of the content of the hex dump of a given component that is always in hexadecimal format...
I'll give it that for the vast majority of those who modify the ECU would be impossible to understand something in a sea of numbers and letters developers of sw editing have implemented the mode 2 and 3d..
But at the dawn of the ecu the only way was to understand the language binary and hex..
I would say start with an example and a good example is the edc16c39 enough used and easy to learn.
I highly recommend everyone to strive to put into the above with the info given
The correct display I from the eprom or the e2p or the microprocessor that are viewing it in the sw of the change...
Not always is 16bit but can be 8-bit,look at the marelli nevertheless, for example, or 32-bit as the denso mounted on the ecu in the Subaru for one thing or can also be in floating point as some maps in ECU Mitsubishi Lancer Evolution..the 2d mode is only a graphical representation of the content of the hex dump of a given component that is always in hexadecimal format...
I'll give it that for the vast majority of those who modify the ECU would be impossible to understand something in a sea of numbers and letters developers of sw editing have implemented the mode 2 and 3d..
But at the dawn of the ecu the only way was to understand the language binary and hex..
Paradoxically, if I knew how to read and understand the ecu in the hex... I could learn from them this kind of information...that is, if 8bit or 16 32 etc.. ?
But this information in hexadecimal where can I find it?
Last thing... a control unit, for example, that has as a display 16bit...will remain' for all its maps to 16 bit... or is it possible to find parts that appear better in 8-bits, other 32...and other 16bit?
I would say start with an example and a good example is the edc16c39 enough used and easy to learn.
I highly recommend everyone to strive to put into the above with the info given
In fact, I'm just taking that as a cue this ecu EDC16C39... and right here I've noticed this thing is reading online... that is, I open the file with ECM Titanium, I chose the exact driver...and I open the 2d view.
At this point the ECM although I had already loaded the driver...and he knew already what it is...show me all with display 8bit IEEE and Zoom v to minimum or 32k with ECM2001 type... but in reality,' the correct display should be 16bit Motorola (as indicated in some guides, for example, to exclude the EGR with zoom to 16k).
You do it simple..
What is a byte?
You do it simple..
What is a byte?
I say to know!!!!
the byte is a set of 8 bits and has 256 vaiabili different from 0 to 255 (same thing goes for the ipv4 and finqui even the most idiot knows what that is)
Perfect... this already makes you understand that if you would like to display a value from 0 to 255 in 16bit it would be impossible right?
Then let us always return to the speech that we were doing before on the hex dump..
Are the same values that are contained in a component that will dictate the correct display..
I don't know if it is clear..
Perfect... this already makes you understand that if you would like to display a value from 0 to 255 in 16bit it would be impossible right?
Then let us always return to the speech that we were doing before on the hex dump..
Are the same values that are contained in a component that will dictate the correct display..
I don't know if it is clear..
Beginning to think by now...
Why is it impossible? If I have to represent a value from 0 to 255 then the 1-byte in 16-bit ( 2-byte), I will have always a 00xx ? no ?
I'm doing a slaughterhouse.
Perfect... this already makes you understand that if you would like to display a value from 0 to 255 in 16bit it would be impossible right?
Then let us always return to the speech that we were doing before on the hex dump..
Are the same values that are contained in a component that will dictate the correct display..
I don't know if it is clear..
the concept is clear that the view is attached to the bit of the component body but not knowing it at first glance, one switcha view until you have a shape drinking..
the question of the 8-bit to 16 bit of course you can do, 16bit has 65536 variables from 0 to 65535, so scale is different from 8bit, of course, in view 16bit, the top-of-the-curve, 8bit, stops at 255 to 65535 bits in the display to 16bit.. then that is a motorola or ieee should be on the basis of which type of memory holds the file open.
right?
In fact, I'm just taking that as a cue this ecu EDC16C39... and right here I've noticed this thing is reading online... that is, I open the file with ECM Titanium, I chose the exact driver...and I open the 2d view.
At this point the ECM although I had already loaded the driver...and he knew already what it is...show me all with display 8bit IEEE and Zoom v to minimum or 32k with ECM2001 type... but in reality,' the correct display should be 16bit Motorola (as indicated in some guides, for example, to exclude the EGR with zoom to 16k).
To me, ecm titanium driver uploaded I motorola 16-bit for this family of controllers.
it is true that visually, taking the known areas is the only type of display that in a graphical sense.
Perfect... this already makes you understand that if you would like to display a value from 0 to 255 in 16bit it would be impossible right?
Then let us always return to the speech that we were doing before on the hex dump..
Are the same values that are contained in a component that will dictate the correct display..
I don't know if it is clear..
ok, it is just a kind of choice for display graphics and ease of understanding with respect to the table esa or binary...
but... then.. I don't know how to explain.... if I open the file to read the flash of a EDC15C7 (which is a component in 8-bit) value from table for one and the same address is in the table that in 2D graphics, by choosing the " display IEEE 8bit is the same. here not ago na the wrinkle.
if I open the EDC16C39 (I suppose, always to see the area of the flash but in this case I imagine to be a component 16-bit) with display motorola 16bit I see something graphically sensible, but every address in the chart has a value including TWO values on the table are hex...
if I had not had the driver, by the only vision of the hex, as I would never have guessed that I would have to use a display 16bit?
do I have to be already aware of how many bits has the component that I'm reading it, no matter what I see in the tabular hex to make a right choice of the graphical view?
and... are not at all well versed in electronics... motorola from IEEE? this also must be a choice made, already knowing the type of component that I want to read graphically?
You're to make a trip friend.
View as you it seems.. in the end you need to know the value of b.p. and the z-axis. The rest is fuffa
If you want to understand is fuffa, use IDAPro and open the dump that you want. Them understand the difference better.
To me, ecm titanium driver uploaded I motorola 16-bit for this family of controllers.
it is true that visually, taking the known areas is the only type of display that in a graphical sense.
ok, it is just a kind of choice for display graphics and ease of understanding with respect to the table esa or binary...
but... then.. I don't know how to explain.... if I open the file to read the flash of a EDC15C7 (which is a component in 8-bit) value from table for one and the same address is in the table that in 2D graphics, by choosing the " display IEEE 8bit is the same. here not ago na the wrinkle.
if I open the EDC16C39 (I suppose, always to see the area of the flash but in this case I imagine to be a component 16-bit) with display motorola 16bit I see something graphically sensible, but every address in the chart has a value including TWO values on the table are hex...
if I had not had the driver, by the only vision of the hex, as I would never have guessed that I would have to use a display 16bit?
do I have to be already aware of how many bits has the component that I'm reading it, no matter what I see in the tabular hex to make a right choice of the graphical view?
and... are not at all well versed in electronics... motorola from IEEE? this also must be a choice made, already knowing the type of component that I want to read graphically?
Exactly...
Here's to you, I would like to know why on ecm, we have "ieee " and "motorola " and on winols "hi/lo" and "lo/hi" . That seems to me the same thing. Why to 8bit, you cannot change your choice in 16-bit.
Erre are two different ways of saying the same thing...the processor/memory Motorola use data architecture, hi/lo, while the processors/memory Intel(IEEE) have the architecture data in lo/hi..
virtually lohi hilo refers to the "storage method" data in a component that is called simplifying a lot.
If you are interested in the topic search of literature on the processors..you will open a world..
Powered by vBulletin® Version 4.2.2 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.