Avatar for allObjects


Member since Jul 2014 • Last active Sep 2018

Very excited about Espruino! JS is just a great, universal language that provides me - thanks @Gordon's implementation all essential programming concepts there are available on STM32 ARM 3/4/... MCs. The Espruino boards and accompanying Web and native IDEs are the perfect means to do IoT the easy way, including hardware access thru the many modules already available. The relationship between me and The Flintstones is about the same as Espruino and Arduino, or JS and C... not that C-a-likes are not of use or are not needed anymore for certain things, but I can get practically all of IoT done with JS and some compiled JS.

Most recent activity

  • in Puck.js, Pixl.js and MDBT42
    Avatar for allObjects

    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,"codeNumberRepeatin­gAndMatchingMessageAsString") 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();
          cds = cds.substr(1);
          if (cds.length > 0) setTimeout(bl,1);
    var setup = 
    exports.setup = function(pin1, pin2, logging) {
      lng = !!status == true;
      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?

  • in ESP8266
    Avatar for allObjects

    @hungryforcodes, ...was only talking from prospect of having fun with Espruino... doing business is a totally different ball game: no brain time can fix money set in sand. Like running code on not pre-validated data and then being scratching the head about surprising results. With great numbers of IoT devices in the field all over the place and failing (intermittently) there, fixing an issue is not just producing a few more to drop the non-passing with them in the factory.

    What burn-in tests of the final product do you have? ...and how long are they running? Does the burn-in test run additional code - on top of the intended application code - to do stress test beyond the regular stress limits?

    What is the test result gathering / presentation and degree of automation of the test(s)?

  • in ESP8266
    Avatar for allObjects

    @hungryforcodes, thank you for validation. Sad to hear about thinks like flash memory corruption - that's as bad as it can get, and all bets are off. Saving a green buck and spending many (hours) grey (brain) bucks... including the one of others. - Yes, sometimes the most precious and not replenish-able resource - time - is more readily available than money, bottom line (over time) though, time always is in shortest supply... (maman, never mind my assumption).

  • in Projects
    Avatar for allObjects

    ...I guess @rmd6502 wants to go for the retro look... last but not least his screen name affinity to the famous 6502 - I'm I right, rmd6502?


  • in ESP8266
    Avatar for allObjects

    @maman, I'm not surprised... because a 8266 is just one processor and a very significant part of its processing capacity is Wifi stack ASSIGNED... and if it does not get it... it flunks. 8266 timing has hard stops: every x ms the Wifi stack expects the full processor being available to just do Wifi work. If processor is tied up with something else... Wifi / all 8266 crashes.

    What though seems fishy to me is the sequence you get without even doing something... so I can think of bad connections, iffy power supply, etc. (assuming setWatchI() actually works on 8266).

    Even though 8266 is very popular and many things can be done with it, it is not though to do other things than serve Wifi through AT commands. Period.

    Get a Pico and combine it with your 8266 - or better: get a Espruino-Wifi, and you are best off, because the embedded dedicated (slave) 8266 does Wifi very well and you free what ever to do on the JS side.

  • in Projects
    Avatar for allObjects

    ...there you go... just a few more digits... Retro Bubble Displays driven with 74HC595.


  • in ESP8266
    Avatar for allObjects

    I'd always put retry invocations to and/or within self into a setTimeout() in order to 'loose' context... and let resources go... yes, it may be in a callback, but still, code-connected things/references keep things a-life and resources blocked...

  • in JavaScript
    Avatar for allObjects

    ...it looks like hat you have some left-overs in your Espruino...

    g is nowhere defined in that snipped, so I expect it came from previous post... but it also could come from some internal that the interpreter looks at, does not find it a bindable, but thinks it is a number.

    Doing things in the console without wiping every thing out, creates a lot of confusion.

    Again, I feel that Espruino is still playing tricks on you, @Robin... Espruino is a living object,... similar to the DOM of or in a Browser. Most operation on it leave some (big Bear claw) prints behind... to haunt later... Halloween is about to come... So we should get some Espruino driven flashy wearables... what about a contest, @Gordon?

  • in General
    Avatar for allObjects

    that extra line of code reads the next 100, and so on.

    @Gordon, good to get confirmed... did actually not expect to find a limitation in the code with no mentioning in any of the documentation. I'm not sure I ever had 100+ files in one of the directories, but a lot for sure.

  • in General
    Avatar for allObjects

    not really, because this is odd... may be it saves a line or a few bytes / instructions, but it's more about proprietary than solution.

    Adding a new version of soft SPI based on the existing one in the firmware is the only solution I can see. working... or use a attiny## slave with bitbanging...