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
#assembly #assembler #performance
Espruino Javascript is great for high-level things, but when it comes down to move byte by byte - and even worse - bit by bit - around, then the system is more busy with running all the niceties of the environment then actually doing the work. I see the hybrid approach the best... and that is genuinely taken by Espruino. Things that have to go fast are low-level implemented with an easy access interface on the Javascript (interpretative) level.
When I did graphics, such as retrieving bytes to store them away to later restore them, assembler / native is the answer... (not just because I was accessing the bytes SPI, but also the number of bytes: n bytes per pixel.
Regarding your 5KHz transmission thing... what kind of code would be in that loop of 5KHz?... because already an empty loop is slower... (see about performance). When @JumJum and I did meddle around with ILI9341 driven 320x240 262K Color LCD, speed became of essence... Even when I used it for driving a Stepper Motor in continuous mode, I touched the limit. Others have tried to work with cheap RF / wireless, and it is just not enough juice in the setup... except low level things move into native...
Therefore, for time critical things, have sub controllers that do nothing else than just run, for example, the stepper continuously, or do transmission continuously... and interface them easily with Espruino over what ever communication interface is available on the coarse granularity of whole messages / information packages, etc. Espruino may be able to run one device on a low level, bit / byte banging thing, but everything has to wait, and when the system is busy with something else and the time for bit / byte banging is there, it will miss it... (not completely because Espruino has an event queue to survive input/interrupt bursts... but that means that times of bursts have to be followed by low activity / down times so the queue can be worked through).
When talking performance, Espruino's power consumption performance has to be taken into consideration... and in that respect Espruino is at the top...