I'm implementing an stm32 which reads data from an LTM86 sensor and transmits the converted temperature in a CAN bus.
My problem is related to the ADC configuration because the voltage value provided by the ADC is different from that measured on the pin with a voltmeter. As a consequence, the converted temperature will be wrong.
I tried this ADC setup:
Related
I am trying to know the status of MCP3424, either it is connected or not to the master STM32 with defined address 0x68. The ADC module gets connected with the Arduino in same address but using STM32, I am not able to get connected with the following code:
while (1)
{
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
if((HAL_I2C_IsDeviceReady(&hi2c1, 0x68 << 1, 100, 1000))==HAL_OK){
HAL_UART_Transmit(&huart2, "device connected\r\n", 10, 10);
}
else{
HAL_UART_Transmit(&huart2, "no device\r\n", 100, 10);
}
}
Is there any mistake that I have done in this code by chance or any other way there is to deal with MCP3424 ADC module specifically? Please suggest me.
I believe your problem lies with voltage levels: your STM32 functions with 3.3V, while MCP3424 is powered from 5V. Let's open the datasheet of the MCP3424, page 6:
High level input voltage is 0.7Vdd, which is 0.7V*5V=3.5V, which means your A/D can't detect "1" on the line. It sees the line as always "0", even when STM32 MCU outputs HIGH (3.3V).
Possible solutions:
Logic level conversion (various ways). A circuit between A/D IC and MCU to convert 3.3V levels into 5V levels. There are dedicated chips for that, there are also other approaches using resistors and mosfets. Something you may want to explore on electrical engineering stackexchange.
Check the datasheet of the MCU, find GPIO properties. It's very likely those I2C pins are in fact 5V-tolerant, meaning you can pull up I2C lines to 5V and still drive them with 3.3V STM32, and it will be within the spec of STM32 MCU. If that's the case, no extra circuit will be necessary.
I have a STM32F417IG microcontroller an external 16bit-DAC (TI DAC81404) that is supposed to generate a Signal with a sampling rate of 32kHz. The communication via SPI should not involve any CPU resources. That is why I want to use a timer triggered DMA to shift the data with a rate of 32kHz to the SPI data register in order to send the data to the DAC.
Information about the DAC
Whenever the DAC receives a channel address and the new corresponding 16bit value the DAC will renew its output voltage to the new received value. This is achieved by:
Pulling the CS/NSS/SYNC – pin to low
Sending the 24bit/3 byte long message and
Pulling the CS back to a high state
The first 8bit of the message are containing among other information the information where the output voltage should be applied. The next and concurrently the last 16bit are containing the new value.
Information about STM32
Unfortunately the microcontroller of ST are having a hardware problem with the NSS-pin. Starting the communication via SPI the NSS-pin is pulled low. Now the pin is low as long as SPI is enabled (. (reference manual page 877). That is sadly not the right way for communicate with device that are in need of a rise of the NSS after each message. A “solution” would be to toggle the NSS-pin manually as suggested in the manual (When a master is communicating with SPI slaves which need to be de-selected between transmissions, the NSS pin must be configured as GPIO or another GPIO must be used and toggled by software.)
Problem
If DMA is used the ordinary way the CPU is only used when starting the process. By toggling the NSS twice every 1/32000 s this leads to corresponding CPU interactions.
My question is whether I missed something in order to achieve a communication without CPU.
If not my goal is now to reduce the CPU processing time to a minimum. My pIan is to trigger DMA with a timer. So every 1/32k seconds the data register of SPI is filled with the 24bit data for the DAC.
The NSS could be toggled by a timer interrupt.
I have problems achieving it because I do not know how to link the timer with the DMA of the SPI using HAL-functions. Can anyone help me?
This is a tricky one. It might be difficult to avoid having one interrupt per sample with this combination of DAC and microcontroller.
However, one approach I would look at is to have the CS signal created as a timer output-compare (like PWM). You can use multiple channels of the same timer or link multiple timers to create a delay between the CS output and the DMA trigger. You should allow some room for jitter, because depending on what else is happening the DMA might not respond instantly. This won't hurt your DAC output signal though, because it only outputs the value on the rising edge of chip select (called SYNC in the DAC datasheet) which will still be from your first timer.
I am using internal ADC temp sensor , in a low power device without the sensor in stop mode ,the uController consumes around 4 uA but when the temp sensor is on the consumption goes up to 8-9 uA
the problem is i can not turn the sensor OFF / i just measured the off current by setting it off from start by stmcube
i am searching for a code that can turn off the temp sensor
up until now i have tested these:
1-
HAL_ADC_Init(&hadc);
hadc.Lock=HAL_UNLOCKED;
__HAL_UNLOCK(&hadc);
HAL_ADCEx_DisableVREFINTTempSensor();
2-
ADC1->CR&=0X00000000;
ADC->CCR&=~(1<<23);
i prefer to work with HAL , it dose not seems to cut the Sensor power
Your ADC1->CR &= 0x00000000; line looks wrong to me, depending on the controller you're using.
There is usually a bit to disable the ADC which needs to be set, rather than writing all 0s. Try ADC1->CR = (0x01 << 1); instead. If you have the ST Micro written defines for your processor ADC1->CR = ADC_CR_ADDIS; should be the same but more readable. After disabling the ADC you will be able to turn off the TSEN bit of ADC->CCR.
I'm trying to get temperature from LIS3DH sensor (accelerometer with integrated temperature sensor)
I'm using Particle electron board that contain that sensor.
The datasheet provide too few information
set TEMP_EN and ADC_EN from TEMP_CFG_REG register.
I read value that fluctuate continuously and does not correspond, to temperature.
Do you know which register I have to consider to get it works ?
The datasheet states that to connect ADC3 to the temperature sensor, set both TEMP_EN and ADC_EN of the TEMP_CFG_REG register to 1.
Then read OUT_ADC3_L to get the raw value and use the Temperature sensor characteristics table for conversion.
Hope this helps.
I'm relatively new to the I2C protocol and I have to write a c++ library for a particular sensor I have. I'm using a raspberry pi to interface and wiringpi (the i2c component) to handle the low level communications. This is a pretty standard library (read8bits, read16bits, readbuffer, same for write, that support register operations) so all I need to do is the specific, more higher level, sensor operations and export the sensor data to the main project.
But I have a problem, this particular sensor is a 10DOF IMU sensor
(https://www.waveshare.com/product/10-DOF-IMU-Sensor-C.htm) - which provides temperature pressure accelerometer magnetormeter and gyroscope information - and I've managed to get the pressure and temperature sensor reporting just fine but the MPU component is just odd...
So the sensor registers two I2C addresses, one for the pressure/temperature and one for the accelerometer/magnetometer/gyroscope.
Waveshare has a C library which I am using to understand how the sensor works and, for some reason the library is writing to different addresses (different from the registered ones). This particular sensor registers two addresses, 0x77 and 0x68, which I check with i2cdetect but consulting the code it has a particular address for the gyroscope and accelerometer and a separate one for the magnetometer (0xD0, 0x18 again) which should be the same.
So is it normal to do read/writes on addresses other than the registered ones? Would that even work? What am I missing?
The MPU-9255 is actually 2 separate I2C devices, the accelerometer and gyro are accessed on I2C address 0x68 (or 0x69 depending on the logic level of the AD0 pin), the the magnetometer is accessed on I2C address 0x0C.
The accelerometer and gyro I2C address are covered in section 7.2 of the MPU-9255 product specification. The magnetometer I2C address is in section 4.11.
The values that you are seeing in the code (0xD0 and 0x18) are shifted by 1, which leaves room for the I2C read/write bit.
0x68 << 1 = 0xD0
0x0C << 1 = 0x18