STM32F7 - Espruino+ / Espruino Plus?

@Gordon, ran across these news:

http://globenewswire.com/news-release/20­15/06/25/747531/10139776/en/STMicroelect­ronics-Begins-STM32F7-Production-First-t­o-Market-with-Microcontrollers-Featuring­-Advanced-ARM-r-Cortex-r-M7-Core.html

http://www.st.com/web/en/press/p3701

Is the STM32F7 the heart for next version of Espruino?

The interesting parts are

1. F7 backwards compatibility with F4 instruction set
   
2. Built in encryption coprocessor
   
3. Special (code/data) memory for extra fast execution
   
4. ...and much more
   
   

Just too bad that there is no pin compatibility and the minimal pin config is 100pins (4x25)... so not really suitable for the Pico idea of a micro controller on a usb stick... (except components on both sides and may be 2+ layer PCB... and a price jumping throgh the roof).

Especially noteworthy is the special memory for faster execution, something that could help the Espruino interpreter... (have though no information about actual requirements in regard of resource use of the interpreter...).

Hmm... Interesting. I think I'd heard about it. Problem for me is even if I quadruple the speed of the processor, Espruino is never really going to be 'fast enough'.

I'd be better off sticking with the existing processor in the Pico (there's a possibility that the clock speed in it can be doubled - obviously voiding any kind of warranty you have with ST :), and putting some more effort into polishing the code compiler - which should give a huge performance boost.

On the software side, the available memory could even be effectively doubled by leaving read-only stuff (such as program code) in Flash.

To be honest the new processor that interests me more is (I think) the STM32L4. One of ST's new low power processors has the ability to enter STANDBY mode (so everything off - crazy low power), but while still keeping the contents of memory. It's also got UARTs that work in STOP mode (what I called Deep Sleep), so you can finally go into proper low power modes while waiting for data from Serial devices (GSM/GPS/Bluetooth/WiFi/etc).

There's also a chip that'll do crystal-less USB - meaning literally all you'll need on an Espruino board is a diode to drop USB voltage, and a capacitor. There could then be an Espruino that fitted inside your USB socket, and that cost just a few dollars.

Ic. I'm living VMs/interpreters since the end of 70'... so I do not think per se that faster is better... becuase what does it help to get the execution faster but it is so difficult to get there hat the point of execution is never reached, but it could help to solve some of the issues we noticed in the past, such as making sense out of 'noise' of a 315/433MHz cheapo receiver.

Regarding speed: The business term TCO - Total Cost of Ownership - has been created to be clear that making one thing cheap (or fast, in regard to our discussion) is not making the cut. That's why I used to explain TtM - Time to Market - is relevant when talking about creating software at the time where (Window 3.1 / OS/2 2.0) GUIs needed the (C/C++) programming of low level message handling for just everything that can happen to any (square) area on the screen... and Smalltalk was handling it just like that, but was (in the beginning until availability of JIT to platform code) not as fast as C/C++ doing it. Similar interpretative systems were available on mainframes, where still only execution speed was measured but time to market was not taken into account. With hardware getting cheaper and cheaper - still expensive at that time - development cost for the application became the more challenging point.

I notice in you thoughts a similar pattern but going in a different direction: what's the point of speed when the battery - or whatever power source is available / affordable - is drained befor the POST - Power On Self Test - completed, and the actual code is never even reached. With the IoTs going that direction that even my glasses should tell me - or my networked nearfield servers in the rooms and on my body - where I've misplaced them, and still should be very light weight... should they?

Looking forward to things hatching in your space. Have a great weekend!

I feel like there's a lot more room for fancier Espruinii within the existing STM32 lineup - have you seen the higher-end STM32's based on M4 architecture? You can get some pretty nice chips if you wanted to make an Espruino++, in terms of being faster and having more memory...

The 433mhz issue is a lot less bad than it was with the shit receivers, if you use an SYN470/480 receiver chip with like a ~5meg resistor on the sensitivity adjust, so squelch the noise. It's amazingly good. The Syn470 rx units are only $1.50 or so on ebay shipped, so about the same price as a tx/rx pair of CheapoRF ones (the cheap transmitters are fine) - I use the narrow yellow ones, search ebay for superhetrodyne receiver and look for the yellow one with SOIC-14 on it.

While the speed of the Espruino does limit it... most of the things that the Espruino has trouble with due to speed - except bitbashing serial data in/out in non-SPI-like formats, which is what is the case with 433mhz - are things that you need to use tricks to do on Arduino too.

I have to say though, sometimes I feel like @Gordon is obsessed with power consumption! I've frankly not yet had any projects where the MCU power usage was significant. When you're switching a MOSFET to dump 3.5A@40V through an LED (that's the only battery op project I've made I think - not with Espruino, since the control logic is trivial - waste of an Espruino, and also very well suited to arduino, conceptually*), do you care if the control module uses 50mA or 5mA @ 12v? I have trouble seeing interesting projects where I use small batteries - maybe I just lack finesse...

I find the most restrictive limits on my Espruino experience are that the Pico doesn't have enough serial, and no software serial, and the available memory when using the ESP 8266 in light of the artificially low limit on Pico's memory (as discussed in depth in the other thread). Sometimes I want one with more pins, but that's not that often (usually as a result of a keypad.

*The loop polling the inputs seems very appropriate for it, it's not complex enough that there are obvious improvements possible with event-based paradigm.

@allObjects interesting chip. I really like the hardware accelerated crypto feature.

