Few people will argue that AVR is a "nicer" CPU architecture, but the fact that Microchip now owns Atmel shows that the architecture just doesn't matter.
Yet, this is NOT intended to be the beginning of another uCU war; it will be about FACTS only...
Yet, this is NOT intended to be the beginning of another uCU war
Yet, this is NOT intended to be the beginning of another uCU war; it will be about FACTS only...If there is some simple logic control mid-range PICs with only 35 instruction set and much lower than 1K SRAM are pretty much good as any AVR with 120+ instruction set, probably much cheaper than AVRs. And reduced cost always means better position to beat competition and more annual income for any company...
Hello there,
I recently found out that I could get free microprocessors from Microchip as a student. http://www.microchip.com/samples/
I can get 2 different microprocessors each month, up to 3 units of each.
I would like to get into learning about microprocessors but am unsure which ones to get/how to utilize this resource to the best of my ability.
I have been developing with the Atmega324A and Atmega328P but would like to learn about more processors.
Which ones would you suggest getting and trying out?
Thanks!
(I tried inserting the URL as a hyperlink but couldn't figure it out )
Are we talking about Brands popularity (Microchip or Atmel) or about uCU families (see: architecture) capabilities (PIC/AVR), in order for the OP to choose from?
Was not me the one who suggested the (non Microchip/Atmel but STM, perhaps) Cortex-M architecture as the next step performance level?
bsf variable,0
ldr r1,[r0]
orr r1,r1,#1
str r1,[r0]
again:
ldrex r1,[r0]
orr r1,r1,#1
strex r1,r1,[r0]
cmp r1,#0
bne again
Perhaps you should do more research before posting! Ofcourse ARM controllers have ways to set or clear bits on a GPIO so a single store instruction does the job. No need for read-modify-write and atomicity isn't an issue.
Perhaps you should do more research before posting! Ofcourse ARM controllers have ways to set or clear bits on a GPIO so a single store instruction does the job. No need for read-modify-write and atomicity isn't an issue.Perhaps you're responding to my post (since yours is next to mine), but I was discussing the instruction set and haven't say a word about GPIOs, so I don't understand what you wanted to say and why it is relevant.
GPIOs are the only place where bit-flipping is really necessary.
GPIOs are the only place where bit-flipping is really necessary.
add w0,[w1++],[w2++]
And yet if you insist on using bits there are ARM controllers which have SRAM bits mapped to a memory address so you can set/reset a single bit with a single instruction if you want to.
And yet if you insist on using bits there are ARM controllers which have SRAM bits mapped to a memory address so you can set/reset a single bit with a single instruction if you want to.
Interesting. I've never came across such beasts. What are they?
Well, if you insist on using 8-bitters, the following message will NOT be in favour of the PIC microcontrollers line of products.
Yet, this is NOT intended to be the beginning of another uCU war; it will be about FACTS only...[...]
If you need to know the reasons why not to move from AVR to PIC, please take the time to read the quoted passage at this message.
Quoting someone competent in both architectures:
- The AVR has thirty-two target registers, sixteen of which can be an 'accumulator'; the PIC has one.
- The AVR can perform conditional jumps; the PIC can only skip one instruction conditionally.
- The AVR has individual vectors for each interrupt; the PIC has a single interrupt for all.
- The AVR has a contiguous RAM memory space; the RAM on the PIC is accessed either by setting one or two bits in the status register to select the required bank or by using an indirection register (and potentially another selector bit).
- AVR registers are accessible through specialised instructions or as direct memory addressing; PIC registers are available only through the paged memory system.
- AVR completes one instruction per clock cycle; the PIC requires four cycles.
- The AVR has a stack available to the program and potentially as large as the internal RAM; the PIC has eight levels, with no user stack.
- The PIC peripherals are generally not as useful as those of the AVR, in particular the timers (though the PIC can offer interrupts on more pins (I think) than the AVR).
In general, on the AVR you generate code which targets the 'accumulator' registers; on the PIC most operations target memory directly.
It is even more advanced in PIC24/dsPIC33 where you can read from one memory location, perform an operation and store it at a different memory location, such asCode: [Select]add w0,[w1++],[w2++]
which executes all in one cycle. Not to mention no-overhead looping, which (as an example) lets you add very long numbers at a rate of 1 byte/cycle.
That won't execute in one cycle because it needs two memory access cycles.
ARM has a huge amount of resources to throw at creating really clever CPUs for microcontrollers so don't think they'll leave out anything which makes their cores perform considerably less than the CPUs from a competitor.
Yet, this is NOT intended to be the beginning of another uCU war
No, of course not.
That won't execute in one cycle because it needs two memory access cycles.
PIC24's instruction cycle is two clock long.ARM has a huge amount of resources to throw at creating really clever CPUs for microcontrollers so don't think they'll leave out anything which makes their cores perform considerably less than the CPUs from a competitor.
This is not a question of performance. They only need to make you believe they cores MUST be better than others,
Well so far you haven't shown me anything the ARM can't do and/or is particulary slower at.
IMHO you shouldn't get a MCU sample if you don't know for what you're going to use it.
OP is a student, use for it is educational, its called learning.
Note that the MPlAB Xpress board is that it’s programmer only, there’s no debug on board. While this might not be a problem for everyone, it's a significant limitation for many. On the other hand, the Microchip Starter Kit, Curiosity and Microstick boards all offer onboard debug.