Forum Discussion
Occasional ContributorNiosV and juart-terminal
Summary:
- printf(%f) always prints 0, even if the variable contains valid floating-point number.
Change the On-Chip Ram size from decimal (such as 167.5KB / 167500 bytes) to binary (such as 167KiB / 171008 bytes). - Character é is printed wrongly.
Change the active code page of Windows's command prompt from 437 to 65001 (UTF-8)
- printf(%f) always prints 0, even if the variable contains valid floating-point number.
ContributorHi ETang2
I copied and ran similar code as yours.
However, rather than I2C access (which I don't have), my code directly initialize the numbers in your example.
The memcpy is successful in replacing the values from 0 to valid values.
And juart-terminal prints the correct values.
Could it be possible that you need to change
usleep(3000);
alt_avalon_i2c_master_rx(i2c_dev,rxbuffer, 3,ALT_AVALON_I2C_NO_INTERRUPTS);
to
while(1) {
usleep(3000);
alt_avalon_i2c_master_rx(i2c_dev,rxbuffer, 3,ALT_AVALON_I2C_NO_INTERRUPTS);
if(rxbuffer[1]==0x01) break;
}
When you use breakpoint, there is sufficient delay for alt_avalon_i2c_master_rx() to return rxbuffer[1] = 0x01 at the first attempt.
However, when you let the application to run normally, usleep(3000) is not enough to get rxbuffer[1] = 0x01.
Perhaps it is only possible after a few attempts.
Thus, co2U32, tempU32, and humU32 remains at 0 due to rxbuffer[1] = 0x0.
Which leads to memcpy 0 into the printed variables, that is also 0.
To proof this phenomena, you can define different initial value between the printed variables & intermediary variables. This can help to understand whether it is a memcpy or rxbuffer issue.
float co2Concentration = 888;
float temperature = 888;
float humidity = 888;
alt_u32 co2U32 = 0;
alt_u32 tempU32 = 0;
alt_u32 humU32 = 0;
Regards,
Liang Yu
