AVR is times faster than PIC???

Go To Last Post
58 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello all

I'm learning AVR these days and found this great forum.

I've been a PIC developer for many years. My company has some new projects (WEIGH SCALE), the boss are intended to use AVR.

I searched the web trying to compare which uC is better and found this interesting comparing test from another electronics forum (edaboard.com)
http://www.stc-51.com/comparing.php

The page compares the speed of some popular uP running at the same crystal frequency. To my surprise, for a certain program written in C, AVR need 188uS but PIC need 1059uS. That means AVR is 5.6 tims faster than PIC!

Can your guys explain why there's such a big different between these 2 uC? Both are RISC structure, 1 clock per instruction. Or is there something wrong with that test?

Regards
Ray

Hello I'm newbie of avr

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

At least the PICs I've seen use four clock ticks to perform one command, so given that fact, with 4 MHz crystal, AVR executes 4 million instrunctions per second while PIC executes only 1 million.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you ever see any of these 'comparisons' look carefully at the way they are conducted!

An AVR does one instruction per clock cycle.
A PIC does one instruction per 4 clock cycles
A 8051 does one instruction per 12 clock cycles.

So any meaningful test should be at the maximum clock frequency.

The PIC16F77 is fairly ancient. Is not very good with C compilers. You should compare with a PIC18Fxxx family.

Likewise there are SiLabs 8051 variants that can run at 100MHz and one instruction per cycle. i.e 50x faster than an 89C55 clocked at 24MHz!

There are pros and cons for every chip family. You have to choose what is best for you.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

damn...I took a look at PIC manual and found that it's 4 clock. I had thought it's 1 clock for several years. Fooled by 'RISC'...How stupid I am!

Ray

Hello I'm newbie of avr

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks David.

Most of our products use PIC, they works perfect. Some new applications need more powerful uC so we may have to move to avr or PIC18, depend on which is more cost effective. 8051 is not in concerning although the price of STC MCU is dirty cheap.

Hello I'm newbie of avr

Last Edited: Fri. Feb 11, 2011 - 08:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PIC has only 35 instruction But AVR has more than hundred. The main advantage with AVR is that the architecture is designed with C in mind, so the code space and also the performance is better in AVR if the code is developed in C.

-Krishna Balan S

-------------------------------------------------------------------------

"Heroes are ordinary people with extraordinary commitment"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The AVR saves quite a bit compared to the old PIC since it's
not centered around an accumulator register, so you need less
data moving around.

These days, "PIC" appears to be a pretty generic tag Microchip
applies to every controller-like device they are building, so
there's no such thing anymore like "the PIC" to compare against.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

according to the testing, the avr has the longest code after compiled (198 bytes), pic is 132 words, 8051 has only 109 bytes. does that mean the c compiler of avr is less effeciency than PIC?

I think 8051 has less code length because it's CISC, right? So, some 8051 (silicon labs, STC) with 1 instruction cycle must be very fast.

Hello I'm newbie of avr

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seems to compile with CVAVR to 326 bytes - so make of that what you will.

...and any decent AVR programmer will notice that the character array handling serves no useful (external) purpose so will optimise it out so that the code just toggles PORTB :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

(198 bytes), pic is 132 words

One of these is not like the other. Assuming the PIC uses 16-bit instructions like the AVR, then the AVR code is shorter.

Also, one of the major advantages of AVRs over PICs is that we don't have Leon using AVRs - a situation that Microchip won't easily be able to correct for several years at least.

Every benchmark and comparison between two non-identical products is flawed, so you need to pick the aspects that are important to you, for your specific application. For example, one chip may be faster but consume more power, or have smaller code size but cost more per unit than a larger competitor.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

PIC has only 35 instruction But AVR has more than hundred.

Not true - have a look at the instruction set - a lot of them are synonyms for the same opcode bit pattern. (Take for example all the SREG flag set/clear instructions!)

But what does number of instructions matter? The ARM has very few and yet it's possibly the best CPU core ever designed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In a few years, we'll all put an end to the RISC/CISC nonsense with these sort of processors:

