Project In Progress - New Serial Terminal, Taking Suggestions
idbruce
Posts: 6,197
Hello Everyone
I have decided to jump right into the PC side of serial communication and create a new serial terminal. This serial terminal will be created with Visual C++ 6.0, using the Microsoft Foundation Classes, and providing that I can upload the associated file types, I will also make it an open source project. As a template for this project, I will be using the source code which can be found at this page:
http://www.codeproject.com/KB/system/serial.aspx
Considering that I value the suggestions and opinions of forum members, I am seeking very specific information.
Bruce
I have decided to jump right into the PC side of serial communication and create a new serial terminal. This serial terminal will be created with Visual C++ 6.0, using the Microsoft Foundation Classes, and providing that I can upload the associated file types, I will also make it an open source project. As a template for this project, I will be using the source code which can be found at this page:
http://www.codeproject.com/KB/system/serial.aspx
Considering that I value the suggestions and opinions of forum members, I am seeking very specific information.
- What are the PRO's of the current Parallax Serial Terminal?
- What are the CON's of the current Parallax Serial Terminal?
- What kind of capabilities would you like with a new serial terminal?
Bruce
Comments
At least if you get the code running, I am sure someone could convert to the free version. This would be a great addition as we always want something a little different to the normal PST and other terminal programs.
As long as it doesn't require .NET to be installed on my computer, I laud your effort and can't wait to try it!
-Phil
The linked source code above already works without alteration. It has many nice features for making various settings and it supplies numerous wrappers for various types of applications. It is also written in C++, which is way more powerful and configurable then VB, as governed by available WINDOWS functions. Besides my experience is with C++ and not VB.
But thanks for your input Clusso
Bruce
The best terminal I have seen is Tera Term. See:
http://en.wikipedia.org/wiki/Tera_Term
http://www.ayera.com/teraterm/ (I'm not sure if this is the official site)
And the best text editor I have found is Edit Plus 3
http://www.editplus.com/
I did pay $20 cash money for this years ago but it has been well worth it.
The main things I do in the Propeller environment are working with forth and FemtoBasic's variation DongleBasic.
I use a combination of Tera Term and Edit+.
All my editing, software development, and other things are in Edit+.
I setup Tera Term for my preferred serial parameters.
I setup Tera Term for my preferred terminal emulation, usually VT100 with a fixed font.
Now here is the cool part!!!!
Highlight any text source in Edit+ or from any other source which puts it in the clipboard.
Place the cursor on the terminal window and click the right hand mouse button.
The clipped characters now get entered just as though entered by hand.
Cool huh.
I also can send the VT100 escape code commands to move the terminal cursor around the screen.
To be fair there is a lot more in Tera Term like TCP/IP but I don't use this.
Give it a try and see what you think.
Especially the clipboard thing.
Duane
I will give you a nice serial terminal, without .NET. I am sure you will like it when I am done. This will be a much easier project than a new Propeller Tool. I figure within a week or two, I should have a nice serial terminal with a great GUI. Additionally, I can't state this for certain, but I am going to attempt to make this project similar to a Microsoft Excel workbook in the manner that all comm ports will be shown as tabs at the bottom of the page instead of "Sheets". So all you will have to do is just click a tab for a certain port and you will have access to it. There are a lot of available settings, take a peek at the screenshots below
Bruce
I wrote an application many years ago that would take copied text and add it to a list. Upon selection of a list item, that item would be copied to the clipboard, thus allowing it to be pasted in any application that allowed text pasting. If people want this possibilty, I will gladly add it.
Bruce
He will live on through this new serial terminal by his contribution of the tab control.
Bruce
EDIT: In case any of you might be interested, here is a link to where he introduces the tab control.
http://www.microsoft.com/msj/0499/c/c0499.aspx
That way we can all use it!
theres a billion term apps for PC.
with the click of a mouse you can built compiled app for PC ,MAC & LINUX in one go.
You would also have a lot less code to write vs C++
I have a few serial apps I have written in realbasic, there's not much to it.
Dave M
The answer is simple. Because I am experienced with Visual C++ 6.0 Microsoft Foundation Classes.
Bruce
What will it so that's special?
Just a dumb terminal?
If so what's the point?
What does the Parallax terminal do that's special?
I didn't think it was even useful especially since I have experienced a really good one in Tera Term.
Just saying.
Once you have used the clipboard thing to download a whole program
several times in a couple of minutes including the editing you will be hooked.
Another "feature", actually its just part of clipping, is one can include program commands
along with the program. You can really do a lot of stuff. Here is an example snippet:
NEW clears memoy
Then the program that is loaded (This is only a snippet)
RUN starts the program
Then the series of numbers are inputs to the running program.
Some are commands and some are numeric values.
The last "0" quits the program
The last 3 sequence are labor saving things, I hate to retype stuff.
NEW
90 I = 0 : L = 0 : OUTA[7..0] = $11
100 CLOSE : REM Start Point
110 PRINT " | 0=Quit |"
120 PRINT " | 1=Move Absolute |"
130 PRINT " | 2=Move Relative |"
140 PRINT " | 3=Move From File |"
150 PRINT " | 4=Download to File |"
170 DISPLAY 7 : INPUT " " ; Q
180 Q = Q & $7 : Q = Q // 5
190 GOTO 190+1+Q : REM CASE
191 STOP : REM CASE 0
192 GOTO 300 : REM CASE 1
193 GOTO 400 : REM CASE 2
194 GOTO 500 : REM CASE 3
195 GOTO 600 : REM CASE 4
RUN
4
1
63,255
1
255,255
1
191,63
1
63,0
1
255,255
1
63,255
1
255,63
1
0,0
0
NEW
10 PRINT "LOADING StpMtr01.txt":LOAD "StpMtr01.txt":RUN
SAVE "AUTOEXEC.BAS"
NEW
10 PRINT "Ready":NEW
SAVE "AUTOEXEC.BAS"
SAVE "StpMtr01.txt"
My main goal is to create a much better GUI than the one that is currently available, plus add a little more functionality. As I mentioned it will be open source, so anyone can add the functionality that they desire. Additionally as mentioned, I will probably spend a week or two on this project, and in that time, I should accomplish my goals as I see them.
It is not my goal to create a commercial application that would take months or years to perfect. However, I am certain that I will provide a decent foundation and framework which can be built upon.
Bruce
IIRC the free versions from microsoft are .Net cutdown versions. I would much rather remain with VB6 and I think you would rather remain with VC++6. I couldn't justify the learning curve, and the rewrites, to move to VB.net.
Your goals are admirable, and as you say, we can add features later if we wish/require. A basis is what we require first.
I see two things that would be nice in a terminal program, apart from the usual logging of data...
1. Ability to reset the prop (selectable by either DTR or RTS).
2. Ability to download a binary (using either DTR or RTS).
If done correctly, I see that we could use a cheapie USB/TTL instead of the PropPlug with the transistor circuit.
I agree whole heartedly, and as I said, C++ is much more powerful than VB. By creating this project in C++, the entire Windows API is at a programmers fingertips. So if someone does want to add to it, or alter it, they will have lots of options. However, don't get me wrong, VB is pretty powerful stuff also, but C++ is king.
I don't believe this should be a problem, but I will have to investigate.
I am not certain, but this may be a problem.
In no way am I claiming to be a serial communication genius, in fact this project would not be possible (or should I say it would take MUCH longer) if I did not have some serial communication source code to use as a template. I will just have to implement the sample source code into my GUI and experiment upon suggestions such as yours. My main contribution to this project will be the GUI, not the serial communication programming. However, I will do the best I can to accommodate requests that can easily be obtained. Of course I am more than willing to learn about and experiment with the serial communication programming.
Once again, thanks for your input.
Bruce
As you do this, I'd be interested in how small a terminal you can create, with the absolute basics, ie just sending and receiving characters at a preset baud rate. No menus etc.
I started looking for the smallest windows terminal program out there, but its a difficult thing to search for. There are several options 200kB~ 1MB. I'm looking for something < 100kB, and big brownie points for something < 8kB (!)
Some of these things used to be easier to accomplish. Using old QuickBasic 4.5 the standard example was about 8 lines of code, but I'm sure it wouldn't work with windows serial ports.
I can't say exactly for sure, but pretty darn small. All you really need is a dialog based applicication, and I would imagine that could at minimum 1" X 1". And from that point, you could make it invisible to where it does not show up on the taskbar or desktop.
Oh you mean file size sorry
Bruce
Well that would be difficult to accomplish, although I am sure it could be quite small. When I create executable, I normally use what is called a statically linked library, that way I am certain that the necessary software is installed on the users computer.
If an application chose to use linking as a shared dll I am sure it would cut down the size. I will be able to tell you more and give you a better idea in a couple days.
The file size of an executable is drastically cut when you do actual "RELEASE" builds instead of "DEBUG" builds.
Bruce
EDIT: Additionally, there are other items to consider, as what is all linked together, as in dependancy. I have not taken that close a look at the source code just yet, I just know that it will work for a new serial terminal.
Just as you proceed you'll probably start with a working bare minimum, if you do a quick 'release' build at that point and measure the file size I'd appreciate it. I'm going to do the same with VB6 later in the week
thanks
tubular
In the sample that is linked at the top of the page, there are different wrappers for different situations. It was my intention to include all these wrappers with the source code, but of course that would have no effect on the size of the executable. My goal really isn't for the smallest executable, but more for utility. In that sample, there are two specific wrappers that would probably cut down the size tremendously and they are CSerial and CSerialEx, with CSerialEx having extra capabilities. Out of all the wrappers provided, it was my intention to use either CSerialWnd or CSerialMFC, because my main goal is the user interface, which those to wrappers support better as compared to the previous two.
I cannot promise a very small executable for this project, but it won't be to large either. When I create the "Custom AppWizards" from all the wrappers, I will know exactly just how small it can be. I was going to do that first, but got wrapped up in the creation process
Bruce
I have a terminal in the Catalina IDE I wrote last year (which has become somewhat redundant now that Ross has integrated Catalina into Codeblocks). It is in vb.net and a rewrite in C++ would be great. (I also use Teraterm FWIW, but never the propeller terminal)
Keep it simple. A text box. Variable baud rate. Maybe the ability to search for available com ports. I ended up adding xmodem later, as a way of transferring files to and from an sd card when the propeller was running Kyedos, but it usually works out quicker to physically unplug the sd card.
I guess I have one suggestion there. I learned to type on a typewriter, and to me "Carriage Return" means to move the carriage to the left side (and ding a bell!). And Line Feed means to move up one line. These have two separate ascii characters. But I think the prop terminal does things differently and it ends up double spacing text. It is the main reason I use other terminal programs like Teraterm and Shamcom and Putty.
Anyway you might need an option button to select between different standards.
Sounds good.
A couple of suggestions
* Increase the Baud rates, (and allow manual entry of the number, to pass thru to the driver).
Some systems now allow over 2MBaud, (even to 12MBd!) so 115200 is rather long in the tooth.
* Give users a Pin-Toggle form, that shows IP pin status, and allows OP pins to be set/cleared.
* Add a Byte-rate Tx Test, that confirms Baud rates. (this probably needs a packet-size & Char fields too.. & a Buffer Size, for corrections.),
For COM tests we repeat send 'U' as that allows a frequency counter to check Baud rates, and we found the buffers can affect the
simplest BYTE rate calculations, as the Tx routine returns when it has handed over the last-byte, into the FIFO, actual final byte send, is some time later.
We've just done tests here on SiLabs CP2105, and you can set the Baud to close to 2MBaud, but what happens over ~ 500K baud, is there is more gap between bytes - so the byte rate at 2MBaud, has topped out at only around 70Kbytes/second.
Those speeds could still be useful, if you can use the FIFOs to give the uC time elsewhere.
Here, Exar claim a device up to 12MBd, but they do not say what the sustained byte-rate is
(and disti prices do not match $1.89/1K claim )
http://www.exar.com/Common/Content/News.aspx?id=8180
I would guess a FT2232H/FT232H, should get close to reaching > 1MBytes/sec sustained rate ?
A uart needs strict timing, not really windows comfort zone ?
SPI/i2c master are possible, but we did tests on Handshake line toggle rates recently, and they were MUCH higher on a 'genuine' serial port, than on a USB emulated one. USB ones (IIRC) had a 1ms transit time, I guess to ensure write then read works
That means a phantom channel is possible, but it is never going to win any speed prizes. 300 Baud modems anyone ?
Cheaper and smarter, to just use a DUAL USB UART ? - we've picked the CP2105 as it is well under $2 /1K
@Dr_Acula - Thanks for your input. It started out fun until I started trying to integrate the tab controls at the bottom of a Single Document Interface, but I'll get it.
I am only willing to increase the baud rate options to 921,600, after that rate, I will allow for passing a manually entered number through to the driver.
As previously mentioned, I am not a serial communications genius, and my main contribution to this project will be the GUI. User options are easy for me to configure, but actually applying it to the serial communication will be a lot more difficult for me. But I am interested in suggestions, so please tell me more about the IP and OP pins, and perhaps I may be able to accommodate this request.
As for this request or suggestion, it sounds a little complicated, and it will require some thought. Let me get the first version out, and perhaps I will implement it later, or maybe someone else will want to tackle it.
I wasn't really planning to dig into the serials communications code just yet, because it already works, and I am not that knowledgable about it just yet. Let me get it going first, and we will see from there.
Thanks for your suggestions.
Bruce
Bean
That should not be a problem, I truly believe the source code was meant to do exactly that.
Bruce
EDIT: I am not 100% certain, but I don't believe it supports transmitting binary files, and I do believe it currently supports transmitting ASCII text only, but I could be wrong. Many possibilties can be explored once the GUI is made.
Here is a minimal Terminal in PureBASIC:
; Minimal Terminal in PureBasic Global k$,c$,hndl OpenConsole() c$=" " hndl = OpenSerialPort(#PB_Any,"COM6",115200,#PB_SerialPort_NoParity, 8, 1, #PB_SerialPort_NoHandshake, 1024, 1024) Repeat k$ = Inkey() If k$ > "": WriteSerialPortString(hndl,k$): EndIf If AvailableSerialPortInput(hndl) ReadSerialPortData(hndl,@c$,1) Print(c$) EndIf Until k$=Chr($1B) ;Esc CloseSerialPort(hndl) CloseConsole() EndThis compiles to a Windows EXE with 9 kByte (no DLLs or so required). Damn - no brownie points...I have also written a Propeller Teminal 4 years ago (because there was no Parallax solution like the PST at the time) with a lot of Propeller related functions:
- Propeller Font
- .binary/.eeprom download
- Graphic commands
- Colors
- Mouse events
- Spin objects compatible to "TV_Text", "Keyboard" and "Mouse"
- many things more...
See the thread here: PropTerminal
The PropTerminal.EXE is a bit under 200 kB
Andy
Yea that looks pretty simple and that would be extremely small in size. I am sure something like that could be done with a Windows console app written in C++, however that is truly bare bones, no error checking and such. I am just one of those guys that likes a GUI, instead of the console apps.
I will take a peek at your work when I take a break from this.
Bruce
Okay Dave, now you got me smiling. As stated earlier, I will lay a good foundation and framework for expansion of the capabilities. We will see what happens from there. As I said, it will be open source. As for pasting text into the terminal window and transmiting it to the serial port, that will definitely be implemented.
I believe I will have a file where you can store desired text on seperate lines, which will be accessible through a list box, upon selection, the selection goes to the terminal and is transmitted. Additionally, you will be able to paste, but you will have to hit enter.
Bruce