 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : GFXterm - does not like COM8?
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Hi there.  Rob - I get this odd error when I connect a VT100 terminal(Geoff's MX250 one) to GFXterm:  TeraTerm talks just fine to it on COM8, but If I close TT(leaving VT100 connected), and try to connect via GFXterm, I get that error every time. Close GFXterm, reopen TeraTerm, connect to COM8 - away I go no problems. Any reason why that should be? I don't care - I was only playing with the VT100 board tonight for something. Just thought I would report it. Smoke makes things work. When the smoke gets out, it stops! |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
I don't think that com8 is the problem. The VT100 code had an issue with it's USB-serial. MMEdit and a few other programs also have problems talking to them. It was fixed for some later devices but I don't think the VT100 has been updated. Jim VK7JH MMedit |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Ahhhhhhhh - gotcha. Yes, I seem to recall that being the case now, but had totally forgotten about that. Smoke makes things work. When the smoke gets out, it stops! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
Over the years I have noticed that some 'software' has a working 'limit' for correct operation via the Windows issued virtual COM port numbers. These limits often seem to be COM8, COM16, and COM32 (maybe higher too, but never been in that scenario). It is not a hardware issue, and as TassyJim says, it is fixable via the applications software. I seem to remember that MMEDIT suffered from a limit of 16 (or 8?) - and Jim did indeed fix it  |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
GFXterm is perfectly happy with COM9 - which is a 1455 interface thing. Smoke makes things work. When the smoke gets out, it stops! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
Depending on how software is written, some may 'mask-out' bits (i.e. the lower three bits) and then do their 'check' on that. Hence 8 becomes zero and things stop working; 9 becomes 1, and this could be valid (even if there is a 'clash' with other hardware). Not saying that this is the issue - just that I have seen lots of different problems with the software when dealing with COM Port numbers when 'hitting' COM port 8, 16, 32 and your original post immediately made me think of this. Purely out of interest, can you 'force' the Com Port number (through the 'Advanced' tab within Device Manager) to other values including 16 and 32 and see if that works or fails? Will fire up a MX250 VT and see if I can repeat here . . . . |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
an interesting error, if i had the hardware here i could run GFXterm from the delphi IDE and inspect the data passing back and forth between GFXterm and windows while the port is being opened. comm port names are obtained directly from the windows registry, so there are no limits on the port number - indeed, the name does not even need to be in the form of "com<n>", it simply has to match one of the registry enteries under the list of active serial comm ports. the sequence of win32 API calls for opening and configuring the comm port is then: 1. CreateFile: this converts the ascii port name into a 32-bit numeric handle and opens that handle. this is the only part that uses the ascii name. 2. SetupComm: configures the size of window's internal read and write buffers associated with the port's handle. 3. GetCommState: retrieves from windows the port's current configuration into a DCB (device control block) structure. 4. BuildCommDCB: modifies the DCB using the string "baud=38400 parity=n data=8 stop=1" (or whatever other baud rate you have entered). 5. SetCommState: sends the modified DCB back to the driver controlling the port. 6. SetCommTimeouts: adjusts read/write timeouts. while you're seeing the failure at step 5. SetCommState, i bet the problem is actually with GetCommState returning invalid data in the DCB. examining the DCB while GFXterm is running within the IDE would show the corrupt entries. or i could compile a 'special' version that displays the DCB, but that would be more difficult! cheers, rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
give this test version a try: 2017-12-02_212819_GFXterm_TEXTD.zip it should pop up a couple of dialogs, the first showing the DCB retrieved, the second showing the DCB that it is about to try and save. if you can grab an image of each one, it should provide a few clues about what is going on. cheers, rob :-) |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Howdy. As requested:    Smoke makes things work. When the smoke gets out, it stops! |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
right, give this test version a spin: 2017-12-04_095036_GFXterm_TEST_version_E.zip you'll still see an error, but have the option of ignoring it. tassyjim sent me some info that allowed unravelling the mystery a little more - it looks like there is/was a bug in the microchip USB stack, and that teraterm (rather naughtily) silently ignores the resulting error returned by windows. cheers, rob :-) |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Downloaded, will try later and let you know. Is there any chance you can add XMODEM ability to GFX term? GFX is my go-to terminal now for working with MM projects, but I still have to use TT to transfer any program one way or the other. Not a problem if this is a no, just thought I would ask while I had your attention.... Smoke makes things work. When the smoke gets out, it stops! |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
i did look at xmodem early on, but found it added very little value. essentially all the protocol does is chop the ascii data up into blocks, adds short headers, and does the tranfer without the data appearing onscreen. there is no compression and quite primative error handling. to upload to a micromite using GFXterm i use: AUTOSAVE <enter> menu: paste -> from text file then when the paste counter reaches zero press ctrl-Z at the keyboard. at 38400 baud this takes around 60 seconds for a 42k basic program. i must confess i have NEVER tried xmodem, how quick is it in comparison? alternatively, GFXterm can paste directly into the micromite's editor, though this is as slow as a snail wearing fluffy slippers! to download from a micromite using GFXterm i use: LIST ALL menu: LOG to file press <enter> on keyboard when the listing has finished menu: STOP logging i can look again at adding xmodem upload if you like. for the last week or so i've been (unsuccessfully) struggling with alternative fonts and unicode characters :-( cheers, rob :-) |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Never thought of doing it that way. Thanks, I will try that. I mostly want to upload to the MM more then download from it. I had forgotten the AUTOSAVE command....  Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
THIS ONE WORKS FINE. I get the error as you said, but I click on IGNORE, and the VT100 terminal is accessible just fine after that. I even connected a MM to it, and can still talk to it fine.  Smoke makes things work. When the smoke gets out, it stops! |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
