AVR8 vs Cortex-M???

[Dielectric]

... put code where the vector table would go if you were using interrupts, etc.

eh?

Sometimes you can put an instruction or two right in the vector table instead of actually incurring a call.  If all you need is a flag, then an OR opcode on a reg or a byte of RAM is all you need.  I've done it and made double-sure to document that change.

[Sal Ammoniac]

M7F got a MMU, just map all memory into one logically contiguous chunk.

This is news to me. As far as I know, the MPU in the Cortex-M7 is the same as the one in the M4, and the ARM architecture manual explicitly states:

MPU support provides control of access rights on physical addresses. It does not perform address translation.

[Jeroen3]

Some vendors alias the memory. Same goes for bit-banding.

[andyturk]

Sometimes you can put an instruction or two right in the vector table instead of actually incurring a call.  If all you need is a flag, then an OR opcode on a reg or a byte of RAM is all you need.  I've done it and made double-sure to document that change.

Maybe that worked for earlier ARM processors (haven't tried it myself), but the Cortex-M treats the vector table as a bunch of 32-bit addresses--no opcodes. One of the benefits of the architecture is that the hardware stacks some registers automatically on an exception entry, so there's less need/opportunity to play those kinds of tricks.

[westfw]

... put code where the vector table would go if you were using interrupts, etc.

eh?

At the beginning of the ARM address space is a "vector table" that normally holds the addresses of the handlers for exceptions and interrupts and such.  It's pretty big.  On an Atmel SAMD21 there are 16 words worth of CM0-common vectors, and 28 words worth of Atmel Peripheral interrupts.
A C program normally fills them in with pointers to "unhandled_exception" or similar.   That's 176 bytes of program space, and it's one of the reasons that ARM code looks so bloated even for trivial programs.   Now, the first two words hold the initial stack pointer and the reset_handler address, which are pretty important.  But the remaining 168 bytes are only useful if you actually implement handlers for the exceptions or interrupts that they handle, so they can be reclaimed if you're really desperate.
(On a STM32f103 you have 16 words of CM3 vectors and 60 words of ST Peripheral vectors.  304 bytes!)

There are intermediate hacks - most chips seem to allow you to relocate the vector table to RAM (handy for OSes) (This is an ARM "optional" feature.)  So you can omit the table from FLASH and "build" it in RAM - if you need only a couple of interrupts (UART and SYSTick?), the code to build a RAM table probably takes less space than leaving the whole table in flash.

[Brutte]

On a STM32f103 you have 16 words of CM3 vectors and 60 words of ST Peripheral vectors.  304 bytes!

out of 128kiB. It is a const array of pointers. It has exactly the same size members as the ones on mega AVR8s, that is 4 bytes per one IRQ. Cannot see a spectacular difference.

[Jeroen3]

The fact that you think 304 bytes is a lot means you're pushing the envelope on your current platform. Wake up, get smaller silicon!
I toss around lookup tables all over the place on ARM since you have A LOT of flash and there is no significant speed penalty reading random from flash. (there is some penalty for cache miss)
That same STM32F103 you mentioned is available with 1 MegaByte of flash. Which will only be used when you start loading images for your LCD application.

On the last project (custom PLC-ish core) I wanted to output some human readable debugs strings when an input (one of ~400) was triggered. I copied the entire schematic netlist into ann char* array. Whopping 10KB of debug content. No worries.

[westfw]

Yeah, yeah.  But if you're going to say "the ARM is so horribly code-bloating that a 16k part is the minimum you should consider", it's worth pointing out that the same tricks people use to get their code working on small 8-bit micros will work on small ARMs, too (say, 4k - still "mid-sized" by 8bit standards.) (4k is also the minimum I've seen on an ARM microcontroller, I think.)

[Jeroen3]

With thumb instructions a 4k flash part is really small. Comparable to a 2k AVR parts, like ATtiny's.
If you're looking for chips in this region, the price should be the determining factor.
But remember that the price consists of the chips, the work, and the tooling. If you have to buy the tooling again for low volume, it's not going to win. Same applies if you have to educate your developers again.

[nctnico]

The problem I have found with ST's devices is that their peripherals are allover the place and knowledge gained on one chip is totally useless for the other. You have to consider those costs as well. Just saying their evaluation boards are cheap is like saying you should buy whatever has the most shiny parts without looking under the hood.
If you are in low volume stuff (<10000 units) then it makes more sense to choose for a broad microcontroller family with consistent peripherals so you can share a lot of code between projects without having to rely on bloated hardware abstraction layers.

[dannyf]

As a result of maker movement, MCU boards are pretty cheap these days.

I don't know if that's because of the maker movement. MCU prices have gone down significantly, and manufacturing technology has advanced also, so the cost of producing a mcu board has gone down significantly. I don't dispute that the maker movement has broadened the demand and economy of scale has helped drive down the total cost.

But I think the maker movement is more a result of low prices rather than a driver of low prices.

[Brutte]

(..)4k is also the minimum I've seen on an ARM microcontroller, I think.

Frankly, why would a hobbyist wanted to buy a uC that is below 128kiB? These go like $2 a pop. I would not buy a 4kiB chip even if it were $0.01 a pop. It is simply not worth saving a buck and hitting "now please skip to assembler (or rewrite a library) because we are out of flash".
Perhaps, if it were a 10k volume. But even then I doubt I'd use a 4kiB ARM.

[Kjelt]

What I see happening all around is that people that have limited SW/HW engineering skills but want to produce something with a lot of ADC/GPIO/I2C/SPI/LCD/TCP-IP etc. take a pi or BBB.
And considering all the topics on this forum how get things going with an Cortex chip I find that a very good and wise decision.
My advice to hobbieists at this moment: simple projects: arduino/8 bitter, more advanced projects: pi or BBB or generic pcb's like that.

But the TS is no hobbieist, he is a SW engineer following education, and then you have to prepare for what a future employer wants from a fresh employee.
Then comes the decision what kind of product:
- embedded low end stuff (standalone not internet connected) my advice: Cortex M is the way to go since for any significant amount of production they will use that kind of uC's.
- embedded high end stuff (internet connected): go learn embedded linux and seperation kernels, so microprocessors with MPU/MMU that is the future where the entire IIOT v4 (Industry Internet of Things) is going to IMO.
The last I see more and more developing currently, and the requested jobs are shifting towards this esp. in the western world.

[westfw]

why would a hobbyist wanted to buy a uC that is below 128kiB? These go like $2 a pop. I would not buy a 4kiB chip even if it were $0.01 a pop.

Well, yeah.  The relevant question is more like "are the $0.50 ARM chips that vendors are targeting at the same sockets currently using $0.50 8-bit chips, actually capable of doing the same job?"  (and some of them only have 4k 4kib.)  And I'm claiming that the answer is generally "yes."

It is simply not worth saving a buck and hitting "now please skip to assembler (or rewrite a library) because we are out of flash".

how do you feel about "pay $0.10 more for the chip in the same package that has more memory"?

Now, you can also see vendor claims of the sort: "ARM is so wonderful that our 16k SAMD10 chip will easily replace your 32k ATmega328." (ok, usually not that blatant.  More like "we're not even going to sell 32k SAMD10 chips, even though we do sell 32k AVRs in similar package sizes.")
This seems rather unlikely...

[dannyf]

"embedded high end stuff (internet connected): go learn embedded linux and seperation kernels, so "

At the application level, as well as human capital management level, it is definitely true that more encapsulation (aka dumbing down) is needed. Starting up on cortex m chips isn't difficult for a competent embedded engineer but many times people less than struggle.

Here, tools like arduino present an attractive alternative. They have dumbed down the chips so much that pretty much anyone can use it.

I'm actually surprised that no OEM has taken the approach that 8051 ipcore vendors have some: they provide turn-key solutions that comes with a single purpose ide, libraries that perform 99 PCT of the targeted applications, and reference hardware designs.

This approach would have totally isolated the designer from the hardware.

Personally, going to a full blown OS like Linux is an overkill. A much simpler OS or heavy encapsulation would work.

[Kjelt]

Well the reason I said that is that no company with a right mindset will sell internet connected devices without an (online updatable) security suite.
If you look at the requirements and footprints of such security solutions a lot of microcontrollers (incl. cortex m3 imo) are out of their league.

Be aware that last year was a breakthrough year where in the US companies were pursued by the FTC because their devices lacked basic security mechanisms (see attachment)
Very interestng developments

[Dielectric]

Sometimes you can put an instruction or two right in the vector table instead of actually incurring a call.  If all you need is a flag, then an OR opcode on a reg or a byte of RAM is all you need.  I've done it and made double-sure to document that change.

Maybe that worked for earlier ARM processors (haven't tried it myself), but the Cortex-M treats the vector table as a bunch of 32-bit addresses--no opcodes. One of the benefits of the architecture is that the hardware stacks some registers automatically on an exception entry, so there's less need/opportunity to play those kinds of tricks.

Yeah, this is on older 8-bit machines (like a PSoC M8C), I don't even know how I'd attempt it on an ARM.  Actually, I wouldn't try it on ARM because the interrupt controller is too spiffy.  If I thought I needed that kind of optimization, I'd reconsider my assumptions because I'm probably doing something wrong.   

[Sal Ammoniac]

But I think the maker movement is more a result of low prices rather than a driver of low prices.

And the maker market is so totally insignificant compared to the general market that it's lost in the noise as far as the manufacturers are concerned.

[nctnico]

But I think the maker movement is more a result of low prices rather than a driver of low prices.

And the maker market is so totally insignificant compared to the general market that it's lost in the noise as far as the manufacturers are concerned.

I wouldn't be so sure about that. A manufacturer needs both high volume clients and a large user base to be succesful. The first to sell in quantities the second to create chances to get into high volume designs.