-
Tue 2019.07.23
above #4 'The USART will be communicating with another microcontroller'
@indianajones, I started a project with the same/similar requirement just two weeks ago:
Running low on available pins, so searching for another solution. It appears I may have to resort back to the USART solution, but without a signalling pin. Still a couple of weeks out on getting back to that. Should you find some success, would you mind posting a few snippets to present some ideas please? That would improve my awareness on how to find the solution to this goal. When completed, I'd be willing to create a tutorial for this very subject, unless of course, someone has the desire and beats me to that completion. wink, wink
' be executed by the node event loop'
No experience with node, but is your question base on the similar loop function concept that Arduino uses? I stay away from the loop concept with Espruino, favoring the setInterval() function instead. And link in #3
For #5 The next comment beneath the one you referenced,
'// Advanced: If specified, the given pin will be read whenever the watch is called
// and the state will be included as a 'data' field in the callback'I've not used that option, so I'm unsure. My impression is that the compiled code is just referenced/utilized within the hardware interrupt, at that level, when it occurs. The same callback that is provided will be executed either way.
I'll defer to @Gordon as he would be the better source to answer your #5 question. Please be patient waiting for an answer as new Espruino features are his main priority currently.
You are reading a single comment by @indianajones and its replies.
Click here to read the full conversation.
Robin
@indianajones
Thanks everyone for taking the time for thoughtful replies.
I have a little-more-than-basic understanding of js and node, which is what prompted the questions. Of course, I've never run this on a microcontroller, where there is no mouse, hard drive, display, etc to manage at the same time -- which gives one hope! Because I have no plans for any code to be long-running (just "get in and get out"), I'm hopeful that the js code will be able to perform with a real-time feel to it.
The USART will be communicating with another microcontroller, sending and receiving messages at -- hopefully -- 10ms intervals. It will never be a stream of data, just a message payload sent at a pre-determined interval. The payload would be less than 1kb always, and frequently be less than 100 bytes. So I doubt I'll have problems overloading the buffer (unless I do something in the code that's long-running). BUT, there are commands in that buffer which the javascript will be executing: perhaps turning on/off an LED, bits like that. So there IS work in there, I just don't think I'm I/O constrained.
At the moment, I have no code that needs to run every XX milliseconds "just because"; I'll only have code that will run as a response to external stimuli (button press, that darn slider pot), and to commands from the USART. So I chose setWatch.
Yeah that slide pot is the big worry, because the code to handle a change in the pot would be something like:
potCallback() {
}
If the user is just reaming on the slider, generating tons of these callbacks, while messages are coming IN to the USART, that's where I worry about latency becoming a concern.
I could also slow down the watches and USART to 15ms to allow for more breathing room - that's still 66 updates per second.