hellow every one,
can you tell me please what is the effect of the iprintf statement in real time applications. i have MOD5282 with ucos as rtos.
i am trying to run an ISR which reads 1024 bytes from the SDRAM ,while also prints the notifications statement inside ISR. now when i remove this statement is read correctly all the 1024 bytes, bu when i keep PRINTF statement inside ISR, than it reads 1025 bytes.
why does this happens?
what is the effect of printf on real time on MOD5282?
-
- Posts: 19
- Joined: Fri Dec 12, 2008 2:54 am
Re: what is the effect of printf on real time on MOD5282?
The total time for an interrupt service routine needs to be in micro seconds, not milliseconds or higer. Just get in and out. The rule is you never do a iprintf or printf in an isr. If you have any processing that takes more than a few microseconds, use a semaphore post, and a corresponding task that pends on that semaphore. You can then do whatever you need to in the task.
That said, you also need to consider how your system will operate . Lets say you are using a serial baud rate of 115,200 bits per second. A very rough (I know) byte rate would be to take 10 bits per byte (including start, stop, etc) which comes to 11,520 bytes per second. If you are printing 1024 bytes, a rough time estimate would be 88ms plus the iprintf overhead plus whatever time your isr is taking to do other things. Does your system guarantee that you don't get another irq condition in less than 88ms? That would overwrite buffers, so maybe that is a consideration as well.
That said, you also need to consider how your system will operate . Lets say you are using a serial baud rate of 115,200 bits per second. A very rough (I know) byte rate would be to take 10 bits per byte (including start, stop, etc) which comes to 11,520 bytes per second. If you are printing 1024 bytes, a rough time estimate would be 88ms plus the iprintf overhead plus whatever time your isr is taking to do other things. Does your system guarantee that you don't get another irq condition in less than 88ms? That would overwrite buffers, so maybe that is a consideration as well.