New Espruino Board

making it very easy to do EEPROM emulation nicely...

Tat's really cool... leads to virtually 16KB non-volatile RAM: two nurseries with garbage collect with only one active at one time, and when it runs out of 'fresh' memory, it can garbage-collect into the other one and fl-U-sh (erase) the first one. With one erased and one in use, autodetection of the one in use is easy and needs to be done only once on power up.

@Gordon, did you not write some code like that a while ago that could be used for something like that? ...wear leveling use of Flash EEPROM...?

did you not write some code like that a while ago

I don't think so, however FlashEEPROM could be changed to do that pretty easily (although it does wear-levelling already, so you'd only see the benefit if you couldn't to store all the EEPROM contents in RAM while doing the page erase).

Making sure that there is always a significant amout of RAM free is not a simple task...

Predictability at runtime of RAM usage is difficult and out-of-memory cpndition is a potential haphazard, especially with connected devices, such as a Web server. Malignant requests can mount a state of service denial...

Being able to contain - predict - at build time using resource planning the behavior of as many subsystemsas possible contributes to the robustness of the solution. It obviously comes with a price, in this case 50% of the resource: 1 / numberOfPages and numberOfPages >= 2. In other words, the more pages available, the more affordable it becomes. Unfortunately that is mostly defined by the design of the memory laoyut and limited placement options for the given firmware and saved code.

The time will come when interpreting code in ROM has to be implemented (interpreting directly, without paging-in)... a challenge to the existing, currently straight forward implementation, process and lfe cycle architecture...

Btw, having get and set properties' implemented would nicely support a transparent access to things -properties of 'objects' - in ROM.

How difficult is it to mark a function at definition time to be 'self-executing' - in absence of opening parenthesis IN INVOCATION SOURCE to invoke without parameters or when assignment token is detected to take the right side as single argument (and comma-separated expressions as multiple positional parameters)? (..stepping out of the language defined perimeter is not my recommended policy for living out solution creativity, but sometimes you do what you gotta do and step out of the box...)

The time will come when interpreting code in ROM has to be implemented

eval(E.memoryArea(...)) works right now, as does E.setBootCode(...). I believe you can even hack in ROM-based function code with:

function a() {
};
a["\xFFcod"] = E.memoryArea(...);

