You are reading a single comment by @Gordon and its replies. Click here to read the full conversation.
  • Hi! I don't generally work at the weekend so I'm afraid I'm a bit slow to offer any help here.

    I did indeed see that FIFO buffer error at least once .. but definitely not every time.

    Yes, you wouldn't - once reported it doesn't get sent again unless the error flags are explicitly cleared (as generally repeatedly reporting it just compounds any overflow issues).

    I'm not sure of the rationale for executing each line as it uploads - I can see that any setInterval could fire for a function not yet defined

    Basically on a microcontroller you haven't got a whole bunch of RAM available. If you had to store the whole program in memory and then run it, you'd be extremely limited by what you can get in - you basically need double the amount of memory (one for the text version, one for the version that's just been interpreted).

    You can save to flash with Save on send and execute from there, but then you don't get the same ability to 'tweak' your code while it's running and then save the state of it (a bit like a PC hibernating).

    It's a bit of a compromise because we're trying to cram a JS engine into sometimes quite limited microcontrollers - but hopefully when you're used to it you'll find it's worth it!

    I could see I was getting syntax error on code I hadn't written - some sort of corruption.

    This is almost certainly your code, but with sections missing? Or errors can get thrown from modules like DS18B20 but they're unlikely to be syntax errors.

    My laptop is an HP Spectre 360

    If it's connected to the Pixl via Bluetooth then you can be pretty sure it's got Bluetooth LE. I haven't heard of cases where BLE is working and connecting but losing some data, so I think given what you've got so far, you're probably fine.

    I just tried the code I posted above and it works fine with the DS18B20 between GND and 3.3v.

    However, one thing to watch out of is that the OneWire implementation is software-based, and unfortunately the Bluetooth stack has to take absolute priority or the Bluetooth connection will drop out. It means that while you're connected by bluetooth, getTemp may return null every so often if Bluetooth has jumped in and messed up the timings. When you're disconnected from Bluetooth it'll work perfectly though - and it's easy enough to work around by just calling getTemp again...


Avatar for Gordon @Gordon started