Instead of using the console - especially when it interferes with resources - and with BLE being the only communication channel (no USB connectivity), I uses blinking of a led or two to communicate where things run through in actively running code. See example for that in this conversation: , in posted code, lines 233..257 - around // logging / LED blinking (beginning w/ setting the variable logging to true and more so to false but still getting some 'logging' done - with application in lines 269, 292, 284, latter two logging error and success with lg(0,aCodeNumber0to9,"codeNumberRepeatingAndMatchingMessageAsString") and lg(1,...). It also makes sure that in disconnected state with no console device/display attached - and logging set to false, nothing will fill up buffers and make the system 'die'. May be I should make a module out of it... (by know I should have enough knowledge of git handling... ;-)).
A module something like that:
// mutelogger.js module
// allObjects 20180920_0
var lng = false; // log activities to console
var cds="";
var cdl=null, dev1=null, dev2=null; // 'current (code) LED', LED1, LED2
function lg(ok,cd,obj,override) { // logging / LED blinking
if (arguments.length === 1) {
lng = !!ok;
return lg;
}
if (arguments.length === 0) return lng;
if ((override === undefined) ? lng : override) console.log(obj);
var l = cds.length;
cds += "BB"+((ok) ? "G" : "R")+"LB"+blds[cd];
if (l === 0) bl();
return lg;
}
var blts= {"L":300,"S":80,"P":120,"B":450};
var blds = ["LLLLL", "SLLLL", "SSLLL", "SSSLL", "SSSSL", "SSSSS", "LSSSS", "LLSSS", "LLLSS", "LLLLS"];
function bl() {
var c = cds.charAt(0);
if (c=="G") { cdl = dev2; cds = cds.substr(1); c = cds.charAt(0); }
else if (c=="R") { cdl = dev1; cds = cds.substr(1); c = cds.charAt(0); }
if (c!="B") cdl.set();
setTimeout(function(){
cdl.reset();
setTimeout(function(){
cds = cds.substr(1);
if (cds.length > 0) setTimeout(bl,1);
},blts.P);
},blts[c]);
var setup =
exports.setup = function(pin1, pin2, logging) {
lng = !!status == true;
dev1=pin1;
dev2=pin2;
cdl=dev2;
return lg;
}
Usage examples:
setup w/ with red error LED1 and green ok LED2 and console output on:
var lg = require("mutelog").setup(LED1,LED2,1);
log error with code 3 (can be 0..9) and matching message:
lg(0,3,"3: Failed to connect"); // 3 short and 2 long blinks of the red error LED1
log success with code 4 (can be 0..9, but not 3, 3 already taken) and matching message:
lg(1,4,"4: Connect"); // 4 short and 1 long blinks of the green ok LED2
Override the logger's status for just one log event:
lg(1,5,"5: Logged to console anyway",1); // overriding an eventual mute status
Change status to write or not to write to console:
lg(0); // mute console - switch logging to console off
Returning the logger's logging status (returning 0 or 1):
var logging = lg(); // returns 0/1 for not/logging to console
...and bonus - as inspired by Smalltalk's default return of a method to return always the object if nothing (different) has to be returned - lg() returns itself - in this case the lg() function - to make cascading - repeated invocation - very concise:
lg(1).(1,3,"3:message to console").(0).(0,4,"4:message just blinks");
Btw, this is a first for me to do a cascading of invocations - when object is the method itself (global is the object here global.lg(), but is of no interest).
The setup allows to use any pin - or led or what ever device is connected to that pin, and even the same... the blinking code is the ultimate information. If you run out of codes with two LEDs - one for error and one for ok, you ignore the color for error or ok information and use red for codes R0..9 and G0..9 and knowing with R... an G... are error and ok messages.
Any takers for test? ... or even extending it to two digits error/ok codes?
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.
Instead of using the console - especially when it interferes with resources - and with BLE being the only communication channel (no USB connectivity), I uses blinking of a led or two to communicate where things run through in actively running code. See example for that in this conversation: , in posted code, lines
233..257
- around// logging / LED blinking
(beginning w/ setting the variablelogging
to true and more so tofalse
but still getting some 'logging' done - with application in lines269, 292, 284
, latter twologging error and success
withlg(0,aCodeNumber0to9,"codeNumberRepeatingAndMatchingMessageAsString")
andlg(1,...)
. It also makes sure that in disconnected state with no console device/display attached - and logging set to false, nothing will fill up buffers and make the system 'die'. May be I should make a module out of it... (by know I should have enough knowledge of git handling... ;-)).A module something like that:
Usage examples:
setup w/ with red error LED1 and green ok LED2 and console output on:
log error with code 3 (can be 0..9) and matching message:
log success with code 4 (can be 0..9, but not 3, 3 already taken) and matching message:
Override the logger's status for just one log event:
Change status to write or not to write to console:
Returning the logger's logging status (returning 0 or 1):
...and bonus - as inspired by Smalltalk's default return of a method to return always the object if nothing (different) has to be returned -
lg()
returns itself - in this case thelg()
function - to make cascading - repeated invocation - very concise:Btw, this is a first for me to do a cascading of invocations - when object is the method itself (global is the object here
global.lg()
, but is of no interest).The setup allows to use any pin - or led or what ever device is connected to that pin, and even the same... the blinking code is the ultimate information. If you run out of codes with two LEDs - one for error and one for ok, you ignore the color for error or ok information and use red for codes R0..9 and G0..9 and knowing with R... an G... are error and ok messages.
Any takers for test? ... or even extending it to two digits error/ok codes?