MCC18 Driving me crazy

[blueroomelectronics]

RB0 is analog by default, add this and speed it up and the debugger goes much faster

    OSCCON = 0x72;  // 8MHz
    ADCON1 = 0xFF;  // all digital I/O
    INTCON2 = 0b00000101;    // falling edge, high priority

Adding a PORTB watch window will show the bit now goes low.

 

[blueroomelectronics]

The IRQ routine works in the debugger, set a breakpoint and press button 1
Also your code was clearing the IE not IF bit...

Note: not sure if it applies to C but in Swordfish BASIC I got used to putting the main program at the bottom of the code.

#pragma    config OSC=INTIO2, WDT=OFF, LVP=OFF, DEBUG=ON
#include <p18f1320.h>

void interrupt_at_high_vector(void);
void high_isr (void);

#pragma code /* return to the default code section */
#pragma interrupt high_isr
void high_isr (void)
{
    /* ... */    
    INTCONbits.INT0IF=0;    // clear the flag and return BREAKPOINT and watch
}
void main(void)
{
    OSCCON = 0x72;            // 8MHz
    ADCON1 = 0xFF;
    INTCON2 = 0b00000101;    // falling edge, high priority
    INTCON = 0b11010000;     // Setting Bit 3 to 1 gives a automatic interrupt 
    TRISB = 0b00100101;

    while(1){

    }
}

// -------------------------------------------------
#pragma code high_vector=0x08
void interrupt_at_high_vector(void)
{
_asm GOTO high_isr _endasm     //   brakpoint here 
}

 

[futz]

Note: not sure if it applies to C but in Swordfish BASIC I got used to putting the main program at the bottom of the code.

In C you should get in the habit of using function prototypes at the top of code. Then you can put your functions in any order you like. And of course it's nicest to have main() at the top IMHO. You don't need a prototype for main().

Swordfish makes you do that because (as far as I know) you can't pre-declare your functions in this way. The compiler isn't smart enough to look all the way through the code before starting, so you have to have your functions "declared" before they're used. I could be wrong. There might be a way. RTFM

Say you have a function like this:

void function1(int n)
{
	while(1)
	{
		n+=1;
	}
}

At the top of code, above main(), up with the defs and stuff, put this function prototype:

void function1(int);

Don't forget the semi-colon.

Prototypes not only pre-declare the functions, but are an important error checking helper for the compiler. They tell the compiler what kind of arguments to expect when you call a new function..

A C expert could give you a better explanation.

 

[futz]

**broken link removed** is on sale. It's written with Hi-Tech PICC in mind, but has MCC18 code on the disk. The differences are small. At this price it might be worth getting. Cheaper than Amazon. Looks like not too bad a book. I ordered one.

 

[AtomSoft]

I wouldnt want a expert.. lol they would over complicate things. I think im starting to actually understand it all. Thanks a bunch here we go working finally lol

#pragma    config OSC=INTIO2, WDT=OFF, LVP=OFF, DEBUG=ON
#include <p18f1320.h>

void interrupt_at_high_vector(void);
void high_isr (void);
void MyDelay(int xD);
void MyFlash (char qTimes, char xSpeed);

#pragma code /* return to the default code section */
#pragma interrupt high_isr

void high_isr (void)
{
	INTCONbits.INT0IF=0;    // clear the flag and return BREAKPOINT and watch
	MyFlash(3,50);
}

void main(void)
{
	OSCCON = 0x72;            // 8MHz
	ADCON1 = 0xFF;
	INTCON2 = 0b00000101;    // falling edge, high priority
	INTCON = 0b11010000;     // Setting Bit 3 to 1 gives a automatic interrupt 
	TRISB = 0b00100101;
	ADCON1bits.PCFG0 = 0;
	TRISA = 0b10111110;

	while(1){
		LATA=0b00000001; // Turn LED on
		MyDelay(200);

		LATA=0b00000000; // Turn LED off
		MyDelay(200);
    }
}

void MyDelay(int xD)
{
	int countD = xD * 100;
     	
	while (countD > 1)
   	{
		countD = countD - 1;
	}
}

void MyFlash (char qTimes, char xSpeed)
{
	int x = qTimes;
	while(x != 0)  
	{
		TRISA = 0b10111110;
		LATA = 0b00000001;
		MyDelay(xSpeed);

		LATA = 0b01000000;
		MyDelay(xSpeed);

		TRISA = 0b00111111;
		LATA = 0b01000000; 
		MyDelay(xSpeed);

		LATA = 0b10000000;
		MyDelay(xSpeed);

		TRISA = 0b01111110;
		LATA = 0b10000000;
		MyDelay(xSpeed);

		LATA = 0b00000001;
		MyDelay(xSpeed);
			
		x--;
	}
	
	TRISA = 0b10111110;
}

#pragma code high_vector=0x08
void interrupt_at_high_vector(void)
{
_asm GOTO high_isr _endasm     //   brakpoint here 
}

 

[futz]

void main(void)

By the way, you're going to run into this eventually, so I'll tell you now. Even though it's really silly on microcontrollers, some compilers won't allow a void main(). The one you're using does, obviously, but others I've used still want the traditional PC style int main() and a return(0) at the end of main(), even though you're not returning to anything on a PIC except a reset.

 

