MCU of choice for production? - Page 1
Forum section: electronics / general

author: mrburnzie
author_rank: Regular Contributor
timestamp: September 27, 2019, 10:17:17 pm
content: Hi!By your judgment what is the best controller to use for production (5k-10k boards) (STM32, STM8, AVR, PIC ect.)The project is not very special, it doesn't require high speed, special peripherals. It uses the MCU to get the info from the sensors and forward it via a wireless protocol.I'm mostly interested in easily accessible, stable (tested) and of course cheap MCUs.Best regards!

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 27, 2019, 10:30:24 pm
content: You could see if your 'wireless protocol' handler can do everything ?Otherwise, if you just need Sensor to Serial, then select the MCU based on ADC and possibly DAC performance.DACs can help trim sensors and give a self test path.Most new MCUs spec 12b ADC, and some have 14b ADC, so you may want to focus on what you really need.Notice the core has not been mentioned at all yet ?That's because core is a 'don't care' these days, and other factors often dictate what you use.Cheapest small MCU with 12b DACs I think is the EFM8BB3, and the EFM8LB1 gives 14b ADC and 12b DAC for not much more.

author: nctnico
author_rank: Super Contributor
timestamp: September 28, 2019, 12:13:48 am
content: Quote from: mrburnzie on September 27, 2019, 10:17:17 pmI'd use something modern with an ARM core. Even at 5k to 10k boards the engineering costs will be a large chunk of the money invested. A good place to start is to choose an MCU which has pin-compatible versions with various amounts of memory. That way you can develop on the device with the most memory and then go for a smaller device. The same goes for the clock frequency (if power is a concern); start high and reduce if necessary. The worst situation to get into is having hardware designed & ready with a microcontroller which isn't up to the task. Starting by choosing the cheapest possible part(s) is the start of the road towards that worst situation. Cost = hardware development time + software development time. Unfortunately the latter is too often grossly underestimated.Also look at how to program & update the firmware. A serial (UART) bootloader can be very handy because everyone can deal with connecting a serial port and start a program. A JTAG dongle is less handy (and probably more expensive) to use.

author: techman-001
author_rank: Frequent Contributor
timestamp: September 28, 2019, 12:51:29 am
content: Quote from: mrburnzie on September 27, 2019, 10:17:17 pmG'day!More information would help, such as :Number of data bits ?voltage range of GPIOs, 5v, 3.3v ?Operating voltage range of MCU ?inbuilt wireless peripheral or not ?very low power consumption for battery operation or not ?wide family of compatible architectures is important or not ?Surface mount package or not ?Dip package or not ?Tiny package or not ?inbuilt serial bootloader for flashing the memory or not ?SWD or JTAG pins for flashing memory and debugging or not ?

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 28, 2019, 12:59:58 am
content: Just an additional note - what kind of wireless link are you going to use?If it's bluetooth/BLE/or even custom protocols @2.4GHz, there are MCUs that embed all the RF controller, so that's just one chip and a few additional passive components. Certainly something to consider for simplicity's and cost's sake (and often power consumption). If you're interested in that, we can suggest a few references.If it's WIFI, you also have integrated solutions, such as the ESP32. Of course, WIFI is a lot more power-hungry, so take that into account if you still have a choice.

author: richardman
author_rank: Frequent Contributor
timestamp: September 28, 2019, 02:32:07 am
content: I am a big fan of the STM32F0x0 series. They can be have for as low as under $1 with low cost dev boards etc.

author: schmitt trigger
author_rank: Super Contributor
timestamp: September 28, 2019, 02:51:16 am
content: The sensors in the board, how do they communicate? Analog, I2C, SPI, One Wire, other?

author: mrburnzie
author_rank: Regular Contributor
timestamp: September 28, 2019, 08:39:46 am
content: Quote from: techman-001 on September 28, 2019, 12:51:29 amThanks for the questions, I will answer these because it covers other peoples questions tooNumber of data bits - 8 is more than enoughvoltage range of GPIOs, 5v, 3.3v - 3.3VOperating voltage range of MCU - 3.7 - 2.7inbuilt wireless peripheral or not - novery low power consumption for battery operation or not - yeswide family of compatible architectures is important or not - not very important, but a thing to look out forSurface mount package or not - yesDip package or not - noTiny package or not - yes (32-48 TQFP is small enough)inbuilt serial bootloader for flashing the memory or not - can be, but not a necessary thingSWD or JTAG pins for flashing memory and debugging or not - SWD, but no problems with JTAG tooWireless is LoRa (sx1276) and connected via SPI.My main goal here is to achieve low power as much as possible.

