Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

send raw file end before end of file #38

Open
Picatout opened this issue Sep 16, 2020 · 27 comments
Open

send raw file end before end of file #38

Picatout opened this issue Sep 16, 2020 · 27 comments
Assignees
@wvdakker
Labels
bug Need more info

Comments

@Picatout
Copy link

I try sending a raw file but the process stop before the end of file. Every text as been is without errors it just stop send in the middle of the file. The terminal is configured 115200 8N1 no flow control.
@wvdakker
Copy link
Owner

wvdakker commented Sep 16, 2020 via email

@Picatout
Copy link
Author

It is already configured for 100msec delay. It is more like GTKTerm is expecting an ACK or something after sending a certain amount of data even if the port is configured "no flow control".

@wvdakker
Copy link
Owner

wvdakker commented Sep 16, 2020 via email

@Picatout
Copy link
Author

context: Sended a Forth source file to an MCU with stm8_eForth installed. The MCU use GTKTerm as user interface. Actually the source file sent is 6002 bytes. GTKTerm stop after 4096 bytes sent and wait, no error message.
I started with lower delay 1,5,30ms but these were too short. The MCU must compile each forth line before receiving next one. With 100ms delay the 4096 bytes received by the MCU are compiled OK but nothing come next.

Looking a GTKTerm source code I see that in ecriture() func an 4096 bytes buffer is used. So it read first 4096 bytes from file transmit the buffer the stop there...
Tried with 50ms delay same result as with 100ms delay, stop after first buffer sent.

@Picatout
Copy link
Author

Did a test by replacing delay by "wait for this special character before passing to next line" with the same result. First buffer is transmitted then it stop in an infinite loop.

@m700ace
Copy link

m700ace commented Apr 5, 2021

what is the buffer for? its 4096 and stop transmitting is a bit restricting. Should it not loop back after the number of lines setup have been sent or received?

@wvdakker
Copy link
Owner

wvdakker commented Apr 21, 2021 •
edited
Loading

@m700ace or @Picatout What kind of file do you use? ASCII/Binary?
Perhaps you can post an example. As earlier mentioned I can send 300kB without any problems.

@wvdakker
Copy link
Owner

wvdakker commented Apr 21, 2021 •
edited
Loading

@m700ace,@Picatout
It is possible to do a little test with socat?
Run
socat -d -d pty,raw,echo=0 pty,raw,echo=0'
This gives 2 pty's; N and N+1
In another terminal run
cat < /dev/pts/5

Start gtkterm and open port /dev/pts/N+1 and write
a raw file. You can set local echo on if you want.

Check the difference between the rawfile and the output of the 'cat' terminal
If it stuck at postion 4096 then note the last character.

@Picatout
Copy link
Author

Old story! I written my own tool to send file to serial port so I don't fill concerned anymore.

@m700ace
Copy link

m700ace commented Apr 22, 2021

The file I’m sending is an ascii text file. If receiving data it goes way past 50k but sending data just over 4K

@wvdakker
Copy link
Owner

Can you post the file you transfer?
I did a test with 50k ASCII and also 13k binary. No problems.

@3worldswhere
Copy link

Having a similar problem, I'm using GTKTerm to download code (text file, S19 format, ~12k total) to an embedded system, it stops before end of file consistently at 4047 bytes. I thought it might be related to speed that my target MCU could handle so I removed my hardware and set up two GTKTerms talking to each other and sent the same file: same results 4047 bytes then dead stop. Hoping to avoid writing my own or having to use a windows box just to send a file.

@wvdakker
Copy link
Owner

wvdakker commented Jul 16, 2022 via email

@3worldswhere
Copy link