[AtomSoft]

ive seen that book somewhere and someone recommended it to me. I am going to purchase it next week. Waiting to get paid lol (every 2 weeks)

so should i get used to putting it without the addition void in the arguments?

 

[futz]

so should i get used to putting it without the addition void in the arguments?

Eh? Sounds like you've misunderstood me. If your compiler accepts

void	main(void)

without giving you a warning, then that's perfectly legal. Just be aware that when you move to different compilers that may not be accepted. Many require

int	main(void)

and will also want a

	return(0)

at the end of main().

For instance, when I use

void	main(void)

with C30, I get this warning:

blinky.c:11: warning: return type of 'main' is not 'int'

 

[blueroomelectronics]

Can you just put?

main ()

ignoring both the void / int

PS I'm going to order that book too.

 

[futz]

Can you just put?

main ()

ignoring both the void / int

Once upon a time, long long ago, that was fine. But no more. Since C++ came along everything got more complex, and in many ways better and more precise.

Those function prototypes? C++. But they're part of C now too, since C is part of C++. Same goes for all the ultra-careful declaring of returns and parameters.

If your compiler lets you get away without doing it, fine, but don't expect it to work with very many compilers these days. Some will just warn you. Some will give errors. Anyway, doing it the modern way is a good habit to get into. Is it really so hard to declare your return types and parameters? I think not. Just a little typing.

 

[AtomSoft]

ok so im set .. for now

 

[blueroomelectronics]

Stupid question but is C18 a C, ANSI C or C++ based compiler?

 

[futz]

Stupid question but is C18 a C, ANSI C or C++ based compiler?

Definitely not C++. Too fat and totally unnecessary for MCU's. It may or may not be full-on ANSI, but it's at least close. Most compilers aim for the ANSI standard if possible. It's just a C compiler.

An ANSI C compiler is still a C compiler. It just conforms to official ANSI standards for the language.

C++ is the object-oriented superset of C. It includes C and adds the OO stuff as well.

 

[BeeBop]

Stupid question but is C18 a C, ANSI C or C++ based compiler?

I don't think it's a stupid question; I hope my answer isn't stupid.
I believe it is based on gcc, which is (at least very close to) ANSI C, and it is C, not C++.

C++ is an object oriented language, which is, I believe, a natural progression of using structs in C. (anyone care to jump in on this one?)

All of the various compilers make claims they are 'ANSI C compliant,' even CCS, which relies on its own, very obfuscated, unaccessible to the user, routines.

The value in a compiler which complies closely with the standard, is that the code will be very easy to port from one compiler to another. Still, when you try to compile code written in C18, on say HiTech, or SourceBoost, you have tons of changes to make.
There is also the argument that code which compiles with a standard, is more portable between architectures. Perhaps some have achieved this within a microcontroller family, however because of the differences in chip architecture, there is no code which can easily be ported from one to another (PIC C to AVR C. or ...)

 

[BeeBop]

Ha, both typing at the same time.

Some discussion on the differences between K&R, ANSI, etc. would be of use here.

Then there is MS, with its own ideas of how everything should be done. :-O

From the intro to gcc at **broken link removed**

By default, gcc compiles programs using the GNU dialect of the C language,
referred to as GNU C. This dialect incorporates the official ANSI/ISO standard
for the C language with several useful GNU extensions, such as nested functions
and variable-size arrays. Most ANSI/ISO programs will compile under GNU C
without changes.

There are several options which control the dialect of C used by gcc. The most
commonly-used options are -ansi and -pedantic. The specific dialects of the C
language for each standard can also be selected with the -std option.

 

[futz]

Ha, both typing at the same time.

Heh Good, at least you don't disagree with me. I'm kind of making like a C "expert", which I most certainly am not.

I've programmed in C on and off since around 1983. Never professionally - just for fun. Started out on the TRS-80 Color Computer, running OS-9 (Unix). This was before Linux was invented. Biggest thing I ever wrote was a PC paint program from scratch. Wrote my own primitives and all. That was fun. I learned a LOT. Then forgot it all and relearned it years later playing with doing PC Graphic Demos (that Euro demo-scene thing that used to be big there).

Then I forgot it all again till just these last couple weeks when I got that dsPIC30F working and discovered that C30 assembler is very difficult (not the language - the tools), but C30 C is pretty easy.

 

[BeeBop]

My story isn't so different; I learned programming with MODULA II, which was developed by Wirth, as a teaching language, on a Spark Station under UNIX. At the same time, I had a MAC at home, (OS 7, or something) and a PASCAL IDE (Samantec) which is very much like MODULA. I would do my assignments in PASCAL, then port them to MODULA, and using telnet, upload and compile my projects on the work farm.
I learned C on my own, (using Metroworks C) working through some books about the MAC toolbox, building a few 'standard' apps. I've never programmed professionally, either.
Finally, when I was in Korea, where MACs were very expensive, and after tons of frustration trying to get my MAC interfaced with the real world, gave in and built a windoz box. Now, I have no interest in the PC, other than where it meets my micro.

Still haven't got around to that 16 bit part, though!