Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24

really?

I think you will find it is true for most there are exceptions which are in the minority.

MOST MCU's

???

And you appear to be it.

As this is comp.arch.embedded most here will be constrained systems.

That there are no "Standard C" compilers. GCC has it's own standard.

Unspecified and undefined..... there are hundreds of them.

If you are avoiding all those + the language extensions your programs must be very inefficient.

So was I.... The embedded extensions TR.

"moving towards"? Yes and they have a LONG (or even Long long :-) way to go. AFAIK there are only 3 or 4 which even come close to C99.

Not for most at the moment.

No they are well supported it is just that the C standard has moved well away from it target constituency.

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

Hi David,

I'm afraid you're missing the point. What you are talking about is the run time value of a pointer. What I am talking about is the compile time attributes of a pointer.

You can stuff an invalid value into a pointer at run time but at compile time the compiler knows that pointer by its attributes. If you decalre a pointer to char and then stuff a pointer to func in it the compiler will (or should) complain. Yes you can coerce the compiler into doing your bidding but then you also take responsibility for the correct use of the pointer thereafter - you can't blame the compiler for generating invalid code.

Also, by talking explicitly about specific 'C' compiler implementations we are getting side tracked from the issue which is that IT IS POSSIBLE for a compiler to track the use of a pointer and if you give the pointer a dedicated address space attribute, it is possible for *** A *** compiler to generate good efficient runtime code without the "decode at runtime" overhead. Think back to the 8086 'C' compilers that allowed "near" addressing modes for segmented pointers.

My XCSB compiler generates efficient executables for the PIC despite the fact that it allows pointers to RAM and CODE sapce and this is because it does track pointer use.

Regards Sergio Masci

- optimising PIC compiler FREE for personal non-commercial use

.

It's been a while since I've programmed Pic16 chips, but I'd choose an AVR over the PIC's any day, especially if programming in assembler. I prefer msp430 chips (in assembly or C) as a small micro, however - the

16-bit orthogonal single-memory-space architecture is easy to work with.

I agree with a fair number of the points below, so I'm not doing a blow-for-blow argument. But some I definitely disagree with.

The AVR is, by small cpu standards, highly orthogonal. There are, as you say, a few instructions that only work with some registers, but most of those are fixed in the megas. The difference between upper and lower registers is very annoying, but hardly difficult to remember - only upper registers can use immediate addressing modes. More annoying are the limited pointer registers - if the upper four pairs were all pointers and all supported the same modes, it would be a far better chip.

All the registers are memory-mapped in the same address space as SRAM. There are some registers that have shorter addressing modes - consider them as short-cuts instead of standard memory access, rather than as a separate IO space. When working in C, it makes no difference - the compiler will correctly figure out if it can use the short-cut opcodes in virtually every case.

All cpus I've worked with have different branch ranges.

Making STATUS a register would have been nice. More useful would be if the stack pointer was a register pair.

It would be rarely used - you can't fit everything into an instruction set.

Compared to other micros I've used, it's not bad.

I can't think of any reason I've ever had to toggle an IO bit. I always know if I've turned a bit on or if I've turned it off, so I know how to change it.

