Release 1v71 now out

You are reading a single comment by @asez73 and its replies. Click here to read the full conversation.

•

Gordon
I actually just run those tests on linux - not on the ARM boards at all.

I'm almost 100% certain that the character won't be a software issue. Espruino compiles for a whole bunch of different processors and works on them, so I doubt it's something specific to yours.

Actually I just realised what it might be - you could try explicitly setting the serial pins in the .PY file with:
```
 'default_console_tx' : "A2",
 'default_console_rx' : "A3",
```
What this does is in jshReset it stops the pin function from being set back to a normal input - the change of registers may cause a glitch on the input line which makes the USART read in a dud character.

•

asez73 in reply to @Gordon

Hi,
Bravo, it did the trick: No more scary characters in the input line after reset() or load() as shown below.

>
=undefined
>reset();
=undefined
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v72 Copyright 2014 G.Williams
>echo(0);
=undefined
>dump();
function buttonWatcher() {
  console.log("Pressed at "+getTime());
  digitalWrite(LED1, Math.random()>0.5);
}
setWatch(buttonWatcher, "C13", { repeat:true, edge:'both' });
=undefined
>save();
=undefined
Erasing Flash....
Programming 86016 Bytes.......................................................................................
Checking...
Done!
>dump();
function buttonWatcher() {
  console.log("Pressed at "+getTime());
  digitalWrite(LED1, Math.random()>0.5);
}
setWatch(buttonWatcher, "C13", { repeat:true, edge:'both' });
=undefined
>reset();
=undefined
 _____                 _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v72 Copyright 2014 G.Williams
>dump();
=undefined
>load();
=undefined
Loading from flash...
>

I had tried to call jshResetSerial() after load or reset, however it did not do it alone. Defining the RX and TX pins does change the init sequence. That's because there are some

 [#ifdef](https://forum.espruino.com/search/?q=%23ifdef) DEFAULT_CONSOLE_TX_PIN
    inf.pinTX = DEFAULT_CONSOLE_TX_PIN;
 [#endif](https://forum.espruino.com/search/?q=%23endif)
 [#ifdef](https://forum.espruino.com/search/?q=%23ifdef) DEFAULT_CONSOLE_RX_PIN
    inf.pinRX = DEFAULT_CONSOLE_RX_PIN;
 [#endif](https://forum.espruino.com/search/?q=%23endif)

that apparently change the actual final initialisation of the serial port.
Anyway, now it is solved!

Running test on ARM boards is normally not a requirement and actually, breakpoint/watchpoint based debugging won't help much with real time problems...

Now I'll try to test more points about batteries life duration, data logging and ESP8266...

Release 1v71 now out

About

Espruino