Avatar for allObjects


Member since Jul 2014 • Last active Nov 2019

Espruino makes IoT as easy as 123!

Most recent activity

  • in Electronics
    Avatar for allObjects

    @ChristianW, I picked intentionally a bit higher values because you do not want to add additional load on your battery. On the other hand - compared with the power motors consume - current draw is negligible. Important for operating sensitive electronics next to power / servo electronics requires a good 'separation'. The first cars with electronics had two batteries to make sure the power for the controlling electronics is more stable and reliable then the power for driving heavy loads (starter, window motors, etc.). @DrAzzy has quite some experience in - and sells also components for - driving power hungry devices (lights). Search the forum and go to https://www.tindie.com (do see him not that often anymore on the forum, though).

  • in Electronics
    Avatar for allObjects

    Something like that gets you to safety (even while recharging when plugged in):

                        .-----------+----| LOW R   |------- 12.5..14.5V
                        |           |    '---------'
                       .-.          |     100..120 R
                       | | 75..100  |
                       | | k        |
                       '-'         ---
    analog .-------.    |           /   13.8 - 15.0          
    in ----+ opt.  +----+          /_\  V Zener 3W
    put    | some  |    |           |   (Good Quality)
           | fil-  |   .-.          |
           | ter   |   | | 22       |
           | (RLC) |   | | k        |
           '---+---'   '-'          |
               |        |           |
    GND -------+--------+-----------+-----------­----------- GND

    You could add additional safety paralleling the zener w/ a fast transient suppression device / circuitry (TVS; google for 'transient voltage suppressor circuit'). 'After' that you can then also use the power to feed a regulator that runs you digital electronics, including Espruino.

  • in JavaScript
    Avatar for allObjects

    There are examples to push to google spreadsheet doc via wifi... and from there you can get it into excel. Get an Espruino-Pico and ESP8266 - or even better and sinpler: Esrpruino-Wifi - see http://forum.espruino.com/conversations/­269510/ and http://forum.espruino.com/conversations/­576/ and https://www.espruino.com/simple_data_log­ger

    Alternative, you can use Espruino Web IDE built-in testing feature which can log what ever data and on what ever interval you want - when connected - and pull this - with some massage-ing (.csv ?) into a spread sheet.

  • in Tutorials
    Avatar for allObjects

    With Espruino you get the event drivenness all the way thru. There is no main loop like in Arduino (checking flags in your app, flags that can be set by events or other loop participants).

    If you have it running in browser, there is great chance to get it relatively easy and quickly working in/on any BLE supporting Espruino environment/board. I did the opposite already several times: develop on Espruino boards, but for speeding up and logic testing, I setup a cross development environment in browser / html5. Things unavailable in browser, I'm 'shimming' / 'backfilling'... see conversation about Modular and extensible UI framework and ui elements.. In most recent version - not published/updated on that conversation - I even implement typical Espruino hardware dependent items, such as setWatch(). (I'm attaching current version - in transitional work / not all things work yet again - which includes major updates, last but not least in favor of resourcefulness and increased portability - .../uixdev/uiExample.html?example=all and .../uixdev/uiExample.html?example=allPix­l work, allPixl needs to be initialized with onInit button click). For details how to use attached zip see conversation mentioned above.

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

    You can check the error flags - https://www.espruino.com/Reference#l_E_g­etErrorFlags - but more details you would have to access with peek... where though is not known to me... may be it can be figured out looking at the firmware / source code...

    You can bend / spread the leads a bit to get better contact.

    Check also the battery of your puck...

    Some architectural detail:

    Espruino has mainly two interrupt driven activities:

    • Low level hardware activities that pick up pin changes and when watched it puts details it into an interrupt/event queue (similar do timeouts and intervals and completions of some low level functions, like receiving or sending data). This has highest priority and interrupts the other level of activities.

    • High level javascript activities that pick up what is in the event/interrupt queue and executes the piece of javascript that is tied to it. When done with one piece, it checks for the next one and executes it until all is done and then it goes to sleep / idle.

    Since hardware events can happen much quicker than javascript can act on it, the events are put in the event queue. To not miss any events in JavaScript, JavaScript pieces should be as short/small as possible... after all, you have only one processor...

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

    @user104751, I think you get some noise and may be additional signals that makes your interrupt buffer to overflow...

    If your receiver is just sticked into puck's thru holes and the leads do not make good contact, lightest vibration - even from loud sound / music - give you additional signals and the buffer overruns.

    With additional signals may come from other sources or reflections.

    Also, if you keep sending the buffer may overflow.

  • in General
    Avatar for allObjects

    There is a checkbox in IDE settings that seeds date and time from your IDE machine on code upload to Espruino board.

  • in News
    Avatar for allObjects

    ...Only a separate, private repository as fork of original Espruino would have kept you secure... Next time. Hahahaha.

  • in Interfacing
    Avatar for allObjects

    Fixed size block writes require simple algorithms only. It gets a bit more nifty with variable sise block writes. Of course, you can also start with the anchor to find the last written block when each block includes (at the beginning) some type/length information. For any fast access though you would go for a binary-search-like algorithm, and with minimal information at the beginning of each page (page size a choice), information about page full and stradling information (information about begin in previous page of 'record' that stradles the pages) - 2 or more).

    I do not see the need for skewing (ring buffer 'spiraling'), since it is not a rewrite. Even if you have to use page write, after the page is full, it is not written anymore. When reaching memory full, all pages would have about the sam amount of writes / wear (with fixed size block recordings).

    If memory is read out with freeing space before full, information about ring buffer begin is required any and would have to be written somewhere. Using a bit on each page can avoid that. Freeing (w/ Erasing) would then have to happen on full with inactive, delete-able and active records.

    I conclude that one can't get away with just writing application data. There is always some meta / managment data required to make it decently operable.