send raw file end before end of file

[Picatout]

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]

Hi, Try to send with a delay (Advanced Configuration).Start with 1ms. /Willem On Tue, 2020-09-15 at 19:42 -0700, Jacques wrote:

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.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Picatout]

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]

What is the size of the file? I can send 300kB without any problems. Did you start with 100ms? Or went up from 1 to 100 (in steps)? On Wed, 2020-09-16 at 06:17 -0700, Jacques wrote:

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".

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[Picatout]

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]

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]

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]

@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]

@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]

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

[m700ace]

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]

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

[3worldswhere]

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]

Hi,

Thanks for the information. Which options do you use when uploading the file? Are you using flow control? If yes is it possible to test it without? If you upload another file is it then also stopping at 4047?

I have an ASCII file with size of 200k and without problems. So there must - somewhere - be a difference is config or options.

On Fri, 2022-07-15 at 05:58 -0700, 3worldswhere wrote:

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. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[3worldswhere]

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]

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]

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

[wvdakker]

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]

@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]

Hello Willem, Thank you for your interest in my problem. I am trying to send a text file to a small microprocessor that receives the text and converts it into a tokenized version for programming into an onboard eprom. The text file is approximately 60K bytes but once tokenized fits easily into a 27c256 eprom. The microprocessors serial interface received a line of text then converts the line into its internal code, it then issue’s a token when it is ready to receive the next line. The chip i am using is an Intel 8052 AH BASIC device.

Kind regards Mike

Sent from my iPhone

On 3 Sep 2022, at 09:12, Willem van den Akker @.***> wrote:



@3worldswherehttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2F3worldswhere&data=05%7C01%7C%7Ccbe5b44c9bd24b92cc3708da8d84106e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637977895585399678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WAQgDjFzgyoC0IWjqPkew5aTzQUq%2BCaD3c7GKcHQeVA%3D&reserved=0

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.

— Reply to this email directly, view it on GitHubhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJeija%2Fgtkterm%2Fissues%2F38%23issuecomment-1236072985&data=05%7C01%7C%7Ccbe5b44c9bd24b92cc3708da8d84106e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637977895585399678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Z%2FQNECtidDYg5tA5YYi7XoY9%2FhqbLYIqZo8ssw3oVpU%3D&reserved=0, or unsubscribehttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FATRMQR2XE72WS7TAMFZW5TLV4MB7JANCNFSM4RODJF5Q&data=05%7C01%7C%7Ccbe5b44c9bd24b92cc3708da8d84106e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637977895585399678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jTKcwxZR8H53yfEfQLiAupPUEvXI%2FAtwSbwHIAMYX2I%3D&reserved=0. You are receiving this because you were mentioned.Message ID: @.***>

[wvdakker]

Hi Mike,

How fast/slow is writing to the eeprom? With a baudrate of 9600, about roughly once per msec a character is sent. If I read the datasheet I dont see writing times, only reading times. I suppose the 8052 is fast enough to operate at 9600.

Greetings, Willem

On Sat, 2022-09-03 at 05:47 -0700, m700ace wrote:

Hello Willem, Thank you for your interest in my problem. I am trying to send a text file to a small microprocessor that receives the text and converts it into a tokenized version for programming into an onboard eprom. The text file is approximately 60K bytes but once tokenized fits easily into a 27c256 eprom. The microprocessors serial interface received a line of text then converts the line into its internal code, it then issue’s a token when it is ready to receive the next line. The chip i am using is an Intel 8052 AH BASIC device.

Kind regards Mike

Sent from my iPhone

On 3 Sep 2022, at 09:12, Willem van den Akker @.***> wrote:



@3worldswhere< https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit hub.com%2F3worldswhere&data=05%7C01%7C%7Ccbe5b44c9bd24b92cc3708da8d84 106e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637977895585399678% 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I k1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WAQgDjFzgyoC0IWjqPkew5aTz QUq%2BCaD3c7GKcHQeVA%3D&reserved=0>

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.

— Reply to this email directly, view it on GitHubhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2 F%2Fgithub.com%2FJeija%2Fgtkterm%2Fissues%2F38%23issuecomment- 1236072985&data=05%7C01%7C%7Ccbe5b44c9bd24b92cc3708da8d84106e%7C84df9 e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637977895585399678%7CUnknown%7C TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV CI6Mn0%3D%7C3000%7C%7C%7C&sdata=Z%2FQNECtidDYg5tA5YYi7XoY9%2FhqbLYIqZ o8ssw3oVpU%3D&reserved=0, or unsubscribehttps://nam12.safelinks.protection.outlook.com/?url=https %3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe- auth%2FATRMQR2XE72WS7TAMFZW5TLV4MB7JANCNFSM4RODJF5Q&data=05%7C01%7C%7 Ccbe5b44c9bd24b92cc3708da8d84106e%7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1%7C0%7C637977895585399678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd ata=jTKcwxZR8H53yfEfQLiAupPUEvXI%2FAtwSbwHIAMYX2I%3D&reserved=0. You are receiving this because you were mentioned.Message ID: @.> — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were assigned.Message ID: @.>

