Nightly 'bigram' (3250 jsvar) builds for Espruino Board 1.3/1.4 #4348

espruino-discuss3 · 2025-02-12T12:31:29Z

espruino-discuss3
Feb 12, 2025
Maintainer

Posted at 2014-07-15 by DrAzzy

I am now building bigram espruino builds automatically every night (the bigram build is the one to use the full 64k ram 512k flash that the espruino boards seem to have, giving you a total of 3250 jsvars instead of 2600).

These are automatically built in the wee hours of the morning EST and made available at:

http://drazzy.com/e/espruino/bigram

No tests or checks are performed on builds prior to posting them - it is automated. These may not work on all Espruino boards - the manufacturer spec for the chips says they shouldn't work at all - but they seem to work on most boards. So far we have one report of a user who had a board that didn't work with bigram.

Also please read the linked page completely before using these builds.

If you have any problems, first verify that the problem does not occur on non-bigram build, then start a new topic with the word bigram in the subject.

IF YOU ARE USING ANY BIGRAM BUILD FROM BETWEEN 11/12 and 12/28 PLEASE UPDATE - THOSE BUILDS WERE BAD AND DISPLAYED SUBTLY BROKEN BEHAVIOR

espruino-discuss3 · 2025-02-12T12:31:32Z

espruino-discuss3
Feb 12, 2025
Maintainer Author

Posted at 2014-07-15 by @gfwilliams

Thanks!

Just to add that if you flash these, Espruino will start remembering the code that you saved between firmware updates. If I've changed the way data is stored internally then it can cause Espruino to hang at boot time.

To fix it, just press reset, and hold down BTN1 for a few seconds immediately after releasing reset (but not before or you'll enter bootloader mode with the pulsing blue LED).

Posted at 2014-07-15 by JumJum

Just installed bigram and it works fine.
For a large application I was close to "out of memory" and now I have 1000 blocks free.
Thanks a lot !!!

Posted at 2014-07-28 by DrAzzy

Updated the index page with some background, as well as link to javascript to clear out saved programs that might cause future versions to not start correctly (after changes to the format of variables stored in flash)

Posted at 2014-08-04 by DrAzzy

Per https://github.com/espruino/Espruino/blob/master/ChangeLog the memory efficiency changes improvement is now in the main branch. Accordingly, bigram builds will have 3250 jsvars instead of 2600.

Y'all may need to use flashclear when updating from earlier bigram builds.

Posted at 2014-08-04 by @gfwilliams

Yes... I'm expecting it may be a while before the next version as I'll need to be sure that nothing is broken by the changes. It'd be great if people can start playing with the latest build and let me know if they find any problems...

Posted at 2014-08-04 by user7114

@drazzy Good news/bad news
I have loaded bigram( Espruino v70) and it seems to work with simple programs but loading my application program "hangs" when uploading to the Espruino.
The only way I can get the command prompt ">" is disconnect/hard reset and then
reconnect.
Note: This application program always worked with the standard Espruino release firmware v69. BTW ... I loaded the new firmware 3 times and used flashclear to no avail.

Posted at 2014-08-04 by DrAzzy

Hm... the builds work for me (in fact, that's the build I'm using on my desk lamp, which has been working great), and that's not an failure mode I've seen

The v70 on there should be the same as this one - as a reality check, make sure you code uploads on this: http://www.espruino.com/binaries/git/commit_date/2014-07-30%2017:00:29%20+0100/

Also, it's worth trying uploading with throttling (though I haven't needed to do that in quite a while). Sometimes I've had to do this though

Also, it could be that you're unlucky and got an Espruino board where the chip has problems in the high 16k of memory? Nobody else has reported this, but it's certainly possible.

Posted at 2014-08-04 by user7114

Try uploading with throttling

What?

Also, it could be that you're unlucky and got an Espruino board where
the chip has problems in the high 16k of memory?

Is there a diagnostic test that can be performed to detect the chip problems
in the high 16k of memory?

Posted at 2014-08-04 by DrAzzy

(also edited in more above)
Communication options has a check box for throttling uploads. It makes uploads agonizingly slow, but sometimes fixes problems while uploading code.

Also, I assume you've tried ctrl+c?

Posted at 2014-08-04 by user7114

espruino.com/binaries/git/commit_date/2014-07-30%2017:00:29%20+0100/

This firmware link shows 1800 jsvars with v70?

