View previous topic :: View next topic |
Author |
Message |
YendorZ
Joined: 31 Jul 2009 Posts: 3
|
Can't use Functions! Inline only. |
Posted: Fri Jul 31, 2009 7:29 pm |
|
|
This sounds really stupid I know. I've been using CCS PCH for PIC18F's for a few years, and have never had this problem.
In starting a new project with a new PCB, I sometimes start with a "flash-the-led" routine just to get things rolling. I'm stuck on this one.
If I write the routine in-line, with no user-defined function calls, it works. If I make a function like LED1on(), and try to use it, it hangs.
Has anyone ever seen this problem? I've checked the PCB layout and all aspects of the hardware over ad-nauseam - it's a simple board.
if I declare the function as inline , ie. "inline void LED1on();" it works, if not, it hangs. It does not execute the function contents either. It's as if the RCALL assembler mneumonic does not work!
The assembly list (LST file) looks like it should run OK.
Using CCS PCH v4.059
PIC18F4320 |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Jul 31, 2009 7:48 pm |
|
|
Post a very short, but compilable test program that shows the problem.
Test it and verify that it fails, before posting. |
|
|
kender
Joined: 09 Aug 2004 Posts: 768 Location: Silicon Valley
|
reentrancy |
Posted: Sat Aug 01, 2009 2:13 pm |
|
|
I might be pointing in a wrong direction, but when you compile the non-inline version of your code, are you getting warnings along the lines of:
Quote: | Function XYZ called both in interrupt and in main(). To prevent reentrancy, interrupts disabled during calls to XYZ. | ?
Inlining the function would remove the reentrancy. _________________ Read the label, before opening a can of worms. |
|
|
rnielsen
Joined: 23 Sep 2003 Posts: 852 Location: Utah
|
|
Posted: Mon Aug 03, 2009 10:24 am |
|
|
Without seeing what your code is doing it's hard to know what could be the problem. I do know that if you have interrupts enabled, but NO ISR defined to handle it, things can be very erratic.
Ronald |
|
|
YendorZ
Joined: 31 Jul 2009 Posts: 3
|
Sample Project that Does not Work |
Posted: Wed Sep 02, 2009 11:37 pm |
|
|
I know I'm likely doing something really dumb.
I created a very rudimentary project from scratch, which I zipped and made available at (size = 15kb):
http://www.firelightgroups.com/rod/PIC18F4320_Project.zip
The main C code file is as follows:
Code: | #include "C:\PIC18F4320_Project\PIC18F4320_Project.h"
#use standard_io(ALL)
void main()
{
int x;
setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_OFF|ADC_TAD_MUL_0);
setup_psp(PSP_DISABLED);
setup_spi(SPI_SS_DISABLED);
setup_wdt(WDT_OFF);
setup_timer_0(RTCC_INTERNAL);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
//Setup_Oscillator parameter not selected from Intr Oscillator Config tab
// TODO: USER CODE!!
output_high(PIN_E2);
while(1)
{
output_high(PIN_E2);
for(x=0;x<2000;x++);
output_low(PIN_E0);
for(x=0;x<20000;x++);
}
} |
I've used this system a dozen times, but not recently. It's been about a year since I've touched this stuff, and this one has me stalled. The attached source/project was just for demonstration, and this time does not even run without function calls.
I know this does not have a disable_interrupts(GLOBAL) in it, but there are none enabled in the first place.
Oscillator (40Mhz external clock), Vcc, MCLR, etc, are all OK. Using PIN_E2 with a simple LED on it as a tell-tale. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Sep 03, 2009 12:09 am |
|
|
Quote: |
void main()
{
int x;
while(1)
{
output_high(PIN_E2);
for(x=0;x<2000;x++);
output_low(PIN_E0);
for(x=0;x<20000;x++);
}
}
|
The main problem I see is that 'x' is declared as an 'int', but you're
comparing it to values that are larger than 255. CCS is not like other
compilers. It has different data types. In CCS, an 'int' is an 8-bit
unsigned integer. To fix it, you need to declare 'x' as an 'int16', which
is a 16-bit unsigned integer.
Also, there's no need to use for() loops for delays. CCS has built-in
delay functions such as delay_us() and delay_ms() that are much better.
Quote: |
setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_OFF|ADC_TAD_MUL_0);
setup_psp(PSP_DISABLED);
setup_spi(SPI_SS_DISABLED);
setup_wdt(WDT_OFF);
setup_timer_0(RTCC_INTERNAL);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
|
Also, this setup code put in by the Wizard is unnecessary. These PIC
modules are disabled by default upon power-on reset. You don't need
to disable them again with code. |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Thu Sep 03, 2009 6:15 am |
|
|
Code: | setup_spi(SPI_SS_DISABLED); | Like PCM Programmer already mentioned this line is not required, but even worse it is wrong! Disabling the SPI is done with: The original code will set an invalid configuration with unknown results.
Quote: | while(1)
{
output_high(PIN_E2);
for(x=0;x<2000;x++);
output_low(PIN_E0);
for(x=0;x<20000;x++);
} | My guess is you want to toggle the output pin? I suggest you use the same pin in both lines... |
|
|
YendorZ
Joined: 31 Jul 2009 Posts: 3
|
|
Posted: Thu Sep 03, 2009 8:22 am |
|
|
Thanks for all the extremely quick responses. By doing this quick example, hacking some very wrong-headed changes, I've done a good job at demonstrating my idiocy. Guess I need to work on this stuff earlier in the day. You're seeing the end result of some stiff frustration.
About the code, I can say that:
1. It still does not work, even omitting the 'x' variable and the 'for' loops.
2. Even with both output_high and output_low using PIN_E2, it did not work. I has switched from PIN_E2 to PIN_E0 to try another output. Neither one ever responded.
The intention is indeed to toggle an output. This is usually a very quick first step in getting a project running, just to see if things are working...it usually lasts 5 minutes in this state, not hours.
I will re-post this evening with something a little more concise, and correct.
I find it interesting that the auto-generated wizard code is so incorrect. Thanks for the tip that it's not necessary.
Thanks for all the quick responses as well! This forum is the last thing keeping me from migrating to TI's MSP430 line of processors. I still have a legacy of PIC-based implementations however... |
|
|
|