In my opinion, I believe the espruino speed is good where it's at, however, I never had a project that needed lots of speed.

What I wish is for LOTS of ram, maybe 128mb :). Some of you might recommend to use the raspberry pi, but I don't like the boot up time required for the raspberry pi.

A good reason for lots of ram, but not a popular one is for a js crypto library where you can load as a js module. That way the user wouldn't have to mess with setting up a compiling environment.

Maybe the next version of the espruino should stay with STM32F series chips, but choose a processor that allows the use of external volatile memory (maybe 128mb?) that can be added to the circuitry. Does a lower end STMprocessor that supports that feature even exist? I know there is a thread pertaining to using an eeprom, but I think that's different than what I'm referring too.

@d0773d, the challenge with external memory is the number of pins... making it serial makes sense... If you go with 16 bit bus with, addresses have to be multiplexed and data has to be read in two steps... 19 control lines at minimum - pins - would just go for the memory and be lost for IO... now there are tricks to get around of this, but only with external buffers, which make a general purpose board just more difficult to realize. @Gordon is thinking of keeping the code in the eeprom which frees some - major amount - of the ram, but I do not know how far that has come. Instead of overloading one chip, I could think of adding external chips for some of the not so common things.

@allObjects which makes sense as to why microprocessors have limited ram and why someone that requires lots of ram should use a raspberry pie.

@allObjects you mentioned serial ram, MRAM seems promising.
In regards to loosing IO, are there such chips out there to convert an IO to I2c? I.E serial to i2c and etc....?

If you want to use it like main memory, you need to use a pin-hogging form of memory, but plenty of ST's ARMs support it (the F10x series includes at least some chips that do, see chapter 21 in reference manual). This would be a good way to blow away the memory limit in an Espruino++ - I think you include the memory on the board, so the pins aren't as costly as if they were broken out

...another kind-of-pico thing... arduino in sd card.

I would though have expected a little bit a different setup: the microcontroller would - in programming mode - emulate the SD card interface, so writing a file to the card would be like sending a sketch over to it. In run mode it would work like the creator accomplished... (the SD card has a lock - read only - switch which could have been used to distinguish between the two modes).

May be we will (now) end up with a EspruinoSD? ;-)

Radio

I'm hoping I'll be able to get compiled JS code running reliably in an IRQ. If I can do that then radio should get better even on the cheap modules... I do need to try some of the slightly better receivers though - they'd be really helpful.

sometimes I feel like @Gordon is obsessed with power consumption!

:) It's an excuse really. I feel there's a bit of 'competition' from small Linux-based devices, that undoubtedly have much faster V8-based JS implementations. I don't want to move out of the area where Espruino is really good, into an area where it looks bad compared to other devices :)

Software Serial

I've been thinking about this, but personally I haven't had a need for it so hadn't prioritised it. It shouldn't be too hard. I just made a bug for it, and I'll try and get around to it at some point.

What I wish is for LOTS of ram

Espruino was designed (with the JsVar blocks) so that it could use external RAM if needed, although I never actually went as far as making that happen. It shouldn't actually be too difficult to make a build of Espruino that would use external RAM - it'd obviously be slower when it had to drag stuff out of RAM, but when executing from its internal 'cache' it shouldn't suffer too big of a hit.

But for the moment, just doubling the available RAM seems like a good start - which could be done on existing chips by keeping the read-only data in flash memory (and out of RAM).

@Gordon, the I 'understood' the Espruino JS engine, this is really a cool, optimized thing to have the JsVar blocks (with the simple garbage collect) and the option of running the structural information in the RAM and the (bulk of the) source code in (EEP)ROM. At a later time, I could even imagine that the structural information could be generated on upload and put in the (EEP)ROM as well (a parallel pattern to code maps).

I just checked out those STM32F0x2 controllers you mentioned @Gordon and they do look handy. Not just the size and not needing so many external components, but they've got some handy features built in too (HDMI CEC, CAN, capacitive touch, etc.). I was wondering about decoupling capacitors though, as I also noticed you don't have them on all power pins of the pico. Have you found that it's overkill to have all of them?

As for the STM32F7, I do like the idea of a beefier espruino for some applications (robots, "central" home automation controllers, graphics) where you don't want an OS overhead, but I agree that small and low-power is your core market.

Yes, it seems pretty reliable without all the caps. I probably should have stuck more on, but there's very little available board space, and the 'main' capacitor isn't electrolytic, so has quite a low resistance anyway. I think the small size of the board really helps - it's not like there are long traces on VDD that make it susceptible to interference, or a big voltage drop from the regulator/main capacitor.

I'll be putting the next revision of the board through CE testing and have already pre-tested the existing board, which passed just fine - so the lack of extra capacitors isn't causing issues with radiation either :)

Having something with a bit more oomph might be nice in the future though - maybe ST will release a 168Mhz (or more) clock device in the UFQFPN48 pack at some point :)

... I still want to try doubling the Pico's clock though. I think it might be possible - especially if it were for small periods of time ;)

I think at the moment my priority for a 'new Espruino' - which could be a while off - is to put a radio on board. Having been using Espruino's for quite a lot of stuff in the house recently I'm getting thoroughly fed up with getting them connected. WiFi is still a bit of a pain - especially as my router keeps dropping out and will need replacing soon - and when that happens I'll be crawling around in the loft with a Laptop, changing my WiFi credentials on each board!

Hmm? Just make your new wifi have same ssid and pw as the old one....

Just make your new wifi have same ssid and pw as the old one....

Ok, that might be a better solution :)