Yes, i used the "control c" to no avail.

I tried firmware/and program throttling still with no change.

Guess I have one of the "bad" chips. Too bad there is not a pre-test that can
be run to see if your bigram can run?

BTW ...Throttling adds the true meaning to slow. (7 mins)

Posted at 2014-08-05 by DrAzzy

Yeah, that's the normal (non-bigram) build that should be about the same as the build you'd have used.

That's unfortunate, I don't know what to suggest.

Do note that the official github builds now have 2250 jsvars.

Posted at 2014-08-05 by @gfwilliams

There is a test... Use the non-bigram version of the code and do what is described here: http://forum.espruino.com/comments/19893/

So the firmware you got fromthe espruino.com link above works but DrAzzy's doesn't?

Posted at 2014-08-05 by user7114

The v70 on there should be the same as this one - as a reality check,
make sure you code uploads on this:
espruino.com/binaries/git/commit_date/2014-07-30%2017:00:29%20+0100/

quote from @drazzy Do note that the official github builds now have 2250 jsvars.

Ok, this "github" v70 firmware code works with my application user code Ok?
Note: The memory still shows 1800 jsvars? <---
Note: The upper ram test came back with the > after a few seconds.

Next test "again" bigram ...

Update ...
Again, I did another 12 minute throttling of bigram firmware link: (http://drazzy.com/espruino/bigram/espruino_1v70_08-05_espruino_1r3_bigram.bin)

My application "hangs" after uploading to the Espruino. The only way to revive communications is to disconnect/hard reset/reconnect.
Note: It runs fine on the github v70.

@drazzy I can send you a portion of my "top secret" application, for your inspection, but you probably don't have the hardware to run it on.

Posted at 2014-08-05 by @gfwilliams

Sorry - I just checked and that is an old one without the variable size changes. Try this one:

http://www.espruino.com/binaries/git/commits/5e9662d82b23dcc7068fd61675860cadd6b7aebb/

There was a period when the variable sizes were smaller but the variable count was still 1800 - @drazzy's link wasn't one of those though!

If the RAM size check didn't give any errors, looks like it's ok. It may well be the variable size changes then.

What errors do you get, or does the code just inexplicably not work?

If you could give us some example code that exhibited the problem then we might be able to fix it.

Posted at 2014-08-05 by user7114

Sorry - I just checked and that is an old one without the variable
size changes. Try this one:

Again, 2250 jsvars and the "new" link v70 (above) works with my application code.

As for bigram ...My application "hangs" after uploading to the Espruino. The only way to revive communications is to disconnect/hard reset/reconnect.

I will send my "top secret" private application code to an email destination for your
inspection. Just send me a message.

Posted at 2014-08-05 by @gfwilliams

Thanks... Well, if the new 1v70 above works then I'm not sure there's much I can do to figure out why @drazzy's bigram builds aren't working with your code... I guess it is possible that the extra RAM on-chip is a bit flaky - or its extra flash (the code I'd linked to before didn't test flash memory).

At least the 2250 var build should help out with your memory problems though.

Posted at 2014-08-05 by user7114

Happiness is having 2250 jsvars. True happiness is having 3250 jsvars.

Posted at 2014-08-05 by DrAzzy

Well, the bigram build he tried and couldn't make work didn't have the change in jsvar size either (it wasn't in until the 8/5 bigram build).

Posted at 2014-08-06 by user7114

Tried 8/5 bigram build "again" today and the program still "hangs"

On/off, for the next few weeks, I will be trying again to see if, by some chance,
"updated Bigram firmware" might work on my chip.

Too bad, if there isn't a reference from my purchased Espruino serial number or markings on the STM chip to ascertain if the chips can take the bigram firmware or not. Better yet, a yes/no diagnostic with flash/ram testing in the upper 16K
For now, I can live with 2250 jsvars.

Posted at 2014-08-10 by user7114

Let's say if a user needs 3250 jsvars and he wants to buy
an Espruino that has 3250 jsvars. It would be senseless to
purchase an Espruino and find out it can only have 2250 jsvars.
Are there any certified/guaranteed 3250 jsvars "Bigram" Espruinos that can be purchased?

Posted at 2014-08-10 by DrAzzy

Nope. There are the unsupported boards, some of which have more memory, of course.

The new espruino that Gordon was talking about is going to have 64k ram I think, which would give 3250 jsvars

Posted at 2014-08-11 by @gfwilliams

Yes, I'm in the process of doing a smaller board with a slightly bigger chip on it.

When that's done I'll be seeing if I can do a batch of 'super' Espruino boards with the biggest chip available on them though (96kB).

Did you actually try any of our memory reduction suggestions apart from turning on minification? You can fit a huge amount into even 1800 vars, so if your project isn't fitting then you might be defining something in a way that's taking up a lot more memory than you expect.

Posted at 2014-08-11 by user7114

I removed all text/comments for code reduction.
There are no arrays (if any, very few) used in the program code.
Simple minification is turned on.

The problem is all the algorithms needed to support my user application are huge. Devices like GPS, two precision RTC (real time clocks), a 4x20 LCD display, a WS2811 dot matrix, an accelerometer and other sensors. I am taking the Espruino to the max of 2250 jsvars.

Posted at 2014-08-12 by user7114

BTW ... Minification -Advanced Optimisation (not recommended) could get me another 16-17% if it was working?

Yes, Advanced Optimisations are what's produced by the closure
compiler in its 'advanced' mode. Problem is they tend to think that
they can rename absolutely everything, which breaks a lot. I think
someone could potentially write a configuration for it which explained
which things it's not allowed to rename, but I haven't had time to
look into it properly.

Posted at 2014-08-12 by @gfwilliams

Someone could take a look at this if they wanted. The Web IDE is easy enough to tweak, and the relevant APIs are:

https://developers.google.com/closure/compiler/docs/api-tutorial1
https://developers.google.com/closure/compiler/docs/api-ref

Probably what's required is externs_url and a file that contains all of Espruino's built-in functions.

However: once you stop the minifier renaming Espruino's built-in functions, it won't compress your code as much - so I wonder if it's really worth it. If modules were properly inlined the minifier would be able to do a much better job, but right now the only way of doing that is to manually copy the module code into the same file.

Have you tried one of @drazzy's recent big ram builds?

Posted at 2014-08-12 by user7114

No luck, as of 8/12 build BigRam still "hangs" on my Espruino chip.

I would like to state the obvious. (No offense or insults to your customers) With all the suggestions on this board to increase the jsvars, there is no mention of code efficiency. There is a difference between the professional Javascript "Gordons" of the world and novice, hackers like me. My user application bloatware, through efficient "professional" programming, could be reduced to the bare minimum and save hundreds of jsvars!

Posted at 2014-08-12 by user7114

BigRam has consistently failed "hangs" on my user application.
There are only two possibilities. My user code cause BigRam to fail or it was my Espruino chip? Everything, until now, pointed to my chip. Out of total frustration, I rewrote a large algorithm for auto DST (daylight savings time - module DS3231) since the DST is made for UK and not USA. Now, 8/12 BigRam release works on my chip? BigRam did not like my "old" user application code!
Total happiness is having 3250 jsvars!!!!

Posted at 2014-08-12 by @gfwilliams

Glad you got it working!

That is a strange one... If you can track it down to one section of code that fails in bigram I'd be really interested to see it...

Posted at 2014-08-12 by user7114

Code that fails BigRam excluding other user application coding.
This code is pretty straightforward.

var lcd,rtc,rtc1,gps;
var gps_flag = false;
var mon_1  = "  ";
var date_1 = "  ";
var yr_1   = "  ";
var hr_1   = "  ";
var min_1  = "  ";
var sec_1  = "  ";
var date_time1 = " ";
var mon_2  = "  ";
var date_2 = "  ";
var yr_2   = "  ";
var hr_2   = "  ";
var min_2  = "  ";
var sec_2  = "  ";
var date_time2 = " ";

var SF2014x = new Date(2014,2,9,2,0,0); 
var SF2014 = SF2014x.getTime(); 

var FB2014x = new Date(2014,10,2,2,0,0);
var FB2014 = FB2014x.getTime();

var SF2015x = new Date(2015,2,10,2,0,0);
var SF2015 = SF2015x.getTime();

var FB2015x = new Date(2015,10,3,2,0,0);
var FB2015 = FB2015x.getTime();

var SF2016x = new Date(2016,2,13,2,0,0);
var SF2016 = SF2016x.getTime();

var FB2016x = new Date(2016,10,6,2,0,0);
var FB2016 = FB2016x.getTime();

var SF2017x = new Date(2017,2,12,2,0,0);
var SF2017 = SF2017x.getTime();

var FB2017x = new Date(2017,10,5,2,0,0);
var FB2017 = FB2017x.getTime();

var SF2018x = new Date(2018,2,11,2,0,0);
var SF2018 = SF2018x.getTime();

var FB2018x = new Date(2018,10,4,2,0,0);
var FB2018 = FB2018x.getTime();

var SF2019x = new Date(2019,2,10,2,0,0);
var SF2019 = SF2019x.getTime();

var FB2019x = new Date(2019,10,3,2,0,0);
var FB2019 = FB2019x.getTime();
//
var TZ = -1; 
var EDT_EST = false; 
                     
var dstLockout = false;
var DST = 0;
var idx1 = false;
var idx2 = false;
var gps_fix  = false;


 
function onInit(){
I2C1.setup({scl:B8,sda:B9});  
lcd = require("HD44780").connectI2C(I2C1);
digitalWrite([LED1,LED2,LED3],4);
setTimeout("digitalWrite([LED1,LED2,LED3],2);", 1000);
setTimeout("digitalWrite([LED1,LED2,LED3],1);", 2000);
setTimeout("digitalWrite([LED1,LED2,LED3],0);", 3000);

  
lcd.clear(); 


  
I2C2.setup({scl:B10, sda:B11});
rtc1 = require("DS3231R1").connect(I2C2); 
    
I2C1.setup({scl:B8, sda:B9});
rtc = require("DS3231R1").connect(I2C1); 
 
rtc.i2c.writeTo(0x68,0x0E,0x60);

pinMode(C11,'input_pullup'); 
Serial4.setup(9600,{tx:C10,rx:C11});
gps = require("GPS").connect(Serial4, function(data) {
gps_flag = true;      
}); 
  
lcd.setCursor(0,0);
lcd.print("GPS No Button Clock");
pinMode(B3,'input_pullup');    
}

function RTC_INT_1Hz () {
    digitalPulse(LED3, 1, 25);

    date_time1 = rtc.readDateTime();
  
    date_time2 = rtc1.readDateTime();
   
    mon_1  = date_time1.charAt(0) + date_time1.charAt(1);
    date_1 = date_time1.charAt(3) + date_time1.charAt(4);
    yr_1   = date_time1.charAt(6) + date_time1.charAt(7);
  
    hr_1   = date_time1.charAt(9)  + date_time1.charAt(10);
    min_1  = date_time1.charAt(12) + date_time1.charAt(13);
    sec_1  = date_time1.charAt(15) + date_time1.charAt(16);
   
    mon_2  = date_time2.charAt(0) + date_time2.charAt(1);
    date_2 = date_time2.charAt(3) + date_time2.charAt(4);
    yr_2   = date_time2.charAt(6) + date_time2.charAt(7);
  
    hr_2   = date_time2.charAt(9)  + date_time2.charAt(10);
    min_2  = date_time2.charAt(12) + date_time2.charAt(13);
    sec_2  = date_time2.charAt(15) + date_time2.charAt(16);

a = new Number(mon_1);
  if (a === 0) {
  }
  else
  {
  a = a-1;
  }
b = new Number(date_1);
c = new Number(yr_1);
c = c + 2000;
d = new Number(hr_1);
e = new Number(min_1);
f = new Number(sec_1);

var utcDate = new Date(c,a,b,d,e,f,0);
var utcDate_ms = utcDate.getTime();   

a = new Number(mon_2);
  if (a === 0) {
  }
  else
  {
  a = a-1;
  }
b = new Number(date_2);
c = new Number(yr_2);
c = c + 2000;
d = new Number(hr_2);
e = new Number(min_2);
f = new Number(sec_2);
  
var localDate = new Date(c,a,b,d,e,f,0);   
var localDate_ms = localDate.getTime(); 
  
EDT_EST = checkDST(localDate_ms);
  if (EDT_EST === true){
    TZ = -4; 
  }
  else
  {
    TZ = -5; 
  }   
 
DST = processDST(localDate_ms);
 
  if ((DST  ===  1) && (dstLockout === false)) {
  digitalWrite(LED1,true);
  dstLockout = true;
  } 
 
  if ((DST  === -1) && (dstLockout === false)) {      
  digitalWrite(LED1,true);  
  dstLockout = true; 
  }
 
  
  if (localDate.getHours() === 3) {
    dstLockout = false;
    digitalWrite(LED1,false);
    digitalWrite(LED2,false);
  }
  
var TZdiff_ms = utcDate_ms-localDate_ms; 
var ms_diff = utcDate_ms + (TZ * 3600000) - localDate_ms;
  

  if ((utcDate.getHours() === 11) && (utcDate.getMinutes() === 59) && (utcDate.getSeconds() === 59)) {  
    if ((ms_diff >= -5000 ) && (ms_diff <= 5000)){
      rtc1.setTime(utcDate.getHours()+ TZ + 1,0); 
      digitalWrite(LED2,true);
     }
  }
  
   
    
    lcd.setCursor(0,1);    
    lcd.print(date_time1);
    lcd.print(" U");
    idx1 = !idx1;
    if (idx1 === true){ lcd.print("*");}
    if (idx1 === false){ lcd.print(" ");}
  
    lcd.setCursor(0,2);   
    lcd.print(date_time2);
    lcd.print(" L");
    idx2 = !idx2;
    if (idx2 === true){ lcd.print("*");}
    if (idx2 === false){ lcd.print(" ");}
  
   
   
   
    lcd.setCursor(0,3);
    
  if (TZ === -4){
      lcd.print("EDT Sum ");
   }
   else
   { 
      lcd.print("EST Win ");
   }
    lcd.print("TZ");
    lcd.print(new String(TZ));
    lcd.print(" ");  
  
   var dw = localDate.getDay(); 
  
   if (dw === 0) {lcd.print("Sun");}
   if (dw === 1) {lcd.print("Mon");}
   if (dw === 2) {lcd.print("Tue");}
   if (dw === 3) {lcd.print("Wed");}
   if (dw === 4) {lcd.print("Thu");}
   if (dw === 5) {lcd.print("Fri");}
   if (dw === 6) {lcd.print("Sat");} 
  
   lcd.print(" ");

   var month = localDate.getMonth();
   if (month === 0)  {lcd.print("Jan");}
   if (month === 1)  {lcd.print("Feb");}
   if (month === 2)  {lcd.print("Mar");}
   if (month === 3)  {lcd.print("Apr");}
   if (month === 4)  {lcd.print("May");}
   if (month === 5)  {lcd.print("Jun");}
   if (month === 6)  {lcd.print("Jul");}
   if (month === 7)  {lcd.print("Aug");}
   if (month === 8)  {lcd.print("Sep");}
   if (month === 9)  {lcd.print("Oct");}
   if (month === 10) {lcd.print("Nov");}
   if (month === 11) {lcd.print("Dec");}  
    
  if (gps_flag === true){
    //print("got GPS");
    gps_fix = !gps_fix;
    lcd.setCursor(19,0);
    if (gps_fix === true){ lcd.print("*");}
    if (gps_fix === false){ lcd.print(" ");}
    lcd.setCursor(0,1);
    gps_flag = false;
  }
}



function checkDST(current_ms){  
  if ((current_ms >= SF2014 ) && (current_ms <= FB2014)){ return true;}
  if ((current_ms >= SF2015 ) && (current_ms <= FB2015)){ return true;}
  if ((current_ms >= SF2016 ) && (current_ms <= FB2016)){ return true;}
  if ((current_ms >= SF2017 ) && (current_ms <= FB2017)){ return true;}
  if ((current_ms >= SF2018 ) && (current_ms <= FB2018)){ return true;}
  if ((current_ms >= SF2019 ) && (current_ms <= FB2019)){ return true;} 
  return false;
}

function processDST(local_ms){
  if (local_ms === SF2014 ) {return  1;}
  if (local_ms === FB2014 ) {return -1;}
  if (local_ms === SF2015 ) {return  1;}
  if (local_ms === FB2015 ) {return -1;} 
  if (local_ms === SF2016 ) {return  1;}
  if (local_ms === FB2016 ) {return -1;} 
  if (local_ms === SF2017 ) {return  1;}
  if (local_ms === FB2017 ) {return -1;} 
  if (local_ms === SF2018 ) {return  1;}
  if (local_ms === FB2018 ) {return -1;} 
  if (local_ms === SF2019 ) {return  1;}
  if (local_ms === FB2019 ) {return -1;} 
  return 0;
}  
  

    
setWatch(RTC_INT_1Hz, B3, { repeat: true, edge:'falling', debounce:0});


onInit();

Posted at 2014-08-12 by DrAzzy

What are you seeing when you run tht code?

When I do it, on bigram or normal, I see a big delay during which it looks non responsive (due to echo(0) not having been unset until onInit() is finished - this is why I never put onInit() at the end of my code, and always do that manually - so I can see what's going on)

Posted at 2014-08-12 by user7114

After uploading the code to the Espruino it "hangs/stop/halts" the communications and the > prompt does not return. The only way to "unhang" the Espruino is to do a dis-connect/reset the Espruino/reconnect.

I figure if my new code works with BigRam then everything should be OK since all my RTCs
are running in my application user code.

So far, one person has reported getting an espruino with a chip that
doesn't work with bigram.

That is truly amazing since ...

The Espruino Board was Crowdfunded in September 2013 - and we've
already shipped almost 4000 boards to over 2000 customers!

1 out of 4000 Espruino boards and not counting the clones!

Posted at 2014-08-12 by DrAzzy

You're the one person with the chip that I thought didn't work with bigram.

Sorry, I thought your post was the last, but there were a few more between your last post and the last post I'd read that I missed.

I can't reproduce that behavior.

I get a hang, but only while onInit() is running (you will not get a cursor while onInit() is running if you have onInit() at the bottom of the code you send from the right window - echo will still be off until it's done running) - for me that hang is very brief, because onInit() quickly crashes because I don't have any of the hardware you talk to.

Same behavior on bigram and normal.

Posted at 2014-08-12 by user7114

You're the one person with the chip that I thought didn't work with
bigram.

Make that 0 out of 4000 boards for 100% users that are able to run your BigRam except when
there is an unknown user code problem.

My new code workaround did the trick.

Posted at 2014-08-13 by @gfwilliams

Glad you got it sorted! What was the problem?

Looking at your code, the following might help with memory usage:

You can use string[index] instead of string.charAt(index) and save a few characters, or for extracting a substring you could use substr,substring or slice (all of which do basically the same thing)
Instead of if (dw === 0) {lcd.print("Sun");} ... what about lcd.print(["Mon","Tue","Wed",...][dw]); - stuff like that will really compact your code.
I don't know what you intend, but if you define a variable in a function without adding var before it (eg. a=5 vs var a=5), that variable becomes global and will always take up memory. If you add the var before it then the variable is local to the function, and the memory it uses will be freed after the function is done executing...

Posted at 2014-08-13 by user7114

What was the problem?

Something in the code (above) stops BigRam. Since I re-wrote the code to minimize the DST
algorithm, the problem went away mysteriously.

Posted at 2014-09-05 by DrAzzy

The site was down for a day or two due to an amazon "maintenance" during which the instance was forcibly shutdown (I got an emailed warning in early august, which I promptly forgot about) - and I didn't have apache set up to start on boot like I thought I did.

But an interesting aside: It would appear that this "maintenance" moved it to some much spiffier hardware - prior to the maintenance, it was taking about 12 minutes for the two builds. Now it takes 2.

Posted at 2014-09-15 by DrAzzy

Added links showing the changelog to the page, to help figure out which is which.

Posted at 2014-09-21 by DrAzzy

Website reshuffle.

Old links should still autoredirect, let me know if it's busted in any way.

Posted at 2014-09-25 by DrAzzy

Wiznet builds fixed.

Posted at 2014-12-17 by DrAzzy

I manually rebuild the 12/17 bigram so it includes the fix for issue #460 (checked in earlier today).

Also, bumping the thread for people who haven't seen it.

Posted at 2015-01-22 by DrAzzy

Builds will now only be performed if there has been a commit since the last time it was built, instead of every night. No point in building the same binary over and over. Same applies to the nucleo builds.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Espruino JavaScript

Nightly 'bigram' (3250 jsvar) builds for Espruino Board 1.3/1.4 #4348

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Espruino JavaScript

Nightly 'bigram' (3250 jsvar) builds for Espruino Board 1.3/1.4 #4348

Uh oh!

espruino-discuss3 Feb 12, 2025 Maintainer

Replies: 1 comment

Uh oh!

espruino-discuss3 Feb 12, 2025 Maintainer Author

espruino-discuss3
Feb 12, 2025
Maintainer

espruino-discuss3
Feb 12, 2025
Maintainer Author