Intel's new microcontroller - Page 1
Forum section: electronics / general

author: autobot
author_rank: Regular Contributor
timestamp: November 04, 2015, 02:58:40 am
content: Here's the datasheet for intel's new microcontroller , supposed to cost $2-3 depedning on volume, with price decrease in the future.datasheethttp://www.intel.com/content/www/us/en/embedded/products/quark/mcu-d1000/quark-d1000-datasheet.htmlnothing special, right ?

author: c4757p
author_rank: Super Contributor
timestamp: November 04, 2015, 03:20:58 am
content: It looks about as capable as a lower-end M0 and costs 2-3x as much. I don't understand who is supposed to want this.

author: asgard20032
author_rank: Regular Contributor
timestamp: November 04, 2015, 03:24:33 am
content: And it don't get lot of peripheral

author: ralphd
author_rank: Frequent Contributor
timestamp: November 04, 2015, 03:26:29 am
content: Only 33Mhz. Many of the cheap M0s go to 48Mzh.

author: ataradov
author_rank: Super Contributor
timestamp: November 04, 2015, 03:36:32 am
content: That 13 cent Cortex-M0 device that just floated in another thread got more going for it than this chip from Intel. The purpose of this device is not clear.

author: richardman
author_rank: Frequent Contributor
timestamp: November 04, 2015, 04:12:20 am
content: The purpose is for Intel to get to the IoT market which is suppose to be huge and every silicon vendor wants a piece of that pie. Intel has 2 major advantages: their own fab and their own instruction set architecture. Unfortunately, neither of which will help them much in the embedded space. MCUs do not push the envelope of fab manufacturing and the ISA only helps if you are running Windows.OTOH, this is a market that Intel cannot and will not ignore, so it would be interesting to see what they will do.

author: ataradov
author_rank: Super Contributor
timestamp: November 04, 2015, 04:50:11 am
content: Quote from: richardman on November 04, 2015, 04:12:20 amGive up and license ARM core. They already use AMBA for interconnect, so it will be a drop in replacement. And after that they need to work on peripherals, right now there is nothing to look at there.All of this can be achieved by acquiring some MCU manufacturer. Everything seems to be for sale these days.

author: coppice
author_rank: Super Contributor
timestamp: November 04, 2015, 05:30:50 am
content: Quote from: richardman on November 04, 2015, 04:12:20 amWhy can't they ignore it? They used to be a substantial player in the MCU business. First they dropped the low end (8051), and later the higher end (80960, etc). Now things are much more aggressive in the MCU market than when Intel left. What would make sense for Intel now which didn't make sense then?

author: LabSpokane
author_rank: Super Contributor
timestamp: November 04, 2015, 05:42:28 am
content: The real winners in the IoT lottery will be those who don't buy a ticket.

author: Mechatrommer
author_rank: Super Contributor
timestamp: November 04, 2015, 05:44:32 am
content: Quote from: c4757p on November 04, 2015, 03:20:58 amintel's fans, worshippers and nuts.

author: c4757p
author_rank: Super Contributor
timestamp: November 04, 2015, 06:12:23 am
content: Fanboys don't sustain a product line, though.

author: daqq
author_rank: Super Contributor
timestamp: November 04, 2015, 06:19:52 am
content: The ADC parameters and the built in step down converter (just add coil and diode) are nice, but aside from that I can't see what would motivate me to prefer this to, say, something from ST or similar.

author: andersm
author_rank: Super Contributor
timestamp: November 04, 2015, 06:26:23 am
content: Quote from: coppice on November 04, 2015, 05:30:50 amThere's much more money there now, and they can make it run x86.

author: c4757p
author_rank: Super Contributor
timestamp: November 04, 2015, 06:29:00 am
content: Quote from: richardman on November 04, 2015, 04:12:20 amWhy is this an advantage? If I were evaluating someone's microcontrollers for use in a product, the use of a nonstandard ISA only implemented by one company with a very small microcontroller inventory would almost 100% disqualify them.

author: richardman
author_rank: Frequent Contributor
timestamp: November 04, 2015, 06:43:01 am
content: Quote from: c4757p on November 04, 2015, 06:29:00 amIt goes with the 2nd part - the x86 ISA is the reason why Wintel dominates the PC world. Windows had been ported to DEC Alpha, MIPS, PPC, 960, ... all dead. When you throw enough smart people at a pig, eventually it can look like a swan. The obvious point is that the x86 ISA does not carry the same advantages in the embedded world, unless of course if everything runs Windows 10.

