Interupts

[neil]

Hi,
  The project I am working on uses various interupts, and would like to know how they work with the utasker. Below is a list of ones I am using (at moment), and as not yet tested the II2, and SPI.

1. The serial ports:
I am using the 52235, and will be using all 3 serial ports in interupt modes (as explained in previous post on Uart). I assume that the data will be sent when the tx register is empty, and when data is in the rx register the serial interupt will place the character in the RX buffer (size declared when setting up port)?  So if the processor is half way through a task, data is either sent/received (we wont lose any characters, unless of course there is a buffer overflow)?

2. IRQ1-15 interupts , edge detect.
How do these work? Is the function that is used in the setup automatically get  called by the isr?

3. II2 and SPI.
I still have to try these in utasker, does this work on interupts, or as transfer is fast, the task waits till data is received before moving to next application command.

4.Ethernet..
I will be using tcp/ip with simple connect and send. How does this work? Similar to the serial as described above?

Thanks
Neil

[mark]

Hi Neil

1. UART
The UART interrupts works as you have assumed. The tx part is sending the next character from the TTY output buffer each time a tx interrupt arrives. The 3 UARTs each have a TTY output buffer of their own and will operate in parallel.
This means that once your application code has copied the data to be sent into the TTY output buffer (using fnWrite()) it can continue doing other things and can assume that the data will be sent (the actual transmission time will of course depend on the BAUD rate of the UART). The application doesn't need to wait and the rest of the system operates normally (apart from short interrupts which takes place each character interval during the transmission process).
If you have a task which is heavily using the processor power it will also not stop UART reception from taking place. The UART reception simply copies the received byte to the TTY input buffer each time there is character available. This takes place via interrupt. The only possibility of losing a character (rx buffer overrun) is if there is another interrupt blocking the UART rx interrupt, or the application / driver has disable interrupts for a long period of time. The driver/OS use of interrupt disabling has been optimised to a minimum and so there is no problem when operating at BAUD rates of at least 250k. The interrupt levels and priorities in a project can be controlled in app_hw_m5223x.h so that projects with  critical interrupt requirements can best define these to suit each peripheral.

2. IRQ1-15 interupts , edge detect.
The user enters a handling routine when setting up the interrupts. The edge ports interrupts (there is one routine for each in M5223X.c) first clear the corresponding interrupt flag and then immediately call the entered handling routine.
The handling routine is thus called from within the interrupt, which means that it should be kept as short as possible. If you look at the demo use fo these IRQs in application.c you will see that they call:
    fnInterruptMessage(OWN_TASK, IRQ11_EVENT);
for example.
This posts an interrupt event to the application task - this is very fast and so doesn't involve large amounts of work while blocking other interrupts. The application task is subsequently woken and handles the event, where it sends some text to the debug port. The task is of course not working in the interrupt routine itself and so does 'off-line' work which is not so critical. Interrupt routines are generally used to perform very time critical jobs - which are hopefully also very short to perform (saving time stamps, setting hardware registers, etc) - and generating system events which are handled 'off-line'.

3. IIC
You can compare IIC with UART. Tx and RX are interrupt driven. It is very easy to queue several messages (usually control sequences to one or several devices) - the application can assume that they will be delivered and get on with other work.
The driver only performs master mode operation and reads are usually answers to commands. Read commands can be queued and interleaved with other commands. When an answer is read the receiving task will be woken to get it using fnRead() (usually checking fnMsg(IIC_handle) first to see whether a compete message is ready).
 
4. SPI
SPI is used either for EEPROM file system or for SPI FLASH. There is no generic driver since SPI is used in many different ways, making it difficult to define a generic driver. It can and has been used in a similar mode as UART (interrupt driven, with rx synchronised to tx) but this is not a part of the project (at least not at the moment).
For EEPROM file system and SPI FLASH the operation doesn't use interrupts. The idea is that the SPI accesses are simply as fast as possible and the application (file system) layer is reading data in-line as if it were normal (but slower due to serial access) memory. Therefore if you look at the SPI interface you will see that the interrupt flags are only used for polling while waiting for an individual read or write to complete (usually well in the sub-us region).

5. Ethernet
Ethernet interfaces always use a DMA engine so individual byte transmission or reception has nothing to do with SW.
There are interrupts on tx frame and rx frame and on certain errors (also on connection state changes - like link up / link down).
When a frame is transmitted there is an interrupt on completion. This interrupt is almost redundant - it is used to generate a system event if LAN_REPORT_ACTIVITY is activated but otherwise has almost no SW relevance. Frame transmission is generally as fast as the processor can construct and send new frames...

When an Ethernet frame has been received, a rx frame interrupt causes the Ethernet task to be woken by a system event, which then reads the frame buffer. There are a number of frame buffers available (configurable using NUMBER_OF_RX_BUFFERS_IN_ETHERNET_DEVICE) so the time taken to actually process received frames is not that critical. The processing is 'off-line' and the call back routines when handling the TCP/IP protocol are called from within this 'off-line' frame processing. All rx processing on the M5223X are directly in the Ethernet RX buffer and only once the rx call-back (and protocol handling) has completed (returned) is the rx buffer ownership given back to the DMA engine so that it can be used again.

Regards

Mark