| Electronics > Projects, Designs, and Technical Stuff |
| No I2C DMA on a general purpose 32bit MCU? |
| << < (4/5) > >> |
| mikeselectricstuff:
--- Quote from: RoadRunner on March 14, 2019, 03:29:18 pm ---Is there a advantage of I2C in interrupt mode vs Polling? --- End quote --- I2C is fairly slow, so you may not want to wait around for transactions. |
| RoadRunner:
--- Quote from: mikeselectricstuff on March 14, 2019, 04:04:42 pm --- --- Quote from: RoadRunner on March 14, 2019, 03:29:18 pm ---Is there a advantage of I2C in interrupt mode vs Polling? --- End quote --- I2C is fairly slow, so you may not want to wait around for transactions. --- End quote --- With Polling i am actually thinking about preidically (in idle loop, or even better wtih limited maximum polling rate ) checking for status and acting on it, program flow will just return if nothing need to done, flow will not wait there to finish i2c things. will intrrupt still holds any adantage over such polling driver? |
| mikeselectricstuff:
--- Quote from: RoadRunner on March 14, 2019, 04:11:04 pm --- --- Quote from: mikeselectricstuff on March 14, 2019, 04:04:42 pm --- --- Quote from: RoadRunner on March 14, 2019, 03:29:18 pm ---Is there a advantage of I2C in interrupt mode vs Polling? --- End quote --- I2C is fairly slow, so you may not want to wait around for transactions. --- End quote --- With Polling i am actually thinking about preidically (in idle loop, or even better wtih limited maximum polling rate ) checking for status and acting on it, program flow will just return if nothing need to done, flow will not wait there to finish i2c things. will intrrupt still holds any adantage over such polling driver? --- End quote --- Not much, as long as the i2C hardware makes no assumptions about service time. Don't know if this is the case for the PIC32MX peripheral. What is annoying is most MCU I2C peripherals implement all the bells and whistles of I2C that hardly anyone uses, like clock-stretching and multimaster. it wouldn't take much extra logic to implement something that's much easier to use for the vast majority of use cases which are to just read or write a bunch of bytes from a device. |
| Ice-Tea:
I actually had device clock-stretch a few weeks ago. So it *does* happen ;) |
| RoadRunner:
--- 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 --- I was already using IFSxCLR to clear USB interrupts. Just now Problem is solved. Now i cleared USB interrupt flag after serving USB ISR Task. previously USB flag was cleared before serving the ISR task, and I2C interrupt appears while USB interrupt flag was already cleared but ISR was still executing. What could be causing this, i will read up. if someone already know answer please share your view. |
| Navigation |
| Message Index |
| Next page |
| Previous page |