author: JoeN
author_rank: Frequent Contributor
timestamp: November 04, 2015, 09:04:16 am
content: More information. Registers, memory map.http://www.intel.com/content/dam/www/public/us/en/documents/guides/quark-d1000-user-guide.pdfMore information, download the IDE:https://firmware.intel.com/projects/quark/intel-quark-microcontroller-d1000Buy some:http://www.mouser.com/search/ProductDetail.aspx?qs=MNIFWdyJgbqv4nzs%252bL2%2f4g%3d%3d

author: Scrts
author_rank: Frequent Contributor
timestamp: November 04, 2015, 09:16:34 am
content: Quote from: ataradov on November 04, 2015, 03:36:32 amSorry missed that. Can you post a link to that thread?Thank you.

author: ataradov
author_rank: Super Contributor
timestamp: November 04, 2015, 09:20:59 am
content: Quote from: Scrts on November 04, 2015, 09:16:34 amhttps://www.eevblog.com/forum/microcontrollers/new-st-nucleo-boards/msg791932/#msg791932

author: ataradov
author_rank: Super Contributor
timestamp: November 04, 2015, 09:30:31 am
content: Quote from: JoeN on November 04, 2015, 09:04:16 amAt least documentation seems to be reasonably complete.Now where can we get header files for this?It would be an interesting toy if someone came up with a cheap eval board. Beyond that, I rally don't see how this can be successful.

author: tszaboo
author_rank: Super Contributor
timestamp: November 04, 2015, 10:06:32 am
content: Quote from: daqq on November 04, 2015, 06:19:52 amBy the looks of it, they spent some time on the analog peripherals.I think at least it shows that they are going to the right direction. When they targeted the IoT with 400 Mhz x86 with DDR3, doing a wireless temperature measurement, I was laughing my ass off.We dont see the roadmap, probably we get micros with built in wireless, usb, and stuff.

author: legacy
author_rank: Super Contributor
timestamp: November 04, 2015, 10:53:57 am
content: thank you, I will notify it to my executive manager, in order to get a few samples, it "might" be interesting for us.

author: mikerj
author_rank: Super Contributor
timestamp: November 04, 2015, 12:21:25 pm
content: Looks like a decent enough device; very low power sleep, nice fast ADC, loads of comparators, 32 bit timers etc. but they are very late to the party for a device in this class, and if the price estimates are correct it's way too expensive.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: November 04, 2015, 01:24:02 pm
content: interesting. 32bit x86 uc... will have to see where it goes.

author: MT
author_rank: Super Contributor
timestamp: November 04, 2015, 05:07:56 pm
content: Quote from: richardman on November 04, 2015, 06:43:01 amPig's are often quite calm animals while swan's is actually very aggressive. Win10 needs loads of speed to be useable, 33Mhz wont cut.286,386, and even low powerPC on a chip 486have been made by multiple vendors in the past all for embedded use.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: November 04, 2015, 08:16:18 pm
content: well, wont be running second reality or panic on this thing but hmm i am curious about its tooling and debugging...

author: kfitch42
author_rank: Frequent Contributor
timestamp: November 04, 2015, 08:59:09 pm
content: Normally ISA doesn't matter very much in a microcontroller, in large part because most of the microcontrollers these days have converged on similar behaviour for their ISAs. On the other hand, x86 is actually a poor choice for a microcontroller. When reaching for a micro you are usually in a problem space that worries about latency more than throughput. The complexity of x86 makes predictable latency hard (but not entirely impossible). I see two problems with x86:1) Variable length instructions: In a desktop (throughput dominated) problem space this is actually a (small) win since you can have better code density which means better usage of L1 code cache space. In an embedded problem space (latency dominated) this can add weird hiccups to the code execution. Sometimes an memory fetch gets multiple instructions, sometimes it takes multiple fetches to get 1 instruction...2) More complex pipeline: In order to really execute x86 code you need the CPU to translate it needs to be "cracked" into more RISC like internal instructions. This is again a win for Desktop situations where the the same compiled code can run across multiple generations of CPUs that look VERY differently internally, but still take the same x86 code as input. On a power limited microcontroller this is a problem. The translation logic doesn't scale down when you scale down the rest of the CPU. So, it takes a bigger portion of the overall die space and power on a smaller CPU.

