-
Just throwing in my 2 cents in here, because I see many old comparisons to classic 'avr vs pic' battles.
The assembler of PIC 8-bit devices is horrible. End of it. Not much registers, banks, slow instruction speed. Ugh.
The assembler of AVR seems nicer, and because of the much higher instruction speed it's much faster. Flat memory, nice!
The C/C++ compiler of AVR 8-bit is good, because you have support for full C and C++, which I really lack even on 8-bit. I agree, you wouldn't write C++ on a PIC16 device, but on a PIC18 that carries either on-board USB plus ethernet and a bunch of sensors, it can be useful to program in objects.
The C compiler for PIC16/18 is a pain. The free XC8 is obviously bloating NOP's and BRA's all over the place to make the commercial version look worthwhile. If possible, only use these devices for non-timing-critical projects.
Packaging/pricing/availability: unless it's really hard for you to access a certain device, then pick what you can do, otherwise get breakout SMT boards and there basically is no limits for most QFP parts.
I work with SMD components all the time on breadboards with the use of some simple breakout boards etched on college. If required, get some wire wrap and prototype that way. Like here with a ENC28j60, and bodge 0402 50R termination resistors between the pins of an ethernet transformer.
Selecting chips for 'DIP only' is a pain for yourself, because the more popular and common chips are going towards SMT today.
I've never written ASM on ARM (only C and looking at the produced ASM), but I do know the architecture of ARM is very nice , with DATA and CODE in 1 space, instruction sets like Thumb to reduce code space, better interrupt vectors, etc.
I'm writing some inline-ASM on PIC24/dsPIC33 and it seems OK. It has 16 work registers, stack pointers and seems like a performance-orientated instruction set.Code: [Select]MOV W0, [W8++] ; move value W0 to address pointed by W8, move W8 pointer 1 furtherThese operations are 1 instruction word (which is actually 24-bits, or 3 bytes) and take 1 cycle.
SUB W0, #10h, [W8++] ; subtract 10h from W0, store result in address pointed by W8, move W8 pointer 1 further
MOV W0, [W8+1FAh]
However, moving a literal to a RAM byte, is still:Code: [Select]MOV #24h, W0
MOV W0, 0xCAFE ; CAFE = your RAM address
Atleast it also has some software traps and interrupt vectors, so the hardware pre-sorts interrupt sources to your handlers.
Unfortunately, you have to maintain the stack in software, which can cost some cycles. But if your ISR is really that time critical; write it in ASM so it doesn't produce much overhead anyway.
For me personally I wouldn't touch 8-bit PICs that much, especially not if I am looking out to write decent/clean code. I always have to do some adjustments here and there to make it compile and work efficiently on 8-bit PICs.
16-bit and 32-bit PIC's seem OK, just like 8-bit AVR's was for years. Unfortunately, the support for C++ is very shabby from Microchip, where they only just released it for PIC32.. It sounds to me the code density on 8-bit AVR's may be a bit higher than PIC24s , but then again 8-bit AVR's work with 8-bits, and PIC24s with 16-bits. -
The free XC8 is obviously bloating NOP's and BRA's all over the place to make the commercial version look worthwhile.
Oh lay off the conspiracies. The code generated by C compilers is almost always extremely verbose before any optimizations have been applied. The big difference is how much work a compiler will do even when it's claiming no optimizations are being used. -
That's exactly what I mean; their optimizer isn't the worlds state of the art optimizer, it's just that; a normal 'optimizer' which has been left out the free version.
If you have the PRO version and keep optimizations turned off, your code size already has dropped dramatically over the FREE version.
Enabling extra optimizations (of which there aren't many - all default none) is not very effective in reducing the code footprint compared to the free/pro relationship.
As I said, they bloat the code for no obvious reason other than marketing that their optimizer will optimize typically 40% over free version builds. They are charging an awful lot of money for something that's included in a standard GCC build. -
To claim they spent the effort to intentionally pessimize the code to make their own compiler look bad is ludicrous. XC8 isn't based on GCC, but comparing GCC's -O0 to other compilers' equivalent is a good illustration of my point.
-
Quote
comparing GCC's -O0
The examples I've seen of the microchip PIC compilers "completely unoptimized" compiler are MUCH worse than gcc's -O0 output. That's why people were/are disappointed; they were expecting -O0 like output, and instead got stuff that looks like a Compilers-101 class three-operand pseudo-code simplistically translated into PIC. I'll see if I can come up with a realistic example...
-
I'm not disputing that the produced code isn't awful, but that's a lot different that saying it's made intentionally worse.
-
With my simple code I have not had any issues with the XC8 compiler yet. On average I see a 10 byte increase. The only significant issue I see in the asm was writing to port instead of latch. The delays are a bit sloppy but if you need tight like others said inline asm. Not sure how it looks for more complex code with conditionals.
-
The only significant issue I see in the asm was writing to port instead of latch...
Interesting... are you saying that in c you type latb=xx and the compiler produces portb=xx, or are you typing portb=xx and you are expecting latb=xx. The latter would be a compiler bug
-
Writing in c latc = xxx and getting portb almost positive I will re look at and post the listing when I get home tonight.
-
assuming latc portb is a typo and you meant latc portc, I was under the impression you were working with a pic16 part, maybe it doesn't have a latch register and the compiler was kind enough to accommodate. If that's the case check the devices header file and see if they've defined latches equal to ports
-
Was working with a 16f1829 and I did mean portc but there is actually 1 latch for each port on the chip. So that is not the issue. This comes from the data sheet I checked and the tuts that came with the chip + dev board.
-
OK, here's some actual code that I ran through a freshly-downloaded "free" version of XC8 for a "real" PIC12f675 application that I had lying around. The actual app runs pseudo-random PWM on several LEDs to create a "flame" effect, and was previously compiled using the free version of "cc5x"... I think the example serves to illustrate the sort of thing that people are complaining about...
This is from MPLABS disassembly listing; I've added the ";;" comments.Code: [Select]void main(void)So that's 4 or 5 instructions where there should be 2. Presumably the code generator has nice rules about keeping the status register up-to-date, along with some internally-used temporary register?
!{
! char pwm1, pwm2, pwm3, pwm4, pwm5, level_delay, pwm_delay;
! init();
0x2FE: CALL 0x2F0
! bright1 = 50; // "random" initialization
0x2FF: MOVLW 0x32
0x300: BCF STATUS, 0x5 ;; unnecessary setting of status.
0x301: MOVWF 0x23 ;; unnecessary (and soon overwritten) save to mem 23.
0x302: MOVF 0x23, W ;; unnecessary move back to W.
0x303: MOVWF bright1
! bright2 = 20;
0x304: MOVLW 0x14
0x305: MOVWF 0x23 ;; status already set, so only the mysterious loc 23 code!
0x306: MOVF 0x23, W
0x307: MOVWF bright2
! bright3 = 10;
Later, we have some conditional code:Code: [Select]! if (--pwm3 == 0) {Isn't that a swell chain of three GOTOs? I think one would do... Presumably these implement a generic conditional branch if/else setup, using the skip instructions. But, yuck!
0x350: MOVLW 0x1
0x351: SUBWF pwm3, F
0x352: BTFSS STATUS, 0x2
0x353: GOTO 0x355
0x354: GOTO 0x356
0x355: GOTO 0x358
! led3_off;
0x356: BCF GPIO, 0x3
0x357: GOTO 0x358
! }
(Just for reference, here's the similar part of code from CC5x (which also claims to have better optimization in their "non-free" version. I like the CC5X code just fine, but find the XC8 code "yucky." You can make your own judgements.)Code: [Select]0049 2001 0247 CALL init
0248 ; bright1 = 50; // "random" initialization
004A 3032 0249 MOVLW .50
004B 00A8 0250 MOVWF bright1
0251 ; bright2 = 20;
004C 3014 0252 MOVLW .20
004D 00A9 0253 MOVWF bright2
0254 ; bright3 = 10;
:
0317 ; if (--pwm3 == 0) {
0073 0BA2 0318 m010 DECFSZ pwm3,1
0074 2877 0319 GOTO m011
0320 ; led3_off;
0075 1283 0321 BCF 0x03,RP0
0076 1505 0322 BSF 0x05,GPIO2 -
Looks like pretty typical unoptimized code, especially the redundant loads and stores. You get a lot of that from GCC too.
-
Here's what gcc produces for AVR, with -O0 (optimization explicitly turned off)Code: [Select]
;; The initialization code is much nicerI rather like this "bad code" better than the PIC's bad code, because it's more obvious what it's doing and what it hasn't done. The AVR code is a sort of naive translation of the C into AVR assembler. The unoptimized PIC code is (probably) more of straightforward translation of an "intermediate abstraction" of a compiler target (one short sequence of PIC code for each abstracted operation), and is much less obvious (thus leading to the rumors of intentionally bad code.) (because you can think in C, or you can think in assembler, but somehow compiler writers' usual abstraction isn't very close to either one. Sigh.)
bright1 = 50; // "random" initialization
178: 82 e3 ldi r24, 0x32 ; 50
17a: 80 93 61 00 sts 0x0061, r24
bright2 = 20;
17e: 84 e1 ldi r24, 0x14 ; 20
180: 80 93 64 00 sts 0x0064, r24
bright3 = 10;
184: 8a e0 ldi r24, 0x0A ; 10
186: 80 93 60 00 sts 0x0060, r24
:
;; But the conditional code is considerably worse.
if (--pwm3 == 0) {
1fe: 8d 81 ldd r24, Y+5 ; 0x05 ;; local variables come from the stack
200: 81 50 subi r24, 0x01 ; 1 ;; decrement
202: 8d 83 std Y+5, r24 ; 0x05 ;; and go back to the stack.
204: 8d 81 ldd r24, Y+5 ; 0x05 ;; and are gotten from the stack again
206: 88 23 and r24, r24 ;; separate test for zero.
208: 39 f4 brne .+14 ; 0x218 <main+0xb6>
led3_off;
20a: a8 e3 ldi r26, 0x38 ; 56 ;; and then we have this awful code for led3_off, which
20c: b0 e0 ldi r27, 0x00 ; 0 ;; isn't quite fair because avr uses portb &= ~mask;
;; while the PIC has "bit variables" gpio3 = 0;
20e: e8 e3 ldi r30, 0x38 ; 56
210: f0 e0 ldi r31, 0x00 ; 0
212: 80 81 ld r24, Z
214: 8b 7f andi r24, 0xFB ; 251
216: 8c 93 st X, r24 ;; and separate pointers for reading and writing??
}
Of course, avr-gcc does support optimization. With -Os, I get:Code: [Select];; (The initialization code is the same)
if (--pwm3 == 0) {
11a: 91 50 subi r25, 0x01 ; 1 ;; local variables now optimized to registers.
11c: 09 f4 brne .+2 ; 0x120 <main+0x5c>
led3_off;
11e: c2 98 cbi 0x18, 2 ; 24 ;; The special io bit set ins is used!
} -
Ok here is the listing file for my binary counter program run on a raw PIC16F1829 from breadboard. I added ;; comments to point out the spots that I found as an issue in my previous few posts yesterday.Code: [Select]
37: void main(void)
38: {
39: // 8 bit number (1 byte)
40: unsigned char cnt = 0;
07E7 01F2 CLRF cnt
41:
42: // set internal oscillator to 500kHZ
43: OSCCON = 0b00111000;
07E8 3038 MOVLW 0x38
07E9 0021 MOVLB 0x1
07EA 0099 MOVWF T1GCON
44:
45: // make all of PORTC (RC0 - RC7) and output
46: TRISC = 0;
07EB 018E CLRF PORTC ;; NO! You should be clearing TRISC (Surprised this line is not causing issues)
07EC 2FED GOTO 0x7ED
47:
48: while (1) {
07FD 2FED GOTO 0x7ED ;; Why? totally not needed 7ED is the next instruction!
49: LATC = cnt;
07ED 0872 MOVF cnt, W
07EE 0022 MOVLB 0x2
07EF 008E MOVWF PORTC ;; NO! You write to LATC not PORTC
50:
51: // 1 second delay
52: __delay_ms(1000);
07F0 30A3 MOVLW 0xA3
07F1 00F1 MOVWF 0x71
07F2 3055 MOVLW 0x55
07F3 00F0 MOVWF 0x70
07F4 0BF0 DECFSZ 0x70, F
07F5 2FF4 GOTO 0x7F4
07F6 0BF1 DECFSZ 0x71, F
07F7 2FF4 GOTO 0x7F4
53:
54: // increment count by 1
55: // when it overflows passed 255 it will reset to 0
56: cnt++;
07F8 3001 MOVLW 0x1
07F9 00F0 MOVWF 0x70
07FA 0870 MOVF 0x70, W
07FB 07F2 ADDWF cnt, F
07FC 2FED GOTO 0x7ED
57: }
58: }
07FE 3180 MOVLP 0x0 -
45: // make all of PORTC (RC0 - RC7) and output
46: TRISC = 0;
07EB 018E CLRF PORTC ;; NO! You should be clearing TRISC (Surprised this line is not causing issues)
[...]
49: LATC = cnt;
07ED 0872 MOVF cnt, W
07EE 0022 MOVLB 0x2
07EF 008E MOVWF PORTC ;; NO! You write to LATC not PORTC
I think this is just a failure of the listing pretty-printer -- remember the PIC banks its registers, so only the bottom part of the register address is present in the MOVWF instruction. The other half is in the bank select bits, which in your excerpts are set by the MOVLB calls prior to the MOVWFs; the pretty-printer is obviously just looking up the operand and translating to a bank 0 address, rather than trying to keep track of which bank will be selected for each instruction. I would imagine the register summary will show PORTC, TRISC and LATC are all at the same address but in banks 0, 1 and 2 respectively.
(Not that I've actually checked, of course, but that's certainly how PORTx and TRISx are laid out on chips that don't have the LATx registers...) -
I think this is just a failure of the listing pretty-printer -- remember the PIC banks its registers, so only the bottom part of the register address is present in the MOVWF instruction. The other half is in the bank select bits, which in your excerpts are set by the MOVLB calls prior to the MOVWFs; the pretty-printer is obviously just looking up the operand and translating to a bank 0 address, rather than trying to keep track of which bank will be selected for each instruction. I would imagine the register summary will show PORTC, TRISC and LATC are all at the same address but in banks 0, 1 and 2 respectively.
(Not that I've actually checked, of course, but that's certainly how PORTx and TRISx are laid out on chips that don't have the LATx registers...)
Correct. There is nothing wrong with the actual code it is just that the disassembler does not even try to track the bank select bits so all names given to SPRs will pretty much default to the name of the SPR in bank 0. The same thing happens regardless of language or compiler. It is the "dumb" disassembler that is defaulting the SPR names to bank 0 values.
To get an assembler source listing containing the correct SPR names from XC8 I believe you must use the correct switches on the command line.
-
Ok that makes perfect sense and explains why no code issues arise.
-
One thing to be careful of with PIC is controlling the bits on a port with the PORT command, use LAT for changing a port from 0 to 1 or 1 to 0 .
If you use PORT to change the bit ,the bit may not change right away or may take a cycle or two to change because PORT is telling the chip to write the value to the latch. Depending on the chip the write may not take place at all if it is shared with a peripheral and the PORT command is used.
PORT for read and LAT for write, keeps it simple.
Early PIC chips may not have LAT so you have to use PORT.
In the source code , setting up the oscillator should be done and tested before you start assigning port uses.Quotemovlw b'00111000' ; We want a clock of 500kHZ giving us (1/(500k/4)) per instruction
movwf OSCCON ; Move W register into OSCCON -
NOTE: This is not comprehensive and I may have made a few wrong assumptions etc... I am new to micro's like many other people and still learning various things about how the compilers work with them as I go along. I am also not a compiler expert in no way shape or form.
Well it has been a while actually particularly because I have been doing various testing scenarios on my own to come to a conclusion. So now that the testing is done I figured I would stop by and explain the conclusion I came to.
I ultimately Tested 2 chips ended up being 3 due to a odd discrepancy that came up on the PIC side but after reviewing the lst files generated by XC8 it turns out the discrepancy was only in setup code. So the 2 chips used were the PIC18F14K22 (20 Pin PDIP) and the ATMega328P (28 Pin PDIP).
I reviewed basic chip features and peripherals first.
PIC Flash = 16 kbytes AVR flash = 32 kbytes
PIC SRAM = 512 bytes AVR SRAM = 2 kbytes
PIC EEPROM = 256 bytes AVR EEPROM = 1024 bytes
PIC ADC = 12 10-bit channels AVR ADC = 6 10-bit channels
PIC I/O = 17 + 1 (input only) AVR I/O = 22 + 1 if RSTDISBL Fuse is set
Neither Chip has DAC
PIC Max Op Freq = 64MHZ (With PLLEN) AVR Max Op Freq = 20 MHZ
PIC Instruction set = 74 (std) 83 (ext) AVR Instruction set = 131
PIC WREGs = 1 AVR WREGs = 32
This was just a quick basic overview there are many differences but both chips are very comparable.
With both chips I decided to write a hello world blinking led program to compare compiler output size as the biggest factor in my decision involves the toolchains and development environments. With PIC I used MPLABX with the XC8 C compiler. With AVR I used AVR Studio 6 with AVR-GCC compiler.
The first major difference I noticed was that with developing PIC you need to set the chips fuses in code. This is rather crappy in my opinion as it is rather tedious to do and easy to make a slip up, however this can be negated by creating a standardized header file to handle this for us. With AVR you set the fuses with a tool in the IDE by setting Hex values. This tool was awesome especially when you have a calculator Like the one at Engbedded to calculate the bit values for you. You can also just select the fuse settings right from the tool as well instead of using values.
The next major difference is in the IDE quality. MPLABX on netbeans does have the advantage of cross platform, however, as a whole MPLABX is very buggy and a lot of the issues arise directly from the core netbeans backend. These bugs have been in netbeans for a long time and I swear Oracle refuses to fix them. AVR Studio is built on VisualStudio and despite it not being cross platform it is rock solid and just works with no real annoyances. The only real annoyance I found was when programming the chip if the programming rate is too low or too high in the tool project settings the chip will not program and the error you get is so obscure you would almost never guess it was the programming rate.
The code I wrote was as similar as possible. API wise XC8 wins by having the I/O registers built as structures where you can access the bits like
LATCbits.LATC0 ^= 1.
With AVR you need to do a
PORTB ^= (1<<0); or a PORTB ^= _BV(0); or PORTB ^= (1<<PORTB0); or PORTB ^= _BV(PORTB0);
This is a negligible issue really but I think the Structure method leads to code that looks cleaner in the long run.
Not really much more then this as it was just hello world. Now onto the code size difference.
The PIC compiled to 62 bytes of flash (Free version of compiler with little optimization) With the AVR it compiled to 162 bytes of flash (O1 optimization, however it was the same under all levels of optimization due to simplicity of program).
WOW!!!!! The AVR was 100 bytes larger. Okay Okay lol. Now in all seriousness yes it is 100 bytes larger but in the long run it would gradually equate to or be smaller then the PIC code. HUH? Yes it would. In such a simple program the differences are amplified so let me explain why. Setup Code!!!!!. All the extra working registers on the AVR take up some space. Also AVR-GCC sets up all the Interrupt vectors where the pic does not leading to 68 extra bytes. So if you take into account all of this stuff over time the AVR will come out ahead as the pic will have to add this extra stuff later. Also the 31 extra working registers means we have to use less ram overall. So if you put the chips under an even playing field the AVR has a extra 100 bytes of setup code take that away and they are both at 62 bytes of flash in theory ONLY. But as stated eventually the PIC will have to init the interrupts etc... Being that I do not have $450 - $1000 for compilers as projects become more complex the AVR will always come out on top for me code size wise because I have access to optimization levels that I don't get with PICs free XC8.
So after all this I decided I have to make a decision over all. It is without a doubt that Microchip has a greater variety of chips available but AVR has a great selection as well just smaller. The tool chain for AVR covers all of their chips 8,32, and ARM. Where with PIC every chip class 8, 16, or 32 has a different compiler. Overall I have always like visual studio far better than netbeans. I also really like gcc it is a very solid tool. I have also decided to move away from asm for now and go to C because I have a much better understanding of how things are working under the hood now. So for me and my hobby endeavours I am going to have to go with AVR. I really like the development echo system and it really fits the tight hobby oriented budget. I will keep PIC in mind always because they really are great chips and you never know when a project might need one. -
The first major difference I noticed was that with developing PIC you need to set the chips fuses in code. This is rather crappy in my opinion as it is rather tedious to do and easy to make a slip up, however this can be negated by creating a standardized header file to handle this for us.
MPLAB X does have a built-in editor for fuses. If you open up the Configuration Bits memory view you can edit the bits as you see fit, and when you click the "Generate Source Code to Output" button it generates code which you can copy into your source files. -
The first major difference I noticed was that with developing PIC you need to set the chips fuses in code. This is rather crappy in my opinion as it is rather tedious to do and easy to make a slip up, however this can be negated by creating a standardized header file to handle this for us.
MPLAB X does have a built-in editor for fuses. If you open up the Configuration Bits memory view you can edit the bits as you see fit, and when you click the "Generate Source Code to Output" button it generates code which you can copy into your source files.
Oh wow that is really cool can't believe I missed that I guess it is just not as in the face obvious as the one for AVR Studio.
Another thing I did notice is from a Chip perspective feature wise PIC really does come out on top in almost every case there selection is really amazing. My biggest issue is there compilers the price is just so crazy and as a hobbyist eventually it will bite me in the ass if I embark on a crazy project. Having the different compiler for every chip is just bad imho and the $450 per compiler for 25% optimization + the maintenance subscription is just not feasible from my perspective. It would be really nice if they could smarten up about the compiler situation if it was not for the compiler price PIC would have been a really easy choice. Sure there is SDCC which is free and covers quite a bit of 8bit PIC chips but the pace that they add new chips is very slow and I am not sure how well it integrates with MPLABX. -
SDCC is free for pic and you can use whatever IDE you want . If a pic isn't supported it is easy to add it, just create new include files.
Some useful tools for pic that are free:
http://vasco.gforge.enseeiht.fr/index.php?article=PUF.html
http://sdcc.sourceforge.net/
http://www.casadeyork.com/jalv2/
https://code.google.com/p/jallib/
http://www.sfcompiler.co.uk/swordfish/
http://sourceboost.com/Products/Products.html
Sourceboost really isn't all that well known, but the compiler is one of the best I have used and the pricing is fair going from free to $150 for full commercial version.
-
Quote
Having the different compiler for every chip is just bad
The AVR has different compilers for each range of chips (AVR, AVR32, ARM.) They're all builds of gcc, but you'll still have three directory structures, three sets of binaries, and (probably) version and up-to-date issues of one WRT another.Quoteas a whole MPLABX is very buggy and a lot of the issues arise directly from the core netbeans backend.
Is that based on your personal experience, or hearsay? With MPLABX, or other NetBeans IDEs?Quotebut in the long run [avr-gcc] would gradually equate to or be smaller then the PIC code.
Oh come on. If you're going to create a benchmark, you shouldn't then make up excuses as to why the results "really mean" something different than they actually show. You don't have any evidence at all that the AVR code will be smaller in any real-world application; you're just repeating your assumptions. I mean, I think you're probably right, but you might as well not have done any benchmark at all! (In fact, the inability of avr-gcc to "prune" the interrupt vector table to reflect only the interrupts actually used is a subject of somewhat frequent "request for enhancements." That 68 bytes (plus or minus, for different AVRs) can be pretty painful for small chips, or if you're trying to fit a bootloader in 512bytes, or whatever. (Fortunately, it's pretty easy to omit the vector table entirely.)QuoteAll the extra working registers on the AVR take up some space.
No, not WRT the image size. In fact, you can write substantial AVR programs that use NO ram, storing all their data in registers (and there are (were) AVRs that don't HAVE any RAM; just the registers.)
-
The IDE bugs I talk about come from netbeans in general they are minor but can get annoying at times most deal with the code editor. I also do apologize for reiterating my assumptions but I really do not have much more to go off of. Everything turns out to actually be quite similar in the long run. I am still evaluating the situation partly because of the great pic community plus huge chip selection. Hands down there chips have more variety of perifs.
As for the working registers sure they do not take ram but what the lst shows me is that they do inc the setup code size but I could be reading it wrong.