I am using stm32f4 on discovery board with freertos running on it.
Just started working with stm32 controller and trying to make data transfer using UART. Printf based on HAL_UART_Transmit works perfectly, but receiving data isn't working.
According to numerous tutorials it should be very simple. I create a project in Stm32CubeMX, add all necessary stuff (freertos, USART3, NVIC), enable USART3 global interrupt and generate the code.
I'm trying to add HAL_UART_Receive_IT(&huart3, &rx_char, 1); or something similar in a task and it doesn't do anything. I suppose it flies through it very fast and doesn't wait for characters to be sent from the terminal.
What do I miss here?
Related
I'm having trouble with i2c communication. In my i2c bus, i have 4 boards (STM32L4 Sensortiles) and sometimes one of them blocks the bus and the others stop communicating consequently. When I reset that one that blocks the bus, all boards starting working again.
In my debugs, this bug happened when HAL_I2C_GetState(&hi2c3) returns HAL_I2C_STATE_BUSY_RX, even my others i2c functions HAL_I2C_Slave_Receive_IT and HAL_I2C_Slave_Transmit_IT returns HAL_OK:
Any ideas what Im doing wrong? Thanks.
Using libraries like HAL leads to problems like this one. Why?
HAL users feel free from knowing your hardware as magic library will do everything for you.
HAL users usually do not know how the peripheral works and how to debug it.
HAL users do not bother to go through the magic HAL function to see what the problem is.
Posting some images form debugger will not help.
What you need to do:
Get even the cheapest logic analyzer (there are $10 on ebay) and record the communication. See if the slave keeps the clock or data line low. If yes toggle the clock pin 9 times to unblock the line
If nothing helps reset the I2C peripheral using RCC register (it has to be implemented on all connected boards).
I'm working on a project that is using a Raspberry Pi with Raspbian and an SGTL5000 based sound card (FePi.) I have no problem selecting the card and getting samples in both directions - once I have configured the multiplexer to properly select line In/Out. I did this with Alsamixer. I want to automate the process so that the only step required is to run the application.
I don't see a way to do this using PyAudio/PortAudio. Is my only option the ALSA API or is there a way to do this with PyAudio (or PortAudio) that I'm not spotting?
Thanks in advance for any insight you can provide.
Oz (in DFW)
I ran into a similar problem, I wanted to automate changing mux settings but I wanted to adjust inputs not exposed by alsamixer too.
To deal with the limitations of the driver I ended up porting over the Teensy 3.x sgtl5000 control software to the pi yesterday
https://github.com/Swap-File/pi-sgtl5000
You could force feed the same commands via i2c via python.
The only downside is, once you start force feeding the sound card i2c commands, you break alsamixer (and anything else that might try to adjust it's own volume settings).
I have been having an issue in my project with LWIP. I am using a ST32F4 MCU and running with no OS. The network seems to run fine, the protocols all work, but then (usually a day or two later) the stack just stops running. It seems to happen when trying to make a new connection, but I can't confirm that because I haven't been able to locate what is causing it in the code.
Has anyone else come across this issue? I think it may be the same as this guy.
Do you call any LwIP functions from any interrupt-handlers, like UART etc?
How do you feed packets in/out of LwIP? Directly via interrupt handlers, or do you push them in from your "main-loop" ?
Lock-ups can also be signs of double free, or use-after-free of pbufs.
I also experiences that one project was unstable with wierd random locks-ups when running at the top-rated frequency of the STM32. If I clocked my STM32 at 100MHz instead of 120MHz, all my problems went away....
I'm trying to use the lpc1343 as a i2cslave to transmit some data. Writing to the board gives no problems and works exactly as I want it.
However, reading from the board gives problems. It seems I'm not getting any data back although I am sending the right commands. Whenever I try to debug it my board just hangs and I have to reset the driver and my pc to get it running again.
Also, I made a LED go on/off whenever I try to read from it. It only does this once and whenever I try to do it again nothing happens. I think the I2c is stopped then but I have no idea why.
I have found the example code on the website once but now it seems to be gone. Does somebody have an updated I2cslave code?
Which operating system are you writing code for and how can you tell that writing to the i2c chip is successful?
If the write function returns, it could be that the message has been sent but the chip is in a weird configuration that doesn't act on the message received.
I am working on a university project in which i need to interface pic18f4550 with i2c EEPROM.
I implemented the following circuit using proteus simulator. The following in my connections
when I implemented the interfacing on real, I faced a problem when the PIC reads from the eeprom. it is suspended and so I was not able to see if the reading operation was performed correctly.
What could be the problem?
You do need to make sure you are following the I2C protocol for reading an EEPROM, and that is best served with a state machine on a PIC.
Try sequencing through the following actions, making sure your flags are set correctly:
Start condition
Write to the EEPROM with the address to which you want to read.
Repeated Start condition.
Read from the EEPROM as many bytes as required (keep in mind that the EEPROM is paged, and you will roll over if you go past a page boundary.)
Stop condition