→ wens: 不能等 buffer 滿了才送 interrupt 啊, 大概 1/2 ~ 3/4 滿 03/09 10:49
→ wens: 就該送了。interrupt handler沒有保證馬上執行的 03/09 10:49
→ gn00618777: 好感動,感謝w大回應。您說 buffer 滿是說誰的 buffer 03/09 12:57
→ gn00618777: interrupt handler 沒有保證馬上執行,那如果我是在上 03/09 12:58
→ gn00618777: 半部,也就是request_thread_irq的第二個參數設一個 03/09 13:00
→ gn00618777: ISR(硬中斷),會不會這個handler 就會保證馬上執行? 03/09 13:01
→ gn00618777: 因為查詢結果,request_thread_irq的第三個參數,是在 03/09 13:02
→ gn00618777: process context的,所以不保證迅速執行,而是被kerne 03/09 13:02
→ gn00618777: 排班,而 request_thread_irq的irqflags我有設 03/09 13:03
→ gn00618777: IRQF_ONE_SHOT,這個代表 thread process要執行完才能 03/09 13:04
→ gn00618777: 再打開 interrupt,所以我的 driver 會不理 mcu 發的 03/09 13:04
→ gn00618777: interrupt 甚至會延遲進入 thread handler 03/09 13:05
推 askacis: 要是我會請MCU那邊改寫法,miss interrupt就掉資料, 03/10 12:53
→ askacis: 別人一天到晚在等MCU就飽了 03/10 12:54
→ gn00618777: 好,我再花點時間去了解MCU有沒有更好的解決方案 03/11 11:26
→ gn00618777: AP這端我還有兩到三種方法可以嘗試,之後再來這邊報告 03/11 11:27
→ gn00618777: 謝謝。 03/11 11:27
→ wens: 沒設ONE_SHOT會更崩潰,而且SPI bus一次也只能一個存取啊 03/13 00:09
→ wens: 我說的buffer指的是MCU上的buffer。舉一些I/O裝置為例,通常 03/13 00:10
→ wens: 會內建個FIFO,可以存一點資料,然後可以設定要滿到什麼程度 03/13 00:10
→ wens: 的時候發 interrupt或DRQ (DMA的狀況) 03/13 00:11
→ wens: AP這端我覺得你沒太多可以做的,因為你就是沒辦法在top half 03/13 00:12
→ wens: 做IO去讀資料出來,而且即便是top half也沒保證馬上輪到你, 03/13 00:12
→ wens: 其他的ISR 也會擋你啊 03/13 00:12
推 askacis: 另外一個暴力的方式是不要用kernel的SPI API,自己填 03/13 09:19
→ askacis: register去控制SPI拿資料, 03/13 09:20
→ gn00618777: 為什麼要用填 register的方式? 目前測時間 spi cs 拉 03/14 19:17
→ gn00618777: 下來到被拉上來,整個spi寫入讀取只花 0.1ms 03/14 19:18
→ gn00618777: 請問w大,您說我沒辦法在 top half 讀資料,是因為API 03/14 19:20
→ gn00618777: 是阻塞的function嗎? 然後a大才說用填暫存器方式? 03/14 19:21
→ gn00618777: 另外為何說沒設 ONE_SHOT會更崩潰..?? 我就是不打算 03/14 19:29
→ gn00618777: 在 thread 做,所以 ONE_SHOT 沒有應該不會影響吧?? 03/14 19:29
→ gn00618777: 抱歉..因為板子還未到,我只能一直先這樣詢問了解 03/14 19:30
→ gn00618777: 懇請各位賜教 謝謝 03/14 19:31
→ wens: 如果沒有要在 thread 裡面做,那似乎無所謂? 03/17 16:50
→ wens: 然後top half不能讀資料確實是 API 限制沒錯 (SPI可能sleep) 03/17 16:51