What µC are you preffering

[crayon]

That would depend on the ECU you want to develop, and again, the specific problem you want to solve. There are ECU specific microcontrollers designed to satisfy common industry use cases, eg. instrument clusters, pcm, bcm, hvac....

[ogden]

Similarly, what if FPGAs costs come down and they become cheaper than today's 32-bit MCUs. What if they become smaller, will consume less power and will have built-in flash. Suddenly, it doesn't sound stupid anymore, right?

"What if" hope that FPGA capable of running 32-bit soft core MCU will become cheaper than same 32-bit MCU implemented in ASIC, will consume less - sounds insanely stupid. It will never happen. Period. Just stop dreaming and *actually* implement something using FPGA

[Bassman59]

Similarly, what if FPGAs costs come down and they become cheaper than today's 32-bit MCUs. What if they become smaller, will consume less power and will have built-in flash. Suddenly, it doesn't sound stupid anymore, right?

"What if" hope that FPGA capable of running 32-bit soft core MCU will become cheaper than same 32-bit MCU implemented in ASIC, will consume less - sounds insanely stupid. It will never happen. Period. Just stop dreaming and *actually* implement something using FPGA

Or, you could actually choose the device which makes the most sense for the design. You probably don't want to do a USB device stack (after the serial interface engine, anyway) in an FPGA, nor an Ethernet interface. And you can't directly interface 32 channels of LVDS/DDR serial high-speed ADCs to a microprocessor.

But you can use a processor bus interface to connect the two.

-----------

Sometimes the non-obvious approach works. For the hell of it, I built a nice audio ADC/DAC. It has an SRC4392 that implements the S/PDIF interfaces and does SRC for the DAC side. I used an SiLabs clock synthesizer chip for the clocking (mainly to see if it would work for audio, and yay, it works great). The SRC, the clock and the converters all have I2C and/or SPI interfaces for configuration. Cool! I'll pick a micro that has the interfaces and it'll be easy.

And it was. Until I decided I wanted to add Dorrough-style input metering to the ADC side. Sure, the micro has its own ADC of more-than-adequate resolution and sample rate (12 bits at 100 kHz or whatever is more than enough for metering) and it can do the averaging and generate peak hold and all of that. OK, time to drive LEDs. How many GPIO do I have left over? Or should I do it serially and go SPI out to HC595s or to dedicated LED drivers or what? What costs the least?

But wait! The design is an ADC. Why not just spy on the I2S port from the ADC and connect it to the micro as well as the SRC? Oh, great! Lots of ARMs have synchronous serial ports that can be configured to do I2S! This will be easy! Except ... when I looked closely I saw that were limits on the rate of the I2S bit clock when the micro's port is run in slave mode? Nothing I found supported I2S bit clocks of 12.288 MHz in slave mode. (This was a couple of years ago, I'm sure now there is something that can do this now.) So no 192 kHz sampling capability. Phooey.

So I looked at doing the whole thing in an FPGA. Multiple SPI and I2C ports for configuring the devices? Check. ROM lookup tables for those configurations? Check. Implement I2S slave and doing the math for meter averaging and peak detect? Check. A bit of logic to determine the frequency of an input word clock, to which the clock chip syncs, and use that to set up the clock chip for correct operation with that frequency? Check. Enough I/O pins for multiplexed LED drive for the metering? Check.

Cheaper than a microcontroller? Actually, check -- I did it with a Lattice MachXO2-1200.

Of course now I want to eliminate the $17 SRC4392 and do the S/PDIF interface and the SRC in an FPGA.

And I also want to add USB. So, back to the micro and the FPGA together. Or an XMOS part.

[ogden]

"What if" hope that FPGA capable of running 32-bit soft core MCU will become cheaper than same 32-bit MCU implemented in ASIC, will consume less - sounds insanely stupid. It will never happen. Period. Just stop dreaming and *actually* implement something using FPGA

Or, you could actually choose the device which makes the most sense for the design.

