Swordfish

I'm trying to fine-tune some interrupt handling code, and have been playing around with the (undocumented) ACCESS modifier. This seems to work great, as it places the locals and temp variables of a subroutine in a new separate stack frame in the access bank. The problem that I have is that when I ha...

When you have the priority mechanism enabled(IPEN=1), the PEIE bit becomes GIEL, so that's not the problem. Gordon - On the surface, what you have looks fine. Since there's some code not shown, I'd check: - make sure that you've got the other IPRx priority bits set properly - verify that you're actu...

Glad to hear things are working out for you. I try and avoid save(0) if I can get away with it (and if you're really careful in what you do in the intr handler, you usually can). As far as events go, as I said before, events are an indirect function call. With the pic architecture, that amount of ov...

If I remember correctly, the save(0)/restore block takes about 160 cycles to execute.

Take a look at the asm listing. Depending on how you've declared the variables, you'll probably find that the multiply is using PRODH:PRODL registers. But that is probably the least of your issues. If the comments are correct, it looks like you've got the timer intr set to generate 20 ticks/msec, wh...

Nothing obvious jumps out at me, but then again I haven't even finished my first cup of coffee yet. Some general things to check are... - A lot of pic's have an errata for the priority saving mechanism. Try using #option ISR_SHADOW = false and see if this helps. - Make sure you're setting the IPRx p...

That's one solution. I guess I just wasn't expecting the result I got at first.
It still doesn't seem right to me.

Thanks, octal.

Jerry

As I stated, if 'b' is declared as a bit, then the code works as expected... dim b as bit PORTA.0 = b generates ?I000003_F000_000024_M000000 ; L#MK PORTA.0 = B BTFSC M0_U01,0,0 BSF LATA,0,0 BTFSS M0_U01,0,0 BCF LATA,0,0 and there are no extra writes to the LAT. I was expecting similar code to be gen...

Always READ FROM PORTx registers and write to LATx registers (this let you also avoid Read/Write/Modify behaviour of PIC ports) !!! SF (at least 2.1.0.1) is nice enough to take care of that automatically for you... if you look at the generated code, you'll see that writing to a "port" actually writ...

I just noticed that if I use dim b as byte PORTA.0 = b the compiler generates BSF LATA,0,0 BTFSS M1_U08,0,0 BCF LATA,0,0 which results in the port pin always being set high first, which wreaks havoc with my hardware. (It doesn't do this if 'b' is declared as a 'bit'). I've had to result to using if ...

I've seen the following syntax in a few modules #option SSPI_SCK = PORTC.3 dim FSCK as SSPI_SCK.SSPI_SCK@ This seems to define FSCK as a 'bit', whereas if I do #option SSPI_SCK = PORTC.3 dim FSCK as SSPI_SCK FSCK ends up being a 'byte', which isn't what I want. I can't seem to find this explained an...

David,

There's a couple of threads over in the IDE forum about this and working with mplab.
See http://www.sfcompiler.co.uk/forum/viewtopic.php?t=835 for example

Jerry

you're not alone. see http://www.sfcompiler.co.uk/forum/viewtopic.php?t=835

While it works, it's pretty ugly.

I've given up trying to build under mplab. I use the SF ide to compile,
and just import the cof file into mplab for debugging. A bit of a pain,
but workable.

Jerry

Thanks, octal. That syntax worked out much better. However, your warning about "USE AT YOUR OWN RISK" is right. If you declare a function with the 'prototype' keyword, the code generator screws up, causing any 'inline' routines accessed by that function to be expanded incorrectly. Taking a look at t...

I ran across a compiler issue while using the following... const sHelp() as string = ( "this is a test of const string array length", // line is ok...max length (69+1=70) "123456789012345678901234567890123456789012345678901234567890123456789", // line is too long (70+1=71)...compiler terminates "123...