CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

IEEE floats Modbus - always 0 - CLOSED

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Gabriel



Joined: 03 Aug 2009
Posts: 1057
Location: Panama

View user's profile Send private message

IEEE floats Modbus - always 0 - CLOSED
PostPosted: Tue Dec 14, 2021 5:31 pm     Reply with quote

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: 21667

View user's profile Send private message

PostPosted: Tue Dec 14, 2021 11:50 pm     Reply with quote

I made a complete test program. Then I was able to make it work.
The program shown below displays the following:
Quote:
FLOAT: 6.740

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: 18130

View user's profile Send private message

PostPosted: Wed Dec 15, 2021 8:08 am     Reply with quote

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: 1057
Location: Panama

View user's profile Send private message

PostPosted: Thu Dec 16, 2021 11:52 am     Reply with quote

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: 18130

View user's profile Send private message

PostPosted: Thu Dec 16, 2021 12:26 pm     Reply with quote

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: 1057
Location: Panama

View user's profile Send private message

PostPosted: Thu Dec 16, 2021 12:54 pm     Reply with quote

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: 1057
Location: Panama

View user's profile Send private message

PostPosted: Thu Dec 16, 2021 1:37 pm     Reply with quote

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: 1057
Location: Panama

View user's profile Send private message

PostPosted: Thu Dec 16, 2021 1:44 pm     Reply with quote

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: 18130

View user's profile Send private message

PostPosted: Fri Dec 17, 2021 8:49 am     Reply with quote

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: 18130

View user's profile Send private message

PostPosted: Fri Dec 17, 2021 12:01 pm     Reply with quote

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.... Sad
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: 1057
Location: Panama

View user's profile Send private message

PostPosted: Sat Dec 18, 2021 3:10 pm     Reply with quote

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: 18130

View user's profile Send private message

PostPosted: Sun Dec 19, 2021 4:25 am     Reply with quote

Private message me with your email address.
Gabriel



Joined: 03 Aug 2009
Posts: 1057
Location: Panama

View user's profile Send private message

PostPosted: Sat Jan 01, 2022 8:04 am     Reply with quote

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: 18130

View user's profile Send private message

PostPosted: Sat Jan 01, 2022 9:33 am     Reply with quote

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. Very Happy

Happy New Year.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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 vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group