| View previous topic :: View next topic |
| Author |
Message |
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
| IEEE floats Modbus - always 0 - CLOSED |
 Posted: Tue Dec 14, 2021 5:31 pm |
 |
|
Hi All,
Its been a while since I've posted, i hope you are all well.
I'm working with an old proven driver, and for some reason this always returning 0.
I was inputting the int32 via make32 but that was not working.
Feeding the int32 directly as below also returns 0 when it should be 6.74
| Code: | ModBus_Type_F=f_IEEEtoPIC(0x40D7AE14);
fprintf(FTDI,"FLOAT:%3.2f\r\n",ModBus_Type_F); |
If i print the float as a %lX it just 00000000.
My settings:
| Code: | #include <18F47Q43.h>
#device PASS_STRINGS=IN_RAM
#device adc=10
#fuses MCLR
#fuses NOWDT
#fuses NOLVP
#fuses NOXINST
#fuses NODEBUG
#fuses NOPROTECT
#fuses HS
#fuses RSTOSC_EXT_PLL
#use delay(clock=64MHz) |
Thanks,
G.
_________________
CCS PCM 5.078 & CCS PCH 5.093
Last edited by Gabriel on Sat Jan 01, 2022 8:05 am; edited 1 time in total |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Dec 14, 2021 11:50 pm |
|
|
I made a complete test program. Then I was able to make it work.
The program shown below displays the following:
MPLAB vs. 8.92 doesn't support the 18F47Q series, so I used
18F46K22 for testing (in the simulator).
If the data type shown below (float for the variable) isn't what
you are doing, then please post your own (short) test program.
Test program:
| Code: |
#include <18F46K22.h>
#fuses NOWDT
#use delay(internal=4M)
#use rs232(UART1, baud=9600, ERRORS, stream=FTDI)
#include <ieeefloat.c>
//=================================
void main()
{
float ModBus_Type_F;
ModBus_Type_F = f_IEEEtoPIC(0x40D7AE14);
fprintf(FTDI, "FLOAT: %7.3f \r\n", ModBus_Type_F);
while(TRUE);
}
|
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Wed Dec 15, 2021 8:08 am |
|
|
The critical thing is how ModBus_type_F is defined?.
What you try to do seems 'odd', since if this is a float for transmission on
ModBus, then it would need to be in IEEE format. You are calling the function
to turn an IEEE into MicroChip format. |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Thu Dec 16, 2021 11:52 am |
|
|
Hi thanks for the responses.
ive done a simple sample program and the result is still the same.
always 0.
| Code: | #include <18F47Q43.h>
#device PASS_STRINGS=IN_RAM
#device adc=10
#fuses MCLR
#fuses NOWDT
#fuses NOLVP
#fuses NOXINST
#fuses NODEBUG
#fuses NOPROTECT
#fuses HS
#fuses RSTOSC_EXT_PLL
#use delay(clock=64MHz)
#include <string.h>
#include <stdlib.h>
#include <ieeefloat.c>
#include <Hardware - Rev_2.h>
//==========================
float ModBus_Type_F=55.55;
void main()
{
setup_oscillator(OSC_EXTOSC_PLL|OSC_CLK_DIV_BY_1|OSC_PLL_ENABLED|OSC_EXTOSC_READY);
while(TRUE)
{
ModBus_Type_F=f_IEEEtoPIC(0x40D7AE14);
fprintf(FTDI,"FLOAT:%7.3f\r\n",ModBus_Type_F);
delay_ms(1000);
}
}
|
Ttelmah, "Modbus_Type_f" holds the response for the slave device. the modbus device responds in IEEE and im trying to convert it to PIC for procesing. i built the driver to read slave devices and place the result in 1 of 3 posible variables, floats, ints, bool... ive used this driver before on the PIC 18F67K40 with no issues.
im now wondering if its the PIC thats the problem since i know the driver works, and PCM_Programmers test code worked.
G.
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Thu Dec 16, 2021 12:26 pm |
|
|
Which of the two compiler versions you list are you using?.
I'll try a build of PCM Programmers code with your compiler, and see
what it does on your chip. |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Thu Dec 16, 2021 12:54 pm |
|
|
Im using 5.093 PCH
so in a debuging effort, i took the ieeefloat.c and removed all the stuff for other compilers, just leaving the basic required functions for my setup.
i then printed the int32 as received:
| Code: | float f_IEEEtoPIC(int32 f)
{
fprintf(FTDI,"raw:%LX\r\n",f); |
raw prints out to 0 too... WTF.
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Thu Dec 16, 2021 1:37 pm |
|
|
I just tried running this on a PIC18F87J50:
| Code: | #include <18F87J50.h>
#DEVICE PASS_STRINGS=IN_RAM
#DEVICE *=16
#DEVICE adc=10
#fuses NOWDT
#fuses NOXINST
#fuses NODEBUG
#fuses NOPROTECT
#fuses HSPLL,NOCPUDIV,NOIESO,NOFCMEN
#fuses PLL2 //set usb pll clock to 4MHz (from 8Mhz input)
#fuses NOCPUDIV //set cpu clock to 48MHz
#use delay(clock=48MHz)
#use rs232(UART1,baud=9600, BITS=8, PARITY=N, STOP=1, xmit=PIN_C6, rcv=PIN_C7,ENABLE=PIN_G0, ERRORS,STREAM=U1) //Modbus
#use rs232(UART2,baud=9600, xmit=PIN_G1, rcv=PIN_G2, ERRORS,STREAM=FTDI) //GSM
#include <string.h>
#include <stdlib.h>
#include <Ieeefloat.c>
//==========================
float ModBus_Type_F=55.55;
void main()
{
setup_oscillator(OSC_PLL_ON);
while(TRUE)
{
ModBus_Type_F=f_IEEEtoPIC(0x40D7AE14);
fprintf(FTDI,"FLOAT:%7.3f\r\n",ModBus_Type_F);
delay_ms(1000);
}
} |
same code as before just different pic, no issues at all.. it ran perfectly.
Its tied to the PIC18F47Q43 for some reason?
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Thu Dec 16, 2021 1:44 pm |
|
|
ran the same code on an earlier revision of the board using the 18F47Q43, and i have the same problem, ieeetoPIC returns 0 always.
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Fri Dec 17, 2021 8:49 am |
|
|
This is beginning to 'ring a little bell'. I went back and had a look through
all my emails to CCS about problems, but haven't been able to find it.
However I have a memory that there was an issue with the rotation handling,
on certain chips, about a dozen compilers ago. I think it was only there when
you did accesses with a structure.
The IEEE conversion routines rely on this type of access.
Just tested and on the current compiler, it gives a correct output built
with this chip.
No, scrub that it has a slightly different problem but still not right.
It's the handling of the passing the value into the function that is not
working. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Fri Dec 17, 2021 12:01 pm |
|
|
OK. A bit more research.
It is the #locate that is causing the issue. If you look into the ieee conversion
routines, they force the value passed to address 0x20. It is this that breaks
the routine on the Q43 chip. After this is done, the variable contains '0'.
Before this is done it has the right value. This then means the code inside
the routine does not actually get the value to be converted.... 
They do this so they can use hard coded assembler to actually perform the
shifting.
I tried copying the ieee conversion library, and changed the #locates,
and the assembler to use 0x520 instead of 0x20, and it then works. Quite
a lot of fiddling needed.
Now I can't see any reason in the data sheet that address 0x20 won't work
on this chip.
It looks as if nobody has actually used the Q43 and the ieee routines, so
this has not been seen. I can send you the bodge to make it work if
you want, but I would say contact CCS.
Revise that, it's because on these chips 0 to 0x5F, is the fast SFR area,
not normal RAM. So mapping to 0x20 doesn't work.
Last edited by Ttelmah on Sun Dec 19, 2021 10:33 am; edited 1 time in total |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Sat Dec 18, 2021 3:10 pm |
|
|
Hi Ttelmah,
thank you for your indepth analisis... I would certainly appreciate your bodge code while ccs responds officially. that is way above my understanding, i dont remember any of my ASM. i dropped that like a bad habit the same day i discovered CCS back in 2001.
I've contacted CCS support and forwarded the sample program and LST.
i found a bug! yeih!
Thank you
G.
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Sun Dec 19, 2021 4:25 am |
|
|
| Private message me with your email address. |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Sat Jan 01, 2022 8:04 am |
|
|
Thank you for your help with this.
As pointed out by Ttelmah (via PM) there is an issue with the ieeefloat.c driver.
If you experience the same, contact CCS!
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Sat Jan 01, 2022 9:33 am |
|
|
As a comment, it is specific to chips which have the fast SFR access banks
at the bottom of the RAM. I have my own fixed version. CCS has worked on
a fix, and say this will be in the next compiler, but the ones they have so
far produced still have a problem on these chips!...
I've sent them my fix, so hopefully they will get it right in the New Year. 
Happy New Year. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
