| Electronics > Projects, Designs, and Technical Stuff |
| No I2C DMA on a general purpose 32bit MCU? |
| << < (3/5) > >> |
| mikeselectricstuff:
With a hardware i2C peripheral it shouldn't be possible for problems to be caused by poor latency. To get to the bottom of this, it is helpful to put markers on all other ISRs to set a pin while active ( or output fast UART data) so you can tell exactly what is happenning when on the scope. ideally have a pin per ISR stay high for the duration of the ISR to see when interrupts overlap. |
| Ice-Tea:
Just a thought.. 20-30kB of data on a 400kH I²C bus seems a bit like a stretch? |
| Siwastaja:
--- Quote from: SiliconWizard on March 13, 2019, 08:12:51 pm ---On STM32's, DMA transfers are supported with I2C. --- End quote --- On many (especially older) STM32's, it's not very useful, even though there is a "supported" tick in a box. You still need an interrupt-driven state machine to control it, and turn on the DMA transfer at a correct time, and can only DMA part of the transfer. Some newer controllers can do a full DMA cycle with just a single, initial configuration (per transfer), but it is not always obvious whether the controller is capable of this or not. "Supports DMA" claim doesn't suffice, I'm afraid. But as others have pointed out, the lack of DMA isn't the actual problem OP is having. |
| mikeselectricstuff:
--- Quote from: AndyC_772 on March 14, 2019, 08:49:43 am ---Could the USB ISR be clearing multiple interrupt flags rather than just its own? --- End quote --- Make sure you are using the hardware atomic bit ops, i.e. IFSxCLR=1<<_IFSx_xxx_MASK , NOT IFSxbits.xxx=0 Also make sure you are clearing the IF bit at the start of the ISR, in case it gets set again by hardware before the ISR has ended due to other ints. if you clear at the end, you may clear an int that should have been serviced. |
| RoadRunner:
--- Quote from: Siwastaja on March 14, 2019, 10:02:57 am --- --- Quote from: SiliconWizard on March 13, 2019, 08:12:51 pm ---On STM32's, DMA transfers are supported with I2C. --- End quote --- On many (especially older) STM32's, it's not very useful, even though there is a "supported" tick in a box. You still need an interrupt-driven state machine to control it, and turn on the DMA transfer at a correct time, and can only DMA part of the transfer. Some newer controllers can do a full DMA cycle with just a single, initial configuration (per transfer), but it is not always obvious whether the controller is capable of this or not. "Supports DMA" claim doesn't suffice, I'm afraid. But as others have pointed out, the lack of DMA isn't the actual problem OP is having. --- End quote --- Similar problem is with PIC32 as well , you can certainly trigger DMA on I2C interrupt , but I2C interrupt is genrated on 24.4.2.1 MASTER INTERRUPTS Master mode operations that generate a master interrupt are: Start Condition – 1 BRG time after falling edge of SDAx Repeated Start Sequence – 1 BRG time after falling edge of SDAx Stop Condition – 1 BRG time after the rising edge of SDAx Data transfer byte received – 8th falling edge of SCLx (after receiving eight bits of data from slave) During send ACK sequence – 9th falling edge of SCLx (after sending ACK or NACK to slave) Data transfer byte transmitted – 9th falling edge of SCLx (regardless of receiving ACK from slave) During a slave-detected Stop – When slave sets the P bit (I2CxSTAT<4>) if any of these Condition occur, DMA will be triggered which make no sens. you can not mask individual trigger source, which make DMA not very useful for I2C, --- Quote from: mikeselectricstuff on March 14, 2019, 11:30:18 am --- --- Quote from: AndyC_772 on March 14, 2019, 08:49:43 am ---Could the USB ISR be clearing multiple interrupt flags rather than just its own? --- End quote --- Make sure you are using the hardware atomic bit ops, i.e. IFSxCLR=1<<_IFSx_xxx_MASK , NOT IFSxbits.xxx=0 Also make sure you are clearing the IF bit at the start of the ISR, in case it gets set again by hardware before the ISR has ended due to other ints. if you clear at the end, you may clear an int that should have been serviced. --- End quote --- Thank you for suggestion i will look into this now , and report back the results. One more question stucked in my head , what is the point of using I2C in interrupt mode? while device attached on i2c is normally do not have really urgent handling requirements and I2C gives out multiple interrupts even for one byte transfer. if we let I2C running is polling, we will save time wasted in context switching and jumping to and from ISR. Is there a advantage of I2C in interrupt mode vs Polling? |
| Navigation |
| Message Index |
| Next page |
| Previous page |