B4R Question ESP8266 - software serial - not receive data

[petr4ppc]

Dear friends, please very much for help,

I am using two esp 8266 connected via sofware serial

ESP1 to ESP2 (see picture with pinout in attachement)
pin 14 --> pin 12
pin 12 --> pin 14
GND --> GND
both esp are connected to usb

I have this simple code in both esp:

#Region Project Attributes
    #AutoFlushLogs: True
    #CheckArrayBounds: True
    #StackBufferSize: 500
#End Region
'
Sub Process_Globals

    Public Serial1 As Serial                'Serial connection for Debug..
    Public Serial2 As SoftwareSerial      
    Public astream As AsyncStreams
    Public timer As Timer
'
End Sub

'
Private Sub AppStart
     Serial1.Initialize(115200)
     Log("AppStart")'
'  
    Serial2.Initialize(9600,12,14)    'pin ESP07
    astream.Initialize(Serial2.Stream,"astream_newdata","astream_error")
'
    timer.Initialize("timer_Tick",2000)
    timer.Enabled=True

End Sub

Sub timer_Tick
    Log("tick")
    Dim msg() As Byte ="hallo"
    astream.Write(msg)
End Sub


Sub astream_newdata (Buffer() As Byte)    '
Log("from esp:",Buffer)
End Sub

'
Sub astream_error
    Log("Serial - No Connection")
End Sub

I am using board setting - please see picture

but I am trying it this simle connection second day and I cant receive data....

Please, where I am doing mistake?
I want use software serial and in the past I know that I had success with this, but now I dont know where I am doing mistake...

Please for help..
Thank you
p4ppc

 

[barx]

Please explain from the beginning.

This is the documentation of Stream.readBytes: https://www.arduino.cc/reference/en/language/functions/communication/stream/streamreadbytes
What do you expect to happen when the value is -1 ?

From the beginning:
I have a project written a long time ago (2 years roughly) in b4r. It is an ESP8266 and uses an RS232 to TTL board to talk to a Solar inverter. It was working fine. Then I updated it recently (latest b4r, arduino, etc) and it broke. it appeared to stop receiving data back from the rs232 connection. I thought I had damaged the rs232 board when tinkering so ordered a new one. In the meantime I noticed this thread with someone else having the same issue so I wondered if it was a software issue.
Now I have new hardware and tested it with a simple arduino sketch in loopback fashion (connecting the rx and tx pins on the d sub connector). It gets a response.
I then created a small project in b4r to test the same. It does not work. _NewData never seems to be called. So I went hunting in the libs to try figure why. I added Serial.print statements to try follow the code flow and discover where it goes wrong.

In the B4RStream lib, when it reads the bytes, the code that follows looks as though it expects the 'number of bytes read' to be stored in the 'i' variable. This is also what the documentation linked above would indicate.
This does not happen though.
On the first read of bytes, 'i' is set to -1 and so the 'total' is never incremented and is returned as 0.

Now, given that this is being used with SoftwareSerial. From the docs for SoftwareSerial->read(). It returns the bytes read, not the number of bytes read. I don't know if this is what could be causing it?

The code in subject is below to save you having to find/open files. This is from B4RStream

    UInt B4RStream::ReadBytes(ArrayByte* Buffer, UInt StartOffset, UInt MaxCount) {
        ::Serial.println("Stream- ReadBytes");
        ::Serial.println(StartOffset);
        UInt total = 0;
        while (MaxCount > 0) {
            ::Serial.println(MaxCount);
            ::Serial.println("Bytes");
            //::Serial.println(wrappedStream->readBytes(((Byte*)Buffer->data + StartOffset + total), MaxCount)); // When uncommented, this prints 4294967295 I commented it though in case it consumed the bytes
            Int i = wrappedStream->readBytes(((Byte*)Buffer->data + StartOffset + total), MaxCount);
                ::Serial.print("i: ");
                ::Serial.println((String)i);  // Logs -1
            if (i <= 0) {
                ::Serial.print("total: ");
                ::Serial.println(total);
                return total; // This retuns total as 0
            }
            MaxCount -= i;
            total += i; // This never runs
        }
        
        return total;
    }

Lastly, just to reinforce the theory. As mentioned in my last post, when accessing serial stream direct in b4r. The bytes are logged

b4r - helloworld

but the length (len) = zero

Hope this helps and creates a clear enough picture.

 

[barx]

Just to add, and I'm sure this won't be the final answer. I have managed to get the test project reporting something.

Changing the B4RStream->readBytes method to use wrappedStream->available() to tally up the total like below

    UInt B4RStream::ReadBytes(ArrayByte* Buffer, UInt StartOffset, UInt MaxCount) {

        UInt total = 0;
        UInt availableTotal;

        while (MaxCount > 0) {

            availableTotal = wrappedStream->available();
            Int i = wrappedStream->readBytes(((Byte*)Buffer->data + StartOffset + total), MaxCount); // i not used

            if (availableTotal <= 0) {
                
                return total;
            }
            MaxCount -= availableTotal;
            total += availableTotal;
        }
        
        //::Serial.print("totalled: ");
        return total;
    }

The AsyncStream _NewData sub now gets called in b4r and the bytes are indeed available in the buffer.

Would be nice if we can get this sorted as I don't really fancy re-writing 600+ lines of code translating into arduino code. Especially as I'm not fluent in arduino code so will come with it's own headaches ?

 

[barx]

Had a little bit more of a play today. The above gets some results, but it isn't reliable. Sometimes end up with extra bytes and also had the odd wdt trigger. Also getting an exception in some other part of code, not sure if that is a buffer overrun due to extra bytes. Think I may call it a day on it.

I tried lol, but run out of ideas and knowledge.

 

[Erel]

In the B4RStream lib, when it reads the bytes, the code that follows looks as though it expects the 'number of bytes read' to be stored in the 'i' variable. This is also what the documentation linked above would indicate.
This does not happen though.
On the first read of bytes, 'i' is set to -1 and so the 'total' is never incremented and is returned as 0.

It that is true then it is a major OS bug. This means that you cannot use readBytes at all as you have no reliable way to find the actual data that was read.

You cannot assume that all available bytes will be read.