PCM Logger 014 reading RAM addresses
PCM Logger 014 reading RAM addresses
When using PCM Logger 014 to read PCM addresses from 0xFF8000 to 0xFFC000 it always returns 0s. Reading registers above this RAM space always returns 0s. I tried using the PCM Logger 014 Example 2 log file and all of the RAM addresses log as zero when using the 3358 PCM. Is there something else that needs to be enabled? I saw a thread on WB Logging where they were trying to read the A/D at address FFFF2C2 and also received 0s.
Re: PCM Logger 014 reading RAM addresses
Please try: PcmHammer16D-Preview
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Re: PCM Logger 014 reading RAM addresses
Thank you for the link to the latest. When I run that version of PCM Logger 016D-Preview and the 3358.RamParameters.LogProfile none of the RAM variables are listed in the CSV Log file. With PCM Logger revision 014 the RAM variables are listed but are always set to 0.
Re: PCM Logger 014 reading RAM addresses
I noticed the Pcm Logger 016-D Preview 2 byte calculations are not what I expected. I changed the bin to force a run time of 0xF080, and did the same for the MAF sensor PID so I could report RAM address location values. Something strange is going on with the MSbit assuming a sign position and how the remaining 7 bits are used. It is not a standard 2s complement.
I expected to see 0xF080 = 61,568 is Pcm Logger assumes unsigned which the XML assumes since does a MSB*256
or a -61,568
From the Parameters.Standard.file
<Parameter
id="11A1"
name="Engine Run Time"
description=""
byteCount="02"
bitMapped="False">
<Conversion units="Boolean" expression="((x_high*256)+x_low)" format="0.00" />
I think for now I will just report the RAM Address WORD sized data using two different byte sized PIDs which seem to not assumed 2s complement data.
I expected to see 0xF080 = 61,568 is Pcm Logger assumes unsigned which the XML assumes since does a MSB*256
or a -61,568
- codechange.PNG (5.81 KiB) Viewed 2922 times
<Parameter
id="11A1"
name="Engine Run Time"
description=""
byteCount="02"
bitMapped="False">
<Conversion units="Boolean" expression="((x_high*256)+x_low)" format="0.00" />
- pcmlogger016D.PNG (45.42 KiB) Viewed 2922 times
Re: PCM Logger 014 reading RAM addresses
Can you post your modified bin file?
That will make this easier to debug.
Thanks!
That will make this easier to debug.
Thanks!
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
Re: PCM Logger 014 reading RAM addresses
Hi,
I figured out what happened. Here is how it goes. I was reporting a value of 0xF080 in the Mass Airflow PID.
MSB = 0xF0
LSB = 0x80
The Pcm Logger assumes the MSB of the Airflow PID is SIGNED, and the LSB is UNSIGNED.
2s complement of 0xF0 is NOT(0xF0)+1 = 0x10 = -16 decimal
Pcm Logged computes this : -16 *256 + 128 = -3968
It does the same for the EngineRunTime so if the MSByte bit 7 is ever set it will start reporting negative. I am guessing it does this for all of the PIDS that report 2 bytes.
I figured out what happened. Here is how it goes. I was reporting a value of 0xF080 in the Mass Airflow PID.
MSB = 0xF0
LSB = 0x80
The Pcm Logger assumes the MSB of the Airflow PID is SIGNED, and the LSB is UNSIGNED.
2s complement of 0xF0 is NOT(0xF0)+1 = 0x10 = -16 decimal
Pcm Logged computes this : -16 *256 + 128 = -3968
It does the same for the EngineRunTime so if the MSByte bit 7 is ever set it will start reporting negative. I am guessing it does this for all of the PIDS that report 2 bytes.
Re: PCM Logger 014 reading RAM addresses
Yes, I think you've got it figured out.
I'm pretty sure that you can now use just "x" instead of combingin the x_high and x_low values in the expression, but the "x" value is going to have the same problem because it is computed the same way.
In the Subaru logger definitions from the RomRaider project, there's a storagetype attribute, so for example you can say storagetype="uint8" or storagetype="int16" or whatever. That tells the code how to avoid this kind of problem. I'll add the same thing here, and use that in place of the byteCount attribute that's in there now, since storagetype also indicates the number of bytes.
I'm pretty sure that you can now use just "x" instead of combingin the x_high and x_low values in the expression, but the "x" value is going to have the same problem because it is computed the same way.
In the Subaru logger definitions from the RomRaider project, there's a storagetype attribute, so for example you can say storagetype="uint8" or storagetype="int16" or whatever. That tells the code how to avoid this kind of problem. I'll add the same thing here, and use that in place of the byteCount attribute that's in there now, since storagetype also indicates the number of bytes.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
Re: PCM Logger 014 reading RAM addresses
I posted a zip file here that should fix the issue, please give it a try and let me know how it goes:
viewtopic.php?f=42&t=6688&p=107406#p107406
The x_high and x_low stuff is gone, now there is just x and it should always be correct.
The byteCount attributes have all been replaced with storageType attributes.
viewtopic.php?f=42&t=6688&p=107406#p107406
The x_high and x_low stuff is gone, now there is just x and it should always be correct.
The byteCount attributes have all been replaced with storageType attributes.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
Re: PCM Logger 014 reading RAM addresses
Hi,
I ran the 16E pcmlogger.exe and Win10 reported an unhandled exception. I have attached the Win10 debug report. I clicked on the exception window "continue" button and then PcmLogger allowed me to select a param file. I selected the 3358 param file in the same directory. The log window then reported it could not evaluate the "Engine Speed" equation and displayed it. The equation did appear to be correct.
I ran the 16E pcmlogger.exe and Win10 reported an unhandled exception. I have attached the Win10 debug report. I clicked on the exception window "continue" button and then PcmLogger allowed me to select a param file. I selected the 3358 param file in the same directory. The log window then reported it could not evaluate the "Engine Speed" equation and displayed it. The equation did appear to be correct.
- Attachments
-
- pcmLogger16E_Log.txt
- (5.21 KiB) Downloaded 120 times
Re: PCM Logger 014 reading RAM addresses
It occurred to me you mentioned only "x" exists now in 16E. The "standard" file in the Pcm Logger 16E directory contains both "x" and "y" in the 16 bit equations. This is likely the reason PcmLogger 16E is failing and reporting the unresolved equation for the Engine Speed since it is the first x and y equation it encounters. I will try modifying the equations later to just use x * K instead of (x*256 + y) * K.