author: andersm
author_rank: Super Contributor
timestamp: November 04, 2015, 10:21:37 pm
content: Quote from: kfitch42 on November 04, 2015, 08:59:09 pmFunny that you think it's a problem, because few architectures actually use fixed-length instructions. Even classic RISC-style architectures have added or moved to variable-length to increase code density (eg. Thumb-2, microMIPS, Power VLE).QuoteThe Quark is basically an i486, and has a single-issue, in-order, 5-stage pipeline. Instruction cracking and the likes didn't appear until much later. AFAIK, x86 was (and still is) a fairly popular industrial real-time platform, and several RTOSes (eg. µC/OS, RTXC) were first written for that architecture.

author: neil555
author_rank: Contributor
timestamp: November 04, 2015, 11:26:23 pm
content: Hmmmm, looks interesting *BUT*It's too slow (even the STM8/AVR etc is almost as fast)8K of ram is pathetically smallQFN's are a bitch to solder especially for hobbyists making their own boardsIf it was available in LQFP, ran at like 100Mhz and had 64K (or more) ram then i could think of loads of uses for it, eeh well

author: free_electron
author_rank: Super Contributor
timestamp: November 04, 2015, 11:45:55 pm
content: Quote from: AcHmed99 on November 04, 2015, 03:31:28 amthey invented them ... the 4040 ( not the 4004 ) was the first microcontroller they made. followed by 8048 and 8051 and 8096

author: free_electron
author_rank: Super Contributor
timestamp: November 05, 2015, 12:57:51 am
content: Quote from: AcHmed99 on November 05, 2015, 12:01:24 amThey pulled out of the microcontroller market long before most companies even entered that market ...

author: coppice
author_rank: Super Contributor
timestamp: November 05, 2015, 10:47:37 am
content: Quote from: free_electron on November 04, 2015, 11:45:55 pmThe 4004 and 4040 were not microcontrollers. They were microprocessors. The 4004 was not actually the first microprocessors, but it was the first to achieve any significant sales. The first microcontroller was probably the TI TMS1000, which was a 4 bit device and sold in really big numbers. TI had a big advertising campaign when it hit 100 million units, which was a vast number for a chip in those days. Intel probably made the first 8 bit microcontroller, the 8048.

author: rsjsouza
author_rank: Super Contributor
timestamp: November 05, 2015, 11:49:18 am
content: Quote from: andersm on November 04, 2015, 10:21:37 pm+1 to that. In addition to the examples above, several DSP architectures have variable length execution and they are very demanding in terms of latency and predictive code. One detail that makes it harder on embedded systems isout-of-order execution, which wasstarting to make inroadsin 486 processors (although only fully implemented in Pentiums).Quote from: andersm on November 04, 2015, 10:21:37 pmSimilarly as before: DSPs also have long pipelines which do not translate into loss of predictive behaviour. Also,ARM mentionsThumb ISA is translated internally into ARM microcode.Quote from: coppice on November 05, 2015, 10:47:37 amAlthough it is generally believed Intel invented the microprocessor and TI the microcontroller, the history is somewhat controversial as to "who made what first", when TI was granted with a patent for the TMS1000 as the first microprocessor and Intel paying royalties to them.Back in the 90's I was already working with PC-104 architecture for industrial control - a big honking 486 running at a decent speed for its time (33MHz). If these processors can run DOS (I wish!) or a decent RTOS, it is a good headstart. However, everything relies on the availability of a decent BSP (Board Support Package).All in all, I always believed that, when the largest semiconductor manufacturer on the planet makes a move we better be on the lookout.

author: commie
author_rank: Frequent Contributor
timestamp: November 05, 2015, 03:40:21 pm
content: I can't understand peoples interest in 32 bit mcu's mainly because you dont get any bang for buck which is governed by the supporting compiler. For example, I would expect a 32 bitter to do one 32-bit flop per clk cycle. The way things look, they don't even support 64 bit floats.The supporting 32-bit compilers are deliberately impeded so whats the point?Well, the electronics industry has got about 25years worth of technology still to feed through to us and they are certainly dragging their feet about giving it to us and that's with a technology that's ever speeding up with the time.Another thing, prototyping would be very difficult due to the packages these 32-bitters come in, making the only choice being a 3rd party or vender evaluation kit or breakout board. Nah, not interested, I'm sticking with 8 bitters for now.

