You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
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.
@allObjects
@russdx, doing things directly - without intermediate or sub controller - in javascript can become quite demanding... not just from a processing/cycle point of view, but also from a memory consumption point of view.
The combination of driving a decent sized display and driving it over SPI pushes the envelope. As @Gordon points out, there is always the option to become a sub and dive into assembler for selected operations. Even with a SPI driven sub controller - such as IL9341 controlling a 320x240px color LCD - updating the LCD becomes a challenge when Espruino has also to do some processing at the same time. For example, receiving GPS sentences, parsing them, and updating the display required me to go for optimizations, such as partial and staggered/skewed updates, in order to keep up with the 1Hz GPS data rate... most of the time :(. For code and video clip see uBlox GPS and 320x240 TFT LCD w/ touch screen post. There is though hope for you: In my case, Espruino does A LOT of processing - even heavy graphical processing: it generates the font... You may also look at my other posts related to driving the LCD.
Your suggestion to go with the PLT-2001v1 - which notably is a dedicated processor AND runs already at 100MHz (vs. 72Mhz) - looks to me the way to go.
This is not at all to put down Espruino, but specific bit banging and memory buffering tasks is - imho - not what Espruino as a board and as a language/SW environment is targeting. What it though does in combination with sub controllers handling those tasks, is the quick and easy programming the overall control job. Passing on/thru of larger data amounts though has to happen in streaming mode. Receiving an update of a 192x32x3 bit 'image' is close to 2.5KB and quite a lot for a store-and-forward. Im sure you have control over how your updating server can deliver the 'image' data and you could break it up in chunks. PLT-2001v1 would have to have at least a 2-page buffer capability to have not garbled display while the update is underway.
Alternative for temporary storage I use a F-RAM / Fe-RAM / M-RAM technology, which has the advantage of no wait cycles over the use of SD cards.