Search found 1473 matches
- Mon Jun 01, 2009 5:23 pm
- Forum: Compiler
- Topic: any way to disable stack frame recycling?
- Replies: 0
- Views: 2672
any way to disable stack frame recycling?
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...
- Mon Jun 01, 2009 3:42 pm
- Forum: Modules
- Topic: High/low priortiy interrupts question (again)
- Replies: 7
- Views: 5912
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...
- Sat May 02, 2009 10:02 pm
- Forum: Compiler
- Topic: High/low priortiy interrupts question
- Replies: 13
- Views: 8469
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...
- Sat May 02, 2009 9:14 am
- Forum: Compiler
- Topic: High/low priortiy interrupts question
- Replies: 13
- Views: 8469
- Fri May 01, 2009 10:42 am
- Forum: Compiler
- Topic: High/low priortiy interrupts question
- Replies: 13
- Views: 8469
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...
- Thu Apr 30, 2009 9:58 am
- Forum: Compiler
- Topic: High/low priortiy interrupts question
- Replies: 13
- Views: 8469
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...
- Wed Apr 01, 2009 11:34 pm
- Forum: Compiler
- Topic: code generated for setting a port bit
- Replies: 6
- Views: 4257
- Wed Apr 01, 2009 5:00 pm
- Forum: Compiler
- Topic: code generated for setting a port bit
- Replies: 6
- Views: 4257
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...
- Wed Apr 01, 2009 3:41 pm
- Forum: Compiler
- Topic: code generated for setting a port bit
- Replies: 6
- Views: 4257
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...
- Wed Apr 01, 2009 11:26 am
- Forum: Compiler
- Topic: code generated for setting a port bit
- Replies: 6
- Views: 4257
code generated for setting a port bit
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 ...
- Wed Mar 11, 2009 10:39 am
- Forum: Compiler
- Topic: help with #option and defining bits
- Replies: 1
- Views: 2048
help with #option and defining bits
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...
- Sat Feb 28, 2009 12:47 pm
- Forum: Compiler
- Topic: New updates coming?
- Replies: 5
- Views: 4030
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
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
- Fri Feb 13, 2009 12:27 pm
- Forum: IDE
- Topic: MPLAB 8.10 problem
- Replies: 4
- Views: 5185
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
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
- Fri Feb 13, 2009 12:02 pm
- Forum: Compiler
- Topic: syntax for 'prototype' declaration
- Replies: 2
- Views: 2557
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...
- Thu Feb 12, 2009 11:09 am
- Forum: Compiler
- Topic: const string array limits
- Replies: 1
- Views: 2452
const string array limits
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...