| Author |
Message |
Andreas Schwarz
Guest
|
 Posted:
Sat Oct 15, 2005 9:42 pm Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Mike Harrison schrieb:
| Quote: | On Sat, 15 Oct 2005 09:59:35 -0400, "Michael N. Moran" <mike@mnmoran.org> wrote:
larwe wrote:
I disagree. The only thing I don't like about the AVR is the Harvard
architecture, because it makes handling of constants and variables a bit
cumbersome when you program in C
Interesting. Do you mean cumbersome in C itself or in the underlying machine
code created by the compiler?
It's almost invisible in C. Look at the documentation for avr-libc.
There are ROM versions of the string functions, but little else is
magic.
It's that *almost* part that bothers me ;-)
I wish that the C/C++ standards bodies would use the AVR
and other "pure" Harvard architecture machines as an example
and standardize a set of memory space qualifiers as a part
of the type system to address this issue.
That ... along with other systems programming support
features such as alignment (for caches, and pages).
But that's another thread ...
Surely a compiler ought to be able to figure out if data is constant or not, and allocate it
appropriately..?
|
The problem is not allocation, but access to variables:
void function (int *something) { return (*something == 1); }
function(ROM_address);
function(RAM_address);
To make this work, the compiler would have to generate code that can
tell a ROM address from a RAM address at runtime. |
|
| Back to top |
|
 |
