PIC and AVR thinking of a switch but need more info

[blewisjr]

I have been working with pic chips now for about a month using assembly and really learning some cool stuff about how uC's work.  I have been in the process of designing my own little project and the 8 bit pic architecture is driving me nuts.  It just seems like all of its nuances step on my toes.  I am sure I can work around them but can't help but think about maybe avr is better for me.  I do have an arduino I could use as the base for getting started with the transition. 

Just a few of my issues with pic include the single accumulator, the annoyance of constant paging,  I also find the 4 cycle per instruction very odd.

Does anyone on the avr side of thing have any input? 

I do not want this pic vs avr I am already somewhat un happy with my pic experience so far.  I am just looking for some outside input on my concerns.  If my question are unclear just say so I can clarify better when not typing on a phone.

[ve7xen]

1. Accumulator - AVRs have 32 general purpose registers, and most instructions can use any of them as target (and source). Some are fixed though.
2. Paging - AVR has flat address space
3. Instruction execution time - AVR has variable instruction cycle count

[AlfBaz]

1. Accumulator - AVRs have 32 general purpose registers, and most instructions can use any of them as target (and source). Some are fixed though.
2. Paging - AVR has flat address space
3. Instruction execution time - AVR has variable instruction cycle count

Is that for an 8bit mcu?. If the OP is struggling with asm on an 8 bit micro surely a 32 bit arm isn't going to be any easier

[ve7xen]

Yes, AVR is an 8-bit arch.

[blewisjr]

1. Accumulator - AVRs have 32 general purpose registers, and most instructions can use any of them as target (and source). Some are fixed though.
2. Paging - AVR has flat address space
3. Instruction execution time - AVR has variable instruction cycle count

Is that for an 8bit mcu?. If the OP is struggling with asm on an 8 bit micro surely a 32 bit arm isn't going to be any easier

Note I never stated I was struggling with ASM.  Learning the ASM is not the issue in the least.  The issues I am having revolve around the way the PIC MCU is structured.  It is simple only 35 instructions or so on a PIC16 but because of the way they architect the chip to get to that point it makes it incredibly difficult and tedious to do a lot of things because your are constantly doing stupid little stuff like having to change banks constantly to get at the right registers.  Everytime you have to do this it costs 1 instruction cycle which is 4 cpu cycles.  You also only have the 1 accumulator  which causes you to have to for instance use 2 instruction cycles to set a user file register instead of just 1 instruction cycle.  It is not the asm I have issues with most of the time my issues revolve around understanding the formulas behind certain tasks for instance cycle time which I now understand.  My issues are revolving around the actual PIC architecture being rather crappy which makes it more difficult to do the kinds of things I want to do.

1. Accumulator - AVRs have 32 general purpose registers, and most instructions can use any of them as target (and source). Some are fixed though.
2. Paging - AVR has flat address space
3. Instruction execution time - AVR has variable instruction cycle count

Right pic has variable instruction cycle counts as well but at a 1:4 so 1 instruction cycle takes 4 cpu cycles to complete. Is AVR a 1:1?
Also how is the AVR ASM?  Or rather maybe I mean to say how does the AVR ASM flow?  What I noticed from the PIC architecture through the asm is that you need to often do unnecessary steps  for instance...

movlw  0xA1
movwf Foo

2 instruction cycles instead of a simple

mov Foo, 0xA1

which would be 1 instruction cycle and makes more logical sense at least to me.  This is what I mean by flow.
I like to think in steps and when saying move value to w then move it to the memory address seems awkward compared to move value to memory address

[Psi]

Yep, AVR is a 1:1 for most instructions.
Some instructions take 2 and a few take 3-5. But yeah, most are 1:1
For a real world app the average is around 1.5 clocks per instruction.

You will find ASM on AVRs easier.
ASM on PIC has been described as akin to stabbing yourself in the face. http://www.ladyada.net/library/picvsavr.html

However, both AVR and PIC are getting a bit old now.
You might be better to forget AVRs and move to a 32bit ARM micro.
The price just keeps falling and they've got much more power and features.
I've never done any ARM ASM but i would imagine its pretty nice.

[ve7xen]

AVR assembly is quite sane IMO, but I haven't done all that much with it.

