This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

#pragma iv

Hello:

I have a project where I use #pragma iv(0x600), with Silabs processor 8051F385.
This processor indicates that interrupt 8 at 0x43 is "special" and when generating HEX file, the address is still at 43h. Why the compiler #pragma won't translate it to 643h?
Thanks !

  • Sorry guys, I was misled by the that there was no interrupt defined inside the source code, however one of the libraries actually uses it. Once the body is defined inside the source, it will generate it.
    Thanks anyways!

  • This processor indicates that interrupt 8 at 0x43 is "special" and when generating HEX file, the address is still at 43h. Why the compiler #pragma won't translate it to 643h?

    the only thing 'special' is the Pending Flag.

    The interrupt vector is hardware defined and will ALWAYS be at 43h. The compiler wil, when told insert a ljmp to 643h at 43h

    Erik

  • Hi Erik:
    Thanks for the response
    I have another question, perhaps you can enlighten me:

    I am using USBX_f38x.lib, which uses interrupt 8 "on its own"... I mean that my source doesn't define this interrupt, hence the compiler is not modifying the 43h to 643h. How's the compiler knowing that there's an interrupt there ? If so why the #pragma iv(0x600) does not affect this ?
    Thanks
    Juan

  • How's the compiler knowing that there's an interrupt there ?

    It does not, you have to tell it. If the interrupt s enabled and you do not have an ISR your code will blow

    so why the #pragma iv(0x600) does not affect this ?
    see above I did describe it. The interrupt vector is HARDWARE DEFINED and will ALWAYS be at 43h. The compiler will, when told insert a ljmp to 643h at 43h

    The next version of Keil will magically change the connections inside the chip so the hardware will work difrerently :)

    Erik

  • Lol...
    Well, I am missing something. There's a precompiled library that utilizes this interrupt and it is not in the source code. The thing is that the compiler just doesn't modify the vector to point to this ISR !
    Once I add the interrupt function it does it. How can I cheat the compiler to do this ?
    Thanks

  • I just recall that there is something fuzzy about ISRs and libraries. Since I am not much of a library user, (it is a *** trying to debug something you do not have the source for) I can only say "I tend to recall that" ISRs inside a library are called by nobody and thus ignored. You need to contact wherever you got those library routines.

  • The thing is that the compiler just doesn't modify the vector to point to this ISR !

    How could it? Nobody passed your choice of compiler flags to their run of the compiler. And unless you get into contact with them and convince them to build your a specialized copy (or give you source code), nobody ever will.

    There's actually no way you can use that option on pre-compiled third-party code. You'll have to make your own vector table entry and then call their interrupt handler. There will be two tricky parts about this:
    1) finding that actual interrupt handler function (the C function their vector table entry points at)
    2) avoiding the disruption their interrupt vector table entry would generate in your program, if it were included.

    On a related note, I really don't believe that IntVector(offset) is a C51 option which one should ever set by #pragma. This is an option that has to be applied uniformly across the entire program, so it really should be set at the top-most level of the build system. Sticking it as a #pragma into some header risks that some modules will not get the news, and thus become incompatible with the rest. Hiding that #pragma in individual .c files would practically guarantee that kind of failure.