Hummm, for some reason the quoted message below
arrived twice into my mailbox. I just realized
it after writing the answer/example that
follows. Anyhow, here it is. It may be useful to somebody.
As Maarten Brock said in another message, you can
just add a dummy interrupt function to set the
maximum number of entries in the interrupt vector
table. How many vectors do you need for the
nRF24E1? Say 10, then in the file where your
main function is, you should add:
void mydummyISR (void) interrupt 10 _naked
{
}
This generates the following asm code:
;--------------------------------------------------------
; interrupt vector
;--------------------------------------------------------
.area HOME (CODE)
__interrupt_vect:
ljmp __sdcc_gsinit_startup
reti
.ds 7
reti
.ds 7
reti
.ds 7
reti
.ds 7
reti
.ds 7
reti
.ds 7
reti
.ds 7
reti
.ds 7
reti
.ds 7
reti
.ds 7
ljmp _mydummyISR
Jesús
At 10:38 AM 9/30/2006, you wrote:
>Hello all SDCC users & developers, being that
>the 8051 is in your area of expertise, I wanted
>to ask your thoughts on the following issue I
>have been having.... I have poured through the
>message boards to no avail. My question is very unique.
>
>I built a boot loader using SDCC 2.4.0 for the
>Nordic nRF24E1. I did this to eliminate the 4K
>memory barrier, which allows me to swap firmware
>loads in/out of memory on the fly.
>
>Part of my boot loader updates the interrupt
>vector table for the firmware load of
>interest. It seemed despite SDCC 2.4.0 claim
>that it automatically adjusted the table based
>on the ISR requirements it seemed to always
>adjust to a full size interrupt 0-5
>(0x0003->0x002B) table no matter what, with a
>total length of 41 bytes. This was advantageous
>to me, since all the firmware loads I would swap
>in and out of RAM would always have the same
>length interrupt vector table and layout
>irregardless to my ISR usage for that particular
>firmware load. My boot loader vector table
>update process could could work reliably with consistent table lengths.
>
>Now, since I upgraded to 2.6.0, SDCC does
>automatically adjust the ISR table length based
>on ISR usage for each firmware load, which are
>not consistent from firmware load to firmware
>load because of different ISR usage, and my boot loader is not happy with this.
>
>Do you know of a way with SDCC 2.6.0 to make it
>behave as 2.4.0 as far as the interrupt vector
>table is concerned, but yet still use SDCC 2.6.0
>for its other improvements and bug fixes?
>
>Thanks in advance for your help on this.
>
>Excellent job on SDCC, it is a remarkable compiler!
>
>Thanks.
>Jon Hallsten
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