Hi,
Thanks for the response. This is a simple Rx/Tx only connection, low speed (9600, 8, no parity, one stop bit, no flow control). In the past with other terminals (typically tera term) we used character and / or line delay to avoid overflowing the target's UART buffer. I tried using line delay, but no matter the setting (0, to 500mS/line) it stopped at the same point.
That's when I connected two instances of the terminal (using USB/Serial cables) back to back, taking my hardware out of the equation completely, the file still stopped at the same point. I am running gtkterm 1.0.1 on a recent version of linux mint.
I just tried sending another text file between the two terminal instances, it stops at 4624 bytes. It is the same sending from either terminal, I tried several times, it seems repeatable. So it seems (with the small amount of testing I have done) that the amount of the file sent depends to some extent on the file selected, but it seems consistent for that file. Adding 50mS line delay has no effect: still stops at the same point. I have now tried two different computers, though both are running linux mint.
Thanks for any help you can give.

@3worldswhere
Copy link

Further information: I closed one instance of GTKTerm and connected to that port (/dev/ttyUSB0) with a terminal running 'screen', then copied the contents of the file I was testing with to the clipboard and pasted it into the screen terminal. The entire file sent correctly to the receiving instance of GTKTerm. Hopefully that is of some use.

@3worldswhere
Copy link

Correction: the full file was sent using 'screen' but there were many dropped characters in the received file.

@wvdakker
Copy link
Owner

wvdakker commented Jul 25, 2022 •
edited
Loading

Hi,
Can you give me the exact file size of all files and position where it stops?

If the transfer stop do you get a 'Error sending file' message? Or does it end without any message?

@wvdakker wvdakker self-assigned this Aug 17, 2022
@wvdakker
Copy link
Owner

wvdakker commented Sep 3, 2022

@3worldswhere

I did some testing with a gtkterm and screen system and can reproduce the problem.
As far as I can see the buffer is working correctly. All data is send to the serial device.
The problem arises when the 'receiving' system is to slow. The only way to make it
work correctly is lowering the speed (as you did) or use a smaller buffer.
Lowering the speed did not work for you, you used 9600 and it also had problems.

Do you have the posibility to test it with smaller buffers? If that works we could make
the buffersize configurable in 2.0. Assume the problem still exists in 2.0. It will use a
completly different buffering.

Hope to hear from you.

@m700ace
Copy link

m700ace commented Sep 3, 2022 via email

@wvdakker
Copy link
Owner

wvdakker commented Sep 5, 2022 via email

@m700ace
Copy link

m700ace commented Oct 11, 2022 via email

@dirkatz
Copy link

dirkatz commented Dec 21, 2022

Hi Willem,
I had the same problem (raw transfer stops early) with version 1.0.1-1 of gtkterm. This version comes with Ubuntu 20.4 (LTS).
I built version 1.2.1 from this repo. The problem does not occur with this version.

Regards,
Dirk

@wvdakker
Copy link
Owner

wvdakker commented Dec 21, 2022 via email

@blardyblar
Copy link
Contributor

I have the exact same issue. I installed GTKTerm 1.2.1 from Debian (SID).
I can receive files just fine, but Send RAW file just stops if the file is bigger than 4k.
I can send the exact same file just fine with minicom.

For files that are smaller than 4k, it sends correctly, but the dialog box with the progress bar doesn't go away automatically either, and you have to manually press 'Cancel' after it's done. For files that are larger than 4k, the progress bar gets stuck and it just won't send anymore characters.

My settings are 119,200 7E1 no flow control. With the cable completely disconnected and no flow control, it should just send the whole file 'into the ether', but it still doesn't work.

My real settings need to be 119,200 7E1 with hardware flow control to actually talk to the device. Again, this works correctly in minicom, but GTKTerm would be nicer to use as it allows saving captures coming in the other direction slightly easier than minicom does.

@blardyblar
Copy link
Contributor

I just compiled from source, and now the issue is gone - so it has something to do with the debian package - the current source works fine (including closing the progress dialog after the file is sent)

@wvdakker
Copy link
Owner

Hmmm ... interesting
I will take a look at the debian package.

@m700ace
Copy link

m700ace commented Jun 22, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@wvdakker wvdakker

Labels
bug Need more info
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@wvdakker @Picatout @blardyblar @m700ace @3worldswhere @dirkatz