But I don't get why you need to execute from ROM - the problems you're talking about with runtime RAM usage won't be fixed by that... Sure, you'll be able to handle more concurrent requests (or whatever you're doing) but at some point you'll still run out of RAM - not because of allocated program code, but because of data that needs to be allocated at runtime.

Right now, in Espruino boards, ROM is more scarce than RAM. So much so that the contents of RAM actually has to be compressed before writing it into ROM. So despite the fact that Espruino can execute from ROM, there's very little point in doing so because you'd have to store your code uncompressed, so would actually get LESS available code space.

When you have more than enough flash memory there's actually a branch of code here that will execute everything from ROM (using RAM as a cache), including variables that aren't modified. Sadly nobody else seems bothered to do anything with it and it's been basically ignored since I did it at the end of last year.

With getters/setters - yes, potentially that could be added by adding a new variable type in Espruino. It's not high on my priority list though :)

Just curios what skew will the ESP be on the WiFi board? Base ESP-12, ESP-12E, ESP-12Q or ESP-12F?

I'm not 100% sure yet - I think realistically it's what I can find for the most sensible price.

Oh actually I don't suppose it matters, apparently none of the extra pins on the ESP-12E are actually useful :/

They're for accessing the flash memory I think - but actually none of the ESP8266 pins will be usable anyway, because the ESP8266 will be running the AT command firmware - it's the STM32 that all the pins will be connected to.

Well, the pins will be usable if you flash Espruino onto it and tack on flying leads...
I don't see how the pins would be particularly interesting in that case though, since you've got plenty of pins on the Espruino itself, all of which are a lot more capable.

@Gordon just checking at to the status of the [cheap board]? if/when it might ship.
I've joined opensensors.io and we got a education project which would be a very good fit as
Pico is unfortunately too expensive.

Hi - I'm afraid I've stopped work on it for the moment. ST are releasing a new chip that'd be much more suitable (with crystal-less USB), and I have a meeting with them in the next few months where I'm hoping I can get them interested in a cheap board.

The Pico is much cheaper in quantity though - 100-off it's £12 ex VAT... Or if you're designing a board you could put an STM32F103 on it pretty easily.

@gordon thanks for the heads up.

Aw, crap (re: cheap ones) - I was really psyched about that F0 chip with the oodles of UARTs, though I guess if there's going to be an el-cheapo crystalless USB board, that'd be a lot more compelling than an "Espruino Pro Mini"... more accessible, at least.

Is the wifi one still happening?

Yes, wifi one is still happening - I'm just making some final checks, but otherwise Seeed are good to go for manufacturing a whole of them.

Awesome!
Got the final layout settled yet? I'd love to see what they'll look like.

It's actually almost identical to what i posted up here

So it definitely has some compromises, but I think some nice things too.

I actually just heard back from Seeed and they want to change a few things (via placement and silkscreen mainly). They've obviously changed their processes and now it seems they get upset if there are no silkscreen markings for pin 1 on components.

@Gordon Great work on the new board Gordon. My 2 cents: Running an espruino board from a battery pack is definitely something I'd love. It makes it very convenient to place it in the field where you can't/don't run any power supply. (Do the power lines have decoupling caps?)

I just saw the shims on Tindie and I think I'll purchase that to start off with. They +esp8266 seem like the perfect combo to me. Agreed there are many variants of esp8266, but the esp-01 with it's features packed in a small size is ideal for so many applications.

@electronicsguy, until the Espruino-Wifi is available, I go for this interim solution: small breadboard with PICO and ESP8266 ESP-01 - both made breadboard friendly. I'm working on a ESP-09 (10mm x 10mm), but somehow it is still talking gibberish to me when I try to pull the version information. It may be that I have to flash it anyway before it can do its intended job. Before I run an standalone or reflowed on a board, I put it on a break-out board.

Do you have some experience with ESP-09?

1 Attachment

@Gordon - cool - so is that pin spacing and pinout final then? If it is, I'd like to know in time to get some project boards designed for it and ordered so I can jump on that when it becomes available. How far apart are the rows of pins?

@electronicsguy
The other Espruino boards have had caps on the power rails - though not big ones, obviously, due to space constraints. Like many, I'm a big proponent of BFC's (also, caps on the supply rails that are there for power supply filtering are usually referred to as such, while "decoupling" is reserved for ones placed close to a specific part to deal with it's current spikes, those caps are often smaller, as the smaller caps respond better to the sharp spikes in current typical of digital circuitry)

The ESP-01?! That one sucks! It only brings out 8 pins and they come with the small flash on it, so they're much less suited to reprogramming. They don't have a shield on them, so the radiate EM noise and are almost certainly not FCC compliant. The antenna is also inferior to the ones on more sophisticated modules like ESP-12, resulting in poorer range. I think the ESP-12 is the best package - you get all the pins, plus a better antenna, they come with the larger flash chip, and it's got castellated pads so you can easily incorporate it into a board design.

As far as using the board for simple AT-command wireless, ESP01 is quite nice in that it doesn't give you much more than you need. A breadboard-friendly ESP with loads of 0.1" pins would have been really popular with makers though!

@DrAzzy I'll let you know for sure when Seeed actually order the PCBs, just in case something stupid changes. I don't think it will, but you never know :)

@DrAzzy to each his own. I don't care about FCC certification. The esp-01 is a nifty lil thing and perfect for what I need.

@Gordon I don't want to hurry you, but do you have a rough time schedule for the new board?

I'd say 2 months. Seeed have the final designs now and have hopefully ordered the required components a week or 2 ago - but some of them can take a while to arrive. After that they're doing an initial batch of 100 just to check, but you could have some of those...

Sorry for the delay - I know it's been dragging on for ages. I've been trying to balance a lot of stuff recently so I haven't pushed this through as fast as I should have.

Will you be running another kickstarter campaign or selling directly?

I'm just selling directly this time - I'm interested to see what happens, and realistically it means I can get it in people's hands more quickly :)

Hopefully a lot of the existing distributors will take it as well.

I'm also working on a BLE device (with battery, case and sensors) and I'll be doing KickStarter campaign for that one...