Which Microchip processors should I get?

[JPortici]

heh, while the issues i'm having may be depending on something in my hardware configuration, doesn't change the fact that the support is officially in beta while the "real" pk3 is fully supported. they should be exactly the same thing, right?

[eugenenine]

So being a student are there any general area you are interested in, IOT, robotics, etc?  Look for ones that meet those interests.
I bought a pickit 3 a couple years ago after selling my stuff a decade or so before that.  I got the pack with the 44 pin demo board so I ordered a couple of the equivalent but in dip form so I could protoboard them.
I subscribe to Microchip's mailing list and when they introduce or highlight something that interests me I'll order a couple.  I'm not a student so I have to order through mouser or digikey but I usually just stick a pair on an existing order so the cost is trivial.  I always buy in pairs in case I let the smoke out of one

[westfw]

[ARM is better than AVR is better than PIC, etc]

By my calculations, a modern 8bit PIC (PIC16f1707 is the datasheet I happen to be looking at) can set a bit in any IO register in two (14-bit) instructions:

Code: [Select]

   movlb bank(regAddr)
   bsf offset(regAddr), regBit
A modern AVR requires 3 instructions, two of which are 32bits long - 10 bytes (because not all IOregs are accessible via SBI):

Code: [Select]

    lds r16, regAddr
    ori r16, bit
    sts r16, regAddr
A modern ARM CM0 takes a whopping 5 instruction plus 2 data words, for 18 bytes total:

Code: [Select]

    ldr r1, =regAddr
    ldr r2, [r1]
    ldr r3, =regBit
    orrs r2, r3
    str r2, [r1](ok, you could do that with only 16 bytes by changing the load of regBit to a mov (immediate) and a shift, adding one instruction but deleting 4 bytes of constant.)
(Cortex m3 and so on are better (14 bytes, one less register used) because orr gets a thumb2 "immediate" mode.)

