The last 24 hours something really weird happened:
A bit history:
1) A bit ago I used not yet released 1v72 (with new support of exporting anything, not just function)
2) Week or two ago I switched back to released 1v71 version
3) Two days ago I began using @DrAzzy's new AT25 EEPROM modules connecting to my FRAM. To do that, I had to load the not yet released 1v72 - but new than before loaded 1v72 - because of the E.toString() data conversion
4) After a few trials and minor changes in AT25 module code, AT25 worked with only the power cycle caveat: first read and write after power cycle failed. Adding an extra read upfront made it work nicely
5) I started the comparative analysis between the new AT25 module code and code I wrote earlier to - last but not least - figure out why the caveat.
6) This early morning (PST), minutes after 1v72 release announcement in forum, I flashed my - only one board I own - with the default flashing to get the spanking new release.
7) Right away I tested A25 again with fresh upload and it failed even after an extra read which had 'saved' me before
8) Left a few posts about the remedy of the issue
9) Disconnected board, left for work
10) Back from work - about 16 hours later - I look at the forum and try to figure out the hacks
11) Just connected, I look - for what ever reason - at the connect blurb and notice 1v71... what the heck...
12) Without thinking further, I just flash with default again and see now 1V72...
This really puzzled me because after flashing this morning after 1v72 announcement with default what I meant to be 1V72 was actually 1V71...
If I would have detected earlier, some back and forth about AT25/EEPROM would not have happen... on the other hand , cannot really understand why the new AT25 - as pulled with require("AT25") ; in the code uploaded to the board with 1v72 - made Espruino NOT to complain about the new E.toString() function used by AT25... and return (nicely and consistently 0xFF)[http://forum.espruino.com/comments/12067790/]... no matter what...
@DrAzzy, for your - and my - peace of mind, I could not recreate the error after flashing again... I mad at me not to react right properly and test before flashing with default again (sure, I can go back to 1v71 and test... and hopefully would notice the same failures... I know for sure that I got some firmware flashed than I had on the board, because new A25 was working nice (beside the power cycle caveat).
My only explanation is: the 1v71 was still hanging out there in the browser, network, or the http server cache, and I got 'the floor model' delivered... which brings me to the question about the method / exact code the IDE issues to get the .bin file.
@Gordon, is there some reasonable explanation from your point for that?
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
The last 24 hours something really weird happened:
A bit history:
1) A bit ago I used not yet released 1v72 (with new support of exporting anything, not just function)
2) Week or two ago I switched back to released 1v71 version
3) Two days ago I began using @DrAzzy's new AT25 EEPROM modules connecting to my FRAM. To do that, I had to load the not yet released 1v72 - but new than before loaded 1v72 - because of the E.toString() data conversion
4) After a few trials and minor changes in AT25 module code, AT25 worked with only the power cycle caveat: first read and write after power cycle failed. Adding an extra read upfront made it work nicely
5) I started the comparative analysis between the new AT25 module code and code I wrote earlier to - last but not least - figure out why the caveat.
6) This early morning (PST), minutes after 1v72 release announcement in forum, I flashed my - only one board I own - with the default flashing to get the spanking new release.
7) Right away I tested A25 again with fresh upload and it failed even after an extra read which had 'saved' me before
8) Left a few posts about the remedy of the issue
9) Disconnected board, left for work
10) Back from work - about 16 hours later - I look at the forum and try to figure out the hacks
11) Just connected, I look - for what ever reason - at the connect blurb and notice 1v71... what the heck...
12) Without thinking further, I just flash with default again and see now 1V72...
This really puzzled me because after flashing this morning after 1v72 announcement with default what I meant to be 1V72 was actually 1V71...
If I would have detected earlier, some back and forth about AT25/EEPROM would not have happen... on the other hand , cannot really understand why the new AT25 - as pulled with require("AT25") ; in the code uploaded to the board with 1v72 - made Espruino NOT to complain about the new E.toString() function used by AT25... and return (nicely and consistently 0xFF)[http://forum.espruino.com/comments/12067790/]... no matter what...
@DrAzzy, for your - and my - peace of mind, I could not recreate the error after flashing again... I mad at me not to react right properly and test before flashing with default again (sure, I can go back to 1v71 and test... and hopefully would notice the same failures... I know for sure that I got some firmware flashed than I had on the board, because new A25 was working nice (beside the power cycle caveat).
My only explanation is: the 1v71 was still hanging out there in the browser, network, or the http server cache, and I got 'the floor model' delivered... which brings me to the question about the method / exact code the IDE issues to get the .bin file.
@Gordon, is there some reasonable explanation from your point for that?