Unusual Interrupts Application Problem


Closed Thread
Results 1 to 3 of 3
  1. #1
    Join Date
    Aug 2006
    Posts
    65

    Default Unusual Interrupts Application Problem

    I have an application that has a home-grown bootloader which loads a PBP application program. The bootloader needs to be remotely invocable even if the PBP program is defunct or doesn't exist. We implemented this by providing a "long break" detection mechanism. The idea is, if the remote host needs to reload the PIC but the PBP program is kaput, it sends a long break character over the serial link ("Long break" = > 0.5 second space condition). When the long break is received, a "secret handshake" is exchanged by the interrupt handler, and then the bootloader begins to run.

    The long break is detected by connecting the Timer1 T1G (timer1 gate) line to the Rxd line. If the Rxd line goes low for more than about .5 second, Timer1 overflows, generates an interrupt, and starts the process.

    My problem is in how to implement the interrupt handler in the bootloader. We have to assume that the PBP program might be crashed or non-existant, so the long break interrupt process has to run without any support code in the PBP application. Furthermore, if a spurious break occurs but the handshake doesn't work out, control should be passed back to the PBP program. This means that my self-contained bootloader interrupt handler has to preserve enough of the PBP program's state so that it can return if it's possible to return.

    I've studied Darrel's "Instant Interupts" code, but it seems that this requires supporting code in PBP, which might not be there.

    Can anyone help??

    Joe

  2. #2
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default

    Is the bootloader written in ASM?

    The only reason to save the state of PBP's system variables is if the interrupt handler will be using any of the same RAM locations.
    If the bootloader is all ASM, then any variables it needs can be placed at the "End" of RAM so they don't interfere with PBP. Then you can very easily just return (retfie) to the PBP program. (after restoring "context"). As long as none of the system vars were changed, PBP will continue from where it left off.

    Your approach makes it so that the PBP program itself will not be able to use interrupts, including ON INTERRUPT. It would be possible to have the bootloader pass the interrupt to the PBP program, but it won't be too easy. Hopefully, you won't need interrupts in the PBP program.
    <br>
    DT

  3. #3
    Join Date
    Aug 2006
    Posts
    65


    Did you find this post helpful? Yes | No

    Default

    Darrrel

    Thanks for the reply.

    Yes, my interrupt handler is in assembler.

    I thought about putting the interrupt variables at the end of ram, but how can I protect them from getting overwritten by the PBP program if it gets that large?

    Also, I'd like to use interrupts in my PBP program, possibly for another timer and for the UART. It's not necessary to be able to do it through ON INTERRUPT though. We can put in more assembler code, either in the interrupt handler or in the PBP program, as necessary.

    More suggestions appreciated.

    Joe

Similar Threads

  1. Problem with multiple interrupts
    By aratti in forum General
    Replies: 7
    Last Post: - 2nd June 2009, 08:18
  2. 16F946 Instant Interrupts problem
    By jderson in forum mel PIC BASIC Pro
    Replies: 3
    Last Post: - 14th April 2009, 22:20
  3. help: TMR0 interrupts disabling PORTAchange interrupts???
    By xnihilo in forum mel PIC BASIC Pro
    Replies: 4
    Last Post: - 19th August 2008, 15:10
  4. Darrel Taylor Interrupts I2C Problem
    By dcorraliza in forum mel PIC BASIC Pro
    Replies: 11
    Last Post: - 26th March 2008, 02:13
  5. Problem using Instant Interrupts
    By Jerson in forum mel PIC BASIC Pro
    Replies: 2
    Last Post: - 3rd May 2006, 17:35

Members who have read this thread : 1

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts