Hi, > One sidenote. IIRC you cannot access the stack on the pic16f devices. > This is only possible on pic18f devices. There is a wonderfull appnote > about that on microhcip website.
You are right, but ... I was talking about the pseudo stack that is used by the compiler to pass arguments to subroutines. This "stack" is placed into the "sharebank" available on (most?) PIC14 devices to be available in all memory banks and thus avoid banksel's upon access. For the 16f877, the region 0x70..0x7f is mapped to all 4 banks (memory at 0x70..0x7f equals mem at 0xf0..0xff equals mem at 0x170..0x17f equals mem at 0x1f0..0x1ff). The problem at hand can ignore the hardware stack which is used to store return addresses during calls to subroutines as long as this hw stack does not overflow (which would likely result in a different error scenario, although... 8 levels of call stack is not *that* much ... ==> should investigate; unfortunately, there is no reset-on-stack-overflow-indication/reset available) as we employ no "thread switch" but only need to protect memory/registers shared between interrupt handlers and "regular" code from being modified behind the application's back. Best regards, Raphael ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
