1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

interrupt handling using microblaze with XPS

Discussion in 'Embedded' started by chriskoh, Dec 19, 2006.

  1. chriskoh

    chriskoh Guest

    Hi,
    I am pretty new to the arena of interrupt handling and would need
    some help. I am currently using microblaze v4.00a and with Xilinx
    platform studio 7.1 to develop some UART handling routines. what I am
    not sure, is

    1) whether the important registers (eg, stack pointers and other
    registers) are saved during an interrupt handling, or do I have to
    explicitly save them myself.

    I dun think this is handled by the microblaze and am wondering if
    the mb-gcc C compiler would be smart enough to do the same.

    kindly advice. thanks!
    Chris
     
    chriskoh, Dec 19, 2006
    #1
    1. Advertisements

  2. chriskoh

    CBFalconer Guest

    That depends on the machine you are using. Read its
    documentation. For example, an X86 saves the return address and
    the program status (flags, interrupt enables, etc.) automatically.
    Others may differ.
     
    CBFalconer, Dec 19, 2006
    #2
    1. Advertisements

  3. The 68HC11 for example saves all registers on the stack.
    Others (e.g. NIOS2) save nothing on the stack and just swap a
    couple registers.
     
    Grant Edwards, Dec 19, 2006
    #3
  4. chriskoh

    FreeRTOS.org Guest


    I have just been looking at the FreeRTOS.org Microblaze demo to see how that
    configured the interrupts. It seems that the development environment
    handles all the interrupt prologue and epilogue code for you. From the
    FreeRTOS.org documentation:

    "An interrupt service routine that does not cause a context switch has no
    special requirements and can be written as a normal function."

    and looking through the code the serial port interrupt is just written as:
    void vSerialISR( void *pvBaseAddress )

    The fact that it takes a parameter means it cannot be called directly in
    response to an interrupt, but indirectly after some processing.

    So I would conclude - you have to write your ISR like a standard function
    without having to worry about the save and restore of any of the registers.
    Saving of general purpose registers is handled by the tool. Saving of other
    registers is handled by the hardware itself. Once you have written your ISR
    you have to somehow tell the tool about it through the GUI. The file
    xintc_g.c is then automatically generated to contain the interrupt table and
    references to your ISR functions.

    Sorry I cannot remember specifics but I hope this is a pointer.

    Regards,
    Richard.

    + http://www.FreeRTOS.org
    + http://www.SafeRTOS.com
    for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
    Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC
     
    FreeRTOS.org, Dec 19, 2006
    #4
  5. chriskoh

    CBFalconer Guest

    Another variation is delay in re-enabling interrupts. This is
    often intended to allow the system to return to the interrupted
    code before executing another interrupt.
     
    CBFalconer, Dec 19, 2006
    #5
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.