Andreas Schwarz
Guest
|
| Posted:
Sun Oct 16, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Ian Bell schrieb:
| Quote: | Andreas Schwarz wrote:
Ian Bell schrieb:
Michael N. Moran wrote:
Ian Bell wrote:
Andreas Schwarz wrote:
The problem is that you need different instructions to read from RAM
and ROM, so you often end up with two functions that do the same thing,
one for RAM arguments (printf), and one for ROM arguments (printf_P).
Right so the *real* problem is handling large constant strings.
Well ... strings are only one part of the problem.
Any constant tables/arrays, such as:
o state tables
o lookup-tables
o <shield-up> v-tables <shield-down
are problematic to most traditional compilers/languages that
only understand a single contiguous address space.
But surely that is a *compiler* issue not a fault of the underlying
architecture?
No. To achive true transparency, the compiler would have to generate
code that can tell a ROM address from a RAM address at runtime.
Otherwise functions that take pointer arguments would not be possible.
So it *is* a compiler issue.
|
Any hardware annoyance can be hidden by a layer of software. Still I
think it's fair to think of it as a fault of the architecture. |
|
| Back to top |
|
|
Ian Bell
Guest
|
| Posted:
Sun Oct 16, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Andreas Schwarz wrote:
| Quote: | Ian Bell schrieb:
Michael N. Moran wrote:
Ian Bell wrote:
Andreas Schwarz wrote:
The problem is that you need different instructions to read from RAM
and ROM, so you often end up with two functions that do the same thing,
one for RAM arguments (printf), and one for ROM arguments (printf_P).
Right so the *real* problem is handling large constant strings.
Well ... strings are only one part of the problem.
Any constant tables/arrays, such as:
o state tables
o lookup-tables
o <shield-up> v-tables <shield-down
are problematic to most traditional compilers/languages that
only understand a single contiguous address space.
But surely that is a *compiler* issue not a fault of the underlying
architecture?
No. To achive true transparency, the compiler would have to generate
code that can tell a ROM address from a RAM address at runtime.
Otherwise functions that take pointer arguments would not be possible.
|
So it *is* a compiler issue.
Ian |
|
| Back to top |
|
|
Ian Bell
Guest
|
| Posted:
Sun Oct 16, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Andreas Schwarz wrote:
| Quote: | Ian Bell schrieb:
Andreas Schwarz wrote:
Printf was only an example, the same applies to strcmp, puts, and many
more, not to mention your own functions that operate on constant arrays.
And besides, I don't think there's anything wrong with using printf on 8
bit controllers. It makes serial debugging, LCD usage and things like
that much more comfortable, and the additional 2-3 kB scarcely matter.
LOL, that 2-3K makes a huge difference in products with 16K ROM or less
and there are very many of those.
Optimization (writing a specialized function instead of using one from
the library is nothing but optimization) is done when necessary, and no
sooner. If your program with printf & Co. is 14k large and you target a
16k microcontroller, replacing standard functions with specialized code
will gain you absolutely nothing, but takes time, is error-prone, makes
your code larger and hurts maintainability.
|
Not true. Library functions are immensely general purpose which largely
accounts for their bloat and their inappropriateness in small 8 bit
controller products. For simple printing of constant strings a user
function is far better.
Ian |
|
| Back to top |
|
|
Andreas Schwarz
Guest
|
| Posted:
Sun Oct 16, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Ian Bell schrieb:
| Quote: | Andreas Schwarz wrote:
Ian Bell schrieb:
Andreas Schwarz wrote:
Printf was only an example, the same applies to strcmp, puts, and many
more, not to mention your own functions that operate on constant arrays.
And besides, I don't think there's anything wrong with using printf on 8
bit controllers. It makes serial debugging, LCD usage and things like
that much more comfortable, and the additional 2-3 kB scarcely matter.
LOL, that 2-3K makes a huge difference in products with 16K ROM or less
and there are very many of those.
Optimization (writing a specialized function instead of using one from
the library is nothing but optimization) is done when necessary, and no
sooner. If your program with printf & Co. is 14k large and you target a
16k microcontroller, replacing standard functions with specialized code
will gain you absolutely nothing, but takes time, is error-prone, makes
your code larger and hurts maintainability.
Not true. Library functions are immensely general purpose which largely
accounts for their bloat and their inappropriateness in small 8 bit
controller products. For simple printing of constant strings a user
function is far better.
|
Printf variants do a lot more than simple printing of constant strings.
Otherwise they wouldn't take a few Ks. |
|
| Back to top |
|
|
Andreas Schwarz
Guest
|
| Posted:
Sun Oct 16, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Chris Hills schrieb:
| Quote: | In article <4350e6c3$0$21246$9b4e6d93@newsread2.arcor-online.net>,
Andreas Schwarz <usenet@andreas-s.net> writes
Ian Bell schrieb:
Andreas Schwarz wrote:
I disagree. The only thing I don't like about the AVR is the Harvard
architecture, because it makes handling of constants and variables a bit
cumbersome when you program in C
Interesting. Do you mean cumbersome in C itself or in the underlying
machine code created by the compiler?
The problem is that you need different instructions to read from RAM and
ROM, so you often end up with two functions that do the same thing, one
for RAM arguments (printf), and one for ROM arguments (printf_P).
Right so the *real* problem is handling large constant strings.
IMHO the last thing you should be using on an 8 bit micro is library
functions like printf.
Printf was only an example, the same applies to strcmp, puts, and many
more, not to mention your own functions that operate on constant arrays.
And besides, I don't think there's anything wrong with using printf on 8
bit controllers. It makes serial debugging, LCD usage and things like
that much more comfortable, and the additional 2-3 kB scarcely matter.
printf should NOT be used for debugging at all.
some parts only have 2-4 K of program memory.
|
Some parts have only 512B of memory - so what? Of course there are
exceptions.
| Quote: | Only ametures debug with printf on 78 bit micros.
|
And what do professionals use? |
|
| Back to top |
|
|
Andreas Schwarz
Guest
|
| Posted:
Sun Oct 16, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Chris Hills schrieb:
| Quote: | In article <43515ad8$0$6777$9b4e6d93@newsread4.arcor-online.net>,
Andreas Schwarz <usenet@andreas-s.net> writes
Ian Bell schrieb:
Andreas Schwarz wrote:
Printf was only an example, the same applies to strcmp, puts, and many
more, not to mention your own functions that operate on constant arrays.
And besides, I don't think there's anything wrong with using printf on 8
bit controllers. It makes serial debugging, LCD usage and things like
that much more comfortable, and the additional 2-3 kB scarcely matter.
LOL, that 2-3K makes a huge difference in products with 16K ROM or less and
there are very many of those.
Optimization (writing a specialized function instead of using one from
the library is nothing but optimization) is done when necessary, and no
sooner. If your program with printf & Co. is 14k large and you target a
16k microcontroller, replacing standard functions with specialized code
will gain you absolutely nothing, but takes time, is error-prone, makes
your code larger and hurts maintainability.
This is absolute rubbish. A simple function to put a character or two
out to a serial line will only be a few bytes long.
As printf has to use this functionality to address the hardware, and you
may want to re-direct printf, it is often made available in source form
in the library. All you have to do is get the routine. Typically it is
only 4-5 lines of C.
|
Appearantly we have a misunderstanding here. With printf I do not mean a
put-everything-on-stdout-C89-printf. Most libraries have a printf
variant that takes a function pointer argument for a putc function, or a
seperate function to set the printf target. Obviously you have to write
this one yourself.
The point I was trying to make is that it is useless to assemble a LCD
output by hand (formatting numbers, concatenating strings, padding with
spaces) when there is a function like printf that can do it all much
easiert, but may take a bit more space. |
|
| Back to top |
|
|
Chris Hills
Guest
|
| Posted:
Sun Oct 16, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
In article <43515ad8$0$6777$9b4e6d93@newsread4.arcor-online.net>,
Andreas Schwarz <usenet@andreas-s.net> writes
| Quote: | Ian Bell schrieb:
Andreas Schwarz wrote:
Printf was only an example, the same applies to strcmp, puts, and many
more, not to mention your own functions that operate on constant arrays.
And besides, I don't think there's anything wrong with using printf on 8
bit controllers. It makes serial debugging, LCD usage and things like
that much more comfortable, and the additional 2-3 kB scarcely matter.
LOL, that 2-3K makes a huge difference in products with 16K ROM or less and
there are very many of those.
Optimization (writing a specialized function instead of using one from
the library is nothing but optimization) is done when necessary, and no
sooner. If your program with printf & Co. is 14k large and you target a
16k microcontroller, replacing standard functions with specialized code
will gain you absolutely nothing, but takes time, is error-prone, makes
your code larger and hurts maintainability.
|
This is absolute rubbish. A simple function to put a character or two
out to a serial line will only be a few bytes long.
As printf has to use this functionality to address the hardware, and you
may want to re-direct printf, it is often made available in source form
in the library. All you have to do is get the routine. Typically it is
only 4-5 lines of C.
Or you could do it yourself but if writing a SIMPLE function like this
"takes time, is error prone" should you be programming embedded systems
at all?
It will make you code 2-3K smaller and does NOT hurt maintainability at
all. IT gains you a lot as it makes the test outputting smaller and
faster so it distorts the memory map less than printf and changes the
time by a lot less.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |
|
| Back to top |
|
|
Chris Hills
Guest
|
| Posted:
Sun Oct 16, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
In article <uP74f.19146$Yl.14948@bignews4.bellsouth.net>, Michael N.
Moran <mike@mnmoran.org> writes
| Quote: | Ian Bell wrote:
Andreas Schwarz wrote:
The problem is that you need different instructions to read from RAM and
ROM, so you often end up with two functions that do the same thing, one
for RAM arguments (printf), and one for ROM arguments (printf_P).
Right so the *real* problem is handling large constant strings.
Well ... strings are only one part of the problem.
Any constant tables/arrays, such as:
o state tables
o lookup-tables
o <shield-up> v-tables <shield-down
are problematic to most traditional compilers/languages that
only understand a single contiguous address space.
|
No they don't. Compilers for Harvard architecture understand Harvard
architecture very well.
What do you mean by "most traditional compilers/languages"? For
embedded use 99% of C programming uses extensions to C and most
compilers are specialised.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |
|
| Back to top |
|
|
Chris Hills
Guest
|
| Posted:
Sun Oct 16, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
In article <4350e6c3$0$21246$9b4e6d93@newsread2.arcor-online.net>,
Andreas Schwarz <usenet@andreas-s.net> writes
| Quote: | Ian Bell schrieb:
Andreas Schwarz wrote:
I disagree. The only thing I don't like about the AVR is the Harvard
architecture, because it makes handling of constants and variables a bit
cumbersome when you program in C
Interesting. Do you mean cumbersome in C itself or in the underlying
machine code created by the compiler?
The problem is that you need different instructions to read from RAM and
ROM, so you often end up with two functions that do the same thing, one
for RAM arguments (printf), and one for ROM arguments (printf_P).
Right so the *real* problem is handling large constant strings.
IMHO the last thing you should be using on an 8 bit micro is library
functions like printf.
Printf was only an example, the same applies to strcmp, puts, and many
more, not to mention your own functions that operate on constant arrays.
And besides, I don't think there's anything wrong with using printf on 8
bit controllers. It makes serial debugging, LCD usage and things like
that much more comfortable, and the additional 2-3 kB scarcely matter.
|
printf should NOT be used for debugging at all.
some parts only have 2-4 K of program memory.
Only ametures debug with printf on 78 bit micros.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |
|
| Back to top |
|
|
Ian Bell
Guest
|
| Posted:
Sun Oct 16, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Andreas Schwarz wrote:
| Quote: |
Printf was only an example, the same applies to strcmp, puts, and many
more, not to mention your own functions that operate on constant arrays.
And besides, I don't think there's anything wrong with using printf on 8
bit controllers. It makes serial debugging, LCD usage and things like
that much more comfortable, and the additional 2-3 kB scarcely matter.
|
LOL, that 2-3K makes a huge difference in products with 16K ROM or less and
there are very many of those.
Ian |
|
| Back to top |
|
|
Ian Bell
Guest
|
| Posted:
Sun Oct 16, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Michael N. Moran wrote:
| Quote: | Ian Bell wrote:
Andreas Schwarz wrote:
The problem is that you need different instructions to read from RAM and
ROM, so you often end up with two functions that do the same thing, one
for RAM arguments (printf), and one for ROM arguments (printf_P).
Right so the *real* problem is handling large constant strings.
Well ... strings are only one part of the problem.
Any constant tables/arrays, such as:
o state tables
o lookup-tables
o <shield-up> v-tables <shield-down
are problematic to most traditional compilers/languages that
only understand a single contiguous address space.
|
But surely that is a *compiler* issue not a fault of the underlying
architecture?
Ian |
|
| Back to top |
|
|
Andreas Schwarz
Guest
|
| Posted:
Sun Oct 16, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Ian Bell schrieb:
| Quote: | Andreas Schwarz wrote:
Printf was only an example, the same applies to strcmp, puts, and many
more, not to mention your own functions that operate on constant arrays.
And besides, I don't think there's anything wrong with using printf on 8
bit controllers. It makes serial debugging, LCD usage and things like
that much more comfortable, and the additional 2-3 kB scarcely matter.
LOL, that 2-3K makes a huge difference in products with 16K ROM or less and
there are very many of those.
|
Optimization (writing a specialized function instead of using one from
the library is nothing but optimization) is done when necessary, and no
sooner. If your program with printf & Co. is 14k large and you target a
16k microcontroller, replacing standard functions with specialized code
will gain you absolutely nothing, but takes time, is error-prone, makes
your code larger and hurts maintainability. |
|
| Back to top |
|
|
Andreas Schwarz
Guest
|
| Posted:
Sun Oct 16, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Ian Bell schrieb:
| Quote: | Michael N. Moran wrote:
Ian Bell wrote:
Andreas Schwarz wrote:
The problem is that you need different instructions to read from RAM and
ROM, so you often end up with two functions that do the same thing, one
for RAM arguments (printf), and one for ROM arguments (printf_P).
Right so the *real* problem is handling large constant strings.
Well ... strings are only one part of the problem.
Any constant tables/arrays, such as:
o state tables
o lookup-tables
o <shield-up> v-tables <shield-down
are problematic to most traditional compilers/languages that
only understand a single contiguous address space.
But surely that is a *compiler* issue not a fault of the underlying
architecture?
|
No. To achive true transparency, the compiler would have to generate
code that can tell a ROM address from a RAM address at runtime.
Otherwise functions that take pointer arguments would not be possible. |
|
| Back to top |
|
|
Jim Granville
Guest
|
| Posted:
Sun Oct 16, 2005 12:15 am Post subject:
Re: Microchip Introduces First 16-bit Microcontroller Produc |
|
|
Mike Harrison wrote:
| Quote: | On Fri, 14 Oct 2005 22:37:20 +0200, Andreas Schwarz <usenet@andreas-s.net> wrote:
Mike Harrison schrieb:
AVR and PIC have probably about the same number of architectural annoyances
I disagree. The only thing I don't like about the AVR is the Harvard
architecture, because it makes handling of constants and variables a bit
cumbersome when you program in C - but compared to the evils of the PIC
architecture (banking!) this is nothing.
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 registers. In recent parts, there
are THREE diffferent types of IO register access (high register, any register, SRAM), depending on
the register.
Inconsistent branching methods - a mix of limited-range conditional branches and skip instructions.
Maybe if they'd made STATUS a register so you could skip on carry etc. it would be better.
No immediate XOR instruction.
Inconsistent interrupt latency. Set up a timer interrupt and watch that jitter...
No quick way to toggle an IO bit (except on some very recent parts)
Power consumption sucks bigtime at 5V
Watchdog timer wake from SLEEP does a reset instead of continuing
Poor IO drive current.
Most parts can't wake up from sleep on a short pulse.
History of poor availability and obsoleting parts. Microchip are in another league on this - you can
still buy the first mainstream PIC parts (in their original die rev) if you really want to.
Devtools not great (how long did it take Atmel's assembler to get conditional assembly..?)
No standard in-circuit emulator platform across the range.
The AVR has some great features, and I use both PICs and AVRs (sometimes within the same product!)
depending on requirements, but it is a long way from being as perfect as some advocates would have
you believe..!
|
...and you could add
* No Direct memory opcodes (thus register bottleneck and pointer thrashing)
* Limited SFR map
* No Boolean variables/opcodes [well, SOME new devices have a kludge on
this.. ]
* No interrupt priority
* No register banking, so interrupt switch is clumsy/slow.
* Poor family portability
But yes, it is better than the '70s 12 bitOpcode PIC cores.
(and so it should be).
Less of a difference to the newer 16 bitOpCode PICs, and behind the
PIC24's.
A key indicator of a good uC, is when you would use it for a NEW
design, and the new 32 bit ones, are certainly putting pressure on the
larger 8 bit devices.
-jg |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in