>> >> > After our 'interrupt_create', we also have those calls (we use IRQ2 > instead of your PORTA): > cyg_interrupt_attach(t_intrhandle); > cyg_interrupt_configure(CYGNUM_HAL_INTERRUPT_IRQ2, TLV_FALSE, TLV_FALSE); > cyg_interrupt_acknowledge(CYGNUM_HAL_INTERRUPT_IRQ2); > cyg_interrupt_unmask(CYGNUM_HAL_INTERRUPT_IRQ2); > > Why do you call 'cyg_thread_suspend...' ? I do not see code that creates > a thread. And when I create a thread, I do cyg_thread_create(...); > cyg_thread_resume(..);. > > Why do you need a thread when your code is run by interrupts?
I am creating all my threads from cyg_user_start. Each "task" (thread) has its own file and interface (psuedo OO). The overall app has multiple threads, one of them handling telemetry, and a higher priority one handling ALERTB problems using a PMBus (I2C). Once the interrupt works and the DSR is called, the DSR code will do an ARA (get addresses vis I2C), get STATUS_WORD for all address that ALERTed, and then send events so that the alert thread can respond by interacting over the PMBus. I just suspended the thread until I get the ISR to work, then I will add then event and processing code. I could do all the work in the DSR as long as I can call I2C from the DSR. However, I am porting an application from MQX and maintaining its structure, and in MQX I don't have a DSR, so in that version the ARA and read of STATUS_WORD is all in the task code. I tried making some I2C calls from a DSR by using a timer, and the code locked up somewhere. I did not have time to track down the problem. It could have gotten in trouble on a mutex, in the driver, etc. So I may have to put all the code in the task/thread anyway until I have a better understanding of what code can execute in the DSR. I just have to dig through the eCos Ref Manual. Seeing your code, brought something to mind. I had assumed that the interrupt was enabled in the Kinetis HAL and all I had to do was configure the port. Perhaps that is not the case. I'll try to use your example and see what happens. Thanks