The reference manual is here and is generally pretty clear about the specific questions you've asked so far: http://www.atmel.com/images/doc0856.pdf

[AlfBaz]

Yes, AVR is an 8-bit arch.

And only one clock cycle for ALU operations and 4 for peripheral access, very nice

[mikeselectricstuff]

While learning assembler is a good way to understand how things work, once you have a basic grasp of it, it's probably time to move to using C and let the compiler worry about all the quirks of the architecture until you hit something that really needs the speed of assembler.
AVR assember is certainly nicer than PIC, but has its own challenges, like keeping track of register usage and branch range limits, plus a lot more instructions to remember.

[blewisjr]

While learning assembler is a good way to understand how things work, once you have a basic grasp of it, it's probably time to move to using C and let the compiler worry about all the quirks of the architecture until you hit something that really needs the speed of assembler.
AVR assember is certainly nicer than PIC, but has its own challenges, like keeping track of register usage and branch range limits, plus a lot more instructions to remember.

Yes I do have every intention of moving to C.  C is actually my favorite programming language out of the many I can use fluently.  To not know the asm would really limit me in the long run.  I did not know that ARM make uC's I thought they make microprocessors/full CPU's.  Despite not knowing that I would be under the assumption that a 32 bit ARM from the assembly level would be quite complex none the less.  I chose 8 bit because it would give me a solid base to work off of.  From the information I have gathered so far in this thread AVR 8 bit is quite nice.  Yes I understand it has it's own quirks everything does but from my 1 month experience with PIC abouts the ASM I agree is like poking your eyes with a stick.  The architecture is quite awkward.  Now that I know what I know which is much more then when I started + the clarifications given here AVR or ARM would be the way to go for my embedded programming/electronics hobby.

I should have listed to what the other people said when I was first investigating the hobby a month ago.  I was told on StackOverflow to go ARM and I was told on the Microchip forums to actually go AVR ironically.  So lesson learned.

Thanks for all the help and thanks for not starting a uC war  .  If I think of anymore questions I will ask away.  Feel free to keep this awesome discussion going I will keep checking back.

[mikeselectricstuff]

Actually ARM is one of the nicest architectures to write assembler on, but you rarely need to as it is very compiler-friendly. ARM based MCUs do tend to have rather more complex peripherals though.
 

[nctnico]

There is always TI's MSP430. I think it sits nicely between 8 bit and 32 bit controllers. And some are really ultra low power.

[BravoV]

Actually ARM is one of the nicest architectures to write assembler on, but you rarely need to as it is very compiler-friendly. ARM based MCUs do tend to have rather more complex peripherals though.

Just sharing my experience as enthusiast that used AVR in the past, in ARM mcu, C is enough that the need of hand writing an assembly is not a really a high priority since its really fast.

But even you decided to jump into ARM assembly for hardcore fine tuned performance, its still tons-tons better than old mcu architecture, personally when I ventured into ARM world, I was so damn impressed with NVIC feature when I learned it for the 1st time, and my favorite part is when writing an ISR, the nightmare in the ISR routine in the old time like those pesky push..push..push ..<isr body>.. pop...pop...pop is all handled by hardware and its damn efficient & fast. 

Price wise, today's ARM mcu is so cheap that its not an excuse anymore.

Edit : Attached below the excellent illustration on how ARM cpu handles an ISR.

[westfw]

it makes it incredibly difficult and tedious to do a lot of things because your are constantly doing stupid little stuff like having to change banks constantly to get at the right registers.

Yes.  This is usually an excuse to switch to a high-level language.  If you program in C, any ugliness of the underlying architecture is hidden and largely irrelevant.  As long as it's "fast enough."

