Is it worth to still learn C18 language?

[biomed12]

Hello dear members,

I need to design udp server with PIC. I have used CCS C compiler until now. I feel that CCS is comfortable but it is not supported enough. So, I decided that I need to learn any microchip company language. XC8 compiler language feels me very complicated and I think it has disgusting syntax. I saw C18 examples and syntax and I decided that I should learn this syntax. Bu again, i read a lot of bad things about its future. It won't be supported no longer etc etc..

What do you think, is it worth to learn C18 language still? Will I have any problem?

[mars01]

C18 compiler last update was in 2014:
http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=SW006011

Therefore all the PIC controllers that became available in the meantime are not supported in this compiler. Furthermore, the development is frozen and this means no bugs solving, no support ...

XC8 is THE PIC 8bit compiler from the point of view of Microchip.

The fact that XC8 seems to be complicated and "ugly" come from the fact that the way you learned to program was in a CCS way. XC8 is a bare metal compiler and doesn't give much in terms of already made functions like CCS gives to you (or like mikroC does). Using XC8 means you have to do by yourself a lot of things that CCS was doing in a line.
But this behavior gives you the freedom to do it in your own way.

I see the move from CCS to XC8 like a process of growing up. It's not always pleasant but once you get comfortable with it you will see the benefits.

You ask about problems using C18 compiler ... Who knows if you will hit some obscure bug or if you will need to use a new (and cheaper) PIC controller?
Microchip has a policy to manufacture even the oldest controller that they put on the market (but at a higher price than the new ones) so if you stick to one controller already supported (and costs are not so important) then you can use it and hope you'll never hit a bug.

Even Matrix Multimedia, in FlowCode 7, has made the move from BoostC compiler to XC compilers ...

[motox]

I still use C18 with no problem whatsoever.

[anotherandrew]

CCS is garbage. If you want to program in BASIC use BASIC language. If you want to program in C use C. CCS is strange hybrid of these. I have found also compiler bug which causes me a lot of hours to debug my code when error was ultimately in CCS.

XC8/16/32 is decent compiler and PIC has nice library support too. No need for CCS garbage to pollute your design.

[Signal]

CCS is garbage. If you want to program in BASIC use BASIC language. If you want to program in C use C. CCS is strange hybrid of these.

I never used CCS compiler. I thought the main specifics of this compiler is a bunch of built-in functions for most (if not every) hardware interfaces that makes CCS-code easily writable for novices and easily portable between supported devices with the cost of lost control to some degree.

I am very curious what I missed. Where is the BASIC part in CCS compiler syntax?

Posted on: August 28, 2016, 06:31:14 18:31 - Automerged

What do you think, is it worth to learn C18 language still? Will I have any problem?

You need to use C18 now to support/maintain or develop projects that were written in C18 and not yet migrated to new compiler that could be non justified.
Or you have a license for C18 and do not have funds to obtain new license for new compiler.
Another case - you just continue to use old good C18 (like motox does) while do no not encounter a problem.

Any other cases why not to follow recommendations from main compiler supported - chip maker? Why don't you think that Microchip is serious and have reasons to recommend not to use C18 for new projects?

[CocaCola]

CCS is garbage. If you want to program in BASIC use BASIC language. If you want to program in C use C. CCS is strange hybrid of these.

CCS is not a BASIC compiler nor is it a strange hybrid of C and BASIC, claiming this is just silly nonsense...

CCS is a C compiler with a ton of built in already scripted libraries/functions you can exploit...  Yes, CCS is not 100% ANSI C compliant but it's very close and very much a C compiler at the end of the day... Don't confuse built in libraries/functions or not 100% ANSI C compliant as meaning it's somehow BASIC or flawed junk...  If you are writing your own code for CCS the differences should not be a problem as you should be aware of them and code around them, if you are trying to port an existing C project from another compiler you might have issues on occasion, but that doesn't make it bad just different...

I have found also compiler bug which causes me a lot of hours to debug my code when error was ultimately in CCS.

Every compiler has it's quirks or so called bugs, but regardless of that many are way to quick to blame the compiler when it is in fact a coding irregularity for the compiler in question...  I'm not saying compilers are perfect, there are known bugs and limitations, as a coder you discover those bugs and limitations learn code around them based on you compiler choice, in the end it makes you a better more versed and adaptable programmer...

[Vineyards]

I think, I keep writing the same thing over and over again but CCS' approach to programming doesn't suit me at all. CCS uses macros for every little thing which puts me off. Ansi C is already quite powerful for creating re-usable code; there is no need to add so many propriatory macros. C18 looked serious at the beginning but a bit more difficult. So, if compiler were political parties, CCS would be Trump and C18 would be Brezhnev. MikroC represents the mainstream. It has all the required libraries etc, and a lot easier to master. None of these is perfect by the way at least not in the sense Borland sounded 20 years ago.

[CocaCola]

I think, I keep writing the same thing over and over again but CCS' approach to programming doesn't suit me at all. CCS uses macros for every little thing which puts me off. Ansi C is already quite powerful for creating re-usable code; there is no need to add so many propriatory macros. C18 looked serious at the beginning but a bit more difficult. So, if compiler were political parties, CCS would be Trump and C18 would be Brezhnev. MikroC represents the mainstream. It has all the required libraries etc, and a lot easier to master. None of these is perfect by the way at least not in the sense Borland sounded 20 years ago.