author: MosherIV
author_rank: Super Contributor
timestamp: September 28, 2019, 09:12:48 am
content: Hi.Why has the cheif engineer not made the decission?There are a number of factors to look at in this order1 Cost of parts1 Development time or project launch date2 Availability of parts3 Familiarity of micro (affects development time)4 Suitability of micro (sounds strange but the other factors usually wittle the choice down to a few to choose from)5 cost of development toolsThe project needs to decide if cost or development time is more important. Volume may dictate eg 100K will usually mean parts cost is most important but can afford a long development time to squeeze as much functionality as you can into a very cheap (cheap micros are very resource limited).Sometimes launch date is most important because marketing have announced a product launch dateIn this case, development time is most important. May even have decided to allow loss leader on launch and do cost reduction post launch.It is really down to project priorities.Hope this helps.

author: ogden
author_rank: Super Contributor
timestamp: September 28, 2019, 09:32:25 am
content: Such question is relevant only when you are starting in empty place. Otherwise skills of your developer(s), existing development tools/software and even manufacturer's capabilities (jtag scanners, gang programmers) shall be factored in, it may even be deciding factor. Only then comes learning curve, cost of devtools and so on. Well.. maybe not for simple lora sensor, but anyway. Let us know - it is first commercial project of 1-man startup or you work for established electronics company.

author: Psi
author_rank: Super Contributor
timestamp: September 28, 2019, 09:39:38 am
content: Maybe look at those 3-10cent OTP Padauk MCUs.If you can get your BOM cost down from $1 per mcu to 10c per mcu you save 90c per unit, 90c x 10000 units = $9000

author: nctnico
author_rank: Super Contributor
timestamp: September 28, 2019, 11:26:25 pm
content: Quote from: Psi on September 28, 2019, 09:39:38 amEven a small software team will burn through that amount of money in a week (note that employees cost more than just their salaries).

author: james_s
author_rank: Super Contributor
timestamp: September 28, 2019, 11:33:19 pm
content: Are you (or whoever is developing the hardware) familiar with any particular family of uC? If so then look at what's available in that family. If starting from zero I'd probably look at the STM32 family but it really depends.

author: splin
author_rank: Frequent Contributor
timestamp: September 29, 2019, 12:32:36 am
content: At or very near the top of the list *for me* is the availability of a good in circuit debugger for which ARMs are hard to beat. There are many here who don't subscribe to this point of view, who prefer to do most debugging and testing using printf's and toggling spare I/O pins but that doesn't work if your processor crashes due to hardware problems or software errors including stack overwrites, memory corruption through pointer errors, nested interrupt race conditions, hardware clock configuration errors etc.A decent ICE isn't a silver bullet but I find them invaluable - including for single stepping through code generated by a configuration tool such as ST's CubeMX to learn how it works and to clarify the processor's documentation which aren't always completely unambiguous.Getting to a point where your software detects there is a problem - eg. a bad parameter passed into a function, memory protection error handler beinging invoked, it can be very helpful to be able to look at an instruction or stack trace to see how you got there and give you a clue where to look. Also to dump a block of memory to see if it has expected values etc. etc.Continuously adding printf's to your code, rebuilding and downloading can be tedious, time consuming and may change the behaviour of your code by changing memory layouts, timing, stack usage and so on. Once your code is reasonably stable this becomes more useful, but in the early stages when the hardware isn't known to be reliable or you aren't sure your initialization code is correct, I find a good debugger to be very helpful.A good debugger can be a great timesaver when tuning code - eg. by tweaking a timer value or a PID constant and continuing execution to see how the behaviour changes, again without having to go through build/download cycles for something you might be doing hundreds of times.ARM Cortex based devices have very good debugging built in, especially if they have the instruction trace units. The hardware debugging tools can also be virtually free - eg. the STLink included in ST evaluation boards and similar from other manufacturers. Debuggers that support the high speed interface needed for instruction tracing are more expensive (Segger do one) but not excessively so for commercial development and a nice option to have should the need arise.I don't know any 8 or 16 bit cores with good debuggers because they really need to be built into the silicon in the form of hardware instruction and memory address breakpoint registers. Many debuggers use software breakpoint instructions to force vectoring to a software debug routine which then interacts with the debugger using a communication channel such as a serial port. That's OK up to a point but requires the processor to carry on running properly - what if the debuger routine's data or the stack pointer has been corrupted? Software breakpoints also adds wear to the FLASH although this should be much less of a problem these days.ATMEL provide ICEs for many of their 8 bit cores but they have a reputation of being rather flakey, expensive (compared to ARM SWD debuggers) and obsoleted periodically. I don't know about Microchip's tools except that Dave had a few 'problems' with the PICKIT 3! Hopefully they have better tools for the 32 bit PICs. Be wary of vendors who seem to have different ICEs/debuggers for just about every family of products which could make it difficult or expensive to change to a better or cheaper device during development.One option is to develop on a more expensive device because it supports a better debugger (such as instruction trace) and/or has lots more RAM to store your own debug code output such as software traceng data (eg. a printf into a memory buffer at the start and end of critical functions naming the function and printing calling parameters and the stack pointer). A much faster device is also helpful to offset the impact of your debug/test code and allowing you to run unoptimized code - optimizers can introduce horrible bugs or cause bizzare behaviour when your code is not strictly legal (eg. has undefined behaviour). Better to get it running reasonably well first and then get the optimized code to work properly if you need to.When it works well, use a lessor device for production. This stratgey works better for vendors such as NXP who have a better reputation for maintaining backward compatability of their peripheral devices (in the LPC range) - unlike ST where the peripherals change considerably between families - such as STM32F1 to F2, F3 and F4, probably down to different design teams.

