Search results for:

The loss in efficiency does affect strings as well, but I think that given the rise in available variables it probably has a net benefit.

Thanks... With the bmp180, does it also fail on 'normal' builds? If so, that is almost certainly 32 bit as you say.

For the first error, does that fail on 'normal' 1v67 too? It seems like it might - my guess is that you're parsing invalid JSON and that it now throws an exception. Perhaps it shouldn't? I'll have to look at the docs...

Ahh. It's probably worth trying to find a quick git howto - but git pull updates an existing repository rather than git clone that creates a new one.

Everything is saved that you'd expect if you took a 'snapshot' of memory... So:

function foo(a) {
  setTimeout(function() {
    console.log(a);
  }, 1000);
}

foo(42);
save();

will print '42' the next time around, even if it's not global.

The one 'gotcha' is that save() is executed when the interpreter is idle, so:

function foo() {
  console.log("Hello");
  save();
  console.log("World");
}

Will print 'Hello', then 'World', then it will save the state.

It's probably not a nightmare to run Espruino bare-metal on the Pi, but the second you want USB/Ethernet/Video/Sound/etc it's going to turn into an enormous amount of work :)

Thanks! It's really good to have broken this out into an Object of its own...

Do you think you could try packaging it up into a module? Instructions here.

I guess it might be handy to rename SWBtn.prototype.d to SWBtn.prototype.disable... It might make code using it a bit more readable...

@JumJum - I'll be trying to add support for different pins for WiFi (and every GPIO on the new board is 5v tolerant), so you should be able to solder the CC3000 on anywhere as long as you wire up gnd + vcc. I just mean the standard Adafruit module.

On the existing board, the pinout was arranged such that you can solder the CC3000 straight on with only 2 extra wires needed - gnd + vcc.

@DrAzzy the chip is the F401, so it's 3 SPI, 3 I2C, 2 Serial, ~8 analog in, and PWM on almost every pin. By printed USB, I just mean something like the DigiSpark. It's not fantastic, but it makes the board really thin, doesn't need a cable, and it won't ever snap off :) It also means you'll be able to just push it into a mains adaptor/battery pack for power.

No built-in Micro SD I'm afraid - you'd have to solder something on for that.

@d0773d - I don't know about timings yet... I guess when I get the first prototype back and assemble it I'll have more of an idea. I'd hoped for the beginning of September, but everything has gone a lot more slowly than I'd expected so I doubt I'll manage that now. Maybe mid-september.

You should be able to do git checkout origin/small_jsvar in the existing repository (after git pull).

Doing it that way won't let you commit any changes, but otherwise it'll be fine.

3250 vars would be pretty good :) The only bad point is that there's still the same fixed overhead of 4 bytes for long strings, so for big chunks of data it's only 12/16=75% efficient rather than 16/20=80%. The extra vars make up for it though :)

I guess even the value packing should help you out too - I'd be interested to see how many variables it uses in the new build relative to the old.

@possmann - that's not going to happen I'm afraid. It's so small there's barely enough room to get the required components in!

It'll be pretty easy to stick the Adafruit Wifi dongle on though. You should be able to solder it straight on.

@Sacha, yes - it's looking like it'll have 64kB instead of 48. I was considering an even higher spec, but really the plan is to get the cost down as much as possible so it becomes more of an impulse purchase :)

I will almost certainly KickStart this one again as the last one brought in so much publicity - I'll definitely let everyone know on the forum/twitter/etc when it goes up!

@gnz, thanks! I definitely won't be killing the Web IDE!

However because the IDE is basically all HTML and JavaScript, it should be possible to port it to other platforms or to make it so it isn't dependent on Chrome... For instance I'd love to see an Android port of it :)

Yes, there are plans :) I started the design 3-4 months ago, but it's been delayed quite a bit! The board is 0.1" thinner than the Teensy so the pinout's got to be chosen to make the tracking easy.

I actually ordered some prototype PCBs last night, so hopefully I'll have some working hardware in 2 weeks or so.

