Trouble in simple Software Serial code testing

Some months , not coding on Espruino and I started trying "software serial" code on Pico with pin A6 and A5 connected with wire, such:

var s = new Serial();
s.setup(9600,{rx:A6, tx:A5});
s.on('data', function (data) { print("<SoftSerial>"+data); });
s.print("Hello");

But the result :

>
 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v01 (c) 2018 G.Williams
>
<SoftSerial>¤²¶
<SoftSerial>¶
<SoftSerial>o
> 

Always only last character is correctly detected on event data received, for every send package of characters.
Is there a mistake in my code usage ?
Thanks.

Sun 2019.04.21

Any reason the 3 available hardware USART Tx:Rx pins cannot be used? Just trying out Software Serial perhaps?

ex: USART1 Tx:B6 Rx:B7

https://www.espruino.com/USART
1st pp. "On some boards (for example the nRF52 based Bluetooth Espruino boards) the UART can be used on any pin so won't be explicitly marked, but others (such as the STM32 based Espruino boards) only allow the UART on certain pins."

The Pico is an STM32

http://www.espruino.com/Pico

nRF52 boards

http://www.espruino.com/MDBT42Q
beneath circuit layout image: "Note: The nRF52 port has one available I2C, SPI and USART (and infinite software SPI and I2C). Unlike other Espruino boards, these peripherals can be used on any pin."

'If' there is current development for Software Serial on STM32 boards, note this post from three weeks ago:

http://forum.espruino.com/comments/14679595/
last pp: ". . . but note that software serial really isn't that reliable right now so you may hit issues."

Thanks, Robin.
Yes, I always prioritize some reliable hardware serial ports provided. Just my attention was momentarily attracted by good news in the paragraph:

https://www.espruino.com/USART
As of Espruino v2.00 you can set up 'software serial' using code like:

Mon 2019.04.22

Thanks @gito.nirmolo for pointing that item out.

I needed similar clarification in the discussion I started a month ago, last link in #2 above, and understood from the first sentence from Gordon's response in #9 there (same conversation), that the comment only applied to nRF52 boards. As I wondered about USART references also, @Gordon, is my summary from #2 accurate and is further web page clarification needed, as we now have another end-user that also has identified (possible) misinterpreting documentation? A referenced comment within the Serial class on the API Reference page would also help here.

such as: 'applies to nRF52 boards only'

As I continue to work towards resolving all ambiguity when coding and documenting, it would make sense to me, as the color tag 'keys' beneath the Pinout heading on the STM32 pages, contain the green SPI and dark red I2C references; to stay consistent across all documentation and resolve that ambiguity, place the same color tag keys beneath the tabled list along with the statement 'infinite software SPI and I2C available' or something of the sort. In this manner, the inquisitive visitor will see the consistency along with the note, then not have to wonder, as to whether or not the task is done in hardware and why aren't I seeing an SPI or I2C key as I do see a USART one.

the reason I had to create that post in the first place, ambiguity

As gito.nirmolo points out, is development being done for the STM32 older boards also?

( . . . ?no? . . . as comment on that page was meant for nRF52 boards only?)

Not all of us grasp the nuances immediately after reading specification parlance on the first pass. There is usually a ton of 'actual' detail that needs to be learned over time. . . .

@Robin if you have questions please post them as a separate thread rather than hijaking other people's posts. Espruino is open source (including the docs) so if you think the documentation could do with a change then you can always add it yourself.

Development is still being done for STM32 - in fact a lot of work goes into making sure that improvements apply across all boards.

@gito.nirmolo could you perhaps try software serial connected to a hardware serial port? And you could also try lower baud rates.

Software serial isn't 100% reliable (and perhaps this should be made clearer) because it's at the mercy of what's going on in the rest of the system. Especially if you're connected via USB then it's pretty busy servicing USB interrupts as well.

I think what is happening in this case is IRQs are being used to send the data via software serial, but they're also being used to receive as well - so you're basically guaranteed that when a pin changes state Espruino will be at least a little busy, which will mess up the timings. At lower baud rates you might be fine though.

Tue 2019.04.23

'if you have questions please post them as a separate thread'

No questions. There weren't any written or implied in that post.

'rather than hijaking other people's posts'

During the process of solving the observation made by @gito.nirmolo, it's unfortunate the gist of that post wasn't understood. I was simply pointing out that as gito.nirmolo found conflicting documentation that this wasn't the first time on that exact topic as I had a similar correlation in the other post mentioned. My suggestion went unresolved there, so as this in nearly identical, thought I'd try again. No hijacking here. Fake News!

'a lot of work goes into making sure that improvements apply across all boards'

Although it isn't stated concretely, is the intent to have Software Serial functional on previous SMT32 boards then? (as of 2v0)

'documentation could do with a change then you can always add it yourself'

DANGER Will Robinson!

IMO "Too Many Cooks Spoil the Broth"

Users making unintentional false edits would create even more confusion in the near complete work.

A year ago it was made clear to make update suggestions in the forum. Has this now changed?

@Gordon: Got it, for your explanation :

I think what is happening in this case is IRQs are being used to send the data via software serial, but they're also being used to receive as well - so you're basically guaranteed that when a pin changes state Espruino will be at least a little busy, which will mess up the timings. At lower baud rates you might be fine though.

