2011-08-06 03:17 PM
Hello,
I work on a product with master I2C rx and tx, MCU is STM32F295RG.
I started with home made I2C functions for reading and writing using pattern ''send something and brute force while until it's finished'', but faced problems with interrupt priority (if the while loop is interrupted by other interrupts, it can loose the event).
Today I tried the CPAL. First thing, it doesn't work with DMA, it seems the stop condition isn't generated (but both register and data is sent).
Then tried with IT prog mode, and it's working ... BUT, it stills require highest priority interrupts ! I tried method 1 and method 2 (for stop condition sending) and same result, as soon as there is another interrupt with higher priority, I2C is broken.
Problem is I need to reverse the polarity of an USART RX signal, and I'm using an EXTI line to sense each input signal level change and set an output with reversed polarity (which itself is tied to USART3 RX). The USART signal is 100 000 bps, the MCU is clocked at 120MHz, and the EXTI line interrupt must be highest priority for this to work (3% of 100kpbs is 36 clock cycles at 120 MHz).
I just can't manage to get both - I2C and reversed USART - working at the same time :( need help !
Regards,
Thomas.
2011-08-06 03:43 PM
Why wouldn't you just slap an inverter on the USART signal, and stop treating this like a software problem?
74AHC1G04, figure perhaps 5 cents in volume2011-08-07 03:08 AM
Hello,
I tought about it, but there is no room left on the PCB, even for an SC70 inverter.
Moreover, I'll get new sensors with SPI interface instead of I2C, and I hope SPI using DMA will be a lot easier to use with lower priority, but the new sensors won't be available until early september.
What I don't get is why it isn't working ... I mean 100 000 bps is max 100KHz, with a a 120MHz MCU clock there are 1200 clock cycles to handle a very simple GPIO pin read + GPIO pin write.
Say the interrupt switch is 15 cycles, plus 10 cycles for the ISR, that's a 25 more clock cycles latency for I2C interrupts ... but at 400Kbps I2C, 25 clock cycles is 8.3% of one bit timeframe, then the I2C ISR has at least 1100 clock cycles to do its job.
It should be a lot more than necessary, no ?
In CPAL, why is there an option (even a closing method) dedicated to make it work with lower priority, if it is not possible ?
Why CPAL using DMA is not stopping the I2C channel ?
I even don't get why the STM32 I2C needs so high priority to work ? I worked with microchip I2C and you can make it work flawlessly with very low priority, no problem ...
When using the ''do something, wait for it to be finished with a while loop'' pattern, why isn't it working ? Why do you need to catch events so fast, why are they disappearing so fast that you can miss them if a very small ISR happens meanwhile ? Makes no sense to me.
Regards,
Thomas.
2011-08-09 05:52 AM
Hello,
Could you run Basic EEprom example delivered with CPAL Package in DMA and Interrupt mode ??? - How to activate programming model (DMA and Interrupt) : Refer to cpal_conf.h file and uncomment ''CPAL_I2C_DMA_PROGMODEL'', ''CPAL_I2C_DMA_1BYTE_CASE'' and ''CPAL_I2C_IT_PROGMODEL'' defines. Then select specific Mode by setting ''CPAL_ProgModel'' field in main program. Concerning Interrupt priority, check that NVIC_PriorityGroup must be at least set to NVIC_PriorityGroup_2.2011-08-10 12:25 AM
Hello,
Did not test the eeprom example (custom board, no eeprom ...).
When I asked how to activate the DMA programming model, it was more in depth ... I mean I uncommented the defines, etc, but the first communication never stops (no stop condition, CPAL remains in busy tx state, but at least the bytes are sent).
My NVIC priority group is 2.
In fact I don't really care if it's IT or DMA driven, I only read/write short bursts. The priority issue is more of a problem. I already have ITs that need to be served realtime, and as far as I know, I2C also requires highest priority to run correctly. If I was able to run the CPAL with lower priority, even in IT prog model, everything would be fine.
Thomas.