Small, fast MCU... - Page 1
Forum section: electronics / general

author: Boscoe
author_rank: Frequent Contributor
timestamp: June 21, 2019, 06:25:13 pm
content: I've had a couple of projects in recent times that could have done with a small, fast MCU. Something like what's in the ESP32. A couple of hundred MHz, half a MB of RAM but in a small QFN. Does anyone know of anything like this on the market? The closest thing I can find is a 480MHz M7 in a 100 QFP from ST.

author: Dubbie
author_rank: Unknown
timestamp: June 21, 2019, 07:19:37 pm
content: There are some LQFP64 parts at 216MhzSTM32F722 / 30 / 32Only 256K ram tho.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 21, 2019, 08:06:40 pm
content: You'll find QFN packages in the following series:* PIC32MZ: typ. 512KB RAM, 200MHz, QFN64 (eg.: PIC32MZ2048EFM064-I/MR)* ATSAMS70: typ. 384KB RAM, 300MHz, QFN64 (eg.: ATSAMS70J21A-MN)

author: rsjsouza
author_rank: Super Contributor
timestamp: June 21, 2019, 08:33:18 pm
content: Just like blueskull's suggestion, fast could also be a Floating-point DSPTMS320C6713in HLQFP 208 pins running at 200MHz with up to 8 instructions per cycle (1600MIPS, 1200MFLOPS) and 256kB internal RAM. It needs external Flash and, optionally, external SRAM and/or DRAM. Free tools and Free Real-time operating system (DSP/BIOS).In the area of MCUs with gobs of peripherals, check the HerculesRM46L852, a 220MHz Cortex R4F in LQFP 144 pins with 1.25MB Flash, 192kB RAM and several peripherals. It has acheap kitand free tools (Code Composer Studio).

author: krho
author_rank: Regular Contributor
timestamp: June 22, 2019, 11:16:21 am
content: IMO the H7 from STM is the only choice. If you don't need much flash you can take a value series and add external QSPI as program memory. And use the internal one for bootloader.

author: OwO
author_rank: Super Contributor
timestamp: June 22, 2019, 04:55:45 pm
content: Why not just use the esp32? Most of these suggestions are going to be far more ex🅱ensive for no good reason. If you really need DSP capability nothing beats the kendryte K210, which has hardware FFT rather than just multiplies and twiddle generators. If you choose to do DSP in software it has a 64 bit FPU compared to the 16/32 bit integer math the ADSP supports, not to mention the price difference.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: June 23, 2019, 05:38:47 am
content: QuoteWhat sort of prices should we expect for kendryte K210?

author: rsjsouza
author_rank: Super Contributor
timestamp: June 23, 2019, 10:38:25 am
content: Also, kendryte K210 is not available in QFN or QFP... One of the original constraints.Is there a datasheet longer than the one I found in English? The one I found is just 34 pages and has very little to no information on peripherals.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 23, 2019, 01:00:09 pm
content: Quote from: rsjsouza on June 23, 2019, 10:38:25 amIndeed, several answers in this thread don't address the requirement for a QFN package. Reading the original post, even a QFP is probably too big for the OP's needs as I understand it. We may suggest BGA, as then they would find many options, but we can only assume they don't want to deal with BGAs, otherwise they would probably have not asked in the first place (unless they don't know about BGA, which I doubt!)Quote from: rsjsouza on June 23, 2019, 10:38:25 amAs discussed in another, specific thread about the Sipeed boards and K210, yes the documentation is way too spartan, making it pretty much impossible to deal with if you're seriously considering to design a product around it. For hobbyist stuff, fiddling with the SDK may be enough. Not for serious stuff IMO.Another, related issue is that Kendryte's support is very spartan as well, and the team only seems to answer/address whatever they like. For instance: OwO mentioned a 64-bit FPU, which indeed was a nice seliing point for me. But it turns out there must be something fishy about it in the K210. Kendryte's team disabled the D extension support both in the SDK AND in the GCC toolchain that they provide (thus making sure nobody would be tempted to use double precision FP). I opened a ticket in github about it, someone else commented with an interest in the answer as well, and the ticket got closed without any answer. So basically no support for the D extension on the K210 for now, and nobody knows why. No published errata, nothing. Sorry, but that's not something I'd want to deal with for serious development at this point.