pic c

Depends on the compiler. Some PIC "C" (I use the quotes deliberately in this case!) compilers are a long way from standard C; others manage to conform quite closely to the standard. If you want a cheap high-level language for the PIC, buy one of the compilers that make compromises to fit the PIC architecture. If you need a standard C, then expect to pay for it in both efficiency and price! IAR make an excellent standard C compiler for the PIC16 and 18.

The PIC24/PIC30 toolchains are based on GCC, and are pretty much standard.

pete

--
pete@fenelon.com "how many clever men have called the sun a fool?"

Now, let me guess which C compiler you are referring to....MPLAB, SDCC, HI-TECH, WizC, etc.

--
Regards,
Richard.

+ http://www.FreeRTOS.org
A free real time kernel for 8, 16 and 32bit systems.

+ http://www.SafeRTOS.com
An IEC 61508 compliant real time kernel for safety related systems.

Is there a C language item which isn't implemented in one of you mentioned?

Thanks

By C language item, do you mean all items contained in the current C Standard, ISO/IEC 9899? If so, you won't find any C compiler targeting the PIC which conforms to it.

In general, most embedded processors for low-end micros are based on C89 and eliminate features that are typically not required. Many compilers for low-end processors do not support recursion, full IEEE floating point, wide characters, or I/O-oriented library functions, although the latter are not required for a conforming standalone implementation.

If you want to see what features are supported, most vendors offer demo versions of their compilers and/or documentation downloads.

Regarding you question of complex types, I assume you are referring to the C99 built-in complex arithmetic type. No, don't expect to find it in a PIC compiler, at least for an 8-bit target.

Regarding macros, all compilers will have support for macros. The quality of implementation varies, though, and many will miss the subtleties, such as the extra macro reference requiring for stringizing the contents of a parameter that is a macro name, or stringizing an arbitrary piece of text that requires escapes to be generated. A fairly high-end PIC compiler generates a warning for #if defined foo && foo != 1 that foo is undefined when the statement explicitly handles that.

--
Thad

Of Course It is a PIC. You can not get Answers till You ask a Full Question. The PIC16 will have the Most limits PIC16 and PIC24 Less

Hi-Tech Has a Free Limited Version and A Full Demo Download them and see is you code compiles. The main language function are there. The libraries are limited. The Call stack is tiny, and parameter passing has limits. Does #define work? Yes? Can you make unions and Structs? Yes

Actually there are only a few C compilers of any type that fully support C99.

Most are based on ISO C90 with A! And TC's normally called C95

C89 was the local US ANSI standard. C90 is the ISO or international standard.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Questions like yours periodically show up on this newsgroup. I'm always curious why posters are more concerned with C standard compatibility than with programming success. Maybe some over-reaching SWQA department is forcing unreasonable requirements on the programmer, I don't know.

As I see it, PICs (at least the 16F variety which I'm familiar with) are so close to the I/O, not to mention so C unfriendly, that to even hope for a useful standard C tool set is crazy: The code created just won't "fit" well into the task that its asked to do.

For example, look at the compilers offered at

No way are they close to standard C but they're still useful tools because you're programming in C but you're not jumping through hoops to fight the wierd underlying PIC command set just to achieve standard C compatibility.

My preference would be to find a tool that has the best of C mixed with the right hooks/pragmas/deviations that will get you to successful completion of your programming task.

JJS

John Speth wrote: *** and deleted attributions ***

I have no problem with your statements, as applied to PICs. However people generally prefer a system that complies with at least the C90 standard, because that virtually assures portability to other systems. Non-compliant systems should have a comprehensive description of their non-compliance.

Code written for a standard compliant system can be reused in many other applications.

Please don't delete attributions for material you quote.

--
 
 
 
 
                        cbfalconer at maineline dot net

In article , CBFalconer writes

Portability is of little concern to the majority. Also extensions tend to eb done the same way for all targets by a compiler vendor so if you use a GHS, IAR, Cosmic compiler on one target the way they do the extensions will be the same/similar on others. The problem gets worse when you transfer both target and compiler manufacture.

True. See Rule 1.1 of MISRA-C:2004

Not really. It may well be portable but it will probably be hopelessly inefficient.

:-)

:-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

be

I've been using Microchip C18 for a long time, and the bigest differenc (an d problem sometimes) I see is that on PIC you have two separat address space, ROM and RAM. Maybe some compilers abstract to you of that but C18 does not (It adds ram/rom qualifiers) If complex types are those defined with "struct", you can define the sam things as in standard C. Another difference is Integer promotions, that by default works different but you can configure it. I've have compiled lots of "standard C" programs without any problems, an some other with some modifications.

In article , Gonzalo S writes

Many other MCU use Harvard arcghitecute

No.

As do most other Harvard architecture compilers (see 8051)

Other compilers permit this too.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

I was one of the authors of ISO/IEC TR 18037 "Programming languages - C - Extensions to support embedded processors" This WG14 project was designed to address, document and standardize the common extensions that compiler developers like Byte Craft and those who play in the same sand box added to compilers that support embedded systems.

This project started by simply documenting what those extensions were. It basically came down to

