Delay interfacing Arduino and Simulink - matlab

I am trying to read data from potentionmeter using an arduino microcontroller (tried both arduino UNO, arduino FIO) and using serial communication interface it to Simulink (I tried baud rates ranging from 57600-921600).
Here is the Arduino source code:
/*
AnalogReadSerial
Reads an analog input on pin 0, prints the result to the serial monitor.
*/
#define ana_pin A0
void setup() {
analogReference(DEFAULT);
Serial.begin(57600);
}
// the loop routine runs over and over again forever:
void loop() {
// read the input on analog pin 0:
int sensorValue = analogRead(ana_pin);
// print out the value you read:
Serial.print(sensorValue);
// delay(500); // delay in between reads for stability
}
I interfaced it with Tera Term software and there is instantaneous change of values corresponding to 3 V or 0V.
However when I tried to interface it with Simulink model using instrument control toolbox:
there is a 10 second lag when value changes from ASCII representation of 3V to 0V
The block sample time is 0.01 seconds and the model configuration parameters are adjusted accordingly (I tried it for 1 second or more and the delay still remains. Also, I was able to record data from another sensor and LPC1768 development board without any delay.
I also tried it with Arduino support libraries in Simulink:
And it seems that no data is received, as you can see from Scope1 in the png file the status signal is always 0. I have also attached hardware implementation properties from Arduino block in Simulink:
Could you help me understand what is going on and how to solve this issue?

#Patrick Trentin -
I get a delay of 4 seconds when I use baud rates of 230400, 460800 and 921600.
For baud rate of 57600, 115200 I get a delay of 10 seconds.
Thank you for pointing it out I did not focus on that previously.
However since I will be using the sensor in an application which accurately needs reading every 0.01 sec. I dont think I can work with 4 sec delay.

Related

Transmitting I2S mic data over UART in STM32

I have interfaced I2S mic (ICS-43434) with STM32f401RET6 board.
I have wired it correctly, now just trying to test the mic by passing the data through UART to my pc. Hoping someone can point me in the correct direction.
I have tried passing straight to the UART transmit. However I think I may need some datahandling - I am receiving from the UART, but sometimes just 0 or other times just gibberish which is not from the Mic as it still transmits even when i disconnect the mic.
I2S mic is receiving data in 24 bits in 32 bit frame, the last 8 bits are junk. The protocol is Big Endian, I am thinking that the HAL library handles this, however I am not completely sure.
uint16_t data;
while (1)
{
/*USER CODE END WHILE */
HAL_StatusTypeDef result= HAL_I2S_Receive(&hi2s1,&data,2,100);
HAL_UART_Transmit(&huart3,&data,2,100);
/*USER CODE BEGIN 3 */
}
/*USER CODE END 3 */
What did I miss?

STM32F04xx UART transmit unreadable chars when HAL_Delay is set higher than 90 milliseconds

I'm working on transceiving data on stm32F04xx. When I transmit data from the MCU at lower speed, it looks like if the baudrate was wrong and I get a bunch of question marks. When I increate transmission speed. I can read the data I'm sending. I've used to stm32cubeIDE to generate a simple UART code and only added
HAL_UART_Transmit(&huart2, "test\r\n", sizeof("test\r\n"), 1000);
HAL_Delay(500);
in the while loop.
On my NUCLEO-F042K6 evaluation board, I don't see any issues printing data on the tty port. But I have another device which uses the same stm32f042xx chip that only works when transmitting UART data at higher speed. so when i change my delay to something like 80 milliseconds, I can read the data flow.
I've attempted to flash the same binary that I flashed on my evaluation board on the other MCU I have but again the data only readable at higher transmission speed.
I'm flashing the MCU with stm32flash tool so I don't know if that can make a difference where on the eval board, I'm using the stm32cubeIDE to flash it.
I'm not sure what's going on here, I've tried different baudrates and different clock configurations and that doesn't seem to help too.
What could possibly cause the data to be unreadable like if the baudrate was wrong when transmitting at low speed?

HAL_ADC_PollForConversion - what exactly is it for?

I've been tinkering around STM32 (F103RB) for a couple of weeks now and one thing I don't get is
HAL_ADC_PollForConversion
function purpose. I mean, I don't see any impact of this function on ADC readings. Here's my code example:
Version 1 (with PollForConversion on)
while (1)
{
HAL_ADC_Start(&hadc1);
HAL_ADC_PollForConversion(&hadc1, HAL_MAX_DELAY);
uint32_t value = HAL_ADC_GetValue(&hadc1);
float voltage = 3.3f * value / 4096.0f;
printf("ADC = %lu (%.3f V)\n", value, voltage); //send the value via UART
HAL_Delay(250);
}
Version 2 (with PollForConvertion off)
while (1)
{
HAL_ADC_Start(&hadc1);
//HAL_ADC_PollForConversion(&hadc1, HAL_MAX_DELAY);
uint32_t value = HAL_ADC_GetValue(&hadc1);
float voltage = 3.3f * value / 4096.0f;
printf("ADC = %lu (%.3f V)\n", value, voltage); //send the value via UART
HAL_Delay(250);
}
As far as my observations go, it doesn't really matter whether I use PollForConversion or not - the readings on the UART monitor look the same (altough I am not 100% certain they actually are the same). Continous mode is disabled. What am I missing here?
After you start ADC with HAL_ADC_Start(), hardware starts ADC conversion. This conversion takes some time. Exact time depends on your ADC configuration in Cube, the greater value of ADC prescaler and cycle count the longer it takes.
After conversion is completed, EOC flag in ADC hardware is set and measured value is placed in register. You can read that value with HAL_ADC_GetValue() function. But if you read it before end of conversion, you will probably get data that is corrupted or an old value from previous measurement.
That's why you should always wait untill EOC flag is set - this is exactly what HAL_ADC_PollForConversion does.
In your example without polling you probably read value from previous measurement before the current one ended. Or maybe HAL functions that interact with hardware are slow enough to actually read data when EOC flag is set anyway. You can increase number of ADC clock cycles in Cube to maximum and try it then, you should get a value from last measurement.

STM32 Temperature sensor power off

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.

ESP8266 + Micropython: Why do I keep getting the same value with periodic i2c reads?

I am writing some simple code using MicroPython running on a Digistump Oak, which is basically an ESP8266 breakout board. I'm trying to understand the behavior that I see when performing periodic reads of the sensors via i2c.
The following code (which reads the value of the ACCEL_XOUT_H and ACCEL_XOUT_L registers) works just fine:
>>> from machine import Pin, I2C
>>> bus = I2C(scl=Pin(2), sda=Pin(0))
>>> while True:
... h, l = bus.readfrom_mem(0x68, 0x3b, 2)
... print (-((((h<<8)+l)^0xFFFF) + 1) if (h & (1<<7)) else (h<<8)+l)
(That print statement is just performing the conversion from two's complement.)
As expected, that prints out values from the accelerometer that change in approximately real time as I move the imu around.
But if I introduce a delay into the loop, such as...
>>> import time
>>> from machine import Pin, I2C
>>> bus = I2C(scl=Pin(2), sda=Pin(0))
>>> while True:
... h, l = bus.readfrom_mem(0x68, 0x3b, 2)
... print (-((((h<<8)+l)^0xFFFF) + 1) if (h & (1<<7)) else (h<<8)+l)
... time.sleep(1)
...I see some very strange behavior. The values returned by the i2c read operation continue to remain the same for many iterations after the imu has changed orientation. I'm at a loss as to what is going on here: the i2c read operations read from the registers on the imu, which according to the documentation are updated at the sampling rate, which in a default configuration is going to be 1Khz. I don't see anything in the code or data path that could be latching or caching these values somehow.
This is the documentation on the accelerometer registers, as found in the Register Map and Descriptions document:
These registers store the most recent accelerometer measurements.
Accelerometer measurements are written to these registers at the
Sample Rate as defined in Register 25.
The accelerometer measurement registers, along with the temperature
measurement registers, gyroscope measurement registers, and external
sensor data registers, are composed of two sets of registers: an
internal register set and a user-facing read register set. The data
within the accelerometer sensors’ internal register set is always
updated at the Sample Rate. Meanwhile, the user-facing read register
set duplicates the internal register set’s data values whenever the
serial interface is idle.
Since I'm sleeping between read calls, I'm pretty sure the i2c serial interface is idle by any definition, and I don't see anything else seems relevant to this behavior.
Do you have any suggestions as to what could be going on here?