What is LED1/A13? (addressing pins via variables) #3959
Replies: 1 comment
-
Posted at 2014-02-06 by @gfwilliams Hi, The issue you have is that Espruino doesn't keep built-in variables/functions in the symbol table, because there's just not enough RAM. That means that while you can access a variable or function by name, you can't access it as if it were an actual member of the object. It's something I'm hoping to fix - there is a bug open for this but it's a reasonably big change. However nothing stops you from doing:
or even:
Or if you're still absolutely set on accessing everything by strings, you can do:
Note that because Espruino executes from source, there isn't much overhead to running Hope that helps... Posted at 2014-07-17 by @allObjects [1v64] - Hi, from a programming point of view I feel like Richard, and from a resourceful one I understand very well Gordon's implementation. Since obviously RAM is the constraining factor, I might cave in on some of my programming paradigms and expectations. I do not (yet) know engine implementation details, but could imagine a solution with a federated symbol table - (current) RAM symbol table and a ROM symbol table. Lookup - and many other things - will of course have to be adjusted. The 'many other things' is I guess what Gordon refers to by 'reasonably big change'. For myself - in the spirit of my user name - I solved the variable access challenge as follows: LED is a singleton or class object knows all about the LEDs and has a s(et) method accepting the led i(d) and a on/off (true/false) evaluating v(alue) as parameters:
Switching LED2 on and LED3 off is achieved by the following statements:
The LED1..LED3 are mapped to the ids 0..2. If you like to preserve the index of the led, modify the set method to look like this:
The 'program' for a running light Red(LED1),Green(LED2),Blue(LED3) is implemented as an singleton object as well:
The commands RLL.r(1); and RLL.r(0); start and stop the running lights. To start and stop the running light with the espruino onboard BTN1 button, add a button up .c() check method that toggles .run() with start/stop. Note the start of the repetitive button checking by its immediate invocation after definition: RLL.c();. The immediate invocation of the repetitive button check can be left out, but has then to be issued as a command. Paste the complete code below into the edit area of the IDE, send it to Espruino, and push BTN1 button.
Posted at 2014-07-17 by @gfwilliams Hi. Thanks for posting up. Having to have the array of LEDs is a bit of a pain... It's good that you reminded me - the 'reasonably big change' is actually done now - for instance you can now write Posted at 2014-07-17 by @allObjects [1v68] - Hi, very cool! ...weeding out - or at least mitigating - the differences. Do I get this right:
returns the function object (as would
as well), and a following
calls the process.memory function - invokes memory method on process object? Btw, using Espruino is a very capturing journey! Working on a (Espruino) JS survival micro framework and software buttons (BTN1). Latter would really benefit from being able to tap into/connect to hardware interrupts. Posted at 2014-07-17 by @gfwilliams Yes, you're spot on about process.memory. Have you seen setWatch? That uses interrupts internally. Posted at 2014-07-18 by @allObjects [1v64] - Hi, thanks for the friendly - (somewhat) embarrassing ;-) - 'hint' to look for setWatch(). I must have read '...that Espruino does not support hardware interrupts...' in a very early/old (or not very informed/educated) publication. That's why I came up with a software solution - shared below with - for now - only a few comments. I'm a bit embarrassed because my style of approaching a new language (extension) or library is to study the whole API/specs first before venturing into doing by mapping my programming patterns into particular target designs/implementations... But I just got the board from Adafruit and had to get my hands dirty to quench my curiosity. The setWatch() will not only simplify the code dramatically, but free up lots of cycles for other things than just watching and interpreting 'bug leg moves' and setting up and handling of timeouts. Interesting is the similarity of some of the parameters - last but not least the debouncer. The debouncer's implementation had to wait until my day job concluded. But with setWatch(), it may not even come to actual life. (So far, the hardware button is not worn out yet and therefore the software buttons works pretty predictable. More details following the code). Beside the button handling, the code has some interesting features. Implemented in a so called 'JS survival/micro framework' w/ single global muej are:
And all this in almost pure, very easy to use, object-oriented fashion.
Originally, I had planned to make the code the subject of a multi part post/series with tutorial like comments... A perfect, fun tutorial that requires just the board and still have a UI and UI interaction. Now it is out there as a whole... and already outdated... :(] Most interesting is the button BTN1 handling and making it software-wise multiple buttons by loaning the ideas from http://en.wikipedia.org/wiki/Morse_code, developed 1836 by Samuel B. F. Morse... some 'things and thoughts' just never go out of style! - I was trained on it in the army in the signal corps. The Bnt1 object detects sequences of short and long presses. It decodes them into strings of "S"s and "L"s; for example, two short presses are decoded into "SS", and a short, long, and short press into "SLS". Once detected, the string is used as the topic to be published with some other parameters, such as the time. Any subscriber will be notified aka the subscribed function is invoked. In the running light RLL example, one short press ("S" topic) toggles the lights on and off. Two short presses ("SS" topic) make it run faster, and two long presses ("LL" topic) make it run slower. Try it yourself... PS: Gordon, did you notice the IDE's syntax coloring issue in line 8? Posted at 2014-07-21 by @gfwilliams The whole interrupt thing is a bit confusing - but if you got the idea from the website, let me know where and I'll try and reword it... Basically: You can't run JavaScript in an interrupt. But that doesn't stop the interpreter itself from using interrupts. When you use setWatch, the interpreter itself uses interrupts to accurately timestamp the event - which is then executed when the current bit of JavaScript finishes. For stuff like The multiple button thing is a great idea! It'd make a really cool module. Perhaps you could go properly morse code and change I didn't notice a syntax highlighting issue... Could you post a screenshot? Posted at 2014-07-21 by @allObjects The setWatch is absolutely clear... at least to me... that's why I said I'm a bit embarrassed not to look through all the provided functions before venturing into my own implementation. Regarding 'Basically': this became clear to me when some release notes mentioned, that the event buffer size was increased from 64 to 128. Before my work life, I was more a hardware mind - tinkering with germanium transistor OC72... (a black painted glass housing filled with transparent heat conducting paste) and I still love hardware, because you can touch it and you actually can 'see' when something goes wrong (...the heat conducting past developed bubbles... another kind of interrupt). Back to the interrupts we are talking about here: When starting to work with micro processors - Zilog Z8 - to build an in-cable protocol converter - interrupt serving time mattered for timing - and still does, just in a different way. Explaining the setWatch to myself would read like this: Set watch registers a JS function with the particular pin. Depending on the raise or falling or both, the core - or basic 'operating system' puts the JS function into a first-in-first-out (FIFO) buffer, from which the JS interpreter later pulls it and invokes it. Putting the registered function into a FIFO is - time wise - predictable and defines the rate of how many interrupts can be noticed until getting lost, and the FIFO idea assumes that over time all interrupts can be served, because interrupts come not continuously and therefore the serving can be queued. This may though have ramifications for the interrupt service routine (function) implementation with time dependencies, because with the deferred execution 'things' may already have changed again and have to be newly interrogated to make the proper decision. Catching key strokes have a different dependencies, and in order to handle time sensitive sequences, the time of the even is recorded in the FOFO as well. Above 'definition' raises several questions: can a pin have multiple watches set? For the sake of simplicity and basic usage I assume not... that's why I use the pub(lish)/sub(scribe) mechanism which allows me to register with one single setWatch the pub, which in its turn reaches any number of subscribers. Another question is: How can I check 'how full' the FIFO is in order to, for example, tell the user 'to slow down' his activities? .itr() does about the same as .forEach() within a few 'nuances':
Regarding, for example, Posted at 2014-07-21 by @allObjects Notice the syntax coloring difference in line 8. It is a Attachments: Posted at 2014-07-22 by @gfwilliams
Yes, you just use setWatch multiple times on the same pin and it works fine. You can even have different levels of debounce on each watch.
I'm afraid you can't. You can however use E.getErrorFlags() to see if the FIFO has got so full that data has been dropped. Syntax highlighting - that only happens online, and not on the Web IDE? For some reason the forum software thinks it is a reserved word :) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-02-06 by RichardBronosky
I'm very confused by the JS in Espruino for many reasons. I want to start off addressing this simple concern that I believe will also be useful to many others.
I want to address pins whose names are stored in variables to make the code considerably cleaner.
Consider this:
That's pretty amateur. It would be some much cleaner/DRYer to do:
It would be splendid if that would work in the same way this works:
But it doesn't. It seems to require a limited switch/case.
So, what and where are these LED variables an how can I address them programmatically?
Beta Was this translation helpful? Give feedback.
All reactions