The volatile declaration within the interrupt handler looks weird to me. That should not be needed.
As you are not changing the array values within the interrupt routine I would not make them volatile either.
I am not sure how quick / often the interrupt triggers. IN any case I would suggest to reduce the call of function within the handler to a bare minimum. Better is not to do any.
It is also not very good practice to do a delay within the interrupt handler.
The "alias definition" looks good so far. You are creating a pointer to receive a pointer ;-)
All the Best
So, volatile is required only if you modify variable inside ISR? And I don't need it for arrrays?
Inside ISR, I had compile errors if i didn't make pointers volatile.
ISR is routed directly to 8kHz clock - that's multiplex frequency of the LED cube. Delay is to make sure that TPIC6C595 has enough time to detect the pulse.
there are several cases when volatile might be needed. At the end it only says that the variable can be modified by "parallel computing".
For this reason you define variables as volatile that get modified in a normal function AND in interrupt handlers. (a situation i personally try to prevent as much as I can).
To be honest most of the times I do not use pointer definitions inside the ISR. There for it can be that I am wrong and the volatile there is required.
The reason why I mentioned the function calls and the delay is more that I am afraid you might run into a situation were the ISR can not finish properly before the next interrupt event appears. I have not yet tried that on PSoCs, but there are controlers out there where whis can cause the ISR to lock in itself. I rather keep the ISR as short as possible and have the main loop taking care about the rest.
I guess this might be a arguable concept though ;-)
All the Best
I know and agree that ISRs should be short. But I don't know Verilog, so I can't do this using UDBs. I need main loop for USB communication(or can this be done inside another ISRs?). And multiplexing with BAM modulation needs precise timing to work properly.
So, can you recommend me better way to do this?
I have an idea. How about just setting a flag inside ISR and then multiplexing the cube in main loop? But then I need to make USB communication part as short, as possible, or it will cause lagging to multiplexing algorithm. Do it with DMA?
Also, how would you synchronize access to cube data? Do I need to use double-buffering? Or is there some other trick?
Anyway, I would like to ask for help on programming USB communication. I do not need it to act like graphics card - just some interface to dedicated software running on PC and sending pre-computed frames for cube. One frame has 768 bytes. To make things easier, I have rewritten it to use one array.
And I can tell you, before I have removed 10ms delay, I have observed output enable on oscilloscope. Of course isr did not finish before next irq, however there were periodic impulses with equal width and period. So I don't think it may cause program crash.
main_4.txt.zip 1.3 K