Thanks to @Robin , for the insight and opening relation to other links/threads.

Although it isn't stated concretely, is the intent to have Software Serial functional on previous SMT32 boards then? (as of 2v0)

Yes. And I just tested on Espruino WiFi:

Serial1.setup(9600,{rx:B7,tx:B6});
var s = new Serial();
s.setup(9600,{rx:B3, tx:B4});
s.on('data', function (data) { print("<SoftSerial>"+data); });
setTimeout(function() {Serial1.print("Hello");},500);

and

Serial1.setup(9600,{rx:B7,tx:B6});
var s = new Serial();
s.setup(9600,{rx:B3, tx:B4});
Serial1.on('data', function (data) { print("<Serial1>"+data); });
setTimeout(function() {s.print("Hello");},500);

Both work great. It's the combination of send and receive that is the issue.

In fact:

var s = new Serial();
s.setup(600,{rx:B3, tx:B4});
s.on('data', function (data) { print("<SoftSerial>"+data); });
setTimeout(function() {
  s.print("H");
}, 500);

Works fine too - so the issue may be that software serial writes block when writing more than 1 character or so, which then messes with software serial reception if it goes on for too long.

A year ago it was made clear to make update suggestions in the forum. Has this now changed?

Yes, making update suggestions on the forum is totally fine.

For the odd change suggested by normal forum users that works out great - however you in particular have made probably 100+ suggestions to date and continue to make them, usually at the rate of a few a week.

I have spent many days implementing a lot of them (tutorial thumbnails, then a list view option because you didn't like that, the tips and tricks page, and many small tweaks to various bits of documentation). However I can't implement every change you suggest as I just don't have the time, so if you actually want a change made, it would be hugely helpful if you could look at doing it yourself.

I've just filed a bug on GitHub for this: https://github.com/espruino/Espruino/issues/1654

When doing RX and TX, only the last character seems to get output correctly - which feels like a bug to me.

Ok, I have now fixed this I believe. The original code now seems to work for me on the latest builds - however any text much longer and it'll fail because the input buffer for software serial is only 7 bytes.

@Gordon, what about making that buffer configurable from the application? (...if there is no hard limit for what ever reason). I know this can be a challenge (depending where - in which zone - this buffer resides in the 'image' / RAM... because - may be - of save() and restore). On the other hand, if a larger buffer helps me, I'm willing to pay with variables...

(Btw, 7 sounds to me like 3 bits in a (8..32 bit) descriptor or 2 32-bit entities.)

Slightly on topic: I tried to use an Espruino Wifi with two serial devices. Plantower PMS sensor continuously sending data at 9600bps.
One on hw serial, one on software serial, and the software serial was kind-of-random. Sometimes got data on the hw serial between receive from the software serial. I will try with the new build!

I think having a resizable buffer is overkill and would require a few more tweaks than I'd like, but I'll bump the buffer size up to 64 since the memory does just end up coming out of JsVars, so using a few extra isn't too bad.

However, 9600 baud is ~1 ms per char - so even with 7 chars it's still 7ms you've got to be busy running JS code for before you run out of buffer,

@AkosLukacs please let me know how you get on - it may be that those most recent changes help you out.

Hi @Gordon Looks like with the latest build, software serial is significantly worse than it was for the Espruino Wifi (haven't tested other boards).

Did some testing before updating, the software serial did lose / CRC error-ed about 15-20% of the 32 byte packets sent by the PMS sensor. But was working.
With the latest build, my previous PMS driver doesn't work at all with soft-serial. Still works with HW serial tho.

Here is the simplest test code that shows the issue:

Serial1.setup(9600, {rx: B7, tx: B6});
Serial1.on('data', function(d){ print("H", d); });

s3 = new Serial();
s3.setup(9600, {rx: A5});
s3.on('data', function(d){ print("s", d); });

// send some data
setInterval(function() { Serial1.println('abcd'); }, 500)

I use A5 as the software serial RX, I think there is nothing special about this pin. Right?

Connect B6 (hw tx) to either B7 or A5, or to both at the same time. I had to ground the A5 pin when not in use, as it was picking up some noise.

2v01 official build:
Everything (tx -> hw rx; tx -> sw rx; tx -> hw and sw rx) works if the "packet" is short, like 'abcd'.
If I send 'PM1234567890ABCDEFGHIJKLMNOPQRST', hw serial is perfect. Software serial fails most of the time, I guess because the sample that prints each character to the USB console.

Latest (33941e) build:
HW serial works as expected
SW serial is not reliable even for short messages :/ Some bytes are ok, but usually receives wrong character, occasionally receives more characters than sent. Even for short messages.

Back to 2v01 official: SW serial back to "normal".

Thanks for checking this out - just tried on the WiFi and I get the same. It seems there's a bit more to it than I'd imagined if different platforms behave differently with it (ideally they shouldn't).

The code all looks a bit nasty anyway, so I'll see what I can do to rewrite it and I'll see if I can get it any better.

When you get a moment, please can you try the build now? It's been rewritten, and to me at least it seems to behave pretty well on nRF52 and STM32, with both software and hardware UART TX.

This works great!
Doing some more testing, but looks good!

Great! My issue above finally solved with new build.

Perfect - thanks for trying it out!