Posted at 2023-12-28 by user156811

I'm not a expert, but my first question would be can the Pico uart driver even go that slow? I know hardware drivers have to do clock dividers to get to a certain frequency and that might be lower then the ranges it can work in.

But you could try and take a jumper from your Pico TX uart lines and connect it to your RX lines. Thus created a loop in your communication. It should be a quick test to see if the device can actually produce and receive that range. If it can't i would hook up a oscilloscope and see the timing. It might be slightly off.

Posted at 2023-12-28 by @allObjects

@ser156811

First, thank you for reading thru and sharing your thoughts.

Regarding speed, I had a similar thought: can Espruino Pico - the serial appliance of the STM32F401CDU6 - go so low down to 300 bps, but did not think about the divider issue... I should though have taken that though serious, since I know how USARTs (chips of same age) have to be configured...

I also had the thought of using Espruino firmware's software serial... but it may have the very same issue. After all, it uses the same basic hardware: some timer(s), relaying on the same counters...

There are server options for a next step before more serious actions have to be considered:

1. Change Serial1 to a software new Serial()... very easy to do
2. The device has also an output only serial routine using similar bitbanging hardware and software, but with configurable baud rate, and it usually ran on 1200bps and can go up to 400bps. Disadvantages are: has no parity, no CRC (checksum), and disabling for full control of the device: it has output ONLY. The input is only for checking DTR.
3. Making changes to the firmware of the device, posing several sub-options. The devices hardware is though too weak for a reasonable implementation of a configurable, bidirectional serial communication to implement serial with XON/XOFF flow control. Basically: there is no independent time or interrupt control used (and implemented in the devices monitor).

Hooking on a scope is an option... which I did 40+ years ago when validating the devices capabilities and putting it to service. Time fluctuations according to Espruino Poco's measurments are at it's most extreme in the range of 0.003152 thru 0.003157 (time of 1 bit), which is less than 0.2%. With that, I can comfortably exclude accuracy issues, but for sure not speed range ones.

New results will be available soon.

Posted at 2023-12-28 by @allObjects

@ser156811

Regarding hooking up scope: mentioned only the device. But hooking it to Espruino Pico USART1 and transmitting something with 300 (or 316) bauds would also provide new information, mostly so if it will go down that low...

