Mike Harrison wrote:> 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
Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Started by ●October 11, 2005
Reply by ●October 15, 20052005-10-15
Reply by ●October 15, 20052005-10-15
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. Only ametures debug with printf on 78 bit micros. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●October 15, 20052005-10-15
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. 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 \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●October 15, 20052005-10-15
In article <uP74f.19146$Yl.14948@bignews4.bellsouth.net>, Michael N. Moran <mike@mnmoran.org> writes>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 \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●October 15, 20052005-10-15
Chris Hills schrieb:> 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.
Reply by ●October 15, 20052005-10-15
Chris Hills schrieb:> 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.> Only ametures debug with printf on 78 bit micros.And what do professionals use?
Reply by ●October 15, 20052005-10-15
Ian Bell schrieb:> 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.
Reply by ●October 15, 20052005-10-15
Ian Bell schrieb:> 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.
Reply by ●October 15, 20052005-10-15
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. Ian
Reply by ●October 15, 20052005-10-15
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. Ian