So in the first half of your reply you suggest you only need an ANSI C compliant compiler with no need for proprietary libraries but in the second half of your reply you hype the MikroC compiler that in fact uses quite a few proprietary libraries itself and is not ANSI C compliant?

I fully understand that there a different strokes for different folks, but when you inject opinion and/or preference based 'if-then' statements into an argument and fail to follow them yourself, it really makes for a weak argument...

I get it that CCS (or any other compiler for that matter) doesn't suit all, that lack of suiting ones own preferences does not make it factually bad... It simply makes it different and many people like different...

[Vineyards]

Perhaps, I couldn't explain my point very well. I tried CCS a long time ago and tried to learn all those macros that are used for configuring pins, activating timers, reading or writings bits or bytes. The more you learn this stuff, the farther apart you get from the real thing and you still have to learn a bunch of new things which will not help you in anyway should you decide to use another compiler or to port your existing code into another platform. I am not referring to libraries that come with all compilers. In many cases, they are time savers and are indeed useful. Thanks to them you don't have to learn how to communicate with an I2C device by deciphering the meanings of signal sequences etc. I also didn't like the way you had to go through several configuration and initialization screens you had to fill out to reach your blank code page. The current trend doesn't care about my thoughts though. This method has now been used by things like Proteus and even MikroC at the moment.

[Signal]

<...> The more you learn this stuff, the farther apart you get from the real thing and you still have to learn a bunch of new things which will not help you in anyway should you decide to use another compiler or to port your existing code into another platform <...>

That is exactly my impression! Though we are feeding the offtopic

[anotherandrew]

@cocacola i did not mean it was a basic compiler, I mean it is "abstract C" and the library internals hidden so you rely on this high level code. Like @vineyards say, get further from hardware and now your code relies more on CCS than HW.

[CocaCola]

@cocacola i did not mean it was a basic compiler, I mean it is "abstract C" and the library internals hidden so you rely on this high level code. Like @vineyards say, get further from hardware and now your code relies more on CCS than HW.

And to that, I would say if the goal to stay close to the HW and away from high level code, skip C and use assembly...  But, then one would argue that the learning curve for assembly and development time is generally greater than using C, and to I would say yes, and that is the same exact argument one could use to justify the use of CCS over a bare bones C compiler...
 
It's never a one size fits all shoe...  I'm a freelance programmer and I end up picking up many projects started by others, so many times I don't get to choose the compiler the existing project was started in, sure I could port it to something but many times it's best to just wrap it up in whatever compiler it was started in, and many time the clients want exactly that  as they don't want to invest in another new compiler package...  And although I'm far from a wiz at most compilers, I have gained enough experience with many of them to get by, and to me I believe this 'experience' with many different compilers makes me a better rounded programmer in the end, and dare I say might actually bring me closer to the hardware...

[biomed12]

Dear members, thanks for your invaluable advices and experiments with some compilers.

At the and of all of these comments, I thought I should have learned XC8. But I find it so complicated.

I started with the offical "MPLAB_XC8_Getting_Started_Guide". Everything was so simple at the start point. But i realized that at the time, it was like ASSEMBLY language. I felt that I should have controlled every step of project. I mean that

#include <xc.h>

int main(void)
{
WDTCONbits.ADSHR = 1;
MEMCONbits.EBDIS = 1;
TRISD = 0x0; //
LATD = 0x55; //
return 0;
}

it is like assembly. I wonder if i want to use any peripheral like USB or TCPIP, what will be the stuation?

Second issue I came across is related to first issue. I downloaded the "TCPIP Stack Lite" and "just" I opened project in MPLAB-X environment. After, I just clicked "Build" button and there were a lot of error. Briefly, how can i build a peripheral project.

Maybe i couldn't tell what i want, sorry for that. Briefly i want some recommends how to learn xc8 intensively. I want to code it comfortly.

Note: I completed TCPServer project with CCS and it works perfect.

Thanks.

[Vineyards]

I think we have to understand everything categorically:

1- There are hardware registeries, fuses etc and these can change dramatically from one PIC to another. They are not necessarily compatible. The examples you provide must be about assigning values to the Watchdog module. Those are hardware registries or module names determined by Microchip. What works for a specific PIC may not work for another simply because it doesn't have the same modules or it doesn't have the same version of the module or registry. You need to study the datasheet of the PIC very carefully. You can spot all the registry names etc there. Once you learn the names, the functions of those you can start configuring them.

2- There are compiler specific macros, commands, statements etc and they may different significantly between compilers. You should refer to compiler's manual for specific information.

3- There are software and hardware bugs. Hardware bugs tend to be fewer and software bugs can be very annoying indeed. Keep an eye on forums etc.

4- Assembler works at a much lower level and again it is specific to hardware families. This is not a pice of cake. There are few people who have mastered this art. Zuisti is one of them. After having learned everything, you may need to start over if you want to switch to a newer system.

To make things work you need to start with a certain PIC and stay with it until you have learned it sufficiently. It would be good if this PIC is a common one and that it can fully answer your hardware requirements.