Search results for:

This should work just fine. I just tested it out with the exact same pin.

Have you updated to the latest version of the Espruino software? Could you also tell some more on how you wired up the LED? Finally, could you try just typing analogWrite()? This should give you a list of all the pins capable of PWM.

Hmm, good to know :). Seems like we will need some more trial and error to get these lights going.

If you don't have those arrays, could it be that your board is on a version earlier than 1v46? If so, it might be good to tell Gordon that you don't have those issues as it will make it a lot easier for him to track down the bug.

Wait, do you have the black wire of your batteries also connected to the black wire of the servos (as well as to GND)?

Have fun with the kit :).

Have you actually tried to power the board without the USB connection? That could very well be the issue since things all work a bit different when the USB cable is connected. Be sure to save your code first though on the Espruino by using the save(); command. That way the code that has been saved will be executed once the board powers up.

Your wiring seems correct though, but I don't have anything handy to test your configuration.

Actually, if you experience the same problem of all LEDs being white, I think it might have to do with this (pressing) issue! :
http://forum.espruino.com/conversations/490/

Thanks for this. The tutorial in http://www.espruino.com/Individually+Addressable+LEDs does mention that this might be needed, but it is rather hidden away and should be made more clear.

Have you tried to address other lights from your LED strip? Oddly, it seems like I can set the colour of the first 2 or 3 but once I try and set the while string they all turn white, regardless of the colour I set.

I wired the temperature sensor from the set up according to the instructions on http://www.espruino.com/DS18B20 , but all it returns is null. Nothing really that I can add as I've redone the wiring twice (power to 3.3V, ground to GND, data to A1, 4.7k resistor connecting power and data).

Has anyone tried to build the source on OS X? All requirements seem to be in place, except for the ARM GCC compiler. I am not going to start messing with a VM or building CodeBench from source as this is my primary machine unless I know of a fail-proof method to do so. Even then ... building GCC from scratch doesn't sound too appealing ...

The following code causes an infinite loop and Out of Memory warnings:

  var contents = [1,1,1,2,1,3,2,1,3,1,3,2,4,1,5,1,6,1,6,2,6,3];
  var i = 0;
  for (i = 0; i < contents.length; i = i + 2) {
    print(contents[i]);
    print(contents[i+1]);
  }

The problem has to do with print(contents[i+1]);so I assume the issue is in the use of i+1at that spot.

The following modification exposes the same, bad behaviour:

    print(contents[i]);
    j = i + 1;
    print(contents[j]);

Ha, your answer didn't really help me (as the -F flag is not available for example), but a quick look through /dev/ showed another device /dev/cu.usbmodem1411 while I normally connect to `/dev/tty.usbmodem1411. And this one works like a charm.

Maybe best to double check this, but it thus seems that all you need to do on OS X is to write to cu instead of tty. Not surprising though that it is different from Linux/Raspberry, given that it is BSD based instead of Linux based.

I am having some issues interfacing with OS X. I follow the instructions from http://www.espruino.com/Interfacing but when I type echo "LED1.set()" > /dev/ttyACM0 – obviously with the right tty – it doesn't do anything. It doesn't return to the command line and I can't use the Web IDE to connect until I cancel the action. I am able to connect using screen though.

Seems to be fixe with 1.46 :). Do you collect any release notes on new versions?

Sleep mode is available on the STM32 chip (very low power, but ALL DATA is lost from RAM). It is not currently used in Espruino (see Other sources of Power Draw below for why not).

I assume you mean Stop mode is available ... ?

• such a bit problem* -> *such a big problem*

• because the Bluetooth module draws 30mA when active*
  Could you add information on how to reduce this power? Can we write to the pins to put it to sleep? Maybe at a word on how to enable the sniff mode, as that will reduce consumption to about 2mA? See also http://www.edaboard.com/thread267303.html as you may in fact need to change the query duration. I don't have a good enough energy meter to test these things, so someone else would need to go through the trouble to figure out how you can save quite a bit by altering the settings of the HC-05 module.

There are no current results for deep sleep.

Adding a glow light with variable duration and brightness might be a very good idea, consumption-wise. Something like Math.pow(Math.sin( ..), 3) will reduce power consumption by about 60% while giving a nice glow. Brightness could push this down even further.

Any ability for a reduce speed mode where the clock speed is lowered, e.g. like the micro Python board?

It would definitely be interesting to see how low the board can go with all these things combined, e.g. have bluetooth on there where you can still communicate with the board, have a light flashing and have input (e.g. BTN1) working. I think this is also a fairly reasonable use-case. If you have the Espruino disconnected from USB you either are going to use it for the wireless capabilities, or to have it lay dormant and react to e.g. someone passing by to turn on the lights. The last use-case is pretty self-explaining, but the first use-case would definitely benefit from squeezing out as much of the savings as possible. Just my thought though :).

