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

You've snipped the next bit of my paragraph - "The difference between upper and lower registers is very annoying, but hardly difficult to remember - only upper registers can use immediate addressing modes." I was not referring to the immediate opcode issue here, nor the limited pointer modes (which I think is a far bigger problem than the immediate addressing modes, and which should have been a priority when the cpu was first designed).

Actually, now that I look at the datasheets again instead of relying on memory, I see that about the only one that was fixed was (E)LPM, which used to rely on a particular register R0. I had thought that the multiply instructions (which use specific registers R0:R1) was also made more general, but I was wrong there.

I was not referring to external interrupts, although the jitter on these is also substantially worse on an AVR. On a PIC, the interrupt latency is consistent, as all instructions take either 1 or 2 internal cycles, and the pipline is arranged in such a way as to equalise latency regardless of what instructions are being executed at the time. If you set up a regular timer interrupt to generate an output waveform, it will be rock-solid. Do the same on an AVR and you will see jitter due to the varying instruction times.

All PIC16 and PIC18 devices are Harvard architecture. Hi-Tech's compilers inspect pointers-to-const at runtime to access the appropriate memory area.

Correct: where jitter free interrupt vector is nice, is when you want to add some SW into the HW-Time domain. It may be to generate a clean BEEP, or to launch another peripheral, or sample a pin, or update a DAC.... Not all 80C51's have HW that can toggle pins, especially at the simpler end of the spectrum, or the HW pin may be already committed for other uses. That is improving, as over time you get more for your $$.

-jg

I agree and therefore standard library functions will not suffice. Hence my first assertion. As the specifics are micro specific I contend they are best written in assembler; hence my second assertion.

Ian

Ah, talking at cross purposes as usual ;-)

Ian

Agreed.

I don't know the PIC enough to comment but I'm happy to take your word for it.

Except you can do no other processing other than the timer interrupt - seems a tad pointless or at least limiting in functionality?

As does the 8051 except when in IDLE.

So it appears the only time this matters is when using an internal timer and you want a jitter free response on some software controlled output via the Timer ISR. Unless the code to do this is trivial considerable care will be necessary to ensure its execution time is constant. Perhaps the obvious application is toggling a I/O line which is IMHO trivial and anyway achievable without jitter on the 8051 via hardware.

Ian

not good enough.

This applies only to very trivial applications with only a single interrupt (the timer interrupt) in the system.

In systems with multiple interrupts, some concept of hardware arbitrated interrupt priority and automatic nested interrupts would be required in order to get a low latency for the highest priority interrupt.

In systems with even a few interrupts, it is often necessary to disable the interrupts for a few instructions, e.g. when the main program needs to update a 16 bit value used also by an interrupt service routine on an 8 bit processor. This could delay the interrupt service routine with a few instructions.

IMHO, the question of fixed vs. variable instruction execution times is relevant only with very trivial applications with only a single interrupt source and no non-atomic variable updates in the interrupt service routine.

Paul

Ok, that's another way to handle the issue - but it costs in terms of run-time performance and code size. Perhaps the overhead is not (relatively) that big on PICs - I don't remember *any* type of indirect access being particularly efficient, although it was years ago that I last used them. Certainly the idea of extended pointers like this works and gives you a lot of flexibility while sticking tightly to standards, but on chips like the AVR, the cost is generally considered too high.

is not good enough.

Just because an application has only one interrupt source, that doesn't necessarily make it trivial. (And the Pic18 range has prioritised interrupts so you can do a jitter-free timer interrupt while other interrupts are happenning)

OK, I follow you now. Thanks

Robert

Just to muddy the water a bit more, I'm currently doing some work for a processor having two disjoint RAM spaces. I'm certainly glad I don't have to work out the details of making the C compiler for it generate the correct code.

Hi David,

This thread started out talking about how crap the PIC architecture is and I have been trying to point out that it is not as crap as many people would have "you" belive. Along the way the thread strayed into HLL (and 'C') space and now we seem to be fully entrenched in what is valid standards complient 'C'.

Regardless of whether or not it is possible to trace the use of a RAM and CODE space pointer in a standards complient 'C', the fact still remains that with minor extensions IT IS POSSIBLE to do so.

I am really concerned that people with a limitted understanding of what it is possible to do with a HLL base their critisisms of the PIC on what is effectively a very old language developed for a mini computer with less processing power than a modern PDA.

It is possible and practical for a modern HLL to do things that 'C' cannot. We should be looking forward to what we can do with software not holding ourselves back because the current software is limitted.

One of the reasons I chose to write a compiler other than a 'C' compiler was to be able to freely take advantage of what can be done instead of being tied to what others have been lead to expect.

XCSB deals with this by allowing overloaded functions. I would effectively have:

void sendString(const char* p); void sendString(char* p);

In the future I will probably have a mechanism for automatically generating different versions of a function to deal with both cases. Such a mechanism is already in place to handle task safe functions (multitasking is handled natively and not as a bolton library within XCSB).

Regards Sergio Masci

I do not post just for your benefit.

Many people actually prefer to be able read through a single post without having to jump around between posts to understand what is being refered to.

When I do post something just for you I shall be sure to remove as much useless clutter from it as possible.

Regards Sergio Masci

bloody enormous SNIP

Let's hope it is not as crap as your netiquette. Please trim quotes. Your last post was 258 lines long.

Ian

Sergio

Why don't you put all previous posts on your web site, so that the

One doesn't have to delete a post after reading it.

The rest of us prefer to have all unnecessary stuff removed from a followup.

Tom

Most of us agree with Ian. Trim posts is good.

I'm sure sufficient context can be maintined without quoting the entire thread.

Please do the same for me. :)

Well, I certainly don't feel like I gain any benefit from your posts, but that is no excuse for bad manners.

Ian

"Andreas Schwarz" skrev i meddelandet news:43515ad8$0$6777$ snipped-for-privacy@newsread4.arcor-online.net...

Currently implementing "optimized" printf for a 4kB ATmega48 controller. Sure make a difference in price compared to the 8kB ATmega88...