• Thank you mate, I VERY MUCH appreciate it

  • Ok, so I just looked at your code, and it looks like you'd disabled playing sound in it? I had to remove a return statement in playSoundFile. I'll post up here as I think it's useful for everyone though.

    Also just a note - I'd avoid putting save() at the end of the code you upload as it upsets the Web IDE. To test, add 'setTimeout(onInit,100);` if you have to - otherwise just type it on the left-hand side.

    I got the out of memory error you were having, but I think that's because just because you were using up all the memory rather than an actual bug in your code. If I deleted the two images and drawImage statements you had it seemed pretty reliable (I'd also replaced the DS18B20 code with E.getTemperature() to use the internal sensor - as I couldn't be bothered to wire a sensor up :).

    Memory goes up a bit when playing, and then drops off when it's finished - but it always goes back to the same base level after startup, and it's been working for about an hour now without issues.

    So it's basically just a matter of making your code use a bit less space...

    • Try with a smaller waveform buffer (var w = new Waveform(1024, {doubleBuffer:true}); still seems to work well for me). You might be able to get away with 512, but it's possible you'd find the waveform stutters a bit.
    • You can put comments in, but it's best to put them outside your functions. Putting them inside uses space (unless you minify!).
    • Or turn on minification in settings (using Esprima is fastest) - that drops memory usage from 1700 to 1470ish
    • Turn on 'save on send' in settings. This saves your complete source code into flash memory when you send it over (so has the same sort of effect as save() - which you should remove). However, it executes the functions straight from flash memory if it can. It means the memory usage (with minification) drops to under 1000 vars and gives you a lot of leeway. Only issue is you're best using it with minification, as otherwise all comments get saved, including the ones outside functions.
    • There's some info on writing code to make it more memory efficient in Espruino here: http://www.espruino.com/Performance - it might help, but I'm not sure there any many easy fixes for you, apart from maybe trying to keep function/variable names a bit shorter (but there's no need if you're using minification).

    Hope that helps - but yeah, I think you're basically fine. If you absolutely need more then there's always the Pico - it'd need more wiring but it does have a bit more RAM. There's also the WiFi board too, which has even more RAM available.

  • Thanks for taking the time G.

    I got to thinking I may have reached the memory limit, hence stripping the code back as much as I could.

    The return statement was in there as a debug thing, just so it didn't fall over and I could continue to develop the rest of the features while looking for a solution :)

    I did look at using the internal temp sensor as opposed to DS18B20, and I still might revert back. Although, both seen to be around 10 degrees higher than the thermometer I have. Although not critical, it would be nice to have better accuracy.

    The images may have to go then, although they are small (icon size). Would it better to call these in from the SD card, or will that still take up valuable memory space?

    I'll keep playing with some of your other recommendations and see where I can get to.

    I did start out with the Pico, but as I'm using all (and may need more!) of the IO pins, I switched to the larger Espruino (especially as this has the onboard SDcard).

  • I think with the ideas above you should be fine for a while, even with DS18B20 and images - it basically halves your memory consumption minifying and saving to flash. Loading images from flash (especially if you have more) could be good - as would deleteing them if you're not planning on using them again.

    Also, for DS18B20 it's better to use a callback for the temperature: http://www.espruino.com/DS18B20

    Using a normal function is the older way, but it means that your temperature readings are always from the previous call to getTemp.

  • I did start out with the Pico, but as I'm using all (and may need more!) of the IO pins, I switched to the larger Espruino (especially as this has the onboard SDcard).

    @pwhitrow, I do not know what kind of io pins you need, but did you ever think of port expander (s)? They are extremely flexible...

  • Thanks man, I'll add that page to my list of things to read (learn) ....

    I wish I could give further details too but have to protect the IP of the product so shooting blind with some of this. That said, loving what Espruino can do so far!

  • Reading through @Gordon's comments and suggestions, some of the history, and now the number of ports you serve, could it be that JS just does not get quickly enough its cpu cycles? - ...adding setSleepIndicator(pin) / setBusyIndicator(pin) to your code could provide this information. If you have streaks of long JS - with some 'weird' code - worst case looping until a pin status kicks in - interrupt serving in the JS layer is delayed... and refilling the buffers as well...

  • Thanks for your suggestions bud. It's actually working quite well now with G's suggestion to reduce the waveform buffer and seems to play all files. It does stutter occasionally but for this prototype stage I can live with that.

    Interesting thoughts on the cycles issue, will have to dig into that.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Adafruit VS1053 Codec + MicroSD Breakout - MP3/WAV/MIDI/OGG Play + Record - v4

Posted by Avatar for davenelson @davenelson

Actions