Yes indeed. Many or I would say most designs /w FPGA have some host and/or service CPU as separate IC or soft core. My argument was against "FPGA in place of MCU just for better I/O pin mapping", and only. Price/consumption comparison was between ARM MCU like STM32L072 and FPGA which can run said MCU soft core with all the peripherals. FPGA vs CPU/MCU is recurring topic here.

[Bassman59]

"What if" hope that FPGA capable of running 32-bit soft core MCU will become cheaper than same 32-bit MCU implemented in ASIC, will consume less - sounds insanely stupid. It will never happen. Period. Just stop dreaming and *actually* implement something using FPGA

Or, you could actually choose the device which makes the most sense for the design.

Yes indeed. Many or I would say most designs /w FPGA have some host and/or service CPU as separate IC or soft core. My argument was against "FPGA in place of MCU just for better I/O pin mapping", and only.

Yeah, that makes no sense at all.

[psysc0rpi0n]

Hello.

I just started to learn about ARM microcontrollers/microprocessors and using openOCD to load code and eventually debugging in the future. I'm just taking the first steps at all. I don't know how openOCD works nor ever seen an ARM datahsheet at all.

I bought a Chinese clone of a Discovery board with an STM32F407VET6 chip. OpenOCD do not see it as a Discovery board but as a standalone SMT32F4x chip.
I'm actually reading on the main subjects of openOCD manual/documentation. Then, I'll take a survey on the chip reference manual and datasheet. I'm using a Jlink device (also a Chinese clone) to talk to the board using a mode called SWD. I see this as a simpler JTAG approach as it uses this jlink device but it don't use all JTAG pins.

The thing is that I think I'm not mature enough to stick to something until the end. I used AtMega328p in the past, and did a few thing with it. I just learnt the very basics I guess. Then I won a dev board in some contest I participated in and I had a project in mind for it but couldn't make it happen. I ended up leaving it aside as I got interest in other things in the meantime. It was a Microchip IoT dev board with some google cloud shit and a wireless communication antenna and also an on-chip debugger. The chip taking care of all the peripherals was an AtMega4808.

Now I'm on this ARM thing. Let's see for how long!

[brucehoult]

Hey, sounds like fun! Have you got a helloWorld or blinky going?

I think OpenOCD can work in quite different ways on different systems. On the board I use most it works together with gdb to use JTAG over USB to download a small program into RAM on the MCU, which is then used to do self-programming of the flash. it's a lot of different stuff tied together with gaffer tape!

[ogden]

Now I'm on this ARM thing. Let's see for how long!

For quite long. Beauty of ARM "ecosystem" is that you are fully covered from simple & low cost chips up-to hi-performing "embedded monsters" with single set of software/hardware tools and knowledge (of CPU architecture). Yes, you need to know peripherals of particular MCU, but at least you don't have to bend your mind and learn completely different CPU and IDE and compiler as you did when migrated between AVR and PIC. No matter you use STM32F0 < 1$ low cost generic MCU or STM32H7 "monster", you basically are fine with same tools and knowledge. Same apply for other ARM MCU manufacturers - Microchip, NXP and so on.

[NorthGuy]

Now I'm on this ARM thing. Let's see for how long!

For quite long. Beauty of ARM "ecosystem" is that you are fully covered from simple & low cost chips up-to hi-performing "embedded monsters" with single set of software/hardware tools and knowledge (of CPU architecture).

Yeah, but then there are variations, such as Thumb2. And then there's Aarch64 which is quite a bit different from 32-bit ARMs, and who knows what's next.

[ogden]

For quite long. Beauty of ARM "ecosystem" is that you are fully covered from simple & low cost chips up-to hi-performing "embedded monsters" with single set of software/hardware tools and knowledge (of CPU architecture).

Yeah, but then there are variations, such as Thumb2. And then there's Aarch64 which is quite a bit different from 32-bit ARMs, and who knows what's next.

Yes, you need to know be informed about both 32bit and Thumb opcodes, yet I am not sure Aarch64 will be ever used in µC which BTW is main subject here (check Subject if in doubt).