That said, AVRs are much more pleasant to program in assembler than the 8-bit PICs (you didn't say which PIC you're using.  I'll assume, based on your comments, that you have a PIC16fxxx of some kind.  The PIC18s are better, and the PIC24s, PIC30s, and PIC32s are all considerably better.

The AVR does in 1 clock cycle what PICs generally do in 4 cycles, so they tend to be faster.

On AVRs in ASM, you'll find yourself frustrated by needing to move everything to a register before you do anything with it.  While the PIC is Accumulator/memory for most operations, the AVR is pretty much register to register for everything.  Also, the AVR will bite you by having various registers and IO locations inaccessible from certain instructions (direct bit testing works on a small set of IO registers.  IN and OUT work on a somewhat larger set.  The reset have to be accessed like memory, which is bigger and slower.)  So they're not without quirks of their own.

[Psi]

I did not know that ARM make uC's I thought they make microprocessors/full CPU's. 

ARM license their instruction set and provide generic cpu core implementations of it.
Other companies buy those licenses and build actual chips.
Some of the companies make cpus for phones others make microcontrollers etc..

So if you decide to use an ARM microcontroller you have lots of choices.
 NXP,  TI, ST, Atmel etc..

[jucole]

I have been working with pic chips now for about a month using assembly and really learning some cool stuff about how uC's work.  I have been in the process of designing my own little project and the 8 bit pic architecture is driving me nuts.  It just seems like all of its nuances step on my toes.  I am sure I can work around them but can't help but think about maybe avr is better for me.  I do have an arduino I could use as the base for getting started with the transition. 

Just a few of my issues with pic include the single accumulator, the annoyance of constant paging,  I also find the 4 cycle per instruction very odd.

Although an appreciation of asm is certainly a good skill to have I'm not sure why you'd want to use it in your projects unless you had specific reason to do so.

Ok, suppose you spend some time writing some i2c code in asm,  can you port that code easily to another chip architecture?   Also if you had to come back to an asm code project you wrote a good while ago could you easily get up to speed with the code without spending a bit of time on it?    Now would the same be true if you had written the code in C?

To me the portability and maintainability of code is far more important than the chip architecture and instruction set peculiarities across devices and device manufacturers.

[blewisjr]

I have been working with pic chips now for about a month using assembly and really learning some cool stuff about how uC's work.  I have been in the process of designing my own little project and the 8 bit pic architecture is driving me nuts.  It just seems like all of its nuances step on my toes.  I am sure I can work around them but can't help but think about maybe avr is better for me.  I do have an arduino I could use as the base for getting started with the transition. 

Just a few of my issues with pic include the single accumulator, the annoyance of constant paging,  I also find the 4 cycle per instruction very odd.

Although an appreciation of asm is certainly a good skill to have I'm not sure why you'd want to use it in your projects unless you had specific reason to do so.

Ok, suppose you spend some time writing some i2c code in asm,  can you port that code easily to another chip architecture?   Also if you had to come back to an asm code project you wrote a good while ago could you easily get up to speed with the code without spending a bit of time on it?    Now would the same be true if you had written the code in C?

To me the portability and maintainability of code is far more important than the chip architecture and instruction set peculiarities across devices and device manufacturers.

Yes I know C is more portable if done right that is.  I have stated multiple times that C is my language of choice and I have every intention of using it.  The thing is that one of my main goals when starting this hobby is to not only learn circuits but to do something different and learn assembly to improve my high level programming skills.  It is well known that learning asm will improve your capabilities in C even if you do not use inline asm.

On another note I have been looking into ARM and the cortex M0+ looks awesome and can come in dip.  The issue is I already have a Arduino which I can use for AVR so I might end up going that route anyway otherwise I have a useless piece of $35 hardware just laying around.

[bingo600]

I'm using AVR and ARM , and selects by target use.

There's no need to use an ARM to blink a led , when a single input is toggled.
Or to display the temperature from a ds18b20 on a LCD (witch often is 5v anyway)

I'm trying to get my hands on some of the NCP Cortex M0 1114 DIP's now but i cant seem to find anywhere in EU , where i don't have to pay either $6 a piece , or $40 in shipping.

I need the 32bit timers thats available in the ARM , for precision counting (waveform gen)

So i chose the "Hammer" depending on the size of the "Nail".

Ohh. I have never programmed a pic , and would probably only consider a DsPIC (MIPS) if i had to chose one.

I have not done much with the new Atmel Xmega's , as i tend to see ARM's as a better choice if i have to go TQFP & 3v3 anyway. Besides a lot of the ARM's have 5v tolerant inputs (most of the pins)  , witch the Xmega doesn't.

If you're going ARM , i suggest the Cortex'es ... At least the NVIC is standard there.

A STM32xx-Discovery board @ 10..15$ will be a nice beginning , and it includes the debugger.

/Bingo

[olsenn]

I'm trying to get my hands on some of the NCP Cortex M0 1114 DIP's

DON'T!!!!!!!!!!!!!!!!!!

I tried for 3 straight days to get that damn MCU to blink an LED and I couldn't. The datasheet/manual is the worst piece of tripe ever written... I'm pretty sure it was written in Korean or Cantonese and translated to English with Google translate. Register contents/locations are missing, and some things were flat out wrong; even self-contradictory.

If you are designing something that can be programmed with an 8-bit micro, program it with an 8-bit micro... if you're designing something that needs to be programmed with a 32-bit ARM-M0, give up and design something with an 8-bit micro instead! Or hire a slave laborer in Guatamala to program the ARM chip for you.

[AlfBaz]

The issue is I already have a Arduino which I can use for AVR so I might end up going that route anyway otherwise I have a useless piece of $35 hardware just laying around.

LOL
Some could argue... 

[mikeselectricstuff]

I'm trying to get my hands on some of the NCP Cortex M0 1114 DIP's

DON'T!!!!!!!!!!!!!!!!!!

I tried for 3 straight days to get that damn MCU to blink an LED and I couldn't. The datasheet/manual is the worst piece of tripe ever written... I'm pretty sure it was written in Korean or Cantonese and translated to English with Google translate. Register contents/locations are missing, and some things were flat out wrong; even self-contradictory.

If you are designing something that can be programmed with an 8-bit micro, program it with an 8-bit micro... if you're designing something that needs to be programmed with a 32-bit ARM-M0, give up and design something with an 8-bit micro instead! Or hire a slave laborer in Guatamala to program the ARM chip for you.

I've not looked at that particular part but NXP's documentation is usually very good. Errors in docs are aways a risk on very new parts from any maker though. Another real headache can be errors in supplied header file definitions for IO registers etc.

[c4757p]

Another real headache can be errors in supplied header file definitions for IO registers etc.

I don't get this. I can see documentation being wrong, since the people testing the chip would know it well enough not to need thorough documentation, but the headers? Don't they at least compile some code for the chips and make sure it runs?

[bingo600]

I'm trying to get my hands on some of the NCP Cortex M0 1114 DIP's

DON'T!!!!!!!!!!!!!!!!!!

I tried for 3 straight days to get that damn MCU to blink an LED and I couldn't. The datasheet/manual is the worst piece of tripe ever written... I'm pretty sure it was written in Korean or Cantonese and translated to English with Google translate. Register contents/locations are missing, and some things were flat out wrong; even self-contradictory.

If you are designing something that can be programmed with an 8-bit micro, program it with an 8-bit micro... if you're designing something that needs to be programmed with a 32-bit ARM-M0, give up and design something with an 8-bit micro instead! Or hire a slave laborer in Guatamala to program the ARM chip for you.

Could this help
http://www.microbuilder.eu/Forums/Thread/e6d805d6-b4d3-4118-9d06-e86671686c63.aspx
http://www.meatandnetworking.com/tutorials/lpc1114fn28-with-open-source-tools/
https://github.com/Zuph/lpc1114-blink

Or the attached one


I'll give the 1114's a go if i can get my hands on a few ...
Maybe you're willing to part with yours   

Edit: There might be a clock-tip here if not using an xtal
http://forums.arm.com/index.php?/topic/16502-cortex-m0-operation-without-crystal/page__p__40452#entry40452

/Bingo

[AlfBaz]

[I don't get this. I can see documentation being wrong, since the people testing the chip would know it well enough not to need thorough documentation, but the headers? Don't they at least compile some code for the chips and make sure it runs?

They should... I remember microchip making a lot of people angry when they altered their headers for some of the 18F pics. Cant remember the specifics but they issued a work around (edit the header) and subsequently fixed it.

[blewisjr]

May I ask what is wrong with the ARM Cortex M0/M0+ I have heard nothing but awesome about them.  People say it gives 8 bit uC's a run for its money.

Also I should say it would make the Arduino useless for me as I want to focus on one uC at a time to avoid confusing myself.