http://en.wikipedia.org/wiki/One...

Plus a bajillion aliases. Actually, I wonder it that's not such a bad idea, since it would reduce core complexity, allowing you to run it faster to compensate and possibly get a higher speed.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Not true - have a look at the instruction set - a lot of them are synonyms for the same opcode bit pattern

Yeah Opcode may be similar. But almost all datasheets of Atmel megaAVR has mentioned that it has 133 powerful instructions. I just pointed this.

-Krishna Balan S

-------------------------------------------------------------------------

"Heroes are ordinary people with extraordinary commitment"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Plus a bajillion aliases. Actually, I wonder it that's not such a bad idea, since it would reduce core complexity, allowing you to run it faster to compensate and possibly get a higher speed.

That very thing was the death of RISC - it hit the technology wall. To get more performance, one had to do more ops per clock rather than be able to clock faster. The latest pentiums are hardly a simple processor - not something that a person could scribble up on a back of a fag packet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The main advantage with AVR is that the architecture is designed with C in mind, so the code space and also the performance is better in AVR if the code is developed in C.

Sounds like marketing speak. Just like Microchip declaring the PIC as RISC. The number of instructions were never reduced, it was born dumb. Besides, the term RISC refers to a specific set of attributes and which accumulator based is not one of them.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:

Also, one of the major advantages of AVRs over PICs is that we don't have Leon using AVRs - a situation that Microchip won't easily be able to correct for several years at least.

- Dean :twisted:

Unlike many of the fanboys here, like Dean, I'm not fixated on one manufacturer and one architecture, I use whatever gets the job done as cheaply and easily as possible, or whatever the client wants me to use. That might mean using an AVR or a PIC, or something else like an ARM or XMOS chip.

For most applications, it doesn't matter if a PIC is slower than an AVR for the same clock speed. If it gets the job done, and is cheaper, so what? Microchip is the market leader in 8-bit MCUs, Atmel is fifth.

There have been serious supply shortages recently affecting AVR users, mainly caused by Atmel disposing of their fabs. Microchip has their own fabs, and had very few supply problems.

There are 16-bit PICs that have about 4x the performance of an AVR, and a much nicer architecture and instruction set, at about the same price. XLP PICs have far lower power consumption than AVRs, making them much more attractive for battery-powered applications.

Leon Heller G1HSM

Last Edited: Fri. Feb 11, 2011 - 09:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Leon, its unusual for you to bite! There has been admissions of PIC usage by other notables of this forum, so maybe you've created a bit of groundswell.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
For most applications, it doesn't matter if a PIC is slower than an AVR for the same clock speed. If it gets the job done, and is cheaper, so what? Microchip is the market leader in 8-bit MCUs, Atmel is fifth.

There have been serious supply shortages recently affecting AVR users, mainly caused by Atmel disposing of their fabs. Microchip has their own fabs, and had very few supply problems.

There are 16-bit PICs that have about 4x the performance of an AVR, and a much nicer architecture and instruction set, at about the same price. XLP PICs have far lower power consumption than AVRs, making them much more attractive for battery-powered applications.

PIC have variety of MCUs.
The only problem that AVR didn't expand TCP/IP,ethernet,USB host stack and hardware.

Jeckson

www.tokopedia.com/madagang for cheap electronics and manuscript

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman,

I thought I'd have a bit of fun at Dean's expense. When he graduates and gets out into the real world he will find that things are very different!

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Leon, yes, if things had swung another way, he could be working for Microchip now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Quote:

The main advantage with AVR is that the architecture is designed with C in mind, so the code space and also the performance is better in AVR if the code is developed in C.

Sounds like marketing speak. Just like Microchip declaring the PIC as RISC.

Take a look at it
http://www.atmel.com/dyn/resourc...

-Krishna Balan S

-------------------------------------------------------------------------

"Heroes are ordinary people with extraordinary commitment"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Leon, yes, if things had swung another way, he could be working for Microchip now.

