You are reading a single comment by @jtq and its replies. Click here to read the full conversation.
  • Thanks @oesterle - some great suggestions there, particularly investigating Serial1.pipe(). I've veered away from writing my own solution so far, because this feels like something I'd expect to be handled internally by the Espruino runtime (at least some way to read the current state of the Serial buffer, so you know when it's safe to push more data into the connection)... but if there's nothing then I guess it's a straight choice between either creating a pull request into the Espruino runtime or write my own JS routines to manage it.

    The basic setup is pretty simple - just Serial1.setup(28800, { tx:B6, rx:B7 }) to set up the serial port, and

    var strRepresentation = JSON.stringify(obj);
    Serial1.print(strRepresentation + '\u0004');

    to send a data chunk down it. For reference, the data object I'm sending includes a few KB of base64 image and audio data, and going over a couple of KB total is about the point it blows up the connection and crashes the chip.

    Then the same setup line on the receiving side, and

    var buffer = '';
    Serial1.on('data', function(data) {
      buffer += data;  // De-chunk into buffer, and process whole buffer once EOT control character is received
      if(data.indexOf('\u0004') !== -1) { // ctrl+D - End of Transmission character
        // Process whole data object - JSON.parse(buffer), etc.
        buffer = '';  // And reset buffer

    to receive and process it.

    Edit: Ah- looks like Serial.pipe() won't really do it. It's the sending device that crashes due to an overflowed buffer(?), whereas it looks like Serial.pipe() only takes writeable streams (ie, it's another way to receive data from the USART, not a way to push data into it).


Avatar for jtq @jtq started