[m700ace]

Hello Willemstad, The the device I’m using is a pre programmed device originally produced by Intel the device runs an internal basic interpreter the ascii text I’m sending is received by the device, tokenized and stored sequentially in an external RAM memory device. The baud rate I’m using is 4800, quite slow with an end of line delay to allow for tokenizing. I have used the XP version of hyperterminal but wanted a more compact solution for on site service.

Regards Mike

Sent from my iPhone

On 5 Sep 2022, at 05:49, Willem van den Akker @.***> wrote:



Hi Mike,

How fast/slow is writing to the eeprom? With a baudrate of 9600, about roughly once per msec a character is sent. If I read the datasheet I dont see writing times, only reading times. I suppose the 8052 is fast enough to operate at 9600.

Greetings, Willem

On Sat, 2022-09-03 at 05:47 -0700, m700ace wrote:

Hello Willem, Thank you for your interest in my problem. I am trying to send a text file to a small microprocessor that receives the text and converts it into a tokenized version for programming into an onboard eprom. The text file is approximately 60K bytes but once tokenized fits easily into a 27c256 eprom. The microprocessors serial interface received a line of text then converts the line into its internal code, it then issue’s a token when it is ready to receive the next line. The chip i am using is an Intel 8052 AH BASIC device.

Kind regards Mike

Sent from my iPhone

On 3 Sep 2022, at 09:12, Willem van den Akker @.***> wrote:



@3worldswhere< https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit hub.com%2F3worldswhere&data=05%7C01%7C%7Ccbe5b44c9bd24b92cc3708da8d84 106e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637977895585399678% 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I k1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WAQgDjFzgyoC0IWjqPkew5aTz QUq%2BCaD3c7GKcHQeVA%3D&reserved=0>

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.

— Reply to this email directly, view it on GitHubhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2 F%2Fgithub.com%2FJeija%2Fgtkterm%2Fissues%2F38%23issuecomment- 1236072985&data=05%7C01%7C%7Ccbe5b44c9bd24b92cc3708da8d84106e%7C84df9 e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637977895585399678%7CUnknown%7C TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV CI6Mn0%3D%7C3000%7C%7C%7C&sdata=Z%2FQNECtidDYg5tA5YYi7XoY9%2FhqbLYIqZ o8ssw3oVpU%3D&reserved=0, or unsubscribehttps://nam12.safelinks.protection.outlook.com/?url=https %3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe- auth%2FATRMQR2XE72WS7TAMFZW5TLV4MB7JANCNFSM4RODJF5Q&data=05%7C01%7C%7 Ccbe5b44c9bd24b92cc3708da8d84106e%7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1%7C0%7C637977895585399678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd ata=jTKcwxZR8H53yfEfQLiAupPUEvXI%2FAtwSbwHIAMYX2I%3D&reserved=0. You are receiving this because you were mentioned.Message ID: @.> — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were assigned.Message ID: @.>

— Reply to this email directly, view it on GitHubhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJeija%2Fgtkterm%2Fissues%2F38%23issuecomment-1236537150&data=05%7C01%7C%7C932f3218531640e4188008da8efa0fda%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637979501898107396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oDt8zwdMpo2cs336ZnVIq5Y7Tium0Iflk5uFxrOghpg%3D&reserved=0, or unsubscribehttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FATRMQR3OB76YHLTUKBUARGTV4V3WXANCNFSM4RODJF5Q&data=05%7C01%7C%7C932f3218531640e4188008da8efa0fda%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637979501898107396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WnmCXO93zYJTjS1MqK2QZA3TyYGEWU0mRmZfUWvfq%2Bw%3D&reserved=0. You are receiving this because you were mentioned.Message ID: @.***>

[dirkatz]

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]

Hi Dirk,

Good to hear! Hope others have tested with 1.2.1, but not sure.

Regards, Willem

On Wed, 2022-12-21 at 08:26 -0800, dirkatz wrote:

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 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were assigned.Message ID: @.***>

[blardyblar]

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]

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]

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

[m700ace]

Great that your looking at the problem I’m having. A loadable solution would be good. 🥰😎

Sent from my iPhone

On 22 Jun 2023, at 19:17, Willem van den Akker @.***> wrote:



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

— Reply to this email directly, view it on GitHubhttps://github.com/Jeija/gtkterm/issues/38#issuecomment-1603115751, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATRMQR76YCKY2D5ZZ6FN7I3XMSDZ7ANCNFSM4RODJF5Q. You are receiving this because you were mentioned.Message ID: @.***>