author: mikerj
author_rank: Super Contributor
timestamp: November 05, 2015, 06:10:01 pm
content: Quote from: commie on November 05, 2015, 03:40:21 pmWhy would you expect that if a micro doesn't have an FPU?Quote from: commie on November 05, 2015, 03:40:21 pmHow often do you really need to use single cycle double precision floats on a general purpose microcontroller? If you are after serious number crunching then you;d be using a DSP.In what way are 32 bits compilers "deliberately impeded"? Are you drawing assumptions based on a single compiler vendor?

author: rolycat
author_rank: Super Contributor
timestamp: November 05, 2015, 06:54:42 pm
content: Quote from: free_electron on November 04, 2015, 11:45:55 pmMy understanding is that Texas Instruments invented the microcontroller, not Intel.The Intel 4040 - like its predecessor the 4004 - had no I/O and no onboard memory.TI launched a single-chip microcontroller configured as a dedicated calculator chip in 1972, and a general purpose version (the TMS1000) in 1974, the same year as Intel's 4040 microprocessor.Intel's first microcontroller (the MCS-48 series which included the 8048) wasn't released until 1976.It could be argued that TI also invented the microprocessor. There seems to be evidence that although the 4004 was the first commercially available microprocessor, Intel were already paying royalties to TI for their microprocessor patent when the 4004 was launched in 1971.

author: bson
author_rank: Unknown
timestamp: November 05, 2015, 07:01:06 pm
content: There's still a substantial x86 legacy embedded market. This looks like the IA32 version of the EM188Ex series from AMD 20 years ago. Probably a hit in that market. Without getting too abrasive about it, any engineer who uses IA32 for new designs though really needs to get out more.

author: helius
author_rank: Super Contributor
timestamp: November 05, 2015, 07:31:27 pm
content: Quote from: rolycat on November 05, 2015, 06:54:42 pmThe MP944 microprocessor used in the F-14A aircraft was completed before that, in 1970. In a replay of the events that led to the ENIAC and not the Colossus getting credit for the first electronic computer, the paper describing the MP944 was classified and not widely known.https://en.wikipedia.org/wiki/Central_Air_Data_Computer

author: commie
author_rank: Frequent Contributor
timestamp: November 05, 2015, 07:35:05 pm
content: Quote from: mikerj on November 05, 2015, 06:10:01 pmWell, if you are using a 32 bit micro then it should do 32 bit flops every cycle otherwise I might as well carry on with 8 bit micro'sQuote from: mikerj on November 05, 2015, 06:10:01 pmAll of the time, it's nice to have at your disposal, my AVR 8-bit compiler has 64-bit floats, the AVR ATMEGA are hardly dsp. Perhaps you can name a compiler for a 32 bit micro that supports double floats?The specific compiler in use unlocks the power of your micro not the other way about.

author: coppice
author_rank: Super Contributor
timestamp: November 06, 2015, 02:50:44 am
content: Quote from: helius on November 05, 2015, 07:31:27 pmThere were other early single chip processor activities too. People still question who developed the first single chip CPU, but there is no doubt that it wasn't Intel or TI.

author: Kalvin
author_rank: Super Contributor
timestamp: November 06, 2015, 08:43:42 am
content: Quote from: commie on November 05, 2015, 07:35:05 pmYour opinion might be very biased as your are only after 64-bit FPU, and you fail to see other benefits of using 32-bit MCUs over 8-bit MCUs.A 32-bit MCU can typically perform one instruction per clock cycle, where the older 8-bit architectures spend two to four cycles. However, the modern 8-bit architectures will perform one instruction per clock cycle, too. But the performance is more than just instructions per clock cycle, so please read on.Quite often though the needed data types are either 16 bit or 32 bit signed and unsigned integers. The 32-bit architecture can process the operation in few instruction cycles (fetch operands, operand, write the result back. But if the operands are already in the registers, then the operation can be performed in a single clock cycle). The 8-bit MCU need quite many instruction cycles to perform the 16-bit and 32-bit operations.Also the memory access using pointers etc. is much efficient using 32-bit architecture than 8-bit architecture.Code density will be better on 32-bit architecture. The compilers will typically be able to generate more efficient code for the 32-bit architectures than 8-bit architectures are there are typically more registers available to store intermediate results.There is a speed benefit using 32-bit architecture as fewer instruction cycles are needed to perform the algorithm, so they are more suitable in high demanding, embedded real-time applications.8-bit MCUs may still have a energy consumption advantage, but the 32-bit architectures are catching up.