Perhaps he is, in an alternative universe. :)

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Exactly - marketing speak. I have little doubt that the AVR might be better for C than say, a PIC12/13/14/16/18 or maybe an 8051. One would think if the AVR was designed to execute C efficiently, that it would execute C idioms directly. This is not the case. Even GCC needs workarounds to support the AVR weirdness as compared to say, the ARM.

Put it this way, the AVR is not universally lauded as the best micro to execute compiled C code on is it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't think that there are any 8-bit architectures that are ideal for C. That is one reason why Microchip moved up to 16-bits, they were able to design a new architecture and instruction set from scratch that were ideally suited to the language. It's also very nice to program in assembler, coincidentally, much nicer than the AVR.

Perhaps Dean will now chip in again, perhaps with some assistance from his colleagues at Atmel.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I don't think that there are any 8-bit architectures that are ideal for C. That is one reason why Microchip moved up to 16-bits, they were able to design a new architecture and instruction set from scratch that were ideally suited to the language. It's also very nice to program in assembler, coincidentally, much nicer than the AVR.

Perhaps Dean will now chip in again, perhaps with some assistance from his colleagues at Atmel.

Use an XMEGA.

Hey, this is fun! Now I see why Leon likes trolling - the effort required by me compared to the rebuttals is almost nil.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

[ironic travesty]
Yes, AVRs are the fastest. PICs comes in as #5.
[/ironic travesty]

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:

Use an XMEGA.

Have you ever used one? The 16-bit PICs are much easier to use, have fewer bugs, and deliver a lot more performance.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
There are 16-bit PICs that have about 4x the performance of an AVR, and a much nicer architecture and instruction set

Frankly, I don't give a rat's arse what you use, but "much nicer"?
That's not exactly scientific, is it?

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have a look at the two architectures, and see which you prefer. MCU architectures and instruction sets can have aesthetic qualities, just like programming languages and programs.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

just like programming languages and programs

Ah, so THATs why we've all agreed on one language, one coding style, and one compiler... :roll:

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> Even GCC needs workarounds to support the AVR weirdness as
> compared to say, the ARM.

But that's mostly GCC's fault: it has never been targetted to Harvard
architectures. In fact, it has originally *only* been targetted to
32-bit von Neumann architectures. So it's already great enough that its
architecture has proven to be scalable down to smaller CPUs at all, but
with Harvard, its current architecture is definitely hitting a wall.

Besides, while the creators of the AVR sought advise from C compiler
builders (as is documented), they only asked IAR, so the result was
unavoidably biased towards IAR (e.g. towards a two-stack architecture).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I once did some consultancy for Burroughs Corp. and worked with a systems programmer who structured his programs like a piece of music, giving them a prelude, etc.