@gfwilliams mostlikely can answer that right away and would also know how accurate timing is across the bandwidth. I know that at very high frequencies differences between bit times are very course grain (see Espruino controlling LC resonance experiment in HAM Radio class, in particular, post #4).

Posted at 2023-12-28 by @allObjects

Using software serial moved me ahead a bit and may even be the solution...

Minimal change of the routine I had for hardware serial:

function receiveSOD() {
  var errs = true
    , serial = Serial1
    ;
  serial = new Serial();
  serial.setup(316, {rx:SOD, tx:SID, parity:"o", errors:errs });
  serial.on('data', function (data) { print(data); });
  if (errs) {
    serial.on('parity',  ()=>console.log('P'));
    serial.on('framing', ()=>console.log('F'));
  }
}

Console output for 0x0E byte sequence of:

Byte# 0x## 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E
Value 0x##: 00 01 02 04 08 10 20 40 80 FF 00 0F F0 55 AA
VALUE dec.: 0 1 2 4 8 16 32 64 128 255 0 15 240 85 170

var t=`
>




 
@

ÿ

ð
U
ª
ü
>
`;

With ü as being the CRC / checksum.

Creating a version that prints the data in decimal to show non-printable
characters - changing print(data); to print(data.charCodeAt(0)); -
shows the expected (values in) console:

var t=`
>

0
1
2
4
8
16
32
64
128
255
0
15
240
85
170
252
>
`;

But as @gfwilliams pointed out in USART / UART / Serial Port for software serial, there is not much processing cycles left for other things while communication is going on, such as my attempt to print the received data in hex using my generic approach, which also can handle reception of more than one byte at a time. Here the changes and the versatile (hex) output creation (complete, runnable code to load):

// wire connections (in code use ums view names)
//  ums=pico view | ums view || ums              pico
var SOD=B7   // I | SOD   O  || serial output on USART1 SERIAL1 RX (B7) I
  , SID=B6   // O | SID   I  || serial input  on USART1 SERIAL1 TX (B6) O
  ;

function setPinModes() {
  //      ums - pico view
  pinMode(SID,"output");
  pinMode(SOD,"input");
}

function hex(v) { return ((v>15) ?
  hex(v>>4) : "")+"0123456789ABCDEF".charAt(v&15); } // hex...
function hep(v,ds) { // hex, digits (w/ blank padding up to ds)
  return ("        "+hex(v)).substr(-ds); }
function lep(v,ds) { // hex, digits (w/ 0 padded up to ds)
  return ("00000000"+hex(v)).substr(-ds); }

function receiveSOD() {
  var errs = true
    , serial = Serial1
    , opt
    ;
  serial = new Serial();
  serial.setup(316, {rx:SOD, tx:SID, parity:"o", errors:errs });
  opt = // 0 // 0 or any: just print as received (as initialy)
        // 1 // most unasumptional, flexibel hex output
        // 2 // assuming 1 byte at a time reception hex output
           3 // assuming 1 byte at a time charCode (dec) output
           ;
  serial.on('data'
    , (opt==1) ? (function(data){ 
       for (i=0; i++; i<data.length)
         print(lep(data.charCodeAt(i),2)); } )
    : (opt==2) ? (function(data){ 
         print(lep(data.charCodeAt(0),2)); } )
    : (opt==3) ? (function(data){ 
         print(data.charCodeAt(0)); } )
    : (function(data){ print(data); }) );
  if (errs) {
    serial.on('parity',  ()=>console.log('P'));
    serial.on('framing', ()=>console.log('F'));
  }
}
function onInit() {
  setPinModes();
  receiveSOD();
}

setTimeout(onInit,999); // dev only; remove before upload for save()

With output option 1, the console output was absent... (a simpler implementation for 2-digit hex output may have worked, but was not done and tried).

For that reason, I built a buffering into/around the code with a routine for visualization of the buffer... shown in a next post, including the Espruino js Bitbanging solution (not using any appliances (except the timer/interrupts... as is used by setWatch, setTimeout, setInterval for that purpose).

Posted at 2024-01-04 by @gfwilliams

Glad you got this working with software serial.

I just checked the code for serial on STM32 and we call through to the STM32 API and that would appear to be fine.

However, checking on a scope, just calling Serial1.setup and printing something, I can see that as soon as you get below about 330, the baud rate goes completely wrong - I believe the baud rate register is overflowing and ST's API never does any kind of range checking.

So you have two options:

• Just use a baud rate of 330 - as you're having to use 316 on software serial, it's possible using 330 may work fine.
• You can actually lower the clock rate of the UART so that then it can work without overflowing its counter. Run E.setClock({M:8, N:336, P:4, Q:7, PCLK1:2, PCLK2:8}) before you set up the UART and I believe that'll fix it!

Posted at 2024-01-04 by @allObjects

@gfwilliams,

thanks for taking the time to read and respond... I'll give it a shot, last but not least because I'm not successful yet with 'playing back' the received data, which means that either Espruino is not producing the right bit stream or the modulation/demodulation in the original case added something that was compensated in the device's receiving software.

Questions - answered them myself by reading the API doc... haha...:

1. Is the E.setClock(...) also good for Serial2/USART2? - switched over to Serial2 from Serial1
2. What is the impact of changing this for any other serial communication?

Btw, I noticed that the protocol is two (2) stop bits... (explaining the 'gap' of one bit between the bytes received).

I noticed that I never shared the code that does super-soft software serial in JS... Espruino JavaScript is so fast and efficient, that it can handle the 316 baud rate...

Main line is:

• have a single object for control and data to minimize scope for / optimize var look up (rather than have individual globals or a bunch of locals w/ multiple parameters passings - does it matter? @gfwilliams can debunk by thoughts...)
• setup to wait for first start bit in wSB(), start flank
• sample start bit sSB() 'half a bit later' (or a tad shorter - 1.47 instead of 1.57 ms... to not be/start late for sure... also trying to compensate not only for the setup of setWatch() but also for the setup of setInterval()... have though no clue if it and what value makes sense... I'm just thinking)
• keep sampling remaining bits - mainly data bits - in sDB() in intervals of 'a bit later' until including all bits of a byte are done: data, parity and stop bits. Also handle / check parity and keep only 'good' bytes. Key concept used is the bit weight .w that controls everything... (state of 'state machine').
• start over with waiting and sampling until done - stop stopRecSOD() is invoked from console (when device's transmit LED stops flickering), which sets a flag to not watch for stop bits anymore and clear eventual watch, but let eventual sampling finish.
• do hex dump for validation of bytes receive after waiting at least for a byte

Here the code (a bit formatted for legibility...):

// SWSerialInEspruinoJS.js
// 20231228ao
//
var u; // = undefined constant
var lon = true; // false; // true; // logging is on
function log() { if (lon) { console.log.apply(console,arguments); } }

// wire connections (in code use ums view names)
//  ums=pico view | ums view || ums              pico
var SOD=A3   // I | SOD   O  || serial out on USART2/1 SERIAL2/1 RX (A3/B7) I
  , SID=A2   // O | SID   I  || serial in  on USART2/1 SERIAL2/1 TX (A2/B6) O
  ;

function setPinModes() {
  //      ums - pico view
  pinMode(SID,"output");
  pinMode(SOD,"input");
}

function hex(v) { return ((v>15) ?
  hex(v>>4) : "")+"0123456789ABCDEF".charAt(v&15); } // hex...
function hep(v,ds) { // hex, digits (w/ blank padding up to ds)
  return ("        "+hex(v)).substr(-ds); }
function lep(v,ds) { // hex, digits (w/ 0 padded up to ds)
  return ("00000000"+hex(v)).substr(-ds); }

var sod =
{ l: 2056 // length of d
, d:   [] // bytes as u8int array
, f:    0 // fill level of d
, wId:  u // stop bit watch id
, iId:  u // data / parity / stop bit interval id
, byt:  0 // byte
, w:    0 // bit weight
, pC:   0 // parity calculated
, pR:   0 // parity received
, pEC:  0 // parity error count
, fEC:  0 // framing error count
, r:    0 // running (status)
};
sod.d = new Uint8Array(sod.l);

function startRecSOD() { // uses:
  // wSB(): Watch SOD Start Bit
  // sSB(): Sample SOD Start Bit
  // sDB(): Sample SOD Data Bit and others too, incl parity handling
  // sPB(); Sample SOD Parity Bit - part of sDB() - no need, included in sDB
  // sTB(); Sample SOD sTop Bit - part of sDB() - no need, included in sDB
  if (sod.d.length !== sod.l) sod.d=new Uint8Array(sod.l);
  sod.f=0; sod.pEC=0; sod.fEC=0; sod.r=1;
  wSB(sod); // 314,157 ms full bit time / half bit time
}

function stopRecSOD(sAddr) {
  sod.r=0;
  if (sod.wId) sod.wId=clearWatch(sod.wId);
  setTimeout(function(){
      // console.log(new Uint8Array(sod.buffer,0,_.f));
      console.log("...stopRecSOD.");
      var arr=[], prtd=0, cols=16, addr = sAddr || 0;
      console.log( lep(addr,4) + "..."
                 + lep(addr+sod.f - 1 - 1,4) + " + "
                 + lep(sod.d[sod.f - 1],2) + " check byte: "
                 + sod.f + " bytes ok, "
                 + sod.pEC + " parity errs, "
                 + sod.fEC + " framing errs"
                 );
      while (prtd<sod.f-1) { arr=[]; cols=16;
        arr.push(lep(addr,4)); arr.push(":");
        while (--cols>=0 && prtd<sod.f-1) {
          arr.push(lep(sod.d[prtd++],2)); addr++;
        } console.log(arr.join(" "));
      }
    },11*3.14);
}

function wSB(_) {
  _.byt=0; _.w=1; _.pC=1;
  if (_.r) {
    _.wId=setWatch(()=>setTimeout(sSB,1.47,_)
       ,SOD,{repeat:0,edge:"falling"}); } }

function sSB(_) {
  _.iId=(!digitalRead(SOD))
          ? setInterval(sDB,3.14,_)
          : wSB(_); }

function sDB(_) {
  var b=digitalRead(SOD);
  if (_.w<256) {
    if (b) {
      _.byt+=_.w;
      _.pC^=b;
    }
    _.w=_.w<<1;
  } else {
    _.w=_.w<<1;
    if (_.w>512) {
      clearInterval(_.iId);
      if (b) {
        if (_.pC===_.pR) _.d[_.f++]=_.byt; else _.pEC++;
      } else {
        _.fEC++;
      }
      wSB(_);
    } else {
      _.pR=b; } } }
  
function onInit() {
  setPinModes();
  startRecSOD();
}

setTimeout(onInit,999); // dev only; remove before upload for save()

Here the console output:

var t=`
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v19 (c) 2021 G.Williams
>
startRecSOD...
>stopRecSOD(0x800);
=undefined
...stopRecSOD.
0800...080E + FC check byte: 16 bytes ok, 0 parity errs, 0 framing errs
0800 : 00 01 02 04 08 10 20 40 80 FF 0F F0 00 55 AA
> 
`;

The code borrowed ideas from the device's implementation of reading serial input. Something next in line to simulate input for.

'Formatted' code looks a bit bloated... here the origin:

function wSB(_) { _.byt=0; _.w=1; _.pC=1; if (_.r)
  _.wId=setWatch(()=>setTimeout(sSB,1.47,_)
    ,SOD,{repeat:0,edge:"falling"}); }
function sSB(_) {
  _.iId=(!digitalRead(SOD))?setInterval(sDB,3.14,_):wSB(_); }
function sDB(_) { var b=digitalRead(SOD);
  if (_.w<256) { if (b)  { _.byt+=_.w; _.pC^=b; } _.w=_.w<<1;
  } else { _.w=_.w<<1; if (_.w>512) { clearInterval(_.iId);
    if (b) { if (_.pC===_.pR) _.d[_.f++]=_.byt; else _.pEC++; 
    } else { _.fEC++; } wSB(_); } else _.pR=b; } }

Now working on reading the data back: sending the data back to device as received before and stored in a 'file'. Even Espruino Software Serial is not producing a serial data stream accepted by the device. Playing w/ the 330 baud rate and E.setClock(...) gives me some hope until I will take out the 'big guns', like DSO... (My pride to be frugal in material but wasteful in thinking and time gets in my way for moving speedy... but it is somewhat the goal: understanding what's going on and where 'it' leaves the 'happy path'... (I'm part of the 'it'... haha...)...)

...so much for (late) Happy New Espruino Year 2024

Posted at 2024-01-05 by @allObjects

@gfwilliams,

tried both... using 330 for baud rate failed no matter what - w/ and w/o E.setClock(). But the combination of lowering the clock rate of the UART using E.setClock({M:8, N:336, P:4, Q:7, PCLK1:2, PCLK2:8}); and 316bps did the job (on Serial1/USART1).

What properties and values do I have to use in E.setClock(...) for using Serial2/USART2?

Posted at 2024-01-05 by @gfwilliams

What properties and values do I have to use in E.setClock(...) for using Serial2/USART2?

USART2 is on PCLK1 according to the reference manual, so you'd need to use PCLK1:4 to halve the clock rate of that.

I can't be sure where USB gets its clock from, so there is some possibility that lowering the PCLK1 speed will break USB - I'm not sure