Excellent :) Thanks!

No problem, I think this is just the curse of having a very high level language at your disposal.

Thanks for the explanation on the timers. Do remember that a lot of people buying these Espruino's will be coming from the software side and have virtually no experience with electronics. For most of them a clock is a clock and they never consider that there might be other clocks at work as well. I definitely didn't think of it :).

Thanks for the quick response :).

About the delay: yes and no. You can make it very clear in the function description that this is only a rough delay, and that it may or may not be accurate (as I recall, you already do that at some points). While it does block the execution, it could be used with e.g. a setInterval to call it every 2000 milliseconds. Having a dedicated delay function would then hopefully free up that time, eg delay(1000) to do more meaningful things than just sit around and wait for that part of the code to execute. But getting a good implementation may take some time, I'm sure. Furthermore, other things might be more meaningful for the time being. For example an array sort or search? Or a binary tree structure? Such items are easy enough to implement on a low level, but would be prohibitively expensive to do in Javascript.

On the power issue: I actually though you couldn't do that. It says Espruino will only enter Deep Sleep when there are no timers in the reference and I assumed that both are timers. Well, especially the one with setInterval(). It then worsens things further by saying that * The System Timer will also pause*. Ouch :). Good to know though that this already works.

Thanks for clarifying the code. It was already late yesterday and details such as that tend to get lost in those cases. The code is definitely JavaScript, but the JS code you write on an Espruino definitely has a different flavour.

No idea which value causes the pow error, but it occurred when writing Math.sin(pos*Math.PI), 2) in the line that says digitalPulse(pin, 1, Math.pow(Math.sin(pos*Math.PI), 2)*cycle); .

Thanks for the performance page, first time I see it.

Overall, it would be good to have this software PWM on a lower, more barebone level for performance reasons. This code is nice to get your feet wet, but it does show how the Espruino can struggle with relatively simple things due to the embedded nature. I would also still suggest to introduce a delay() function. Where a timeout allows you to asynchronously (I think?) execute a function, a delay would allow similar behaviour during the execution of a function. I think this will simplify a lot of the code.

And now that I think of it: are there any pages on power management on the Espruino? I know that there were a lot of things you could do such as enter a lower power state or even turn off USB, but information on those things is hard to find.

Just a bit of magic and you have a nice collection of fireflies on an Espruino:

function createFireFly(milliseconds) {
  milliseconds = ((typeof milliseconds) === "undefined") ? 0 : milliseconds;
  setTimeout(function() {
    var led;
    var next = Math.random();
    if (next <= 0.05) {
      led = LED1;
    } else if (next <= 0.1) {
      led = LED3;
    } else {
      led = LED2;
    }
    var duration = 1000 + Math.random() * 2000;
    led.glow(duration);
    createFireFly(duration);
  // activate the new firefly after the current one is done, 
  // with an added delay of at most 1 second
  // though every so often ... it may take a bit longer
  }, milliseconds + Math.random() * 2000 + (Math.random() < 0.01 ? 5000 + Math.random() * 10000 : 0 ));
}

Here is an extended version of your last code to glow an LED. There has been a bit of a comment explosion, it allows you to specify the duration and the Hz, and it has an improved glow by taking the power of the sine function, so that only the peak is very bright. I would like to go to pow( .. , 3) but ... floating point error ;).

// add a new function to all pins to glow
Pin.prototype.glow = function(milliseconds, Hz) {
  // see if the user specified a Hz
  // if she/he did not, we default to 60Hz
  Hz = ((typeof Hz) === "undefined") ? 60 : Hz;
  // save the pin: this is important, as in an internal function
  // 'this' would refer to the function, and no longer the pin.
  var pin = this;
  // remember that to achieve a certain Hz, we need to 
  // have cycles every 1000/Hz milliseconds
  var cycle = 1000/Hz;
  // we need to cheat a bit and take pos > 0 since
  // sin(0) = 0 and digitalPulse does not accept 0
  var pos = 0.001;
  // next, we create the function that will call our digital pulse
  var interval = setInterval(function() {
    // we send our pulse, and we use the sine function to determine the length
    // the use of Math.pow( .. ) will epsecially lower the lowest values, while
    // keeping 1 almost 1. This will help to ensure that only the brightest
    // part of the glow is truly bright.
    digitalPulse(pin, 1, Math.pow(Math.sin(pos*Math.PI), 2)*cycle);
    // we advance to the next position, determined by 
    // how long we want one glow to take
    pos += 1/(milliseconds/cycle);
    // if we are done, we clear this interval
    if (pos>=1) clearInterval(interval);
    // finally, we launch this every cycle, where the dimmer cycles
    // will have a shorter pulse and the brighter cycles a longer pulse
  }, cycle);
};

