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?
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'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?
I'm implementing a virtual instrument on STM32 (STM32F103x). Like a normal "hello world", I tried to start with the simplest MIDI message, sending NOTE-ON MIDI message in a loop to see if it works.
I send MIDI NOTE-ON message for every 500ms, only NOTE-ON message in a forever loop, but it not works. Is there any other MIDI message must be sent to make MIDI works? Like some initialize message?
Based on MIDI 1.0 spec, I finish my code on STM32 by sending MIDI message via USART interface.
Then use a logical analyzer, I confirmed my MIDI message is fully match the MIDI 1.0 spec. At least I believe it correct, no issue. 31250 baud rate, 1 start bit, 1 stop bit, one status message 0x92 followed by two data bytes 0x48 and 0x7F, LSB first.
Below is the NOTE-ON message captured by the logical analyzer on TX line of URAT interface. I continue send the same 3 bytes for every 500ms.
The totally time for those 3 bytes are 960 microseconds also match MIDI 1.0 spec mentioned value.
Then, based on "(CA-033) MIDI 1.0 Electrical Specification Update [2014]", I buy one 5 PIN MIDI OUT jack, connect the URAT TX line to PIN-5 through a 10 Ohm resister, connect 3.3V power to Pin-4 through a 33 Ohm resister, PIN-2 and Jack shield connect to GND. Other optional parts (buffer for Rc, ferrite beads) are not used.
However, when I use a USB-MIDI wire connect my MIDI OUT jack to my PC, nothing happen. The USB-MIDI wire has two LED indicators , one for power another for MIDI signal. After connect, the power LED is light, but the MIDI signal LED never light.
I tried to use logical analyzer to analysis PIN-5 of my MIDI OUT jack, the MIDI message byte are totally same with URAT TX line, and every 500ms one NOTE-ON message. However, it never works.
I also tried to create my own PCB with Dream SAM2695 by follow the SAM2695 Evaluation Boards. Then connect the URAT TX directly to MIDI_IN pin of SAM2695, it still no response. Since I have no confidence on my manual soldering PCB, not sure if the PCB itself has issue cause it no response. So I buy a USB-MIDI wire, but the result as I mentioned above, still no response.
======= Apr.26.2021 Update =========
Based on comments, have tried to check the output of the optocoupler.
Before do this check, I bought several BSS138 to transform the MIDI signal to 5V single use below circuit (of course change the resisters near MIDI JACK pin to 220 Ohm as the spec)
After this change I measured voltage of the 5V URAT TX, it show as 4.8+ V, and Logical Analyzer show correct MIDI note on message of this new 5V MIDI signal. However, it still not works.
The only left troubleshooting method for me is measure the output of the optocoupler on this USB-MIDI wire. But I didn't find an optocoupler on this MIDI USB wire PCB. There even do not have any one component has 4 pins on the PCB (based on my understanding, an optocoupler need at least 4 pins).
There only have one main chip on the PCB, it is possible that the optocoupler is embedded in that chip? Since the pin are too small I failed to connect my logical analyzer to those pin to check.
I'm trying to run the code below on an ESP32 TTGO T-display running micropython from loboris. (It's esp32 pre-loaded with display drivers for TTGO Display) I have attached a GY-906 temp sensor through i2c for testing. i2c.scan() finds it without issue on 0x5a [80] like it is supposed to, but when I request temperature data, the response is always 0xFF instead of proper temperature readings.
When I run the exact same code on a WeMos D1 (only difference is the pin numbers) I get temperature data returned. I am attaching both logic analyzer screenshots hoping someone can tell me what I need to do differently. Both are directly wired from 3.3, gnd, and the 2 i2c pins.
Things I have tried: adding pull up resistors to SDA, SLC (10k, 1k, 100). Switching to different i2c pins. Result seems to be the same. What am I missing? Is there supposed to be a resistor somewhere I don't know about? Other hardware? The screenshots make me think that the GY906 is responding, just the wrong response value.
Main Code
import temp_sensor
Pin = machine.Pin
I2C = machine.I2C
i2c = machine.I2C(0, scl=Pin(22), sda=Pin(21), freq=100000)
temp1 = temp_sensor.Temp.init(i2c)
print(temp1.read_object_temp())
time.sleep(1)
print(temp1.read_object_temp())
time.sleep(1)
print(temp1.read_object_temp())
time.sleep(1)
print(temp1.read_object_temp())
temp_sensor.py
import mlx90614 ##From https://github.com/mcauser/micropython-mlx90614
class Temp():
def init(i2c):
try:
sensor = mlx90614.MLX90614(i2c)
except:
print('couldnt connect to an i2c temp sensor')
sensor = False
else:
print('temp found')
#return sensor
finally:
return sensor
bad esp32 TTGO T-Display:
good 8266:
For anyone receiving 1037.55 responses from your gy-906 or MXL90614 sensor, that translates to 0xFF, 0xFF or all high (ones) from the sensor. This seems to happen when the sensor doesn't understand how to respond. (Thank you, #jasonharper for helping me understand this)
Here's how the math works:
The 0xFF, 0xFF in decimal is 65535.
The sensor resolution is 1/50 of
a degree which means you divide 65535 x 0.02 to convert to Kelvin, or
1310.7 (K)
Kelvin to Celsius (subtract 237.15) gets you 1037.55 C
Celsius to Fahrenheit gets you 1899.59 F
Bottom line, your sensor is hiccuping because it doesn't like the stop bit between the write and read, or you have a problem with your I2C bus, either the protocol is doing the request wrong or you have a cabling issue (length or wire gauge or connection, etc).
If it's the protocol like it was for me, see if anyone has updated the I2C system library recently and try a different version if possible.
I traced this issue down for days. Luckily I had a number of different MicroPython capable chips and was able to narrow it down to an old version of the machine.I2C library adding that stupid "stop" above.
I bought a $10 protocol analyzer on amazon to make that image above, and I tried loading the code on each of these: Wemos D1, HitLego ESP32S and TTGO T-Display. By trying the code on each, I was able to narrow it down to only the T-Display not working, which needed an custom old firmware version to get the ST7789 display working. The next step is to try to update and recompile the display library from loboris to work with the most recent Micropython firmware. If I make it work, I will reply below.
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.