Rough specs are:

• 35x15mm
  
• Printed Type A USB connector
  
• 0.1" pad layout, 28 GPIOs
  
• Roughly the same spec ARM
  
• Onboard 32kHz crystal
  
• Same power supply arrangement as the Espruino board - automatic switchover to battery, 3-20v input voltage range
  
  

I'm quite excited about it. It should be a lot easier to include in things and much easier to breadboard with...

Well, you have 2 options:

• Use hardware SPI (in which case you must use specific pins - like B3 and B5)
  
• Use software SPI (in which case you can use any pins you want to)
  
  

For software, the code looks like I pasted above. For hardware, it looks like this:

SPI3.setup({mosi: B5, sck: B3 });
SPI3.write(my_data, MY_ST_CP_PIN);

Seemed to sort itself out!

Not quite. I did it :)

My process was to upload the code, then press the button, then save()

Yes, so it saved the state of the board after you'd pressed the button :)

Am I right is saying that the current value of the vars is written to flash...

Yes, that's basically right - except reset() resets everything - it doesn't load your code at all.

So:

• save() : save the current contents of RAM into flash
  
• power on/hard reset/load() : load image from flash into RAM, run onInit()
  
• reset() : reset everything to 'factory fresh'
  
  

It's a bit different to a compiled language, but it makes sense as there isn't space for it to store both the original state and the new state at once.

There is some at the bottom of the Quick Start:

The save() command saves the current state of the pins and on-chip peripherals, as well as all your functions, variables, watches and timers. The commands that you typed in previously won't be executed again though. If you want to execute some code when Espruino starts (for example you may need to initialise some external bit of hardware like an LCD), create a function called onInit.

and it's touched on slightly in Troubleshooting. It's hard to know where people will look for it though! It seems most people (like me) don't read much of the documentation until they actually have a problem!

Hi,

Take a look at: http://www.espruino.com/ReferenceESPRUIN­OBOARD

And the Arduino example: http://arduino.cc/en/tutorial/ShiftOut

Looks like you need 3 wires - Data, Clock, and latch. Because Espruno does software SPI, you can actually use any 3 IO pins.

The code you might use is:

var spi = new SPI();
spi.setup({mosi: MY_DS_PIN, sck: MY_SH_CP_PIN });
spi.write(my_data, MY_ST_CP_PIN);

Just wanted to add that while Espruino has a hard time turning its internal state back into text, it doesn't mean that save() suffers from the same problems as it saves the internal interpreter state.

I think that in your case, using your existing code and just saving before you press BTN1 would solve your problems. At least it worked for me :)

The issue with the code not displaying is that you need a newline before and after each section of code that you paste in...

I think the main issue you're hitting here is that when you send code to Espruino from the right-hand pane, it's executed immediately. That means if you say:

var foo = myFunction();

Then foo will forever be set to the result of myFunction() - it won't be executed each time you start. Espruino has always worked like this - it's nothing new. When you type dump(), Espruino tries to reconstruct the code that you wrote based on its current state (by adding setWatch, setInterval, digitalWrite, etc) - and sometimes it doesn't get it exactly correct.

It's most noticeable for setInterval/setWatch which return integers - so Espruino has no way of knowing that the number 2 assigned to sp came from setInterval, and not just you writing 1+1.

To get around this, it's best to put code that you want to start into a function called onInit(), which will automatically get called when Espruino starts up:

var list = [
      {"b":0,"g":0,"r":0,"s":0},
      {"b":0,"g":0,"r":1,"s":45},
      {"b":0,"g":1,"r":0,"s":90},
      {"b":0,"g":1,"r":1,"s":135},
      {"b":1,"g":0,"r":0,"s":180},
      {"b":1,"g":0,"r":1,"s":120},
      {"b":1,"g":1,"r":0,"s":90},
      {"b":1,"g":1,"r":1,"s":60}
    ];
var MIN_SERVO = 0.63;
var MAX_SERVO = 2.34;
var ONE_DEG = (MAX_SERVO - MIN_SERVO) / 180;
var ZERO_DEG = MIN_SERVO;