Those Burroughs mainframes were superb machines. The microcode was changed to suit the language they were using.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well...
It takes me a few days learning AVR, comparing it with PIC. But none of them seems to be the winner. I showed my boss the comparing page. Neither PIC nor avr impressed him. The sh*t low price of STC 8051 killed him. In business thinking I understand him. STC is will works fine for the project at much lower price. But I don't like 8051 as a tech guy, especially it's a unknow manufacturer. May be another Chinese garbage.:-(

Ray

Hello I'm newbie of avr

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is nothing wrong with the 8051. It's very widely used because it needs very little silicon and can be made very cheaply.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In one design when microcontroller was being considered, price of AVR with 128kbyte code memory just was so much larger than any STM32 with 128kbyte code memory. You can guess the rest. Your design criteria is different, but with our criteria we got 32-bit 36MHz ARM for less than 8-bit 16-20MHz AVR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

according to the testing, the avr has the longest code after compiled (198 bytes), pic is 132 words, 8051 has only 109 bytes. does that mean the c compiler of avr is less effeciency than PIC?

I think 8051 has less code length because it's CISC, right?


Quote:

the comparing page.

A single small test program of that size isn't really significant. If you gather a number of them, perhaps.

The "TI benchmark", while flawed, has a series of these small tests, addressing different app areas. Overall, the lowly ATmega8 did quite well, thank you. (And code size wasn't a weak point.)
http://www.maxim-ic.com/app-note...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Seems to compile with CVAVR to 326 bytes - so make of that what you will.

That is the whole program, not the compared fragment. I also got a similar number with CV doing a "raw" build of the test program. With the '164 the extensive number of vectors swells the whole program size. Built for a Mega88, "Program size: 127 words (254 bytes), 3.1% of FLASH"

The marked fragment is 53 words/106 bytes, pretty much as shown on the STC page. Of course, none of us are going to force a RMW with "PORTB = ~PORTB;". "PINB = 1; " will save a word and cycle. In CV, "PINB.0 = 1;", or "PINB |= 1;" will result in the single SBI being generated; two words/four bytes saves and several cycles. See what I mean about a small test program? That simple change made a 4% difference in the results.

The clever (read: very confusing) thing to me is how the STC and AT89 manages to use 76 bytes of "DATA" total to hold two 50-byte arrays.

I'm surprised that the "AVRStudio" compiler didn't eat up that test program. As mentioned it would probably trash most of it without a strategic "volatile" or two. And the generated code is very good at using pointers in tight loops. CV isn't as good, and generates straightforward indexing code for each operation.

Changing to straightforward pointer operations versus the indexing results in 47 words/94 bytes. Another 10% savings. And CV isn't particularly good at it; I suspect that GCC would eat this up:

uchar str1[50],str2[50];

void main(void)
{
   uchar i,t;
    uchar * x1;
    uchar * x2;
   //TRISB = 0x00; //for PIC
   DDRB = 0x01; //for avr
   i=0;
   while(1)
   {
      //begin
      PINB |= 0x01;

        x1 = str1;
        x2 = str2;      
      for(i = 0; i < 50;i ++,x1++,x2++)
      {
        *x1 = i;
        *x2 = 255 - i;
      }
        x1 = str1;
        x2 = str2;      
      for(i = 0; i < 50;i ++,x1++,x2++)
      {
      t = *x1;
      
         *x1 = *x2;
         *x2 = t;
      }
      //end
   }
}

The Keil is an excellent compiler so it may well have "eaten up" the loops with some indexing. It >>must<< be excellent, to store 100 bytes of information in 76.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Fri. Feb 11, 2011 - 03:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The marked fragment is 53 words/106 bytes, pretty much as shown on the ST page.

Whoa, I was looking at the wrong column. They show the AVR at 198 bytes of code! With the "AVRStudio" compiler, they must have crippled it at -O0 or something. Even the straightforward CV is half of that. And I'll bet the GCC would eat up those loops or throw them away entirely. One of you WinAVR people build that program woth -Os and report.

Specmanship. Read again the Maxim comments of the "flaws in the TI benchmark"--looks like the same thing is going on here.

You really want to make the AVR look bad? Use GCC; build with -O0; and delay for 0.01 milliseconds...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The most popular "PIC" used in hobby and small projects is the "16" series that have a 14 bit instruction word. When stating the amount of program flash 14 bits is 1.75 bytes(!) and Microchip uses this number to state the size of the flash in bytes. (YUCK!). The "18" series PICs are probably #2 in popularity, these have 16 bit instruction words just like the AVR.

The major advantage of RISC used to be that the smaller instruction set could be implemented in a hard wired decoder and did not require a micro-engine with microcode. Early CISC machines with small instruction sets were also hard wired (such as the original PDP-11). Hard wired processors could run faster as they required fewer clock cycles per instruction to operate than did micro-engine driven ones.
Today Moore's law has put more transistors per square mm on a chip so even a complex CISC instruction set can be hard wired. The advantage of RISC has therefore evaporated. Intel once described the 80486 as having a RISC core, what they meant was it used a lot of hard wired decoding and less microcode to implement thereby getting the number of clocks per instruction down.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch is right, the testing only compares the code between //begin and //end, not the whole program. The compiler always add some initializing code at the beginning of the program.

Don't be confused theusch, the roughly designed page is STC, not ST. STC seems to be a Chinese IC manufacturer (another copier?). They declare they are the No.1 8051 seller in the world, I believe it's true. Think how many cheap electronic garbages shipped from there each year!

Hello I'm newbie of avr

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Don't be confused theusch, the roughly designed page is STC, not ST.

Sorry. I will edit my posts.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seems like engineers could invent a 'figure of merit' formula for microcontroller selection and each shop could tailor its coefficients for each project. You start with some requirements for the project. How fast the program needs to run, how much input data it needs to read, how much output data it needs to write, how many to be built, then you assign a coefficient to each attribute: price, power consumption, speed, familiarity of programmer to language and development system. Lets imagine a company wants to bid on a job to design and build 10,000 gizmos to perform task X. If its a microchip shop, they'll use a microchip processor. Same for an avr shop, arm shop. Use what you are familiar with for lower risk, no learning time, quick time to market. I used to work in a Motorola shop, and we used every moto cpu from the 6800 to the 68020. I noticed that in general, cpus with more registers were easier to program and register variables were faster than ram variables, so I think one could invent a benchmark that used lots of registers and lots of ram. I'd bet on the AVR because it has a lot of regs, but using external ram is a penalty because of the extra cycle to access external ram. How do pics access external ram? That would be an interesting comparison.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
How do pics access external ram? That would be an interesting comparison.

I don't think that they can. At least not the 12,16, and 18 (8 bit) family. On one of the PICS with a lot of ports you can always bitbang your own external memory interface (though you'd be better off with an SPI or I2C memory) and have to do everything in software. The 16 and 32 bit PIC families might support external memory, I don't know I've never used them.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I don't think that they can. At least not the 12,16, and 18 (8 bit) family.

http://ww1.microchip.com/downloa...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was certain that the '12' and '16' family PIC's did not support external memory. I forgot about the very large pin count '18' family though. Interesting in that both external PROGRAM and DATA memory are supported. I don't think any AVR (well maybe AVR32) supports external PROGRAM memory. That's nice since it allows for a true ICE for emulation via breakpoints and writable control store. It also would allow the spector of a user implemented program writable program store in ram (by overlapping program and data address space in certain areas) as was commonly done on 8051's. In other words self modifying code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Great thread.

However, I used this quote in a meeting this morning,

Kartman wrote:
... not something that a person could scribble up on a back of a fag packet.
and got into a lot of trouble...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
How do pics access external ram? That would be an interesting comparison.

Aha, not a problem at all. There're plenty if IO Pins to siumulate the timing of RAM BUS. One of my project was use PIC to access NVRAM.

Just a joke. PIC can't access external RAM because the limitations of it's structure.

Hello I'm newbie of avr

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One engineer I know moved from PICs to AVR way back, in order to get
Orthogonal Instruction Set
Linear Address Space for Flash and RAM
A true (Real) stack architecture
Leave bank-switched tiny memory pages as road kill.

These also make compiler/assembler writers' jobs easier.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

One of you WinAVR people build that program woth -Os and report.

When I build the unchanged (apart from TRISB) program on the ST page for mega16 (my initial error) I got 198 bytes. When I changed to mega164p I got:

AVR Memory Usage
----------------
Device: atmega164p

Program:     238 bytes (1.5% Full)
(.text + .data + .bootloader)

Data:        100 bytes (9.8% Full)
(.data + .bss + .noinit)

To save space I won't recount the vector table or the C pre-amble (which is well known for GCC) but main() becomes:

000000a4 
: void main(void) { uchar i,t; //TRISB = 0x00; //for PIC DDRB = 0x01; //for avr a4: 81 e0 ldi r24, 0x01 ; 1 a6: 84 b9 out 0x04, r24 ; 4 i=0; while(1) { //begin PORTB = ~PORTB; //for PIC and AVR a8: 85 b1 in r24, 0x05 ; 5 aa: 80 95 com r24 ac: 85 b9 out 0x05, r24 ; 5 ae: 20 e0 ldi r18, 0x00 ; 0 b0: 30 e0 ldi r19, 0x00 ; 0 //P1 = ~P1; //for stc12c5a16ad and at89c55wd for(i = 0; i < 50;i ++) { str1[i] = i; b2: f9 01 movw r30, r18 b4: e0 50 subi r30, 0x00 ; 0 b6: ff 4f sbci r31, 0xFF ; 255 b8: 20 83 st Z, r18 str2[i] = 255 - i; ba: f9 01 movw r30, r18 bc: ee 5c subi r30, 0xCE ; 206 be: fe 4f sbci r31, 0xFE ; 254 c0: 82 2f mov r24, r18 c2: 80 95 com r24 c4: 80 83 st Z, r24 c6: 2f 5f subi r18, 0xFF ; 255 c8: 3f 4f sbci r19, 0xFF ; 255 while(1) { //begin PORTB = ~PORTB; //for PIC and AVR //P1 = ~P1; //for stc12c5a16ad and at89c55wd for(i = 0; i < 50;i ++) ca: 22 33 cpi r18, 0x32 ; 50 cc: 31 05 cpc r19, r1 ce: 89 f7 brne .-30 ; 0xb2 d0: e0 e0 ldi r30, 0x00 ; 0 d2: f1 e0 ldi r31, 0x01 ; 1 d4: a2 e3 ldi r26, 0x32 ; 50 d6: b1 e0 ldi r27, 0x01 ; 1 str1[i] = i; str2[i] = 255 - i; } for(i = 0;i < 50;i ++) { t = str1[i]; d8: 90 81 ld r25, Z str1[i] = str2[i]; da: 8c 91 ld r24, X dc: 81 93 st Z+, r24 str2[i] = t; de: 9d 93 st X+, r25 for(i = 0; i < 50;i ++) { str1[i] = i; str2[i] = 255 - i; } for(i = 0;i < 50;i ++) e0: 81 e0 ldi r24, 0x01 ; 1 e2: e2 33 cpi r30, 0x32 ; 50 e4: f8 07 cpc r31, r24 e6: c1 f7 brne .-16 ; 0xd8 e8: df cf rjmp .-66 ; 0xa8

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But Leon

Now Atmel became prosperity MCU.

Because XX that Atmel growing.

I'll be back with PIC also.....

Jeckson

www.tokopedia.com/madagang for cheap electronics and manuscript

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jeckson wrote:

I'll be back with PIC also.....

Great! Maybe then you won't need the "SMD zif socket" and you will go a pester/annoy a different part of the world. I wish you a speedy departure.

I can dream surely ...

Ross McKenzie, Melbourne Australia

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jeckson, kamu inglis ini tidak baik. ( your english is not good). I dare say my bahasa is not much better. Your posts fail to make much sense.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Your posts fail to make much sense.

You're just approaching them the wrong way. Try to get into the right mindset first:

Last Edited: Sun. Feb 13, 2011 - 05:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use the FORTH you must

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman...My English poor.Agree.

Quote:
Great! Maybe then you won't need the "SMD zif socket" and you will go a pester/annoy a different part of the world. I wish you a speedy departure.

Ross,Seems there's hard feelings between us.
Despite in the past and even that I get foolish from you.I forget it and assume that my unluck.

I pick both.
AVR:More memories and easy architecture,etc
PIC:Hardware stack(ethernet,USB host,etc).

Jeckson

www.tokopedia.com/madagang for cheap electronics and manuscript

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jeckson wrote:

I pick both.
AVR:More memories and easy architecture,etc
PIC:Hardware stack(ethernet,USB host,etc).

So, have you finally managed to just light a single LED using these PIC's "unique" hardware stacks? :D:D:D

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think Jeckson mean hardware usb and ethernet support, not the stack were you push and pop stuff (which of course is a hardware stack on avr too, but without a four or eight element limit).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think he's just saying blabla as usually.

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.