I think you're using the wrong metric. It's not flash/RAM that makes something "IoT", it's size, cost, and power.

when it comes to power, low end chips win by order of magnitudes ( for example http://ww1.microchip.com/downloads/en/DeviceDoc/30009941G.pd... ). But it all depends on what your power constraints really are

flash/RAM == size, cost, and power

Look at a die microphotograph of an ARM Cortex M4.

The RAM takes up more than half the die area. Flash is about a third of the die area. ALL the functional units and processing cores takes up less than 1/4 of the die area.

Very good point. For IoT widgets and perhaps even wearables, I'd rank things by power, size and cost coming in a bit later. The old way had cost first but people are seeing the light.

Well with RAM and flash you can either fit everything in on chip memory or you need external memory.

Once you have external memory 64MB is the smallest that you can get and be confident that you can obtain it for the next years. Its also not a big cost factor.

Grisp-Base is a evaluation board to get people easily started with Erlang running directly on hardware so not much use artificially limiting memory here. The board size is also larger than minimal to have all these nice PMOD connectors with enough room for the PMODs around them. Normally one would build some prototypes or smaller applications < 100 boards. When this works its fairly easy and cheap to build a customized board only the parts needed for the actual IoT application.

There are new SoC automotive controllers who will be able to run a Erlang VM without connecting any external memory which we plan to target for the future.

64K flash/16K RAM will never be able to run a Erlang VM so its outside of our scope. IoT trends are to move more calculation towards the edge since the cloud can't grow enough.

I agree, but it is a matter of cost/comfort.

For many use cases, going to a PIC doesn't make sense if just a few units are to deployed, with the price difference being just a few euros.

forth? :)

though it's a bid of a different mindset. Thinking Forth is great book ( not just in terms of forth ) which really sells the idea.

I wish people would quit promulgating Forth.

Sorry, but it is not a production language. It is a puzzle language. Many things which are straightforward in even the worst programming language are a brain teaser to figure out how to organize in the "Forth Way(tm)".

Scheme and Lua come closest to my ideal.

However, I just can't deal with 1-based indexing from Lua. Sorry. Too many things talk to C API's.

Scheme is okay, but almost none of them are truly small anymore. Even the ones like picobit (https://github.com/stamourv/picobit) require quite some grunty support from a desktop machine outside the processor.

Shame no one told NASA what a useless language Forth is.

http://web.archive.org/web/20101024223709/http://forth.gsfc....

I would be very interested to hear from someone using Forth in production (especially for something like the above link) on their personal experience wrt its advantages compared to other available options.

one of my very first jobs we had products for monitoring underground petrol tanks and petrol (gas, even though it's not a gas ;-) ) pumps. All written in forth, while a bit obscure, actually was quite cool.

as an aside, The guy who was primarily responsible for that now has a FRP library ( http://sodium.nz/ ) and written a book on FRP using petrol pumps as an example

It was also used for some of the drivers of a probe in the Rosetta mission (I think, at the very least it was a probe made by the ESA)

With 16k RAM, you won't get much. But the ESP8266 has 64k + 96k RAM and runs things like Lua and MicroPython. So now imagine what you can do with the ESP32, which has 416KB RAM.

If you ignore the external memory the SAMV71 on the Grisp-Base has 384k on chip memory ...

We plan to use this for the inner loop of the Erlang VM since its much faster than external memory. But thats a optimization for later after we can actually ship boards (QI 2017)