author: coppice
author_rank: Super Contributor
timestamp: November 06, 2015, 08:56:14 am
content: Quote from: Kalvin on November 06, 2015, 08:43:42 amIts a long time since an 8 bit MCU was the lowest energy consuming MCU on the market.

author: westfw
author_rank: Super Contributor
timestamp: November 06, 2015, 09:11:42 am
content: Speaking of... MSP430 also has a (very) variable length instruction (and direct memory operations), rather like x86.

author: mikerj
author_rank: Super Contributor
timestamp: November 06, 2015, 10:08:28 am
content: Quote from: commie on November 05, 2015, 07:35:05 pmWhat a ridiculous statementHow many cycles does it take to perform a floating point operation on your 8 bit micro?If neither the 32 bit micro or the 8 bit micro have an FPU, then the 32bit device is going to be significantly faster doing floating point calculations through software. The 32 bit device is also going to be significantly faster whenever you are dealing with integer values larger than 8 bits.If you do want an FPU then your choice of 8 bit devices is going to be close to zero (are there any at all?), but there are numerous 32 bit devices that include this function.Quote from: commie on November 05, 2015, 07:35:05 pmThe majority of compilers for 32 bit devices support double precision floats. The one I frequently use (Keil MDK-ARM) does, and as far as I know the GCC compiler does as well. Again, it seems like you have maybe had a bad experience with one compiler and you've extrapolated this to all other compilers.Even if you had a compiler that didn't include support for doubles, then there is nothing stopping you using a third party library or making your own. It's hardly rocket science.

author: commie
author_rank: Frequent Contributor
timestamp: November 06, 2015, 11:57:12 am
content: Quote from: mikerj on November 06, 2015, 10:08:28 amHere's the price of your ARM compiler,http://uk.farnell.com/arm/mdk-arm/software-mdk-std-std-node-locked/dp/2309940and that's ex-vat, had a quick wiz through it's data sheet, gives no information whether it has 64-bit float support or not.Heck Mike, what are you designing F14-Tomcat flight control systems?

author: c4757p
author_rank: Super Contributor
timestamp: November 06, 2015, 12:10:18 pm
content: Which AVR compiler are you using that has 64-bit floats? avr-gcc fakes them...

author: commie
author_rank: Frequent Contributor
timestamp: November 06, 2015, 12:55:09 pm
content: Quote from: c4757p on November 06, 2015, 12:10:18 pmhttp://www.mcselec.com/I also believe, although not sure that Imagecraft pro supports 64-bit floats. For those that don't know it, 64 bit floats produce 15 digits of precision.

author: mikerj
author_rank: Super Contributor
timestamp: November 06, 2015, 10:59:10 pm
content: Quote from: commie on November 06, 2015, 11:57:12 amNot quite (though we used to make a part for the Eurofighter Typhoon IIRC), but it's pretty much the industry standard C compiler for ARM devices (since they use the official ARM compiler). I agree that the full version it's too expensive for a hobbyist or most small businesses, but the lite version is still very capable.Until you start seriously using 32 bit micros you won't know just how much performance advantage they have over the old 8 bit parts. We've used PIC, AVR and H8 micros in various products over the years and they were fine at the time but we wouldn't consider going back to them now. Not only do they represent poor value in terms of performance/$, once you start needing larger amounts of memory and I/O then 8 bit parts just don't cut the mustard.

author: westfw
author_rank: Super Contributor
timestamp: November 06, 2015, 11:56:56 pm
content: QuoteUnfortunately, this isn't necessarily true. Float support in gcc will "default" to the GNU SW floating point support, which is written entirely in C, and is neither fast nor small. While an 8-bit micro with float support PROBABLY has optimized assembler. Various people in Arduino-land have been shocked when their floating-point intensive sketches do not get "much faster" when run on the ARM boards. (here's one thread:http://forum.arduino.cc/index.php?topic=138802.0Arduino Due, about 3.5x faster than Arduino MEGA, despite 32bits and 5x clock.) Part of that is that their "doubles" (and FP constants) suddenly go from 32bits to 64bits, and their trig functions like "sin" all operate on doubles (and have an extra conversion step if they HAD used "float", but a lot of it is that the AVR floating point math library is ... really good, while the ARM floating point library ... isn't.Looking at the arm-gcc source, I see that there are assembler functions for basic float/double math (.../src/gcc/libgcc/config/arm/ieee754*.S), but no optimized higher-level functions (trig/etc.) Except that they're ARM32/THUMB2 instructions, and don't work on CM0 (so CM0 takes the added hit of going back to the C code.) Meh.Quotegcc for ARM, as described above. PIC32 as well. Probably MOST gcc targets, though not "well." I haven't figured out whether it's able to leverage 32bit float hardware (ie on CM4F) when doing 64bit float math...

