Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Can we Program PIC Microcontroller in Microsoft Visual C??

Status
Not open for further replies.
Feel free to write such a compiler then - but as PIC compiler's generally only run a sub-set of standard C, then what's the point of running a much smaller sub-set of C# or whatever?. Most of both languages don't really apply to PIC's, it's much too small to make use of it.

I'm also not impressed by the portability of C, it's always been one of the most vaunted 'advantages', but from what I've seen every C compiler is different, and it's not that easy to port code from one type to another.
 
I'm also not impressed by the portability of C, it's always been one of the most vaunted 'advantages', but from what I've seen every C compiler is different, and it's not that easy to port code from one type to another.

I've taken code from other systems frequently. FAT libraries, wireless libraries, GLCD display, buffering and common chip interfaces. It's not perfect and some compilers do some silly things, but I certainly wouldn't say porting code is very difficult. I work with 5 different chips here with 5 different architectures/manufacturers and share code between them.
 
Nigel,
Great point in that C is already stripped down, why would we use C# when we already don’t use all of C. Its all in the eye of the beholder I think. This isn’t a “What does C# get me over C”. Its more of a why would it not work?

To your point, if I already have a PVC container that holds 30ml of fluid, but I never have more than 10ml of fluid why would I upgrade to a Nylon container which holds 50ml? The answer is simple… I don’t have anyone on staff who knows how to work with PVC, but I have 100 people who work with Nylon every day. Do I hire a PVC expert and keep using the old PVC container, or use the Nylon even though I could get away with less?

Now what really gets me thinking is the next comment by DirtyLude… “I've taken code from other systems frequently. FAT libraries, wireless libraries, GLCD display, buffering and common chip interfaces.” This comment suggests code reuse with this new language will suffer greatly in the beginning. With C you are expected to do things like directly access hardware, and porting old libraries can be a great resource. If you all of the sudden had to write that FAT driver in Java, you would be porting from C to Java, and you would have to know both languages. Full circle back however to the point of why this could be important to have more modern languages... most people are not using/learning C any more. Those who know it and use it every day will be (already are) a very small minority very soon. Its like finding a COBAL programmer these days, would it be a good reason to stick with COBAL development if you already have a whole bunch of COBAL libraries that can write FAT? Can it do FAT32? What about NTFS? Why not? Because its old, and when the development was going on, these newer protocols had not been invented.

Crazydart
 
The problem with the higher level languages is that they rely on memory being RAM. uCs have very little RAM, and most everything, including data, is in ROM. There is no availability for new() or delete() as it's used now days due to the amount of overhead that goes with them. Just the amount of memory that a dynamic memory manager would need for itself would blow out the RAM on most uCs, not to mention the memory needed for the objects themselves.

C is used for uCs because it is bare bones. You should know exactly how the ASM output is going to look like for every line of C code you write. You must have that amount of control due to the VERY limited resources on a uC. I've used C++ before, but it just ends up looking like C in the end, due to these same restrictions.
 
You cannot compare a micro controller to a PC, as many people have pointed out, C# is an interpreted language, run within a framework, much like Java. C# at the moment is not as portable across platforms as Java or C++, as I guess this is down to demand! It will run on the 2 major operating systems, Windows and Linux (under Mono Project), I program frequently in Java, C / C++ and C#, They all have their strengths and they all have their weaknesses, noteably speed, but with modern processors, you dont really notice that much!

For cross platform GUI applications I would use Java, or C#, for time critical systems, just for sheer proven robustness I would choose C++, this is a fully compiled application, and because of it's close optimisations with assembler routines it is going to come out top trumps in a speed of execution test.

What you have to think, is the back end framework that runs your Java or C# App is probably written in C/C++ anyway, most operating systems are written in assembler and C/C++.

If you want to learn programming, learn C++, if you want to deploy something quickly use C# or Java, if you want to run something cross platform, and fully portable, use Java.

If you want to program a PIC micro, use C or assembler, most of the other language options with a few exceptions bloat the end assembler code and can use up valuable space.

There have been a few suggestions floating around, CCS C, MIKROC, C18, HITECH C.

Most are portable if you know the fuse settings and library representations of each compiler.

Wilksey
 
I use ANSI C, not C++, not C#, for microprocessors.
The microprocessor-specific code is carefully isolated to one module.
I code carefully to avoid non-portable code with dependencies such as size_t (16 vs 32 bit ints) and byte order (endian).

It takes experience (or reading, a lost art), and discipline and care.

If you use a single address space processor such as ARM7/Cortex instead of PIC or AVR8, you get rid of a big portability issue: the dual address buses of flash and RAM and memory-type-dependent instructions.
 
Last edited:
@crazydart

The mind of the person doing the coding is far more important than the language used. A skilled person can write good code in most any language. A poorly skilled person can write crap in any language. I have doubts about teaching objects to people who can not write a decent program without them.

I enjoy OO programing. But most embedded applications are are not good candidates, and many uC's lack the resources for an OO program.

You have given C a bad rap. It has a few warts (beauty spots?) but it has all the bits needed to write good clean code in a reasonable amount of time. C++ is but an extension of C. Java and C# are heavily influenced by it.

I can not help but think that if you were a more diversified programmer you would not be trying to use C# on uC's. That is to say rather than taking the time to become fluent in C (a language well suited to uC's) you are attempting to use C# on uC's.

People who program uC's for a living seldom get the chance to choose processor, language, or even the compiler. These are often determined by people who started the project or more frequently by the culture of the lab/shop you are working in.

most people are not using/learning C any more.
I have not seen where C has been displaced in embedded systems. I use C# on the PC and C on the uC. It is very easy to move between the two.

To use a uC you have to configure the processor and manage the peripherals. Each compiler vendor has a somewhat different way or set of names. It is a major source of pain. Using C# will not make this go away.
 
Last edited:
There is an OOPIC - but I've never found OO at all useful anyway, even though Turbo Pascal was a major supporter of it.

I have seen it and it is too restrictive.

A more robust OO implementation Pic18Forth OO Engine

But then it is based on forth and I am sure people who have not warmed up to forth will object. The major complaint is forth is too flexible, That is an advantage when creating languages based on it. Much as lisp was used by the AI community.

I will be staying with C.
 
It really depends what you want to use C++ for over C#.

They are both similar to each other in ways, chances are if you can program C++ you will pick up C# easier than if you know C# to learning C++.

In fact, if you can master C++ any other language will seem straightforward enough to learn, apart from assembler maybe!

Wilksey
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top