author: westfw
author_rank: Super Contributor
timestamp: September 29, 2019, 08:34:13 am
content: QuoteClearly you need a new Cortex-M33 with built-in BTLE support, Crypto acceleration, secure key management, memory protection, and TrustZone(tm), with good Ada support.It would be unthinkable in today's world to build a device with wireless communications that didn't have "excellent security."(that was sarcasm. In particular, the "built in IoT" seems to result in a lot of chips/modules with short market lifetimes (Simblee, Intel Curie, etc.) :-( You'd be much better off separating the radio module from the sensor handling with some standard-ish interface. Probably. But then you need to pick two vendors...)

author: peter-h
author_rank: Super Contributor
timestamp: September 29, 2019, 08:47:54 am
content: I would go for an "old" company.Looking at my CPU usage since c. 1980... I see Hitachi run theirs for some 25 years (H8/332), Atmel (AVR) discontinuing each chip at about the time I got around to designing it in to replace the one which I was on a "last time buy" (so we would not use Atmel for a CPU again), and now we are going with an ST 32F4xx which should have a decent production life. The 32F series comes in a huge range of variants with every imaginable range of peripherals and is very cheap. Free development tools and a €25 JTAG programmer.

author: techman-001
author_rank: Frequent Contributor
timestamp: September 29, 2019, 08:48:49 am
content: Quote from: splin on September 29, 2019, 12:32:36 amI think you have a lot of real world experience and I agree with everything you wrote here.I myself won't touch any MCU without extensive debugging facilities set up and working and Cortex-M freely meets my every debugging requirement.Regarding backward compatibility, that's a two edged sword don't you think ? For instance if STM had stuck with the STM32F103 usart then the F0 series couldn't do autobaud, the USB peripheral would require a Xtal and so on.

author: techman-001
author_rank: Frequent Contributor
timestamp: September 29, 2019, 08:52:50 am
content: Quote from: peter-h on September 29, 2019, 08:47:54 amDo you really need a (€25) TAG programmer for your particular use ?I use a STM32 Disco or Nucleo for SWD programming or debugging with OpenOCD and that's free with the board itself.

author: MosherIV
author_rank: Super Contributor
timestamp: September 29, 2019, 11:00:49 am
content: As Splin said, for commercial development, the cost of development equipment is less of an issue. A few hundred dollars/pounds/euros is trivial for a company. So getting Segger JLink or ST Link is not going to cause the bean counter to think about it, getting a Lauterbach - that will get some raised eye brows.Can I point out the ICE (in circuit emulator) no longer exist, not for ARM processors. SWD is a type of JTag. Both use a mixture of hardware and softwar (isr) to acheive break points, reading registers or memory etc.For commercial development, having a debugger is essential. All the techiques mentioned can be used, it depends on what you are trying to do. Use the bit toggling to check real time performance of a function or task. Use printf through uart to get lots and lots of variable values, can use this techique to trace program flow in complex system.Now a days a lot of work is done up front on host development machines with Test Driven Deveopment. Where everything is written and tested before it reaches the target hardware. The final target hardware testing is then just to make sure it all works together.

author: nctnico
author_rank: Super Contributor
timestamp: September 29, 2019, 11:52:39 am
content: Quote from: splin on September 29, 2019, 12:32:36 amThere is a much better way: have a serial port with a command line interface (CLI). Have it password protected if you want. This will allow to query the software for the status and enable / disable debugging. To me this has proven to be invaluable to find problems when a board is installed in the field. A JTAG dongle will be utterly useless to do problem solving in the field. My firmware usually collects some statistics too. Like failed attempts, number of interrupts, number of characters sent/received, etc.Personally I'm not sold on doing too much in-circuit debugging. Stepping through code can only work for non-realtime stuff. Besides that stepping through code works better on a PC and iterations between builds are much shorter. Therefore I test most code on a PC first (which also allows to throw all kinds of weird scenarios at the code to test it thourouhgly).ARM processors also have exception interrupts. Have these dump a stack trace over the serial port so you can trace back where the problem is at.

author: Psi
author_rank: Super Contributor
timestamp: September 29, 2019, 12:08:35 pm
content: Quote from: nctnico on September 28, 2019, 11:26:25 pmTrue, but i got the feeling from the OP that he was doing a self employed project by himself.Just had that feel to it.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 29, 2019, 03:28:48 pm
content: Quote from: Psi on September 29, 2019, 12:08:35 pmWhich if that's true, is even more a good reason to stay away from ultra-cheap parts that are certainly not as easy to use as the more common ones and have weird limitations.They are "interesting" to fiddle with probably, but not to develop a product IMO, unless you will ship 100,000+ of them...

author: nctnico
author_rank: Super Contributor
timestamp: September 29, 2019, 04:38:47 pm
content: Quote from: SiliconWizard on September 29, 2019, 03:28:48 pmAgreed on that. Perhaps going for a more expensive part from a more conservative manufacturer (NXP for example) may be something to consider to reduce the risk you get bitten by some funky behaviour. Part of the selection of a part should involve risk assesment. If I use a certain part, then how much does it attribute to the risk of having to recall & replace a significant number of units?

author: westfw
author_rank: Super Contributor
timestamp: September 29, 2019, 06:53:17 pm
content: QuoteWhen is SWD/CMSIS-DAP with a generic ARM debugger sufficient, and when do you need a debugger customized to the particular chip you're using? When does trace become important?

author: techman-001
author_rank: Frequent Contributor
timestamp: September 30, 2019, 01:35:09 am
content: Quote from: westfw on September 29, 2019, 06:53:17 pmMy needs are pretty simple, if I need to debug Assembly Language then I use GDB with OpenOCD via USB on a ST Discovery or Nucleo board (SWD programmer section) to single step thru the code on a MCU.I've never used a custom debugger or "trace" myself.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 30, 2019, 04:32:31 pm
content: Quote from: techman-001 on September 30, 2019, 01:35:09 amNote that you can use OpenOCD with ANY of the supported interfaces (and it supports a lot of them) and CPUs, so you can perfectly use this solution on any custom board, not just pre-made dev boards.

author: ttt
author_rank: Regular Contributor
timestamp: September 30, 2019, 06:51:23 pm
content: Quote from: mrburnzie on September 28, 2019, 08:39:46 amSince you are doing some networking, any idea how large/small the code size will be? How much RAM do you think you will be using? As some guidance if you for instance include a TCP/IP stack count at least 50KB of code + 30KB RAM usage. If you can fit everything into under 16KB Flash + 2KB RAM for instance a low power optimized Cortex-M0(+) is the way to go. Example: STM32L011D4P6 on lcsc.com for $0.70 a piece.That said I am personally more and more drawn towards STM32s, entire range. SWD debugging works quite well with the relatively cheap ST-Link. The dev tools are less painful than others and you can go full open source stack if you need to. Olimex makes great prototype boards for STM32s. They are not the cheapest but more geared towards real dev work.GigaDevice makes STM32 clones which are incredibly cheap. We are talking $1 for a GD32F103C8T6 (Cortex-M3) and <$0.50 for a GD32F130G8U6 (QFN28 package, not quite a clone) for instance. Available on lcsc.com. I would almost count them as a second source, at least for the Cortex-M3 parts.

author: techman-001
author_rank: Frequent Contributor
timestamp: October 01, 2019, 12:40:18 am
content: Quote from: SiliconWizard on September 30, 2019, 04:32:31 pmQuite right, for debugging with GDB I just use the SWD section of a STM32 Disco or Nucleo board and connect it to the MCU in my own custom pcb's using the SWD headers provided on those boards. Other people use Chinese USB/SWD dongles that cost a couple of $.But I mainly use the inbult serial bootloader for flashing STM32's.

author: westfw
author_rank: Super Contributor
timestamp: October 01, 2019, 01:57:54 am
content: Just out of curiosity, what's the debugging environment for Forth look like?I noticed in the UTexas Microcontroller MOOC that the state-machine assignment was particularly annoying to debug (with Keil: a traditional and well-respected C-level debugger) because a statement like:Code:state = statetable;contained so much concurrent indirection. Yeah, you could break it up and have an easier time of it, if the optimized didn't sabotage it.But I'd exepct Forth to have similar problems, without a debugger specifically designed to deal with it.

author: techman-001
author_rank: Frequent Contributor
timestamp: October 01, 2019, 03:17:52 am
content: Quote from: westfw on October 01, 2019, 01:57:54 amIt's a bit like this; "once you've seen one Forth debugging environment .... then you've seen one Forth debugging environment"Everything in Forth revolves around the Stack, so my debugging is all Stack related. The Forth debugger is a Word that examines the Stack called ".s" and read as "print Stack".I always examine the Stack after testing every new Word (subroutine) to make sure that if nothing is supposed to be left on it (as in passing data to another Word) that nothing is. Stack garbage constitutes the majority of my debugging.This is why (good) Forth programmers write short Words of only a few short lines, because then the Stack is easy to examine.With ".s" stack print statements interspersed between commands much like "printf" statements used to debug C programs the Stack state can be easily examined for program bugs. The difference is Forth allows this debugging in realtime.This page details my usual method of examining the Stack in my programs:https://mecrisp-stellaris-folkdoc.sourceforge.io/devtips.html?highlight=development#pr-monitor-stack-values-and-program-flow

author: splin
author_rank: Frequent Contributor
timestamp: October 01, 2019, 05:09:44 am
content: Quote from: MosherIV on September 29, 2019, 11:00:49 amOf course they do! Just because the majority of the debug/watchpoint/trace logic is now physically implemented on the same silicon die as the MCU rather than externally as in older ICEs is neither here nor there - it doesn't alter the fundamental principles of an ICE which are to allow you to monitor, control and idealy trace the execution of a processor when operating in your actual target hardware. Another significant feature of an ICE was the provision of RAM to replace the target's program memory which is no longer required for FLASH based MCUs. If it quacks like a duck....I guess if you want to be really pedantic, a 'proper' ICE for an MCU with on-chip debugging hardware would need to be able to monitor and control the on-chip (or in-chip/ICD) debugging hardware as well as the MCU as you could quite legitimately use the debug functionality as part of your project's implementation. Someone developing an ICE for example might find that especially useful!Either way the 'in-circuit' aspect is hardly in question. As to the 'emulation' term I'd claim they never really existed; popular ICEs including Intel's ICE85, ICE86, ICE48, ICE51 and Microtek 8048 and 80188 all used an actual processor (ie. 8085, 8086 etc) to run the code - sure control signals like read and write strobes, clocks etc. and buses are gated to allow the ICE to access target memory and peripherals but the processors themselves were *not* emulated. The 8051 ICE used a special (epensive!) version of the processor where the internal control signals and address and data buses were bonded out to external pins on a special package to allow the ICE to monitor and control them.I'd guess that some 'true' emulators could have been made using bit-slice logic/ECL/ULAs/FPGAs etc. for military applications where the cost was low down on the list compared to the ability to monitor/control all the internal state of the processor - especially the register files and status flags. That would make trace data much more complete (ie. in addition to the instructions and data) but OTOH there would be the real danger that the emulation did not precisely match the real processor - especially the exact relative timing of control signals which could cause differing behaviour in the target hardware.QuoteSWD/JTAG are simply serial interfaces to allow access to on-chip test and debug hardware. As far as I am aware, debugging functionality on ARMs is entirely hardware - requiring support from software would need the MCU to be fully functional in order to execute that software which would substantially emasculate the debugger's capability/reliability/useability. I don't believe software is required for ARM Cortex debugging.QuoteExactly. Horses for courses - use the appropriate tools for the problem in hand.QuoteNow a days'? I was doing this over 30 years ago. It isn't useful for applications where the majority of the firmware is real-time and dealing with peripherals where you would spend more time creating (probably incomplete and/or inaccurate) emulations of the peripherals in the test harness than you would testing on the real hardware.Quote'Just to make sure it all works together'? For many real time embedded applications the target hardware operation is everything - try testing and debugging an MCU firmware brushless motor controller using your host development TDD environment!

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 01, 2019, 01:12:37 pm
content: Quote from: techman-001 on October 01, 2019, 12:40:18 amOh yeah. STM dev boards include an ST-Link probe, although those are usually the simplified ones, which only support 3.3V for the target, so if you power your targets at a lower voltage, you'll need something else.Apart from ST-Link and all the clones, it also works fine with FTDI-based swd probes. There are many out there, and making your own is pretty easy. With OpenOCD, I get better speed (flashing for instance) with that than with an ST-Link.

author: techman-001
author_rank: Frequent Contributor
timestamp: October 01, 2019, 01:35:33 pm
content: Quote from: SiliconWizard on October 01, 2019, 01:12:37 pmGood point, tho I'm still using stm32F0's with a internal 3.3 -> 1.8 regulator and I have plenty of 5v --> 3.3V smt regs.I rarely flash with OpenOCD, preferring to use the serial bootloader, and I only use that very infrequently, perhaps once a month. Because I'm a Forth user, Forth does all my flashing/erasing from within the MCU itself, rarely fully erasing to upgrade the Forth version, or more commonly erasing back to a 'cornerstone' marker which leaves all my development apps intact and only erases my prototype code.Plus I run all new Forth development code out of RAM until it is tested to my satisfaction, which lowers Flash rewriting as well.I have Disco boards I've reflashed thousands of times since 2014 and they still have no problems apart from requiring the reset button be replaced about once a year because that gets a *lot* of use ;-)

author: ehughes
author_rank: Frequent Contributor
timestamp: October 01, 2019, 01:36:18 pm
content: QuoteUsing something like Segger Ozone with SWD allows you to monitoring anything on the AXI bus without needing to halt the CPU. You can monitor any variable, structure, etc live. It doesn't require any special code to output data. Everything is over SWD. I am working on an OFDM communication routines and have been able to do some very high speed real time monitoring without having to write any special code.The only reason most debuggers (i.e. OpenOCD) halt is because they are based upon an arcane architecture (GDB). SWD on arm supports real time monitoring that is minimally intrusive. It only needs cycles on the AXI bus to grab data as needed.You can also enable a console over SWD that can be much faster than a UART, etc. Segger has a very simple queue called "RTT". It can use both SWD and the fancier trace interfaces. I always route my serial terminals through RTT and an external Uart. It works before you have any other hardware brought up in the system and is extremely useful. RTT also gets routed to a telnet port if you want access via a TCP connection.As for MCU's I generally go with NXP. They have bootloaders in rom that are exposed over several interfaces (UART, USB, SPI). Production programming/recovery is built in.

author: nctnico
author_rank: Super Contributor
timestamp: October 01, 2019, 05:11:30 pm
content: Quote from: ehughes on October 01, 2019, 01:36:18 pmThat definitely looks interesting. I have to keep that in mind.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 01, 2019, 05:59:11 pm
content: Segger tools are fantastic, but rather expensive too, at least for the hobbyist.

author: NorthGuy
author_rank: Super Contributor
timestamp: October 01, 2019, 06:09:25 pm
content: Hire an engineer/developer first. He'll recommend you the chip, and will help with other things too. It is already hard to find one which will do things quickly and effectively (instead of burning $9000/week playing with super expensive MCUs until you run out of your budget). By pre-selecting the MCU, you only make hiring harder.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 01, 2019, 07:30:41 pm
content: Quote from: NorthGuy on October 01, 2019, 06:09:25 pmExactly this. Practically all MCUs available are "suitable for production" - they wouldn't be manufactured otherwise. Someone buys them in large numbers.You need a designer, and you'd want agooddesigner, even for a simple product, so use your preferred ways of verifying the competence and building the trust. Then, they know what part to use; for smoothest development possible, they use what they know the best.Give them something else, no matter how popular, and the timescale on asmallproject easily goes up 5-10x.(I'm assuming a lot about the simplicity of the project, but a really good skilled embedded guy may be able to pull it off in, say, two weeks, but ask them to learn a new platform, and it's easily two-three months, and what's worst, it's very uncertain and hard to predict.)

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 01, 2019, 07:51:00 pm
content: Yeah. Unless you already have a large team, and/or your plan on selling millions of products, the real factor here in terms of resources will be the human resources!If you have to hire someone specifically for a given project, this person will become your single point of failure so to speak. The hire will have much more impact than the choice of an MCU.

author: splin
author_rank: Frequent Contributor
timestamp: October 01, 2019, 11:32:44 pm
content: I strongly recommend watching this video to see the power of debugging using event tracing which is available on Cortex M3, M4 and M7 cores.It is a demonstration of debugging using Atollic TrueStudio using STLink but other platforms support similar functionality. For anyone doing real time development and not using such functionality using printf()s and GPIO toggling should at least see what they are missing.Keil will support event trace but it is an expensive option. I don't know if there are any other free development tools which support event tracing; if not it is a powerful argument (for me at least) to use ST M3, M4 or M7 devices for development with Atollic TrueStudio. Once the code is stable and the real time behaviour and performance well understood you have the option to move the application to a cheaper and even a different manufacture's device if justified.The video is quite long at 50 minutes so I've listed below where the main features are demonstrated:[6:29] printf() output via the debugger - no UART required and lower overhead[8:22] Configuring the trace module to send exception (ISRs) entry and exit events to the debugger. You wouldn't want to instrument the entry and exits of exceptions with printf()'s - too much overhead, probably not thread safe and nested interrupts could get very nasty. This is done without having to change any of your code and is light years ahead of twiddling GPIO and monitoring with an oscilloscope.[11:30] Showing statistics of exception routines - max and min and average execution times, % CPU time in each exception etc.[13:24] Performance profiling - using event tracing to sample the PC and display statistics and which functions consume most CPU time etc.[16:20] Data tracing - view accesses to variables in real time - demonstrates accelerometer values as they are updated, shown graphically versus time (ie. oscilloscope form).[20:03] Viewing data trace log to find an unexpected value and using logged PC, go directly to view the source codethat wrote the bad value.[21:21] Kernel aware debug support - real time viewing of data for every task including semaphores, queues and most importantly minimum free stack.[25:10] Live variable watching (Segger JLINK only).The above event tracing is the cheap option but many Cortex devices support a more powerful trace module which allows instruction tracing. Unfortunately not many debug probes support the high speed trace interface port. SEGGER do of course but a free or low cost option would be interesting. It would ideally be supported by the debugger to be productive but even logging the trace data to a text file could be very helpful.Back in the late 80's we used an i8086 perfomance monitoring tool which was similar to an ICE except that it traced the instruction flow and analysed the data to present information/statistics on the execution time of each function called which allowed you to determine the worst case execution times and code hotspots.It cost around £5K to £10K if I remember correctly and I think it was called SAW, 'Software Analyst Workbench'. Now you get that for free, most of it built into the target processor!

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: October 03, 2019, 12:14:11 am
content: Quote from: SiliconWizard on October 01, 2019, 05:59:11 pmThe J-Link EDU costs around 60€ including VAT and supports Ozone. Using RTT and Ozone is really a gigantic step forward to GDB debugging in e.g. MCUXpresso. And everything is so much faster and more polished in Ozone.Actually, you can even use an LPC Link 2 with Ozone and RTT, but it's quite a bit slower than the latest (v10) J-Link EDU.E.g. you can capture variables with a few kHz using the J-Link EDU while with the LPC Link 2 the capturing seems to peak somewhere below 1kHz.Actually, the J-Link EDU is identical to a j-Link Plus apart from licensing. Well, there are nag screens with the EDU (and LPC Link 2), but there are solutions for that (*cough*).My main gripe with Ozone is that the automatic update of the watched variables tends to get stuck with too many variables. And it's just a shame that Ozone doesn't allow performance measurement over SWO which is a great feature in MCUXpresso.