| Author |
Message |
Guest
|
 Posted:
Tue Oct 18, 2005 7:23 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Chris Hills wrote:
| Quote: | Unless of course you're not interested in portability.
Very few are. There are good reasons for this.
Certainly there are exceptions to every rule,
And you appear to be it.
|
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.
| Quote: | and resource
constrained systems are frequently full of exceptions, but
aside from that, surely portability is a consideration.
As this is comp.arch.embedded most here will be constrained systems.
|
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. |
|
| Back to top |
|
 |
Grant Edwards
Guest
|
| Posted:
Tue Oct 18, 2005 8:01 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On 2005-10-18, john.t.taylor@gmail.com <john.t.taylor@gmail.com> wrote:
| Quote: | 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.
|
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? |
|
| Back to top |
|
|
David Brown
Guest
|
| Posted:
Tue Oct 18, 2005 8:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Jim Granville wrote:
| Quote: | David Brown wrote:
snip
A few things I don't like about AVRs (mostly from an assembly point
of view)...
Highly nonorthogonal - you have to remember which instructions can
only be used with the upper
registers, and then there are a few that only work on a handful of
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.
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
|
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. |
|
| Back to top |
|
|
David Brown
Guest
|
| Posted:
Tue Oct 18, 2005 8:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
John Temples wrote:
| Quote: | On 2005-10-17, David Brown <david@westcontrol.removethisbit.com> wrote:
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.
How is having "const" data in flash not standards-compliant, if I can
access it, and RAM data, through a pointer-to-const?
|
It is not non-standard if you can access them both through a
pointer-to-const. On von Neumann architectures, with a single address
space (such as msp430, ARM, 68k, x86, PPC) there is no problem. There
is only an issue when the compiler must generate different opcodes to
read data from flash from reading data from ram, such as on the PIC (at
least the older ones I've used - maybe newer PICs have a single memory
space?), the AVR, or many other small 8-bit micros. Then you can't
access ram and flash through a pointer-to-const (unless you are using
some sort of tagged pointer, which would be inefficient in both run-time
and code size).
| Quote: |
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);
}
That code will work fine with the PIC C compiler I use, which stores
string literals in flash.
|
The last PIC I used was a PIC16. Do newer PICs have a single address
space? If that's the case, then I can see where I'm causing confusion -
I have been talking about Harvard architecture devices like the PIC16. |
|
| Back to top |
|
|
R Adsett
Guest
|
| Posted:
Tue Oct 18, 2005 8:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
In article <dj159u$4jl$2@slavica.ukpost.com>, ruffrecords@yahoo.com
says...
| Quote: | Everett M. Greene wrote:
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()?
All the more reason not to use library functions and a damn good one for not
using C at all.
|
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 |
|
| Back to top |
|
|
Mike Harrison
Guest
|
| Posted:
Tue Oct 18, 2005 1:59 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On Mon, 17 Oct 2005 22:34:34 +0000, Ian Bell <ruffrecords@yahoo.com> wrote:
| Quote: | Mike Harrison wrote:
But for cases where any jitter on a timer interrupt is uncceptable,
'better' is not good enough. No jitter on a PIC.
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
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. |
|
| Back to top |
|
|
Ian Bell
Guest
|
| Posted:
Wed Oct 19, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
R Adsett wrote:
| Quote: | In article <dj159u$4jl$2@slavica.ukpost.com>, ruffrecords@yahoo.com
says...
Everett M. Greene wrote:
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()?
All the more reason not to use library functions and a damn good one for
not using C at all.
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?
|
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 |
|
| Back to top |
|
|
Ian Bell
Guest
|
| Posted:
Wed Oct 19, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Mike Harrison wrote:
| Quote: | On Mon, 17 Oct 2005 22:34:34 +0000, Ian Bell <ruffrecords@yahoo.com
wrote:
Mike Harrison wrote:
But for cases where any jitter on a timer interrupt is uncceptable,
'better' is not good enough. No jitter on a PIC.
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
I was not referring to external interrupts, although the jitter on these
is also substantially worse on an AVR.
|
Ah, talking at cross purposes as usual ;-)
Ian |
|
| Back to top |
|
|
Ian Bell
Guest
|
| Posted:
Wed Oct 19, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Jim Granville wrote:
| Quote: | Ian Bell wrote:
Mike Harrison wrote:
But for cases where any jitter on a timer interrupt is uncceptable,
'better' is not good enough. No jitter on a PIC.
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.
There are two types of jitter, one is sampling external pins, and that
must quantize to at least the pin sample cycle time.
|
Agreed.
| Quote: | 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 ?
|
I don't know the PIC enough to comment but I'm happy to take your word for
it.
| Quote: |
The 80C51 also can do this, if you interrupt from IDLE - ie you can
get zero jitter interrupts.
|
Except you can do no other processing other than the timer interrupt - seems
a tad pointless or at least limiting in functionality?
| Quote: | Most uC simply complete the current opcode, then vector.
|
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 |
|
| Back to top |
|
|
Jim Granville
Guest
|
| Posted:
Wed Oct 19, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Ian Bell wrote:
| Quote: | Jim Granville wrote:
snip
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.
|
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 |
|
| Back to top |
|
|
John Temples
Guest
|
| Posted:
Wed Oct 19, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On 2005-10-18, David Brown <david@westcontrol.removethisbit.com> wrote:
| Quote: | John Temples wrote:
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);
}
That code will work fine with the PIC C compiler I use, which stores
string literals in flash.
The last PIC I used was a PIC16. Do newer PICs have a single address
space? If that's the case, then I can see where I'm causing confusion -
I have been talking about Harvard architecture devices like the PIC16.
|
All PIC16 and PIC18 devices are Harvard architecture. Hi-Tech's
compilers inspect pointers-to-const at runtime to access the
appropriate memory area.
--
John W. Temples, III |
|
| Back to top |
|
|
David Brown
Guest
|
| Posted:
Wed Oct 19, 2005 8:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
John Temples wrote:
| Quote: | On 2005-10-18, David Brown <david@westcontrol.removethisbit.com> wrote:
John Temples wrote:
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);
}
That code will work fine with the PIC C compiler I use, which stores
string literals in flash.
The last PIC I used was a PIC16. Do newer PICs have a single address
space? If that's the case, then I can see where I'm causing confusion -
I have been talking about Harvard architecture devices like the PIC16.
All PIC16 and PIC18 devices are Harvard architecture. Hi-Tech's
compilers inspect pointers-to-const at runtime to access the
appropriate memory area.
|
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. |
|
| Back to top |
|
|
Paul Keinanen
Guest
|
| Posted:
Wed Oct 19, 2005 8:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On Mon, 17 Oct 2005 18:25:10 GMT, Mike Harrison <mike@whitewing.co.uk>
wrote:
| Quote: | Inconsistent interrupt latency. Set up a timer interrupt and watch
that jitter...
Compared to other micros I've used, it's not bad.
But for cases where any jitter on a timer interrupt is uncceptable, 'better' is not good enough.
No jitter on a PIC.
|
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 |
|
| Back to top |
|
|
Mike Harrison
Guest
|
| Posted:
Wed Oct 19, 2005 1:25 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
On Wed, 19 Oct 2005 09:55:16 +0300, Paul Keinanen <keinanen@sci.fi> wrote:
| Quote: | On Mon, 17 Oct 2005 18:25:10 GMT, Mike Harrison <mike@whitewing.co.uk
wrote:
Inconsistent interrupt latency. Set up a timer interrupt and watch
that jitter...
Compared to other micros I've used, it's not bad.
But for cases where any jitter on a timer interrupt is uncceptable, 'better' is not good enough.
No jitter on a PIC.
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
|
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) |
|
| Back to top |
|
|
R Adsett
Guest
|
| Posted:
Wed Oct 19, 2005 4:16 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
In article <dj3ohe$sec$1@slavica.ukpost.com>, ruffrecords@yahoo.com
says...
| Quote: | R Adsett wrote:
In article <dj159u$4jl$2@slavica.ukpost.com>, ruffrecords@yahoo.com
says...
Everett M. Greene wrote:
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()?
All the more reason not to use library functions and a damn good one for
not using C at all.
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?
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
|
OK, I follow you now. Thanks
Robert |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in