6/22/2023 0 Comments Nucleo f446re i2c pinsSelection-mode switch to use the kit as a standalone ST-LINK/V2-1.On-board ST-LINK/V2-1 debugger/programmer with SWD connector.STMicroelectronics Morpho extension pin headers for full access to all STM32 I/Os.GPIO (50) with external interrupt capability.Adaptive real-time accelerator (ART Accelerator™) allowing 0-wait state execution from Flash memory.The STM32 Nucleo board does not require any separate probe as it integrates the ST-LINK/V2-1 debugger/programmer. The Arduino™ connectivity support and ST Morpho headers make it easy to expand theįunctionality of the STM32 Nucleo open development platform with a wide choice of Of course, given the communication fits into 1.5kHz period, which requires some napkin math.The STM32 Nucleo board provides an affordable and flexible way for users to try out new ideas and build prototypes with any STM32 microcontroller line, choosing from the various combinations of performance, power consumption and features. It would be better to poll it at something like 1.5-1.6kHz and just expect data to always be there. You will have uneven time periods between samples, some data will be very fresh, while some data will come with little delay, plus there will be communication without data ready. I don't see much point in I2C-polling the IC at 2kHz if it produces data at 1.6kHz. Since you're smartly and correctly using timer to schedule regular transmissions, you should be able to set the timer in such a way that by the next timer interrupt, which will send data, your previous communication has already ended.įor example, if you set the timer to 1Hz to start transmission, you can obviously be sure that by the next interrupt all the communication has happened. How to achieve that with interrupts and not waste cycles and processing time? Given in your case you can easily estimate the amount of data per each transmission, there is no probem to estimate how much time every transmission will take given your I2C speed. You need to wait until I2C line is idle and available for transmission. The problem is that while your line of code to send something over I2C has already been executed, the data is still being physically sent over the line, just because your MCU is much faster than I2C. The point of that blocking part is to not start an I2C communication while another I2C communication is in progress. You should look deeper at why it is there and how can you implement what it does without blocking. It's only a small example, a proof of concept, so there is some blocking in there. Is this (the example you provided) an efficient way of doing things? No. Using the polling method is too slow as blocking the code at a rate of 2kHz is not inefficient, but the interrupt method doesn't seem to be any faster as I still need to hang the system during the aforementioned while loop to check if I2C is ready for another command. I use a 2kHz timer to send an I2C command to read the acc/gyr data-ready register, and if the data is ready for either sensor I read their 6 bytes to get the x/y/z plane information. In my personal example, I want to collect the accelerometer/gyroscope data at the 1.66 kHz rate which the IMU is capable of. Isn't this a very inefficient way to use an interrupt, and no different from using the standard polling method? Both block the main code, so what's the purpose of the interrupt? Under comment #-3- they explain that unless we wait for the I2C state to be ready again, after sending a command, the next command will overwrite the previous one, so they use a while loop which waits for the I2C state to be 'ready' before continuing. While(HAL_I2C_GetError(&I2cHandle) = HAL_I2C_ERROR_AF) * When Acknowledge failure occurs (Slave don't acknowledge its address) While (HAL_I2C_GetState(&I2cHandle) != HAL_I2C_STATE_READY) Transfer, but application may perform other tasks while transfer operation State of the peripheral if it’s busy you need to wait for the end of currentįor simplicity reasons, this example is just waiting till the end of the * Before starting a new communication transfer, you need to check the current *#-3- Wait for the end of the transfer #*/ * Error_Handler() function is called in case of error. If(HAL_I2C_Master_Transmit_IT(&I2cHandle, (uint16_t)I2C_ADDRESS, (uint8_t*)aTxBuffer, TXBUFFERSIZE)!= HAL_OK) * While the I2C in reception process, user can transmit data through *#-2- Start the transmission process #*/ Here is a snipped of their code from main.c: /* The board sends the message and expects to receive it back */ Specifically I'll be talking about their 'I2C_TwoBoards_ComIT' example, but all their examples which use the interrupt method have this same quirk. I am using STM32CubeMX and checked out all the example code for my board which is related to I2C. I have a Nucleo-F446RE, and I'm trying to get the I2C working with an IMU I have (LSM6DS33).
0 Comments
Leave a Reply. |