Intel's new microcontroller

[ale500]

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.

[richardman]

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.

That's surprising. What causes the performance drop, do you know?

[farsi]

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.

[farsi]

also connectivity projects require some processing power, might be interesting to compare x86 devices with ARM when it comes to low-level network protocols.

[nctnico]

also connectivity projects require some processing power, might be interesting to compare x86 devices with ARM when it comes to low-level network protocols.

I got close to 1 mbps udp on cc3100 controlled by a 32 mhz arm. Considering the isa advantage and compiler advantage of x86, it should be even faster.

I 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.

[coppice]

also connectivity projects require some processing power, might be interesting to compare x86 devices with ARM when it comes to low-level network protocols.

I got close to 1 mbps udp on cc3100 controlled by a 32 mhz arm. Considering the isa advantage and compiler advantage of x86, it should be even faster. Anyway for iot sensors you really don't need more than a couple kbps.

As soon as d2000 or quark se is out, I will get the first batch of dev kit. No interest in d1000 so far.

What 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.

[Howardlong]

also connectivity projects require some processing power, might be interesting to compare x86 devices with ARM when it comes to low-level network protocols.

I got close to 1 mbps udp on cc3100 controlled by a 32 mhz arm. Considering the isa advantage and compiler advantage of x86, it should be even faster. Anyway for iot sensors you really don't need more than a couple kbps.

As soon as d2000 or quark se is out, I will get the first batch of dev kit. No interest in d1000 so far.

There is something wrong there, I was achieving sustained 14Mbps UDP a year ago on the CC3100 driven via 20MHz SPI.

[dannyf]

nothing special, right ?

Limited peripherals.

But the wake-up time is impressive -> almost MSP430-like.

[coppice]

nothing special, right ?

Limited peripherals.

But the wake-up time is impressive -> almost MSP430-like.

I 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.