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
On lower level function paths with multiple writes, manage the writing of the -csPin yourself because you know what is going on. For higher levels, you handle it in the top level function.
If you need to write multiple things, you set -csPin as first thing, then you do the multiple writes without passing the csPin as last argument, and for the last write you pass the csPin. Yes, the idea is that the -csPin stays low until you are done. For a single (occasional) write you pass csPin with every write as last argument.
Yes, inline C (and compiled methods) are faster as long as you have not to resolve references by name. If you can pass all data into the C code at once, complete everything within, that works great. Works especially great for bit manipulations within contiguous Uint8..32Arrays. For calling functions / methods that expect the caller to be in JavaScript adds some overhead... after all, the main is in JavaScript... and if something is too slow and used often, it usually gets into the firmware (and built-in module or even omni-present class/function).
For most situations - especially with Graphics buffer - @Gordon has already taken care of by providing options in the setup. If you though think about partial update out of a graphics buffer, the pulling out and prepping the array for the display, it is for sure helpful (I used it here: Efficiently moving things around in zig-zag Graphics buffer visualized w/ 24/32 bpp displays / neopixel strings).