Matrix user forums

hello,

I discovered some problems with floating point calculations (increment, decrement) on floating point values after the programm is correctly simulated (AVR flowCode V4) and compiled from c to hex file by both AVR FlowCode V4 and AVR Studio 4.18 SP2.
I am using the ATMEL STK500 board (with the new firmware wich was updated by AVR Studio 4.18 SP2) to program the hex files to the chip.
Only the result by AVR FlowCode simulation works very well.

1. The output of the floating point calc in string format is not send to LCD.
2. Also the LCD display will not correct initialise and makes an onstable impression.
3. Also noticed a difference when hex file is programmed to the chip between AVR studio 4.18 SP2 (led is flasing by rotating de rotary switch and LCD not initialised) and when using AVR FlowCode V4 (nothing happens correct)

Both programs AVR studio and flowCode give no errors when c files where compiled to hex and then programmed by stk500 to the chips. (i pay specially attention to the fuse settings and used the same fuse settings for both AVR studio and AVR flowCode V4. for ATmega88 (0x0,0xF9 - 0x1,0xDF - 0x2,0xFF) for ATmega16 (0x0,0xD9 - 0x1,0x7F) and for ATmega128 (0x0,0xFF - 0x1,0xD9 - 0x2,0x7F)
To get no compilation errors i have taken care of the directory path depth. If the directory path has to many sub directories then errors coming up for both AVR Studio 4.18 and AVR flowCode V4.

I had also taken care of using the output port configuration for LCD, and no using interrupts (disabled) on input port (this is the nex step).

I have written a test programm and used it for ATmega128, ATmega16 and ATmega88 and get for all of them the same results wich are not correct in what i am expected in compare with the result by simulation. The result by AVR FlowCode simulation works very well.

Are their another people who have the same experiences like me when using the floating point in their programs which are programmed on HardWare ???

My PC equipment is a Quad Core Intel Q9550, 8Gbyte RAM, Windows 7 Pro 64bit

Hello Huib,

Unfortunately this problem highlights the practical limitations of floating-point number representations. Although very large and very small numbers can be represented, the precision is limited to approximately 7 significant figures for standard floating-point variables. Double precision maths (as used in Flowcode for ARM) is only practical with more powerful devices.

144.000000 requires 9 significant figures, and increments of 0.000001 will probably be lost in rounding.

Can you accept larger frequency steps? 0.0001 should be achievable.

Hello Sean,

Thanks for your reply.

Yes for the moment i can accept, and is also the answer i was afraid of to do floating point operations by AVR 8 bit family
But the reason i need this resolution is that mine DDS Core has a 32 bit FTW resolution and want to make 1 Hz step resolution possible.
Simular asm programms can do that, but with restriction in complex calculations

And yes the ARM should do that job easier the only thing is that there is no Float to String function available in ARM FlowCode yet and i hope that this can be soon available.


Kind Regards

Huib

One possibility for numbers in the range you require, if you are ok using C or assembler from within Flowcode, is to use the variable type 'long' (32-bit), and display the frequency in Hz.

All the maths will be integerised (no rounding problems) and you will be able to use steps of 1Hz.

The C compiler includes a standard C function that can convert many numeric types to strings (including 'long').

The example below will convert the long C variable 'lVar' to a string and save it in the Flowcode string variable 's'.

sprintf(FCV_S, "%ld", lVar);

The forum article 'V4 AVR Floating-point' describes how to set up Flowcode to provide access to the sprintf() function. Other postings describe how to mix Flowcode and C, and how to share some types of variables (unfortunately not 'long' types).

It might be possible to complete your project with a suitable mix of Flowcode and C/assembler.

I have not noticed any problems with the LCD. I am using a Matrix EB-019 AVR board.

The fuse settings are:

0x0, 0xdf
0x1, 0xff
0x2, 0xff

Hello Sean,

Thanks for your comment, i shall try out your given possibillities to get de 1 Hz step functional in my program.
Also i have to do this for some conversions which is nessessary for the Frequency-tuning word to DDS in 4 byte hex to send by SPI, which is depending on DDS sytem clock and FT = Frequency LCD readout.

The LCD init problems for all the chips i found out later that this lays on wrong LCD pin definition on portpins 5 (R/S) and 6 (Enable) were changed and have corrected this so the LCD instabillity issue is solved.

Kind regards

Huib

A C code 'long' integer can be very easily split into 4 separate bytes. These can be passed back to Flowcode and used with the SPI component.

In this case the use of floating-point variables would make everything much more complicated.

Sean,

I understand that there are other ways to do that, but my knowledge about C and variable funtions and declarations is very very little.
And the function floating point in combination with float2string looks like very easier to understand for me and not direct realising how it is done behind flowcode after compiling to 8bit chips.

But flowcode can help me get a better understanding about C and later on i hope i can do some routines in C in combination with flowcode.

Anyway thanks for your comment and suggestions you have made it can help me to find the right way to search for a solution that i can use in my program.

kind regards

Huib