Who uses Atmel's own assembler? The majority of those programming AVRs in assembler use IAR's assembler (which is free - and downloadable from Atmel's website) or the gnu assembler (which is obviously free in all senses of the word). I don't think even Atmel ever recommended their own assembler.

If you want to start complaining about AVR Studio, however, there is plenty of scope (although it's good value for money!).

Early tools for AVR were very limited unless you wanted to spend a great deal of money on IAR tools. But then, early tools for the PIC were no better. I remember reading the errata and limitations list for Microchip's PIC compiler (before they gave up on it entirely) - it was a real laugh.

You don't use the same emulator for modern PICs as for older PICs either, although admittedly Atmel seems to change faster than most microcontroller suppliers.

Agreed.

It's a RISC processor - everything goes through the registers. It would be a lot better with four pointers, rather and two and a half, however.

Very few small microcontrollers have proper interrupt priority.

You can mess around with pointers to a great extent in C - and if the compiler is following the ANSI standard, it must allow most of these coercions. Like it or not, you cannot call a compiler "standard" if it is not possible to (say) convert a "char*" to a "const char*", and you

*are* free to blame the compiler if it generates invalid code. In particular, it is not uncommon to want functions that will handle a string or a block of memory through a pointer, and the data pointed to may be either "const" or not. The only standards-compliant general solution (on Harvard architectures) is for the "const" data to go in ram. Note that I don't think that slavishly following the standard is necessarily a good thing here. And if your compiler can figure out, at least for the majority of cases, whether pointers and data should be "flash" or "ram", then that is excellent.

Exactly where in the ANSI C standards documents is the "near" pointer qualifier described? It is a proprietary extension to C to help generate more efficient code. It is non-standard. Again, this is not a bad thing here - I am just saying that the C standard allows for certain types of pointer manipulation (some of which are actually useful) that conflict with attempts of separating memory spaces, and that any way of getting round this is necessarily a compromise.

I think that is the best way to handle the problem, in general. But how do you deal with a function such as:

void sendString(const char* p);

char buffer[16]; void test(void) { sendString(buffer); sendString("Testing); }

But for cases where any jitter on a timer interrupt is uncceptable, 'better' is not good enough. No jitter on a PIC.

MPLAB-ICE2000 covers almost all the range, right back to the 16C54, the only exceptions being some of the biggest parts and the dspic range. Adding a new processor is reasonably inexpensive (especially with the developer discounts on devtools).

[snip]

The point is not the type of object to which a pointer is pointing, it's where the pointer physically points.

You're going to recompile all the libraries with every job?!? [Maybe this is a good idea. Bye, bye linker.]

You find some calls to strcpy() that reference ROM for the second argument and some that reference RAM. You're going to have function overloading in C and produce two versions of strcpy()?

....

I would like to know WHICH compiler you use for H8 series that is ISO C fully compliant and does not rely on an extension to define interupt routines. This has been by #pragma and more recently by function attribute for GCC, I ought to know about that.

I know of no standard definition for ISO C or whatever standard that has been used across compilers to define hardware/software interupt functions and vector tables.

It is almost impossible to make an embedded application *fully* portable the bits that directly relate to the hardware, memory map constraints, interupts and processor are target dependent. Some parts may only be portable to systems with the same OS.

Algorithms and quite a few functions may well be portable.

GCC for H8 is not standards compliant for interupts at least, as I am not aware of any standard for defining them in C.

.....

Where in C99 does it specify how to define functions as interupt routines, and if you can find it name a compiler that uses it.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

How is having "const" data in flash not standards-compliant, if I can access it, and RAM data, through a pointer-to-const?

That code will work fine with the PIC C compiler I use, which stores string literals in flash.

--
John W. Temples, III

Extensions do not make a compiler non-ISO-compliant, as long as those extensions do not alter the behavior of a conforming program.

--
John W. Temples, III

Can you clarify that ? Which Megas fix the immediate opcode issue ? My AVR data shows a 4 bit opcode field,dddd, for the register in all immediate opcodes, which is why this has a 16, and not 32 register reach.

-jg

I do not understand this. All micros I am familiar with sample the interrupt at some point in an instruction cycle. If an interrupt is present the current instruction completes and then it vectors to the ISR. No matter what the processor, the jitter in the interrupt latency must therefore be at least one instruction cycle time. That's not no jitter.

Ian

All the more reason not to use library functions and a damn good one for not using C at all.

Ian

I do hate it when people remove TOO much context as the previous poster said that NO extensions were needed at all. A conforming program that uses NO extensions will NOT work on all the targets *I* have seen. By this I mean ALL types of programmes, not just tasks added to an OS on an embedded system.

=== Previous context ======

I would like to know WHICH compiler you use for H8 series that is ISO C fully compliant and does not rely on an extension to define interupt routines. This has been by #pragma and more recently by function attribute for GCC, I ought to know about that. === End previous context =====

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

There are two types of jitter, one is sampling external pins, and that must quantize to at least the pin sample cycle time. The other is response time, and consider a Timer interrupt, running from the CPU clock. There is no jitter in the FLAG setting, but the CPU may have different response times to vector. My understanding is the PIC has a fixed vector response time ?

The 80C51 also can do this, if you interrupt from IDLE - ie you can get zero jitter interrupts. Most uC simply complete the current opcode, then vector.

-jg

Err... assembly language, possibly calling a C function?

I *never* said, nor implied that any C standard specified interrupt handling. I simply lament the fact that the C/C++ language standards have not (yet) dealt with the issue of multiple address spaces.

Sure. However, there are other parts that can be made portable. The more the merrier.

Sure. There are many possible levels/layers of portability/reusability.

Yep, unless they must be optimized for a particular architecture due to resource constraints.

Yep. Again, there are means other than C/C++ for implementing interrupt services, and ISRs can use proprietary extensions in a separate module isolating their impact on the rest of the code.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

OK. Please explain to me how one *without going outside of the C/C++ language standard* declare an "unsigned char" for the AVR that lives in the AVR ROM space and another that lives in the AVR RAM space?

Yep.

Certainly at the low end of the spectrum.

???

Ouch. That sounds ... personal. As much as I might like to think so, however, I'm probably not *that* unique ;-)

Granted, given the original subject of this thread, that this is often the case in embedded systems with varying degrees. *Especially* when combined with the cost pressures of high volume applications (e.g. consumer products).

However, embedded systems programming is much broader than that. The system that I will soon begin work on has 128M of RAM, and it ain't a PC :-)

GCC has extensions ... yes, but they have been emphasizing standards conformance in recent years.

Of course, there is a time and place for each facet of efficiency, as it's needed. Identify and isolate those instances. Right?

From the ISO website: ISO/IEC TR 18037:2004 deals with the following topics: extensions to support fixed-point arithmetic, named address spaces, and basic I/O hardware addressing.

Nice, though I haven't read this. The "named address spaces" seems like what I am asking for.

And?

Yep.

Without reading it, it seems like TR 18037 is fighting that trend. I worry that the C/C++ languages are moving from their systems programming roots as well.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

I agree that the embedded community is less concerned with portability than other programming environments. But I would argue that this is a result of that writing portable code for an embedded environment is

*hard* -- not because the concept of portability has no merit for embedded projects.

Over the past two years, three out of the four projects I worked on the code either had to be rewritten due to changes in the micro or that we had to have inhouse projects to port third-part software packages because our legacy code base was bound to unsupported microcontrollers. IMHO portable source code is requirement - not a luxury - for embedded projects because of the potential volatility of the hardware - i.e. new features requiring the latest micro, feature growth requiring more memory/address space, and cost reduction selecting a cheaper micro.

Why does a constrained system environment mitigate good software engineering practices? Yes a constrained system makes it harder or impossible to the follow the "letter of the law" with respect to software engineering - but the "spirit" of software engineering practices can still be followed. The projects I mentioned above where all projects involving 8bit micros with 16K to 32K of ROM. For the projects that we rewrote, the code is now 98% portable across microprocessors as well as compilers. Moving to a new micro only requires new implementations of the board support packages and a small collection of HAL interfaces - no application has to be modified. And yes, we have verified the portability by having the code compile under multiple compilers as well as run on different processors.

I won't say it has no merit, but I will say that in my experience, the few percent of code in embedded projects that is non-portable is so because it's target specific. There's simply no point in trying to write portable code to deal with features that are particular to a single target.

Who _cares_ if the code I wront to deal with the interrupt controller on a Samsung S3C4530B won't compile correctly under VAX/VMS using DEC's compiler?

--
Grant Edwards                   grante             Yow!  Did an Italian CRANE
                                  at               OPERATOR just experience
                               visi.com            uninhibited sensations in
                                                   a MALIBU HOT TUB?

I don't follow your logic here Ian. If you can have strings in ROM and RAM and allow copy from either ROM or RAM how are you going to do it without either a qualified pointer that distinguishes between the two possible sources or a separate routine for each case (or the moral equivalent thereof)regardless of the language?

Robert