using native strings to access flash is more difficult, I believe, because flash requires 32-bit accesses
Is flash still memory mapped, so is it as easy as just replacing the character read with something like:
char read(unsigned int addr) {
return (*(uint32_t*)(addr&~3)) >> ((addr&3)*8);
}
We'd need to benchmark, but if so it's possible that the string iterator could be changed and it wouldn't really impact performance that much.
write code into the upcoming native strings, which would be malloc'd
I don't think this is a good idea given there's not that much RAM - I think it'd be too difficult for most people to use... If code could be used from flash it'd be amazingly useful though?
the network code could be tweaked to put network buffers into native strings
That might give you some issues with the telnet server and reset() but it could be worked around. It'd mean that far more RAM was available to JS if people wanted it.
It feels like at the moment RAM is just sitting there just in case someone decides to do several concurrent connections. Given the lack of memory it's almost worth trying to reduce the available packet size (maybe also only allow writing of only one connection at a time), so that we can have more guaranteed memory available.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Is flash still memory mapped, so is it as easy as just replacing the character read with something like:
We'd need to benchmark, but if so it's possible that the string iterator could be changed and it wouldn't really impact performance that much.
I don't think this is a good idea given there's not that much RAM - I think it'd be too difficult for most people to use... If code could be used from flash it'd be amazingly useful though?
What about the opposite? Increase variable storage as per #1, and put network buffers into JS vars as 'flat strings'. The TLS code already has some hacks to handle this: https://github.com/espruino/Espruino/blob/master/libs/crypto/mbedtls/config.h#L118-L121
That might give you some issues with the telnet server and
reset()
but it could be worked around. It'd mean that far more RAM was available to JS if people wanted it.It feels like at the moment RAM is just sitting there just in case someone decides to do several concurrent connections. Given the lack of memory it's almost worth trying to reduce the available packet size (maybe also only allow writing of only one connection at a time), so that we can have more guaranteed memory available.