Forum Discussion
NiosV and juart-terminal
I had a project which works fine under niosII. I upgrade all the project with niosv and all seems fine except printing values in juart-terminal.
Here is the main code :
#include <stdio.h>
#include "system.h"
#include "altera_avalon_pio_regs.h"
#include <altera_avalon_i2c.h>
#include <unistd.h>
#include <string.h>
int main()
{
//*
ALT_AVALON_I2C_DEV_t *i2c_dev; //pointer to instance structure
alt_u8 txbuffer[20];
alt_u8 rxbuffer[20];
float co2Concentration = 0;
float temperature = 0;
float humidity = 0;
alt_u32 co2U32 = 0;
alt_u32 tempU32 = 0;
alt_u32 humU32 = 0;
ALT_AVALON_I2C_STATUS_CODE status;
i2c_dev = alt_avalon_i2c_open("/dev/i2c"); //Ouverture du périphérique i2c et récupération d'un pointeur
if (NULL==i2c_dev)
{
printf("Error: Cannot find /dev/i2c\n");
return 1;
}
//set the address of the device using
alt_avalon_i2c_master_target_set(i2c_dev,0x61); //Définition de l'adresse du composant adressé 0x61 pour le SCD30
txbuffer[0]=0x00; txbuffer[1]=0x10; txbuffer[2]=0x00; txbuffer[3]=0x00; txbuffer[4]=0x81; //Remplissage du buffer pour configurer le SDC30 en Continous measurement
status=alt_avalon_i2c_master_tx(i2c_dev,txbuffer, 5,ALT_AVALON_I2C_NO_INTERRUPTS); //Envoi du buffer au composant
if (status!=ALT_AVALON_I2C_SUCCESS) return 1; //FAIL
while(1)
{
txbuffer[0]=0x02; txbuffer[1]=0x02; //Remplissage du buffer pour déterminer si les données sont prêtes
alt_avalon_i2c_master_tx(i2c_dev,txbuffer, 2,ALT_AVALON_I2C_NO_INTERRUPTS); //Envoi du buffer au composant
rxbuffer[1]=0x00;
usleep(3000); // Il faut attendre au moins 3ms avant de demander la réponse
alt_avalon_i2c_master_rx(i2c_dev,rxbuffer, 3,ALT_AVALON_I2C_NO_INTERRUPTS); //Récupération de la réponse du composant si rxbuffer[1]==0x01 alors les données sont prêtes
if(rxbuffer[1]==0x01)
{
txbuffer[0]=0x03; txbuffer[1]=0x00; //Remplissage du buffer pour la lecture des données
alt_avalon_i2c_master_tx(i2c_dev,txbuffer, 2, ALT_AVALON_I2C_NO_INTERRUPTS); //Envoi du buffer de lecture et récupération des données
usleep(3000); //Wait 3ms before data available
alt_avalon_i2c_master_rx(i2c_dev,rxbuffer, 18,ALT_AVALON_I2C_NO_INTERRUPTS); //Read datas
co2U32 = (alt_u32)((((alt_u32)rxbuffer[0]) << 24) | (((alt_u32)rxbuffer[1]) << 16) | (((alt_u32)rxbuffer[3]) << 8) | ((alt_u32)rxbuffer[4]));
tempU32 = (alt_u32)((((alt_u32)rxbuffer[6]) << 24) | (((alt_u32)rxbuffer[7]) << 16) | (((alt_u32)rxbuffer[9]) << 8) | ((alt_u32)rxbuffer[10]));
humU32 = (alt_u32)((((alt_u32)rxbuffer[12]) << 24) | (((alt_u32)rxbuffer[13]) << 16) | (((alt_u32)rxbuffer[15]) << 8) | ((alt_u32)rxbuffer[16]));
memcpy(&co2Concentration, &co2U32, sizeof(co2Concentration));
memcpy(&temperature, &tempU32, sizeof(temperature));
memcpy(&humidity, &humU32, sizeof(humidity));
}
printf("---------------------------------------------------------\n");
printf("SCD30\n");
printf("Concentration de CO2 : %f ppm\n",co2Concentration);
printf("Température : %.1f °C\n",temperature);
printf("Humidité relative : %.1f %% \n",humidity);
usleep(500000);
}
}
I put a breakpoint just before the printf and the values are good :
but when i print the values in the juart-terminal :
I can't figure out why the printf does not work as i expect.
Someone could help me to understand this problem ?
Thanks
Eric
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.
14 Replies
- LiangYuG_Altera
Contributor
Hi ETang2
Please find enclosed the tcl export and a screenshot.
Thanks for the BSP Tcl and photo. I am able to replicate the issue in my design.
It is related to the OCRAM size assignment.
Specifically, the idea of 4KiB is 4,096 bytes.
The issue is replicated when the OCRAM is not "power-of-2-aligned", such as 167500 bytes.
Once OCRAM is "power-of-2-aligned" with 171008 bytes, the issue is resolved.Please try a "power-of-2-aligned" OCRAM size in your design.
(Tips: You can input 167k in the OCRAM input parameter, and Quartus will automatically populated as 171008)Regards,
Liang Yu - ETang2
Occasional Contributor
It solve the problem! Thanks.
While I understand the need for this, I don't see which document specifies it. If I remember correctly, I didn't have this problem with the Nios II.
Regards
Eric
- LiangYuG_Altera
Contributor
Hi ETang2
While I understand the need for this, I don't see which document specifies it. If I remember correctly, I didn't have this problem with the Nios II.
Our team is investigating this behavior, before declaring this as a memory requirement.
I will share the findings here once we found something.In the meantime, please continue applying the workaround.
Regards,
Liang Yu - LiangYuG_Altera
Contributor
Hi ETang2
Our team is investigating this behavior, before declaring this as a memory requirement.
We decided to add this requirement in Nios V Embedded Processor Design Handbook, while investigation is still on-going.
Regards,
Liang Yu