author: helius
author_rank: Super Contributor
timestamp: November 07, 2015, 12:41:05 am
content: Quote from: westfw on November 06, 2015, 11:56:56 pmIEEE 754 double-precision is defined as 64-bits. Some of the other slowness could be "more ambitious" soft float implementations that try to follow more of the standard, which is quite specific about what happens in every situation.

author: richardman
author_rank: Frequent Contributor
timestamp: November 07, 2015, 02:24:14 am
content: Quote from: commie on November 06, 2015, 12:55:09 pmYes we do. Although we still have a user option to select 32/64 bit "double". 64-bits FP is dog-slow with the AVR, there's just no two way about it. Probably a well written set of asm routines will be 3x faster, but you will be starting from the state of molasses, so ...

author: ale500
author_rank: Frequent Contributor
timestamp: November 19, 2015, 06:31:21 am
content: If you are looking for microcontrollers with 1 FP per clock, then you have to go for either a SH-2A or PowerPC based one. The STM32F407 while clocked at 168 MHz was like 20% slower than the e200z4-based MPC5xxx at 120 MHz. ARM code compiled with GCC and PowerPC code compiled with diab.

author: richardman
author_rank: Frequent Contributor
timestamp: November 19, 2015, 06:47:14 am
content: Quote from: ale500 on November 19, 2015, 06:31:21 amThat's surprising. What causes the performance drop, do you know?

author: farsi
author_rank: Regular Contributor
timestamp: November 20, 2015, 09:55:09 am
content: interesting, but backgrounds on the toolchains and supported libraries might be nice. I am currently learning development on an STM32F4 board and with somewhat confusing structs and macro's. But I am making progress. The time from unpacking a device to running "hello world" (maybe on an RTOS) or blinking LEDs would be interesting to know.

author: farsi
author_rank: Regular Contributor
timestamp: November 20, 2015, 10:01:07 am
content: also connectivity projects require some processing power, might be interesting to compare x86 devices with ARM when it comes to low-level network protocols.

author: nctnico
author_rank: Super Contributor
timestamp: November 20, 2015, 01:41:32 pm
content: Quote from: blueskull on November 20, 2015, 10:10:08 amI doubt it. Price of a uC is driven by silicon area. The x86 instruction set isn't exactly very straigforward and the number of registers is small compared to ARM and some x86 registers have a special function. This makes it harder to get the same performance from the same silicon area. Also the CPU will need more clockcycles to do the same so I also expect increased power consumption. All in all the x86 seems like a disadvantage to me in a microcontroller even though Intel did a good job in making a pig fly in their desktop and server processors.

author: coppice
author_rank: Super Contributor
timestamp: November 20, 2015, 03:09:08 pm
content: Quote from: blueskull on November 20, 2015, 10:10:08 amWhat is this compiler and ISA advantage x86 has? Its years since anyone was optimising compilers to get the best out of old simple x86 cores. ARM compilers have had an unending stream of work put into them. The ISA of a basic old x86 isn't great, either. Sure a state of the art x86 does very well against a state of the art ARM, but that's not what we are talking about here.

author: Howardlong
author_rank: Super Contributor
timestamp: November 20, 2015, 05:37:12 pm
content: Quote from: blueskull on November 20, 2015, 10:10:08 amThere is something wrong there, I was achieving sustained 14Mbps UDP a year ago on the CC3100 driven via 20MHz SPI.

author: dannyf
author_rank: Super Contributor
timestamp: November 21, 2015, 06:58:22 pm
content: QuoteLimited peripherals.But the wake-up time is impressive -> almost MSP430-like.

author: coppice
author_rank: Super Contributor
timestamp: November 21, 2015, 07:15:16 pm
content: Quote from: dannyf on November 21, 2015, 06:58:22 pmI don't know if I am reading their terminology correctly, but this chip seems to have a very fast startup from standby, where the fast clock is already running. If the fast crystal is stopped, and only the 32kHz clock is running (i.e. the sort of place ULP MCU like an MSP430 tries to be a lot of the time) its startup is really slow, as it has to wake that crystal. They note a <2us wakeup of the core at the end of ADC conversion, but the fast clock is already up and running at that time. This seems like pretty typical MCU behaviour.