what's wrong with a pic ?

Try bit banging 6 I2C channels and see who wins. The PIC is poor at multi-byte math. The right tool for the job works better. The PIC has its place. How is the MPS430. I missed MSP430 day. I was debugging my PIC code. A little irony there.

I did find a bug in the new version. I must send it in. If you do the "more advanced C programs" in assembly you will find you choose the wrong CPU for the job. It is a PIC not a Pentium. An why should I have to deal with PIC ASM. The compiler works. The code fits into the parts. Going from a PIC16F876A to a PIC16F873A does not affect the cost of my product. The tiny stack makes me wish I choose the PIC18

Yes Hi tech is not fully ANSI compliant. So what! If you are trying to high level C code, you have the wrong CPU.

This isn't c.l.c!

If you want to talk a load of bollox about what C and what is not go back to c.l.c There are virtually no ISO C compilers in existence and those that there are do not exist in the embedded world.

Given the number of DR's on the current version no-one on the planet is using Your definition of C.

A lot of 8 and 16 bit MCU compilers don't have recursion switched on by default.

There are several C compilers for the PIC though their effectiveness varies.

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

Such as? There are LOTS of advanced programs a pentium cant do... you been an Alpha for them :-)

ANSI C was superseded in 1990... I assume you are incorrectly alluding to ISO 9899:1999 ? With or without t TC1 and TC2?

A moot point.

Against speed of development, testing etc it is a case of balancing a lot of variables.

Erm, Neil, next time, before you get all heated up about a single word you find in a posting, please try to read it in context. Chuck was talking about requirements of the C language, not requirements of some project. And he mentioned recursion as an *example*, not as the only issue.

A PIC is objectively too small to fulfill the requirements laid out by the definition of the language. And the one about recursion isn't the only roadblock, either. 32-bit int arithmetic, floating-point support, sizes of variables and functions that must be supported are only the first couple other constraints that come to mind which most versions of the PIC architecture can't expect to meet. FWIW, a large fraction of actual '51 family MCUs can't meet those requirements either.

Yes, there is are programs that claim to be C compilers for the PIC16 architecture. The problem is that the "C" they actually can cope with has not much more resemblance to the well-defined standard programming language C, than the language in the manual of your average 10$ radio alarm clock has with actual English.

If you don't know why then you have no business writing embedded code.

Ian

Except you are completely wrong!

C is not a well defined language.

The current C99 version has two large TC's and a vast number or DR's It is also so far off track as to what C really is (according to quite a few members of the ISO C panels) that virtually no compilers have bothered to fully implement it.

My issue was that his point seemed to be if you can not support the full spec you might as well program in asm. That is not my opinion. The Keil 8052 compiler supports recursion function pointers and malloc. because the standard says so. using the is usually a bad idea.

Hi-Tech PICC supports floats and and 32 bit math.

I was able to copy code from another project that used a real (x86) CPU.

May people assume that if it supports C I should be able to copy my PC code to it and go. You end up with questions like"can I run Linux on a PIC", "can I decode Video on a PIC", "How do I get some widows call to compile on my PIC".

I would never choose to program a PIC in ASM. The available compiler is good enough to acomplish the tsak my company wants. If not I would tell them "I need more power Scotty".

Is the PIC a lame CPU, sure. But it works very well for tasks it is suited for. Cheap, low power small size. And reasonable C support.

I will resign on Tuesday, since Monday is a holiday.

Yes I should know enough about the PIC ASM to single step it. To know if 32 bit math in an interrupt is a bad idea. To make a subroutine in needed.

But an entire project in PIC asm, why? Will I get a raise. More likely questioned about what is taking so long. RISC means more lines of ASM to do stuff.

I am sure I will get my fill since I will inherit a PIC asm project. done in PIC ASM to save money on the code size.

Isn't it pure pedantry to complain that a device with 256 words of code space can't do floating point when it can support plenty of other standard C code? What is the point in complaining that you can't do something that you wouldn't want to do in the first place?

Clearly any device that doesn't have 509 bytes of code space or RAM cannot have a 509 character string literal in a program. But again, who cares? If I needed a 509 character string literal, I'd use a device large enough to support it. And yes, there are lots of PICs that Hi-Tech can compile a 509 character string literal for, while doing floating point and 32-bit integer math at the same time. If a compiler can only pass the translation limits requirements on the largest device in the family, is it useless on other devices?

Can you give an example?

Well at least you can fix it at the roadside.

I fully agree - in c.a.e., the practicality of a compiler for embedded projects suitable for the micro in question is far more important. If you have to go to c.l.c. for advice (rather than just for interest) when writing embedded C, then your code is bad - even if it is legal, and even if it works.

While recursion is very seldom the right way to approach a problem on a small micro, the fact that recursion is not supported (either not at all, or enabled with a switch) shows the processor is not well suited to C, since it is missing one or both of a proper return stack (rather than a fixed-size hardware stack) and a fast access data stack for local variables. These are not essential for making a C compiler (in the c.a.e. sense) - but they are important for being able to efficiently and effectively turn C into target assembly. This makes the "does it support recursion" test quite useful, even if you never want to use recursion itself.

The other important things to look for are a flat data space and a flat code space (or best of all, a single flat space), and plenty of registers to work with (especially more than one pointer). Again, a compiler can work round limitations if needed.

The PIC manages to fail on all these counts - I can't think of any processor I've used that is a worse fit for C. Of course, that doesn't mean that you'll do better in assembly - just that you'll never get fast and tight code from a C compiler for the PIC.

They make the best of a bad job.

Recursion has to be explicitly specified for any functions you want as recursive. By default is it switched of.

I have come across this many times when doing tech support. :-(

I have often see can "can I run Linux on a PIC" Or 8051 etc. Also requests for a full TCP/IP stack for a PIC.

I would prefer to program in C but on a PIC asm is also sensible.

Agreed.

exactly... if you are using a PIC weather the compiler supports floating point maths is likely to be irrelevant.

I have to completely disagree on that. Though there are far better places than c.l.c as they tend to be VERY narrow and come what bigoted.

Well this just in not correct.

Not according to several compiler writers I know.

Maybe.

That is opinion. In a perfect world all embedded MCU would have 512GB of flash in 3mm sq and sun on 2ua...... We would also all be using Modula 2 :-)

Yes you will.... Just not a fully conforming C99 compiler. However as these are like hens teeth and the C standard has wandered off into it's own reality it is not really relevant.

Agreed.

Unless you're talking about proper tail-recursion support, recursion is just a special case of reentrancy. Recursion might not be often needed, but reentrancy is used _very_ often on even the smallest of embedded systems.

If a compiler doesn't support recursion, that means it doesn't generate re-entrant code. Without re-entrant code even simple things like multi-tasking and interrupt routines written in C become very difficult.

Everybody has to do that sometime...

Ah, so you do know.

Depends. If you don't know when it IS worthwhile to do a project entirely in ASM then you should not be writing embedded code.

Ian

LOL

in

If you decide to write an entire project in ASM you are probably a +75 years retired programmer ;)

ASM is dead. A few rare exceptions don't change that fact.

Another 15-20 years and C is dead as well.

Just got a program from a customer which is supposed to drive a TRIAC. The program was 700-800 bytes written in Assembler for an ATtiny13.

Translated the program into C using the IAR EWAVR compiler and cleaned it up. Latest version is now 500 bytes of code and uses less SRAM/Registers...

Who needs Assembler... Except PIC programmers...