Usart terminal tool always covers the IDE

[OT]

The terminal tool works much better now, I really like the autoconnect feature.
However even if the terminal does not have the focus, it insists on staying in the forground, covering all other windows. This also applies to a number of other tools (but not the HID terminal). This gets very awkvard on a small screen. Is there a way to make it not do that and take on more moderate role?

I did have one crash after a lot of use when I closed the terminal window. It took down the whole IDE. Bug report sent.

[OT]

Two other problems with the terminal program:

1. It skips characters. (This made me incorrectly think that the MMC-FAT library had a problem.)

2. Log file does not work. After specifying file name the button is still grayed out, nothing happen when trying to click it and no file was created.

[slavisa.zlatanovic]

Hi!

I've managed to reproduce the issue from your first post concerning the USART Terminal Window.
Thanks for reporting it.

1. It skips characters. (This made me incorrectly think that the MMC-FAT library had a problem.)

I couldn't reproduce this one.
Sometimes, it shows data with some delay but never skipped a byte.

2. Log file does not work. After specifying file name the button is still grayed out, nothing happen when trying to click it and no file was created.

The log file must exist before you choose to log data in it.

Best regards
Slavisa

[OT]

Are you saying that I have to manually create a log file. When I specify a file name, I expect the file to be created if it does not exist.

Try running the terminal at high baud rate on a not too powerful computer. The FFT-FAT example for instance writes very quickly to the serial port at the end. It skipped the 'End test' statement. You could also try my O2anSx project that I previously submitted on the project page, it communicates on UART2 at 115.2 kbits/s. Note that characters are only skipped now and then.

[OT]

Hi!

1. It skips characters. (This made me incorrectly think that the MMC-FAT library had a problem.)

I couldn't reproduce this one.
Sometimes, it shows data with some delay but never skipped a byte.

I now see what might be happening. The display of the serial stream is still too slow (to the degree of being pretty unusable, this was reported in ver. 3.0 beta by several of us). Apparently it is buffering what isn't displayed right away, in the beginning you might be right, it is not skipping anything or barely anything. However with a continuous stream of serial transfer going on for some time, at the end the buffer fills and then and things seem to go astray. When closing the terminal, I then I again got an exception. Bug report sent.
To test this you can use the O2anSx project I previously submitted on the support page (see above, ignore flickering of display, it will still work, or or use another project with a fast continuous serial output). Monitor the stream from UART2 at 115.2 kbits/s for a good while and you will see what I mean. I know the serial output from the above project is working properly when I monitor it with my own terminal program.

[slavisa.zlatanovic]

Hi OT!

Are you saying that I have to manually create a log file. When I specify a file name, I expect the file to be created if it does not exist.

Yes. I'll report this to our software developers. This could be a tool enhancement.

The display of the serial stream is still too slow...

I've managed to reproduce this issue.
I'll report it.

Thanks!

Best regards
Slavisa

[OT]

Hi OT!

The display of the serial stream is still too slow...

I've managed to reproduce this issue.
I'll report it.

Thanks!

Best regards
Slavisa

The terminal is still slow. I did not notice this before, but when one clicks disconnect, the rate of display speeds up dramatically when showing what is evidently stored in the buffer. Tested with a stream at 115.2 kbaud that repeats a long line every 0.2 second. It seems that it is not capable of receiving and displaying (at much rate) at the same time.

[zristic]

The terminal is still slow. I did not notice this before, but when one clicks disconnect, the rate of display speeds up dramatically when showing what is evidently stored in the buffer. Tested with a stream at 115.2 kbaud that repeats a long line every 0.2 second. It seems that it is not capable of receiving and displaying (at much rate) at the same time.

Yes, we are aware of it for some time already. It is on the list for being fixed.