PIC Programming in C Language

[onlineajit2000]

Hi Friends

I have examples in Basic Language of PIC Programmes.
But I know only C Language. So I dont want to learn Basic from
start. Plzzz send me some C written programme for PIC I'll refer them and learn how to programme PIC in C. I found some Compilers of C(MPLIB).
just send .c files if possible scematic digrame and source code
at onlineajit2000@yahoo.com
Thank You!
Ajit

 

[butterfly]

YOU MAY FİND WHAT YOU WANT IN CCS FORUM PAGE:

https://www.ccsinfo.com/forum/index.php

GOOD LUCK

 

[philba]

look here : https://www.google.com/search?hl=en&q=pic+c+source+code&btnG=Google+Search

 

[Oznog]

MCC18 or even PICC18 is a much better compiler than CCS.

Many examples of C coding out there. The code will generally require changes depending on the compiler, though.

 

[philba]

two others to look at

mikroelectonika C **broken link removed**
free version is limited to 2K of code. code gen isn't great but they've got a really nice library for the microcontroller beginner.

cc5x. **broken link removed** free version is limited to 1K but its a lot tighter code than MikroC. for PIC18, check out cc8e

 

[sukumar]

#include<pic.h>

void delay(void);

void main()
{
  TRISB=0x00;
 while(1)
  {
  PORTB=0xFF;
  delay();
  PORTB=0x00;
  delay();
  }
}

void delay()
{
  int i;
  for(i=0;i<3000;i++);
}

This is a very simple code to blink8 led's connected in PORTB. This is compiled using Hitech C compiler. Hitech PICC is very simple to use.

 

[jcirafic]

Thanks Sumukar

Sumukar I just downloaded the hitech c compiler, it seems like just what I needed. Not having to write assembler code will speed up development time. Thank you for the great suggestion and saving me a valuable commodity-time!

 

[giaosucan]

To programe for PIC , you can choose some C language compiler
such as CCS ,HT-PIC .in addition ,you can use ASM language complier (MPLAb)

 

[giaosucan]

I know some website discuss about that ,such as
http://www.picvietnam.com
you can consult

 

[b0j3]

You can also use sdcc (http://sdcc.sourceforge.net)

 

[iso9001]

I've used the Microchip compilers and don't like them at all. The header files are bloated, hard to read, and the interface needs some work.

However, I've used CCS for awhile and its worked great. Better then Hitech I think. The forum is pretty good. The only thing I dislike is that they seem to have new bugs with every single release. And thier support for x64 blows.

Other then all that, I still recommend it.

 

[giaosucan]

how about the basic language ?
is it good ?

 

[sukumar]

Hi,
mikroBasic is also an easy language to use but C is much more easy than basic. when comparing both Basic has additional features. But C is user freindly.

when u are using Hitech picc just install MPLAB Tool suite from hitech-group there by we can write codes in MPLAB without using hitech IDE.
But u have to select language toolsuite in MPLAB by

Projects->select language tool suite->Hitech picc

 

[Nigel Goodwin]

Hi,
but C is much more easy than basic. But C is user freindly.

Interesting point of view?, "C more easy than BASIC, and user friendly", must be the first time anyone has ever suggested that?.

 

[akg]

Interesting point of view?, "C more easy than BASIC, and user friendly", must be the first time anyone has ever suggested that?.

for one who 'thinks' in the C format , basic is trash..

 

[Oznog]

I tried out CCS and found it was a cruel joke.
I think it was when I tried to do passing a pointer to a constant struct that things went downhill. It just could not do anything like that and there's no workaround. I asked about it and found no, they just never got around to implementing all of C. It's infuriating to find something labelled a "C compiler" that won't handle essential parts of C. It's a load of crap and I would not recommend it.

 

[evandude]

BoostC is my personal favorite, you can get it at http://www.sourceboost.com

It's quite a bit like CC5x, but its free version is not as limited, and the full versions are SIGNIFICANTLY less expensive.

Oznog, I can't say much without knowing more about what your program was trying to do, but I do think I will point out that in the end, we're still working on a PIC. I've seen some complaints about certain compilers that they don't work with some of the fancier features of C (or even C++), but often if you think about how that feature would get implemented in assembly, it can get very messy and inefficient, so I don't feel it's heresy to be excluding a few parts of C if they simply don't "belong" on a PIC. On the flip side, there are also a few features that are NOT part of C that are very helpful to include in a PIC "C" compiler... an example being the method of bit accessing that is used in CC5x: if you want to set bit 7 of variable ABC, instead of doing bitwise operations or anything, you can simply do ABC.7=1;
When I first switched to BoostC, they didn't have that feature, and when I suggested it, they were reluctant because it wasn't a standard C operation, but enough people seemed to agree that it was convenient and it's now in there. In the end, you have to fit the tool to the job.

I use C on the PIC because it takes less time to write the code, there's less housekeeping and it's easier to follow than assembly, but at the same time I avoid many of the features of standard C that I think would not port well to assembly.

However, if the features it is missing WOULD port well to assembly, and they just never got done because the developers were lazy, then yes, I would definitely find fault with that. And, based on the times that I tried out CCS, I did not like it very much either. In the same way that I avoid standard C features that are abstracted way away from the assembly level, I also do not like using proprietary functions of the compiler - and CCS seems to make heavy use of these types of functions, where it seems like every time you want to do anything you have to call set_bit() or shift_left() or output_low() or whatever. Not only does that mean the code is not portable to other compilers, but I also don't like not knowing exactly what they're doing, because that's when unexpected things happen.

 

[jcirafic]

akg yes, I agree, being used to C and C++, Basic is just not what I want to use even though most think it is easier. C and its variants are more marketable.

 

[Oznog]

However, if the features it is missing WOULD port well to assembly, and they just never got done because the developers were lazy, then yes, I would definitely find fault with that. And, based on the times that I tried out CCS, I did not like it very much either. In the same way that I avoid standard C features that are abstracted way away from the assembly level, I also do not like using proprietary functions of the compiler - and CCS seems to make heavy use of these types of functions, where it seems like every time you want to do anything you have to call set_bit() or shift_left() or output_low() or whatever. Not only does that mean the code is not portable to other compilers, but I also don't like not knowing exactly what they're doing, because that's when unexpected things happen.

Yep, and the pointer to a struct is something that should have been quite straightforward to implement. If you can implement a ptr to an array, you can implement a ptr to a struct. They were lazy.

I also agree CCS's emphasis on their proprietary functions is a big problem. Coding by writing in shift_left() etc tasks isn't in fact writing C at all. It's not any language really. And of course the program is nonportable and you don't learn much about C if that's all the coding you've done.

 

[Nigel Goodwin]

And of course the program is nonportable and you don't learn much about C if that's all the coding you've done.

Considering one of the big 'plus' points about C was it's supposed portability, it's always been a fairly non-portable language from what I've ever seen of it. Obviously PIC implementations are even more so!, but even Windows and DOS versions can't simply use each others code.