serial communication

[Pere font vilanova]

Maybe you can help me with another problem I'm having with Flashforth.
If I connect the ESP01 board directly to the PC's serial port and connect with TeraTerm, I can send AT commands and connect to an external server, and when it sends information, I read it in the terminal.
If I connect the ESP01 to Scamp and run the TERM program, which reads the data from RX1 and sends it to the screen and sends the keyboard data to TX1, I can program the ESP01 and connect to the external server. I send the required commands and it responds, but for some reason I only receive part of the message. It doesn't crash or anything, but I only receive part of the message.

[Mikael Nordman]

What is the term program?

[Pere font vilanova]

is a program to simulate a terminal in scamp3. is written in the interfaces, serial cimmunications option in the udamonic web page. basically is a loop that read the rx1 and emit and read the key and send by tx1. i used to communicate or read data from/to serial devices by hand.

[Mikael Nordman]

You mean something like this ?
https://sourceforge.net/p/flashforth/code/ci/master/tree/pic18/forth/bridge.fs

It should work transparently. Once I used it as a bridge to a dsPIC. But I do not remember any problems. I have no idea what the problem could be. I'll test it some day.

[Pere font vilanova]

no, i worked with this code
​: term ( -- , uses UART1 )
cr
​ 2 fg \ green text, optional
begin
rx1? if \ has something come in?
rx1 emit \ then display it locally
then

 key? if       \ local user typing
   key         \ get the char
   dup emit    \ echo it locally 
   dup tx1     \ send it
   dup $d = if \ return key?
      $a emit  \ print a new line as well
   then
   $1b = if    \ ESC to quit

​ cr
plain \ plain text
exit
then
then
again
;

but also i will try your code tocheck..... thanks
why you use u1- ?
is possible that if message is longer than 31 bytes the message be cutted?

[Mikael Nordman]

It could be that the local echo increases the traffic on the USB interface so that incoming traffic from the serial line is not read out fast enough and as a consequence the serial line interrupt buffer throws away some characters.
What is the speed towards ESP01 ? 9600? 115200?
The USB TXU routine is not very fast. It sends only one character per USB transaction.

[Mikael Nordman]

I did some tests like this

: test2 ticks swap for $30 emit next ticks swap - cr u. ;

On Windows and teraterm the speed is 124 Kbit/s. 10000 chars prints out in 643 milliseconds.
On Linux and ff-shell the speed is 506 Kbit/s. 10000 chars prints out in 158 milliseconds.
OSX I do not know how that behaves.

So if the data from the ESP01 comes in with 115.2 Kbit/s and the local echo is in use and you are using Windows, then there could be a problem.

One possible improvement could be to remove the echo part.

Another would be to put the RX1 -> TXU part in a background task so that TXU and TX1 do not block each other when they are queuing for the TX to become free.

[Pere font vilanova]

already i removed the echo without results, now i will try with a background task. im working in windows PC. the esp01 speed is 115.200
but wheni use teraterm directly connected to esp01, it woks very well. ( maybe the delay in code of term program is the reason?) first i will check a task to read . send the command and start task. i will see, thanks for your help.....without the term program.

[Mikael Nordman]

How long are the messages and how much is lost ?

[Mikael Nordman]

What is the serial speed and can you lower the serial speed on the ESP01 ?

[Pere font vilanova]

the message is about 113 bytes, and i lost almost all.

[Mikael Nordman]

I have two Scamps connected together over UART1 and using the bridge on one scamp to use as terminal of the other Scamp and there is no data lost. So there appears not to be any speed problem at 115200.

Your problem is a mystery.

[Mikael Nordman]

I have two Scamps connected together over UART1 and using the bridge on one scamp to use as terminal of the other Scamp and there is no data lost. So there appears not to be any speed problem at 115200.

Your problem is a mystery.

Actually I had no problems when using Linux. But when I use Windows I get some character loss on the bridge but not much, less than 1%.

[Pere font vilanova]

i also tested this option with two scamps without problems. or the scamp with the lora module. even two scamps communicte with two esp01 modules with the bridge and with the term. but when i connect with the server from iss, mentioned in the post of mr Jan i can communicate but when the server send the las message of 113 bytes about, always i received only about 1/4 of message and after the 10, 15 characters the message is a garbage.....but this happen only with tje term program. i will check with the bridge one and with a bacground task....and i will inform you.
as last thing i can set the serial speed at lower ratio.

[Pere font vilanova]

Finally the problem was solved. the bridge program or the task system gave also not reception of all characters.
at the end the solution was to put the speed at 9600 bauds! now all is working perfect...

[Mikael Nordman]

So the TXU is too slow to swallow the input from RX1@115200 baud.

I will update FF to transmit 8 or 16 bytes at a time over USB.

I removed that functionality 2 years ago because I thought it would be fast enough with just one byte per USB transaction. But obviously not with Windows, which I never use myself.

[Mikael Nordman]

Updated the PIC24 USB code to a 16 byte packet size for TXU. RXU has a 8 byte packet size like before.
The transfer speed is now approx. 120000 characters per second.
That is approx. 1 Mbit/s.
This has been measured with Linux and with Windows 11.

[Pere font vilanova]

fantastic