Your code needs comments :). I like the approach of prototyping. But there is also a bit of dirty playing here, like starting from pos = 0.001. Might not be so obvious to most. The first code is too much though, no idea what it is doing I'm afraid. Furthermore, I think that the intervals function is undocumented?

Brings me to something else though, why not

1. Build a reference of the javascript that is implemented, so that it is easy to see what is and isn't in there; and
   
2. Provide space and speed complexity for the functions, so that you can figure out which functions you should use.
   
   

The second piece of code is nice though. I'll try to elaborate on that version.

I have myself some pulsing LEDs ... but the journey there wasn't all that smooth though.

First, the code:

function fakeAnalogWrite(value) {
  if (value >= 0 && value <= 1) {
    var on_time = (value*25)|0;
    on_time += 1;
    digitalPulse(LED1, 1, on_time);
    digitalPulse(LED1, 0, 27 - on_time);
  } else {
    digitalPulse(LED1, 0, 26);
  }
}


// pulse LED1 from on to off every *freq* seconds
function pulse(freq) {
  while (true) {
    for (i = 0; i <= Math.PI + 1; i = i + (Math.PI)/(freq*27)) {
      fakeAnalogWrite(Math.sin(i));
    }
  }
}

I would be happy to write a tutorial for this code, but first I want to know if any improvements can be suggested.

The problem with this code is that it halts all other things that are going on. Which isn't all that efficient. So any suggestions on how to improve this would be appreciated. I realise that this can be easily implemented on a lower level (and it should be implemented on a lower level), but the example is great in finding out how well this compact version of JavaScript works. And I have a number of suggestions:

1. a delay function would be great. I had to do a lot of tinkering to get this to work, and essentially I'm abusing the digitalPulse by setting it off for some time. A dedicated delay function should be better, as it can be improved over time to allow other functions to run while this part is just waiting.
   
2. using setTimeOut was pure misery. I honestly failed to write any of it down, but I got bugs, missing functions, memory overflow ... . If someone is brave enough to rewrite it using setTimeOut, maybe we can get started with making it a bit more useful :).
   
3. there does not appear to be tail recursion. This is a shame. It is so easy to detect (just a function at the end) and it makes code so much more compact. Any plans on implementing this (soon)?
   
4. Using the LEDs could be easier. Why not add some prototype functions to them such as on() and off()? Okay, seems like you have set() and reset(), but those names aren't that obvious :).
   
   

quick update:
the problem with setTimeoutis that these things don't seem to work:

function pulse(freq) {
  setTimeout(doPulse(freq), 1000);
}

which fails with ERROR: Function or String not supplied!.

another update:
This is already a bit better and at least allows you to stop the execution:

function doPulse(freq) {
  for (i = 0; i <= Math.PI + 1; i = i + (Math.PI)/(freq*27)) {
    fakeAnalogWrite(Math.sin(i));
  }
  // send an extra short pulse on to turn the LED off
  // the more obvious LED1.reset(); does not seem to work
  digitalPulse(LED1, 1, 1);
}


function pulse(freq) {
  setInterval(function() { doPulse(freq); }, freq*1000);
}

But some messy stuff is going on with the pulse at the end ;).

Sounds like fun. Might try a JavaScript implementation of PWM tonight.

When we use a variable to store an Integer, is there a maximum on the Espruino board? The official maximum for Javascript is 2^53, but I don't know if this holds up for the Espruino.

Furthermore, is there a performance maximum? I would assume that smaller numbers are more efficient since they are easier to represent and can fit in one register. Up to what maximum number would performance be best?

Finally, I assume that the chars in a String range from 0-255? I looked through the reference, but I could not find any description of how to use Unicode chars so I assume those are not supported?

In the reference on the function analogWrite an example is given where you use it on LED1, namely analogWrite(LED1,0.5,{ freq : 10 });. However, the code example on Pulse Width Modulation (PWM) specifies that PWM is only available on certain pins, and LED1 is not one of those according to the reference.

Is it possible to have a pulsing light or not?

I will try to scale the font and see if it happens again. I wouldn't mind a 3x5 font though. Especially when scaled the current font is very heavy and takes up a lot of space. Since both flash and screen space are precious commodities, I wouldn't mind a font that it a bit leaner.