[NorthGuy]

Yes, you need to know be informed about both 32bit and Thumb opcodes, yet I am not sure Aarch64 will be ever used in µC which BTW is main subject here (check Subject if in doubt).

You can never predict the future ... but if you  had an MCU with A53 core, would you have difficulties using Aarch64 because it has different "opcodes" than 32-bit ARM architectures?

[ogden]

if you  had an MCU with A53 core, would you have difficulties using Aarch64 because it has different "opcodes" than 32-bit ARM architectures?

I would have no problems of using ARM MCU with "other kind" of opcodes if needed, especially when I do not have to invest significant additional money in tooling. That BTW was my main point in post about ARM "ecosystem".

[NorthGuy]

I would have no problems of using ARM MCU with "other kind" of opcodes if needed, especially when I do not have to invest significant additional money in tooling. That BTW was my main point in post about ARM "ecosystem".

Would you then have problems using an MCU which uses a different architecture, such as MIPS (used in PIC32) or RISC-V?

They both are supported very well by GCC. I think MIPS has been supported by GCC long before ARM, so it is very mature. RISC-V is excellent ISA without pre-historic overhead and is also supported by GCC. And it's all free and open source - no money to pay at all.

[ogden]

Would you then have problems using an MCU which uses a different architecture, such as MIPS (used in PIC32) or RISC-V?

They both are supported very well by GCC. I think MIPS has been supported by GCC long before ARM, so it is very mature. RISC-V is excellent ISA without pre-historic overhead and is also supported by GCC. And it's all free and open source - no money to pay at all.

It depends. You consider me hobbyist doing one piece of hardware per month at best or decision maker of commercial entity doing thousands or more (per month)?

[NorthGuy]

Would you then have problems using an MCU which uses a different architecture, such as MIPS (used in PIC32) or RISC-V?

They both are supported very well by GCC. I think MIPS has been supported by GCC long before ARM, so it is very mature. RISC-V is excellent ISA without pre-historic overhead and is also supported by GCC. And it's all free and open source - no money to pay at all.

It depends. You consider me hobbyist doing one piece of hardware per month at best or decision maker of commercial entity doing thousands or more (per month)?

I consider you a forum participant who introduced the concept of "ARM ecosystem" and I'm trying to understand what stands behind the concept (if anything). Therefore, I'm interested to know if you feel like you would have difficulties working with similar non-ARM CPUs. I have selected two RISC CPUs as an example of similar CPUs from outside the "ARM ecosystem".

I'm certainly interested on engineering (as opposed bureaucratic) viewpoint.

[brucehoult]

For quite long. Beauty of ARM "ecosystem" is that you are fully covered from simple & low cost chips up-to hi-performing "embedded monsters" with single set of software/hardware tools and knowledge (of CPU architecture).

Yeah, but then there are variations, such as Thumb2. And then there's Aarch64 which is quite a bit different from 32-bit ARMs, and who knows what's next.

Yes, you need to know be informed about both 32bit and Thumb opcodes, yet I am not sure Aarch64 will be ever used in µC which BTW is main subject here (check Subject if in doubt).

There are a ton of 64 bit RISC-V microcontrollers being used. Being 64 bit isn't an obstacle and in fact is often highly desirable especially if the rest of the chip needs 64 bit addressing. The big issue with Aarch64 is that there are no subsets defined, it's all or nothing. RV64I is a 64 bit CPU, but still tiny.

My pick is ARMv9 is going to introduce 1) one or more subsets of Aarch64, and 2) a completely new instruction encoding for Aarch64 with both 16 and 32 bit opcodes, similar to A32 and T32.

You heard it here first.