This doesn't include "secondary effects" - the PIC code sets the memory bank register, the AVR and ARM codes use one or more of the GP registers, etc.  Nor ease of applicability to more general or less general cases.  And it's not really meant to show "better" in any real sense.  It's just a reminder that these things are more complicated than they seem at first glance.
(Now, I don't actually program any of these in assembly language on a regular basis, so I'd be happy to see these "improved."   But I did look pretty carefully, and checked C output, so I'm pretty sure that these are pretty accurate.)
(I've been finding the CM0 "16-bit thumb-only" instruction set to be pretty depressing.  Especially since it's being positioned against 8bit chip with versions having similar flash content.  But then, I guess you're not supposed to program it in assembly...)

[ataradov]

ARM can be optimized a bit:

Code: [Select]

    ldr r1, =regAddr
    ldr r2, [r1]
    mov r3, #1
    lsl r3, r3, #N
    orrs r2, r3
    str r2, [r1]
More instructions, but less data and lower overall memory usage. And if we are only setting low 8 bits (we are comparing against 8-bitters, aren't we?), then lsl is not needed, mov can take 8 bit immediate.

It is useless to compare 32-bit and 8-bit MCUs in this respect.

[NorthGuy]

And if we are only setting low 8 bits (we are comparing against 8-bitters, aren't we?), then lsl is not needed, mov can take 8 bit immediate.

If you use LDRB/STRB then you only need to access low 8 bits to reach everywhere.

It is useless to compare 32-bit and 8-bit MCUs in this respect.

Why not? By strange coincidence, all modern (perhaps not all) 32-bit processors are RISC. IMHO, RISC is not a good idea for embedded systems which execute code from flash. Of course, 32-bitness is a good thing, but is it so good that it overshadow all the  drawbacks of RISC-ness?

[ataradov]

Of course, 32-bitness is a good thing, but is it so good that it overshadow all the  drawbacks of RISC-ness?

For me, it absolutely is. And we are really talking about CM0+. CM3 and up have a lot of good instructions for this kind of stuff.

You can't compare isolated chunks of code like this. There is a lot of optimizations that come from reusing the same constants, values in registers, etc. And that's where good compiler comes in. And GCC for ARM is a very good compiler.

Furthermore, a lot of peripherals in 32-bit world are designed with registers that have set/clear on write, so you only need one write to set or  clear a set of bits. This also ensures atomic operation.

[westfw]

If you use LDRB/STRB then you only need to access low 8 bits to reach everywhere.

Yeah, but I had set the bar at "set any bit in an IO register", and in the ARM world, many of those registers can only be accessed as 32bit quantities.  It's an interesting look at why you might want your GPIO registers to be 8bit, too.

You can't compare isolated chunks of code like this. ...
a lot of peripherals in 32-bit world are designed with registers that have set/clear on write, so you only need one write to set or  clear a set of bits. This also ensures atomic operation.

Yes, and yes.   There seems to be a big problem in general defining what "typical 8bit embedded code" actually looks like.  This sort of "set one bit at a time" is very common.  ARM will show you benchmarks on how a 32bit CPU is SO much better at doing 32bit math, which is obviously true, but 32bit math is somewhat avoided by 8bit programmers.  It's hard to separate the needs from the habits...

Cases like this are interesting to explore, to see what special cases are used and when they fail.  The AVR has "sbi" that can set SOME ioreg bits.  And it has "in/out" that would shorten the code for SOME other bits.  But then if you want to make the address and bit be variables, the code bloats up even more and you get (close to) Arduino's digitalWrite() at ~50 instructions.  Whereas the ARM code is already much more "generic" and doesn't HAVE a bunch of special case instructions to tempt the assembly-language programmer or frustrate the compiler writer.

all modern (perhaps not all) 32-bit processors are RISC.

Intel x86 is far from RISC (perhaps far from "modern" as well, but it's still the elephant in the room.)  I'm a bit stunned that there aren't more x86 microcontrollers out and about, now that the original instruction set is out of IP protection.
Also Motorola Freescale NXP "Coldfire", which is essentially 68k.

[ataradov]

I'm a bit stunned that there aren't more x86 microcontrollers out and about

x86 ISA is only efficient if supported by a very complicated multilevel cache system. Otherwise it will lose big time.

[nctnico]

[ARM is better than AVR is better than PIC, etc]

By my calculations, a modern 8bit PIC (PIC16f1707 is the datasheet I happen to be looking at) can set a bit in any IO register in two (14-bit) instructions:

Code: [Select]

   movlb bank(regAddr)
   bsf offset(regAddr), regBit
A modern AVR requires 3 instructions, two of which are 32bits long - 10 bytes (because not all IOregs are accessible via SBI):

Code: [Select]

    lds r16, regAddr
    ori r16, bit
    sts r16, regAddr
A modern ARM CM0 takes a whopping 5 instruction plus 2 data words, for 18 bytes total:

Code: [Select]

    ldr r1, =regAddr
    ldr r2, [r1]
    ldr r3, =regBit
    orrs r2, r3
    str r2, [r1](ok, you could do that with only 16 bytes by changing the load of regBit to a mov (immediate) and a shift, adding one instruction but deleting 4 bytes of constant.)
(Cortex m3 and so on are better (14 bytes, one less register used) because orr gets a thumb2 "immediate" mode.)

You forgot about ARM Cortex bit-banding and seperate bit set/clear registers on typical peripherals found in an ARM microcontroller which reduce a bit set/clear operation to two instructions.

[westfw]

You forgot about ARM Cortex bit-banding and seperate bit set/clear registers on typical peripherals

I didn't "Forget."   Few CM0 chips include bit-banding, and it doesn't help much anyway (you still need to load a 1 or 0 to store to the bitband region.)  I didn't include the bitset/clear registers, because they're not present for all IO registers (which was my target) (frequently they're only present for GPIO pin registers. (which is one of the places they're most needed, of course.))

which reduce a bit set/clear operation to two instructions.

Show me?  I don't think you can get less than three instructions/8bytes (Hmm.  Better than the AVR!)

Code: [Select]

   ldr r1,=bitband(regAddr, regBit)  ;; doesn't matter if direct reg or "set" register?
   mov r2, #1
   str r2, [r1]