function posServo(deg) {
  return E.clip(MIN_SERVO + (ONE_DEG * deg), MIN_SERVO, MAX_SERVO);
}
function stopTimer() {
  if (timer) {
    clearInterval(timer);
    timer = undefined;
  }
}
function nextLights() {
  digitalWrite(LED1, list[step].r);
  digitalWrite(LED2, list[step].g);
  digitalWrite(LED3, list[step].b);
  servoPos = posServo(list[step].s);
  step = (step +1) % list.length;
}

var step, servoPos, timer, sp;

function onInit() {
  // just in case other intervals were already running when we typed 'save()'
  clearInterval();clearWatch();
  // now init
  step = 0;
  servoPos = posServo(0);
  timer = setInterval(nextLights, 500);

  setWatch(function() {
    stopTimer();
    nextLights();
  }, BTN1, {"repeat":true,"edge":"rising","debounce­":10});
  sp = setInterval("digitalPulse(C5,1,servoPos)­", 20);
}

// Explicitly call onInit, so it starts working (this time) even before you save:
onInit();

Having said that, there seem to be other issues:

• There's a bug in Espruino where it doesn't seem to like dumping a value if it is undefined. Hence why you get var timervar sp = 2; instead of what you should see, which is var timer = undefined; var sp = 2;
  
• Given timer is undefined, it looks like the button has already been pressed (and so stopTimer() was called) by the time you save() - which would explain why nothing happened in your case. I just tried your exact code here and it works fine.
  
• The missing debounce is a bug too - i'll try and get that fixed for 1v68.
  

Retransmitting is done by the chip itself. It's best to read the datasheet and you should get a pretty good idea what it's capable of.

Well, you could work around that issue with the NRF24 by changing the JavaScript code in the module. I don't have time to do it all for you, so I'm afraid you need to dig around and make the changes yourself.

I've heard good things about http://shop.ciseco.co.uk/erf-0-1-pin-spa­ced-radio-module/ - it works using serial comms, so you can actually program Espruino over it. Personally I haven't used it though, and I'm not sure if it does multipoint.

Otherwise there's http://www.espruino.com/433Mhz - which is very basic (and one-way). You'd have to make all your own transmitter/receiver code for it though, which could be hard to get right.

This branch also manages to get the block size for low-end boards down to 12 bytes, while still allowing up to 1023 blocks. It means that the VLDiscovery board now stores 500 blocks instead of 250.

Not only that but as arrays are packed, you can actually get 4x as many array elements in the boards memory as you could have before!

Nobody? :(

New build up here:

http://www.espruino.com/binaries/git/com­mits/ba9ce23084b74a18ccba91a0a88c3cf0c62­821a9/

This one not only uses variable blocks more efficiently, I've also been able to get the block size from 20 bytes down to 16. That means that on the Espruino board, where you could have got 1800 variables you can now get 2250 (I haven't updated the specs for each board yet though).

No... I think the sender is unaware of a problem - this is all the NRF module sending too many packets. You could reconfigure it not to try so many times - but then you'd just lose the data completely.

Are the modules next to each other, or quite far apart?

It looks like one of the modules is able to send data, but it doesn't get an acknowledgement back - so it just keeps sending the same packet over and over.

I think that's something in the NRF module itself. About all we could do to protect against that is to tag each packet with an incrementing counter, and to then throw away duplicate packets.

Ok, fixed. You can try out a pre-release build (once it has built) in an hour or so at:

http://www.espruino.com/binaries/git/com­mits/b7e330060a3c0d7ff1fe56583cd0e57caa7­49849

Just go there, copy the link address of the binary, and paste it into the 'advanced flasher' text box in the Web IDE's settings page.

could you use Serial1.println instead of Serial1.print?

This is definitely some issue with Espruino... My guess is that when the intervals changed (with the 32 bit switch) something got messed up. I'll look into it and should hopefully get a fix in for the 1v68 version.