Tim@Visual Micro wrote on Aug 20
th, 2022 at 1:58pm:
Thanks for the info. So for our tests we should use Teensy in Dual Serial Mode where only the main upload port is being used for serial?
I *think* the port that VM identifies as the upload port is the one I'm currently using for serial ASCII communications between my device and the VM serial terminal. I'm not 100% sure of that because the Teensy does not use any serial ports for uploading, and in fact, virtual serial ports "go away" during uploading and are rebuilt at runtime only if the user defines them in the device software.
Port assignments in Windows are non-deterministic in the sense that when a USB endpoint is defined with two or three virtual serial ports, Windows does not honor the order defined in the USB request. For example, a dual virtual serial port connection with hard-coded setup request sometimes is assigned so that serialusb0 = Com2 and serialusb1 = Com3, and sometimes it may be the other way around. Once assigned they are stable on reconnect unless some external disruption occurs.
Depending on the installation, I've found that VisualMicro may identify either device port as the "upload" port, though this is stable once established.
In my specific case, the device sets up two virtual serial ports. At the moment, those appear in Windows as Com4 and Com9. The device and host communicate using a high-speed binary protocol on one port (the SESSION_PORT). The device communicates with the Visual Micro serial terminal on the other port (the DEBUG_PORT).
My device listens on all device ports for a probe from the host application and responds with a device portID, so serial communication with the VM terminal could be on either the higher or the lower COM port of the pair. However, in the device this communication activity is currently mapped to serialusb1, which is currently mapped to COM4, while serialusb0 is currently mapped to COM9 in WIndows.
At this time, when I "build and run" using VM, it is COM4 that is disconnected and reconnected, and I *think* this means VM identifies COM4 as the upload port.
Quote:
Can you try to increase the "vMicro>General>Global Properties>Communications>Screen Buffer Size" to a larger value.
This was set to 1,000,000 and I have now set it to 10,000,000 & will test to see whether it will affect the 128 byte data loss issue. I suspect it may not, because I sometimes see data loss within the first screenful of data received.
I suspect the problem likely relates to the frequency of reads on the PC side, because I can cause similar data loss in testing by slowing down serial port read activity in my own programs. To keep up with the high speed serial channel I have to put serial port reading in a tight loop on a dedicated thread that does nothing but feed a circular buffer.
Of course my ascii output for debugging purposes is at nowhere near that sustained rate, but it is somewhat bursty when I'm tracking microsecond intervals between block writes for an SD card filesystem or something like that.
Also: I figured out some of what was going on with problem #1 (the "terminal freezing problem").
The freezing is definitely due to AutoScroll getting turned off. I still do not know what causes / caused AutoScroll to occasionally freeze when I'm working in a completely different window, but that's not really a critical problem so long as I can un-freeze it. My previous inability to do so (thus my belief that the problem was not with auto-scroll) was due to user error and misunderstanding arising from interactions with an obscure VM bug and a couple of design "features." I will attach a short video illustrating the bug. Here's what was happening:
I always use the VM terminal window at nearly full screen height, so the bottom of the VM window is close to the windows taskbar. If I hover over any of the buttons at the bottom of the VM window, a tooltip appears for that button. If that tooltip is vertically large enough to overlap the taskbar, it begins to flicker on and off as the two battle for visibility (perhaps just Z-order, but since the taskbar is owned by the OS maybe there's even a momentary loss of focus). This can happen with any of the buttons, but as a practical matter the risk is highest for AutoScroll and Auto-Recon because they have the tallest tooltips. I'd have to shorten the window significantly to stop these two from flickering.
During flickering, the color of the AutoScroll button is constantly changing from enabled to disabled. During this time, clicking on the AutoScroll button often doesn't turn it on, or if it does, it turns back off right away. Your suggestion to check auto-scroll led me to the realization that the flickering is the reason the Auto-scroll button did not un-freeze the screen. When I tried multiple clicks it did eventually work ("because timing??").
Another element contributing to the confusion arises from the fact that VM does not recognize a button click when first regaining focus. After working in another window, the first click on the autoscroll button does nothing at all, regardless of flickering. This "first click" issue is well known in the UX field and is readily addressed through a careful choice of events to handle.
Another point of confusion for me was the fact that "scrolling to the bottom" (as I understand that phrase) does not by itself reactivate auto-scroll, since I scroll to the bottom of a window using the mouse wheel (or occasionally the scrollbar or scroll arrows). What reactivates autoscroll is placing a cursor in the window and moving the cursor to the very bottom of the document. It took me quite awhile to figure that out -- it wasn't clear to me from the documentation, nor had I understood it from anything I found in the forums. It's possible that I may be the only person who would reach for the mouse wheel or scrollbar when instructed to to scroll to the bottom...
Finally, I was misled by the fact that the colors of active, inactive, and hovered buttons are so similar on my system that I can barely tell the difference between them. The text itself does not dim (except for the Connect button, which is dim when connected, which seems more like an ON state than an OFF state). Even after years of VM use I was never sure which pale blue color was ON and which pale blue color was OFF. With a little effort I can tell the difference now, though! But if there's ever a significant new release, it might be worth revisiting those visual cues.
= = = = =
I will test changing the screen buffer size and will let you know whether that affects the remaining data loss scenario.
Thanks!