(but I've been saying it for a while)

[ogden]

Therefore, I'm interested to know if you feel like you would have difficulties working with similar non-ARM CPUs.

I personally will be fine with "non-ARM" core - if needed for some strange reason. As I ignore various cults like "best CPU architecture ever" or "X MCU is few percent cheaper than Y MCU", I just stick with ARM MCU, STM32 to be specific. That series cover my needs well. There are plenty of stuff for ARM around, including optimized libraries and what not. That "plenty of stuff" can be considered "ecosystem"

When we talk about small/medium business - then many other considerations come into play. Apart from pure MCU hardware/peripheral considerations, volume contracts you preferably sign with only one MCU manufacturer, there are other stuff like RTOS, 3rd party IP (libraries/stacks), capabilities of your developers and manufacturing house and so on. Sometimes you look at multidimensional matrix of variables and not always MCU of potential choice is what you or your developers like. What's worse - often preferences of EE department, SW department and business unit do not match.

[NorthGuy]

Therefore, I'm interested to know if you feel like you would have difficulties working with similar non-ARM CPUs.

I personally will be fine with "non-ARM" core - if needed for some strange reason. As I ignore various cults like "best CPU architecture ever" or "X MCU is few percent cheaper than Y MCU", I just stick with ARM MCU, STM32 to be specific. That series cover my needs well. There are plenty of stuff for ARM around, including optimized libraries and what not. That "plenty of stuff" can be considered "ecosystem"

I see. There's plenty of stuff for everything. And getting more. There's no reason to single ARM out into its own ecosystem on that basis.

[psysc0rpi0n]

Hey, sounds like fun! Have you got a helloWorld or blinky going?

I think OpenOCD can work in quite different ways on different systems. On the board I use most it works together with gdb to use JTAG over USB to download a small program into RAM on the MCU, which is then used to do self-programming of the flash. it's a lot of different stuff tied together with gaffer tape!

Hello.

Long discussing going on. I'm a bit out of it as I cannot discuss much about it.

About your question, yes, I made a blinky program working on it, but it was a ready-to-use source file that I just compiled with an also ready-to-use Makefile. I found an whole set of ready-to-use source files in github. I used them just to learn how OpenOCD works and also dfu-utils. I never worked with any of these tools.

But, just for the record, I have no prior experience. I'm just a mid age person that completed graduation in Electrical Engineering (Electronics and Telecommunications) in early 2018 and I developed an interest (and a passion, I guess) for electronics and programming, but NEVER worked on this area/field so I have only academic knowledge which is very limited so I struggle many times with real-world basic situations that were ignored in school, so we got no intuition whatsoever about real world scenarios. That is my complaint and regret for the unfortunate I was by not discovering this world years ago.

Anyways, I'm always trying to learn about new things but in the case of ARM, it was quite a big change because changed the architecture, changed the tools (avrdude mostly for AVR), changed registers, amount of things that needs to be configured, etc, etc.

And a reference manual of an ARM is like 1700 pages. AVR's (at least the one I was reading) was about 400.

Another thing I regret about myself is that I usually start something and then I just can't stick to it until the en. I think, in this field, my mind is very immature. I have at least 2 things, plus now the ARM chip, laying around doing nothing. On of them, I never tried it before, which was a small board I bought from china to try to listen/sniff/whatever Li-Ion battery controllers. The other one is a Mivrochip dev board called somethin like AVR IoT WG which comprises an AtMEga4808, some Google Cloud shit, a Wireless antenna, on-chip debugger , some security/cryptography/encryption feature and a couple of on-chip/built-in sensors. I started to explore this board but also dumped it after some time. I even had a small project to it but I lost interest, probably because to be able to use all these features all at once, a few thousands of lines of code were needed and it was a little bit of a daunting task to learn like 3000 lines of code just to read temp and light and send that info to some Google Cloud server and show it in some web page. I guess I lost the interest because of that huge amount of code.

Anyways, I always try to learn new things. I hope I can stick longer to ARM chips!

[ogden]

There's no reason to single ARM out into its own ecosystem on that basis.

Yes indeed. There is no reason for family sedan, "car of the year" to be the coice of transportation for everything. Yet when random & clueless people are seeking for means of transportation you usually suggest them what? - Car of the year.

[brucehoult]

Hey, sounds like fun! Have you got a helloWorld or blinky going?

About your question, yes, I made a blinky program working on it, but it was a ready-to-use source file that I just compiled with an also ready-to-use Makefile. I found an whole set of ready-to-use source files in github. I used them just to learn how OpenOCD works and also dfu-utils. I never worked with any of these tools.

I think it's fair to say that most people working with microcontrollers don't actually have much idea exactly how tools such as avrdude or openocd operate. Once they have an example blinky project that works they will just incrementally modify that to do what they need.

Of course curiosity is great and you should learn whatever you want to, but if the goal is to complete some useful project using a microcontroller then studying the internals of openocd is an unnecessary distraction, just as learning all the details of exactly how gcc works would be.

The same goes for using a HAL (Hardware Abstraction Layer), whether manufacturer-supplied or something like the much maligned Arduino libraries, rather than learning and programming the machine registers directly. Of course for unusual needs sometimes there is no choice, but often it's fine to take a higher level approach. Especially on a higher-performance CPU.

[brucehoult]

There's no reason to single ARM out into its own ecosystem on that basis.

Yes indeed. There is no reason for family sedan, "car of the year" to be the coice of transportation for everything. Yet when random & clueless people are seeking for means of transportation you usually suggest them what? - Car of the year.

OMG. I would probably *never* recommend a clueless person to buy the "car of the year" chosen by some journalist or group of journalists. Instead I'd recommend they get something super boring and reliable e.g. a Toyota or if the person often drives on bad or mountainous roads or in "real" winter conditions, Toyota's 20% owned subsidiary, Subaru.

Since this is an Aussie-based site, lets look at the Wheels COTY winners:

2019: Volvo XC40
2018: Volvo XC60
2017: Mazda CX-9
2016: Mazda MX-5
2015: -
2014: BMW i3
2013: VW Golf VII
2012: Toyota 86 / Subaru BRZ
2011: Honda CRZ
2010: VW Polo

This list leans heavily towards expensive (and unreliable and poorly supported in Australia) European cars and sports cars. The clueless should be buying neither of those!

The only thing on that list I'd suggest a random person consider is the CX-9, and even there it is more sporty and less practical and more expensive than excellent competitors from Toyota, Subaru, Honda, Kia, Hyundai.

[westfw]

There's no reason to single ARM out into its own ecosystem on that basis.

ARM (especially the Cortex M series) seem to have better-than-average debugging support/documentation/etc.A lot of chips seem to leave debugging to proprietary interfaces (Atmel AVR is particularly guilty :-( (but getting better?))  And wasn't it some of the RISC-V chips that were "it has JTAG, but you'll need a new debug probe to actually do debugging.")
OTOH, ARM seems weak in the simulation department.

[ogden]

OMG. I would probably *never* recommend a clueless person to buy the "car of the year".

LOL. You must be kidding? I did mean it figuratively. Please do not derail this discussion into pointless  about actual cars.

[brucehoult]

There's no reason to single ARM out into its own ecosystem on that basis.

ARM (especially the Cortex M series) seem to have better-than-average debugging support/documentation/etc.A lot of chips seem to leave debugging to proprietary interfaces (Atmel AVR is particularly guilty :-( (but getting better?))  And wasn't it some of the RISC-V chips that were "it has JTAG, but you'll need a new debug probe to actually do debugging.")
OTOH, ARM seems weak in the simulation department.

Since much of the debugging functionality of a "JTAG probe" depends on halting the user program, downloading a very short bit of native code into a small special memory area (perhaps 16 bytes), and running it -- yes, the JTAG probe (if "smart") or the software that drives it (if "dumb") needs to understand the ISA of the chip.

SiFive chips (and FPGA bitstreams of them) work fine with a bog standard and cheap Olimex ARM-USB-TINY-H, which I take it means it is a "dumb" JTAG and not actually ARM-specific at all.

SEGGER and Lauterbach have provided explicit support for RISC-V for several years now.