1) Multiple memory systems RAM ROM differences of most processors. 2) Named address space to distinguish between address spaces RAM and ROM and specialized memory in many processors that feed a MAC in a DSP. 3) User defined memory like I2C memory devices . 4) Recognizing the asymmetrical nature of most I/O registers and address spaces 5) Need for a true single bit boolean (_Bool in C99) 6) Take C back to its low level roots with formal access to the processors and system registers and the compilers ability to access them directly. 7) Extending the number of data types that embedded systems compilers need to support. First by having more size specific integer types (introduced in C99) 8 bit embedded systems can benefit from adding 24 bit data types to the usual mix of 8,16 and 32 bit data types. 8) Many embedded applications (especially DSP and Fuzzy logic based applications) were being written fractional and accum (int with fractional part) fixed point number systems.

The need for this standardization was strong enough that competing companies spent serious time working hard to agree on standards. The 18037 standard implemented these core extensions is now approved by the required majority of ISO member countries is becoming available in released tools and validation test suites.

Where you may ask.

18037 can be found in the tools used to create most automotive engine controllers, many cell phones firmware, many many consumer products and many industrial controllers.

Small processors that have C compilers with the additions of ISO 18037 can for example have there full instruction set described in C and when compiled creates a single instruction for each asm description in C. (Incidentally proof that any asm program can be equal or SMALLER in C)

There is a whole thread on why porting code written entirely in C that uses the additions of 18037 is easier to port than code that has embedded asm in say a cell phone or high volume consumer product.

It Sunday and I haven't had my second cup of coffee.

Walter Banks

-- Byte Craft Limited Tel. (519) 888-6911

snipped-for-privacy@bytecraft.com

ed

Dont be rediculous

You need that second cup before posting.

Apart from the 'there' => 'their', I don't have a problem with what Walter said. He has qualified this with 'can be', and anything that moves towards full opcode coverage from C, to me is a quite positive step.

-jg

ed

ly

Well every compiler ive seen compiles to assembler so his staement is rubbish. Secondly he said "proof" which it doesn't. Of course as a compiler seller he will say anything to ship product. He would do much better by championing the real benefits of C over assembler instead of trying to justify its use on code size/execution speed over assembler, an arguement that he unlikely to ever win.

Well, they compile to machine code - not always assembler, but that's a detail.

I took Walter to be talking about something different : [not a sales pitch at all, but a change in the technical details ]

Older technology allowed in line ASM, but often lost optimise & error checking, when doing so, plus users had to know the semantics of assembler. So, workable, but not elegant.

What he is meaning, is newer compilers, can allow you to create single-opcodes, from C cource code. I'd call that 'C syntax Assembler', and IF you can get close to 100% opcode coverage doing this, you CAN use that _instead_ of in-line asm.

OK, users have to learn the 'C snippets' that map as opcodes, but for embedded design that's not much effort, and I see a number of advantages : The compiler now has full visibility, so mapping/optimize/checks are better, and source is more readable, and Libraries can now be done in this 'betterr C' - ie an advance has been made.

I think I suggested to Walter before that he put a source example of this on his web, and he may have done that.

-jg

In article , snipped-for-privacy@aol.com writes

instruction for each asm description in C. (Incidentally

You might have to eat those words.... I think he has written a commercially available compiler to do exactly what he says that is in use in quite a few places.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

As is yours. Most do NOT compile to assembler these days unless you ask them nicely. By default they usually compile direct to object files for linking.

Not true. Walter is honest in what he says otherwise no one would trust him. Even his time scales for modifications are reasonably accurate. Byte Craft, like most small companies would not last long if the were not honest. Since they have been going 18 years I would think they are honest. It is only the very large companies can afford to have salesmen who bend the truth. Ie Microsoft.

BTW Just in case Walter decides to take legal action over your defamatory statement what evidence do you have to back it up?

He does where appropriate.

He has. I think he produced a compiler to do exactly that.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Actually, cbarn's argument is correct - and although it is of little real value, Walter started this one with slightly pedantic "proof" (which was also technically correct but without real value). Walter claims that by adding assembly instructions to C, you can write any assembly program "in C", and thus for any given assembly program you can write a "C" program that is no bigger than the original assembly. This is correct (baring any required startup code), but of little interest in the real world. cbarn argues that since C compilers generate assembly (or machine code, but this has a one-to-one relationship with assembly), any C program can clearly be re-written as an assembly program that is no bigger than the code generated from the C program.

The two arguments are both correct, and of absolutely no practical use to anyone.

The proof of Walter's statement is obvious, since the extensions to C let you write any assembly program embedded within your C code. Walter is not claiming here anything about the quality of code generated from "proper" C compared to hand-written assembly (though he has done so on other occasions, with good justification but obviously no absolute proofs or claims thereof).

I've heard both big and small companies with honest salesmen and with salesmen who "exaggerate" - I don't see such any strong correlation. But Walter comes across as an engineer, not a salesman - thus honesty and technical correctness are his nature. I certainly have never had reason to doubt him.

There is certainly still room for debate on the benefits of assembly over C for small microcontrollers, but much less than there once was - and Walter's compilers are part of the reason for that. There is no doubt that it used to be the case that a half-decent assembly programmer could write smaller and faster code for a COP8 or an 8051 than a good C programmer with a top-of-the-range C compiler. But there is also no doubt that now a half-decent C programmer can write smaller and faster code using a top-of-the-range C compiler than a good assembly programmer. There can be occasions when assembly is still the best tool for the job, but they are becoming steadily fewer.