Each application has one main window, however that main window has many child windows. In this case, one of the child windows will be for inputing text from the keyboard and another child window will display the output from the terminal, but they will both be contained in the main application window.
Take a look at the pic in post 116, you can cleary see the input area and the output area contained within the main window.
One of the advantages of PST's separate input method is the ability to repeat the commands similar to the DOSKEY or Linux history using up/down arrows. With a "dumb terminal" the history feature has to be built in to the target program.
I now understand what you are trying to say. To be perfectly honest, the only serial terminal I ever really worked with is the Parallax Serial Terminal, so I am just trying to duplicate some of the functionality that I am accustomed to. Additionally, I believe most members in the forum probably use the Parallax Serial Terminal, and they will also be accustomed to that type of functionality.
I'll bet a significantly greater fraction of users have dealt with a command prompt, just FYI.
You might be right, but I think it might be a closer comparison than you would imagine. I think most people that open MS-DOS, type something in, and end up closing it and never use it again:)
I've never really liked the input area in PST. I find it a bit annoying. It would be nice if you could have an option to hide it.
@Dave Hein
Dave, I have gone through a lot of trouble to try and get this type of functionality, the last thing I want to do is hide it. However, everyone will have access to the source code, so you can hide it if you so desire. I won't mind.
I think the idea of a separate input pane has its uses in fact I would probably like to see two input panes, one for ASCII and one for binary data.
Not every program is as clear cut as command/response, some times there is a periodic transmission of data with intervals where the Rx line is checked, if the intervals are short I could see where the scrolling would prevent timely input of a command using only one pane.
I am with heater. The separate window in PST is not really usable in the real sense. Sometimes a second window is nice, but for any worthwhile coding using the pc as a terminal requires the data to be combined in the one window.
A nice feature (using a single window) is to change the color of the text depending of whether it is input or output. However, this would have to be an optional switch. e.g. Typed text could be yellow on blue and incoming text from the prop in white on blue.
If it is going to be a terminal program (rather than a debugger) then you need to be able to configure the screen to be XXX rows by YY columns. You need to be able to specify wraparound or scroll mode. Yes, there are other VT100 terminal type programs out there, but none work properly with the prop because of the DTR usage, and none can load the prop and then goto the terminal window.
@Cluso99
Are you thinking of editing code in the terminal window, that sounds more like a new Prop Tool IDE that has a terminal built in. Edit text in it's text editor window and switch to a terminal window.
I would imagine anything beyond 32K characters would cause the rich edit control to choke, unless the data was streamed in as outlined below.
The other issue is if you are receiving line after line after line etc the Edit style components will just keep adding lines until it chokes.
The EM_EXLIMITTEXT message sets an upper limit to the amount of text the user can type or paste into a rich edit control.
The default maximum is 32K characters.
The text limit set by the EM_EXLIMITTEXT message does not limit the amount of text that you can stream into a rich edit control using the EM_STREAMIN message.
Does anyone know of free application or trial version of some software that has an edit control with a seperate scrollbar for scrolling the contents of the edit control?
It appears that the documentation for the scrollbar control is very limited, so I would like to do a spying to see how they accomplish the task above.
Bruce
At first I was going to say a 32K limit looked like you were reading an old doc file for a 16bit version of the control but on second glance maybe it is
a 32bit control and has a setting to keep the text size low.
When I think of using an edit control, Memo RichEdit etc, as the terminal window I am using it in a known controlled way. In order to use the edit control
I have to add lines to it as they come in. I watch the serial Rx buffer for available characters and build a string waiting for an end of line, that being a cr or crlf.
When I have a complete line I execute something like TMemo.Lines.Add(mystring);
What I mean by in a controlled way is that I know somewhat how many lines I will get at any given time. For example when you are createing a debug window
connected serially. In your prop code you have added statements at various places to use a serial object to send status to you windows debug terminal indicating
I got this far in the code and some var values . The key is your going to clear the lines of the edit control in your windows terminal each time you run a test.
I would think the richedit in 32 bit windows would hold a whole lot of lines more than you care to have it hold .
Maybe the way to do it is have a save to file option, if enabled as the lines come in stream ,append them to a file and if it is disabled do not save them either way
after so many lines clear the memo and they are gone. This way if someone just leaves it running with something sending in line after line and a rich edit with
millions of lines and msoft virtualizing the hard drive to get more memory to save them in.
I seem to remember you saying your serial lib uses a rich edit, maybe there are options in that class to do this. Do you pass a pointer to your rich edit or
does the serial lib create an instance and give you a pointer to it
The serial port object becomes a member of the rich edit control as shown below.
int CChildView::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
// Call base class
if (CWnd::OnCreate(lpCreateStruct) == -1)
return -1;
// Create the rich edit control
VERIFY(m_wndEdit.Create(WS_VISIBLE|WS_CHILD|WS_BORDER|ES_AUTOHSCROLL|ES_AUTOVSCROLL|ES_LEFT|ES_MULTILINE,CRect(0,0,0,0),this,0));
// Obtain the requested COM port
CComSelectDlg dlgComSelect(this);
dlgComSelect.DoModal();
// Open the serial port
if (m_serial.Open(dlgComSelect.m_strComPort,this) != ERROR_SUCCESS)
{
AfxMessageBox(_T("Unable to open COM-port"),MB_ICONSTOP|MB_OK);
GetParent()->PostMessage(WM_CLOSE);
return 0;
}
// Set the serial port in the RichCommEdit control
m_wndEdit.m_pSerial = &m_serial;
return 0;
}
If you are not familiar with VC++:
m_wndEdit.m_pSerial = &m_serial;
m_serial is being passed as a pointer to a serial member of the rich edit control
One of the advantages of PST's separate input method is the ability to repeat the commands similar to the DOSKEY or Linux history using up/down arrows. With a "dumb terminal" the history feature has to be built in to the target program.
Having a simple stack (Up/Dn arrows + line edit) of commands, is what I am used to on the calculator I use.
It also allows select-copy of any part of the scrolling display, and I often grab an 'Eqn and result' set, to paste into source code.
All of those are useful features, but they do not have to require a separate entry window.
I have been trying to use an external scrollbar for the rich edit control of the input window because I could not get the native attached scrollbar to work the way I wanted. While making coffee this morning, before diving into some serious scrollbar math and programming, I had a flash of an idea on how to make the native scrollbar work the way I wanted. So I decided to give it a try, and to my ultimate surprise, it works perfectly and just exactly the way I want it.
I was not looking forward to the scrollbar work that was in front of me, so today is my LUCKY DAY
Now I can move forward with much greater speed and ambition.
Bruce
I have some C++ knowledge from the distant past and did see what was going on in your post.
The ChildView creates an instance of m_wndEdit and tells it that it's parent is the ChildView thru the
this parameter. m_serial then tries to open a serial port and if success as you indicate a pointer to
it is passed to m_wndEdit.
m_wndEdit must be part of your serial lib.
Looking at your last jpg today is this assigning the serial to the termial user input line richedit or
is it the richedit that will display what came in on the serial port.
There is a subclassed rich edit control named CRichCommEdit. Within the header file for CRichCommEdit there is the following declaration:
CSerial* m_pSerial; // This is a pointer to the CSerial class object
In the header file of CChildView there are two important declarations which are:
CRichCommEdit m_wndEdit
CSerialMFC m_serial
During the CChildView::OnCreate method the CRichCommEdit m_wndEdit window is created and the
CSerialMFC m_serial object is created. Since serial communication use the file IO APIs, m_serial opens a file for IO, which is then passed as a pointer back to m_pSerial in the CRichCommEdit class object, to enable output to the rich edit control. The original view is just a view with no edit control, so during sizing of the view window the rich edit control obtains this sizing dimension and is then placed on top of the original view.
m_wndEdit must be part of your serial lib.
In reality these are different class objects, but in this instance, since there is a declaration of CSerial* m_pSerial in the CRichCommEdit class object, m_pSerial becomes a member of the CRichCommEdit class.
Looking at your last jpg today is this assigning the serial to the termial user input line richedit or
is it the richedit that will display what came in on the serial port.
It should not be too much longer until you have access to a new serial terminal and source code, perhaps as early as tomorrow evening. As you should be aware, this will be the first version. It is my intention to update versions in small increments as my knowledge in serial communication grows and as new ideas for a better interface present themselves.
As for providing open source code, I have a couple requests, which are:
If you provide an application to the public which is derived from the source code that I provide, please provide your source code with the application.
If you provide an application to the public which is derived from the source code that I provide, please provide a notice that your source code and application are a derivative of PropCom.
If you provide an application to the public which is derived from the source code that I provide, please provide a different name for your application, so that the public will not confuse it with my original and any future update versions.
PropCom will be arriving soon. It is my sincerest hope that you will find it useful and delightful to use.
You should probably release the source under one of the "official" GPL licenses, others here can probably point you to the one that fullfills your requests.
I think it would be GPLv3.0, but I'm not positive.
I am sure that Parallax will probably have a prefered license for this activity. I will probably ask them what kind of license they want attached to it. I normally just write my own copyright restrictions and licensing requirements, but they have there requests as a content provider. As for this particular project, I have now special licensing requirements or restrictions, they were just merely requests.
Here is a new pic to feast your eyes upon. Since the last pic, background color and font color support has been added. Additionally, the scrollbars are now working 100%. Earlier in this thread I mentioned a program called ClipList, which is a program that I wrote many years ago. I have incorporated the ClipList program into PropCom. This enables you to create text files with titles to selectable text for pasting, which is pretty cool for this terminal.
The text actually looks much better than as shown in the pic.
You wanted to know the file size of the executable. The size currently stands at 236 kb for a "Release Build", but I am sure some excess fat could be cut off.
Tom: No, I did not mean for editting source code. What I mean is for the project to act just as a terminal used to. This is the same way we use the VGA or TV drivers on the prop itself. I see the requirement for a PST replacement to be exactly that, a replacement for the VGA or TV driver, but with the added ability of download capability (not edit or compile), and perhaps with history or logging.
Bruce: Looks nice. Here is an idea. Perhaps you could allow options to display the user input window to also display this in the main window, optionally in a different color. The other option that would be nice is for the main visible window to act as a full terminal. By full terminal, I mean a fixed size like the VGA and TV drivers on the prop, so that this could be an alternative display to the VGA/TV driver.
BTW I noted on an earlier pic you had RLSD. IMHO you should use DCD as I doubt many would recall RLSD these days.
Thanks for the compliment Ray. This time around, I am just trying to make a very nice replacement to the Parallax Serial Terminal that I am accustomed to using. I don't know how many people here actually program in VC++, but I am sure there will be several terminals built after I post the source code. It will be a very good start for anyone wanting to make their own.
In most instances, when I create a piece of software, I generally create it for myself, and I try to include all the things that I think would be handy. However in this case, I am also trying to keep other forum members in mind. Some suggestions to making software are quick and easy accommodations, while others would take a greate deal of time to implement. Please remember that the first terminal will be a learning experience for me.
Let me discuss some of the issues that you brought up.
Perhaps you could allow options to display the user input window to also display this in the main window, optionally in a different color.
This suggestion really is unclear to me, especially the phrase "to display the user input window to also display". However, I am going to assume that you want something like the current serial terminal, which shows text in the output window as type, but you want the input that shows up in the output to be a different color than the standard output color. If this what you mean?
By full terminal, I mean a fixed size like the VGA and TV drivers on the prop
Fixing the window size and line length is no big deal, and that would be very easy to implement, but I also believe that should be a completely different piece of software, instead of trying to combine both into one piece of software. With the source code files, it would probably take someone a couple hours to figure it out. That being said, I would have no problem after the release of this version, to create a fixed sized version, but I would probably name it something else.
IMHO you should use DCD as I doubt many would recall RLSD these days.
As for the RLSD, the sample source code that I have provides support for this, but it does not provide support for DCD. At this point, I don't know what either of them are, but I am still learning as I go.
Attached below is a new pic with a couple more command buttons and more buttons will fill the toolbar. At this time, I am contemplating two other suggestions:
Beau's suggestion about having the ability to run a selection of files at the press of a button.
And I think it was bsnut that suggested visual indication of I/O pin status. Although I don't know how useful this will be.
You wanted to know the file size of the executable. The size currently stands at 236 kb for a "Release Build", but I am sure some excess fat could be cut off.
I have decided to tell you a little about the terminal before it actually is delivered. I did not want to make the first version too complicated, otherwise it would probably never get done. So it is fair to say that it has it's limitations, but I still think it has quite a few nice things, and more nice things will be added later.
I know you guys are just dying to know what all the buttons are for and that will be the topic of this post. Referencing the attached pic below and reading from left to right, here is what the buttons are supposed to do.
Of course this is your ordinary copy symbol, but this one operates a little differently. PropCom has two rich edit controls and this button reads both edit controls to see which one has selected text, and then it copies it to the clipboard. The difference is that it has two potential inputs, one from the input area and the other from the output area.
I have decided to make the output area "read only", this means that you will not be able to type or paste in this area. Once again, this is a semi-ordinary paste symbol. It will allow you to paste text based content into the input area.
This is another semi-ordinary paste symbol, but this button will give you some nice pasting power. This is the ClipList button You can create numerous text based files with the following format: TITLE\PASTABLE TEXT. Each file can have numerous lines. When you click the ClipList button, a dialog box opens which allows you to select any text based file. Providing it has the proper format, ClipList will read the file, and add the titles to a list based control. When you want to paste a commonly typed item, just click on the title, and ClipList will add the pastable text to the clipboard.
This button is for searching through the output text.
Clicking this button will sweep away the text from the input window.
Clicking this button will sweep away the text from the output window.
The print button will print the output.
This button will open a new terminal window.
This is the send file button.
This is the send break button.
This is the font color button.
This is the background color button
This is a button for a floating, but dockable toolbar. It is my intention to some how show the high and low states of the various I/O pins through graphically represented LEDs. I am not sure if it is possible, but the button is there if it is.
Last but not least, we have the About button.
I must admit that I do not have these button all wired up yet, but I am getting close. There will probably still be a few more added.
Perhaps you could allow options to display the user input window to also display this in the main window, optionally in a different color.
This suggestion really is unclear to me, especially the phrase "to display the user input window to also display". However, I am going to assume that you want something like the current serial terminal, which shows text in the output window as type, but you want the input that shows up in the output to be a different color than the standard output color. If this what you mean?
Yes, exactly
By full terminal, I mean a fixed size like the VGA and TV drivers on the prop
Fixing the window size and line length is no big deal, and that would be very easy to implement, but I also believe that should be a completely different piece of software, instead of trying to combine both into one piece of software. With the source code files, it would probably take someone a couple hours to figure it out. That being said, I would have no problem after the release of this version, to create a fixed sized version, but I would probably name it something else.
Yes, it is not complicated to do. I have done it in a single cog together with the bitmap and TV driver in my 1pin TV.
IMHO you should use DCD as I doubt many would recall RLSD these days.
As for the RLSD, the sample source code that I have provides support for this, but it does not provide support for DCD. At this point, I don't know what either of them are, but I am still learning as I go.
They are the same thing. RLSD is just an older name.
]And I think it was bsnut that suggested visual indication of I/O pin status. Although I don't know how useful this will be.
Simple pin-status display is very useful, when first wiring a system, and you are not sure which pin is which...
It is also good for students, as they can flip states on a connector, and see a change on the PC.
Brings the real world onto the screen.
Baud rates:
Further to my earlier Top baud comments, I've fired up a FT2232H I have here (on a Lattice $29 Eval board) , and they have EE Config set as one channel SPI/JTAG, and one as UART. So it shows on my PC as a single UART (COM8)
Scope and counter tests, confirm you can ask this to go to 12MBaud, with a standard COM call, and it will burst at that. Quite Impressive.
( I think also legal are 6MBd, 4MBd, 8MBd, (7MBd aliases to 8Mbd), and 5MBd is off by 0.3%, as they go for closest fit. I did not bother to test lower Baud rates
With my 96 byte send blocks, (sending 'U' which toggles every bit ) the counter does not go above ~ 3.6MHz which is a average baud of 7.2Mbit. Counter is stable below around 4MBd (counter gives 1.999xMHz there).
Updated:
Bumping that Block size to 255, and now 4MBd, 6MBd, and 8MBd all show solid numbers, just 18ppm high.
(ie they are streaming without breaks).
12MBd is ~10.5 on counter, so the system/code almost keeps up with the hardware.
Other suggestions:
One of my tests, for scope/counter work, is to simply repeat send a defined string.
In my case 96 x 'U' (but that's likely small for the 2232H, which has 4K buffers, and , so I would suggest an option, to repeat-send, if that is not already there.
Edit: Just to check the throttle point, I recoded for a larger Send Block, and on my PC system, a Block Size of anything over 296 bytes gives a stable 6MHz on the counter, at 12MBaud.
Comments
Here is a better description.
Each application has one main window, however that main window has many child windows. In this case, one of the child windows will be for inputing text from the keyboard and another child window will display the output from the terminal, but they will both be contained in the main application window.
Take a look at the pic in post 116, you can cleary see the input area and the output area contained within the main window.
Bruce
PST = Parallax Serial Terminal
If I'm typing commands into some program on my propeller I would normally like to see the regular display like
$ command
Some response
$ otherCommand
Other response
All in one window/area/box whatever you want to call it.
That way all commands and responses are nicely matched up as in all command line interfaces going back to the beginning of computers.
I now understand what you are trying to say. To be perfectly honest, the only serial terminal I ever really worked with is the Parallax Serial Terminal, so I am just trying to duplicate some of the functionality that I am accustomed to. Additionally, I believe most members in the forum probably use the Parallax Serial Terminal, and they will also be accustomed to that type of functionality.
Bruce
You might be right, but I think it might be a closer comparison than you would imagine. I think most people that open MS-DOS, type something in, and end up closing it and never use it again:)
@Dave Hein
Dave, I have gone through a lot of trouble to try and get this type of functionality, the last thing I want to do is hide it. However, everyone will have access to the source code, so you can hide it if you so desire. I won't mind.
Not every program is as clear cut as command/response, some times there is a periodic transmission of data with intervals where the Rx line is checked, if the intervals are short I could see where the scrolling would prevent timely input of a command using only one pane.
Jeff T.
A nice feature (using a single window) is to change the color of the text depending of whether it is input or output. However, this would have to be an optional switch. e.g. Typed text could be yellow on blue and incoming text from the prop in white on blue.
If it is going to be a terminal program (rather than a debugger) then you need to be able to configure the screen to be XXX rows by YY columns. You need to be able to specify wraparound or scroll mode. Yes, there are other VT100 terminal type programs out there, but none work properly with the prop because of the DTR usage, and none can load the prop and then goto the terminal window.
Are you thinking of editing code in the terminal window, that sounds more like a new Prop Tool IDE that has a terminal built in. Edit text in it's text editor window and switch to a terminal window.
Tom
I would imagine anything beyond 32K characters would cause the rich edit control to choke, unless the data was streamed in as outlined below.
The EM_EXLIMITTEXT message sets an upper limit to the amount of text the user can type or paste into a rich edit control.
The default maximum is 32K characters.
The text limit set by the EM_EXLIMITTEXT message does not limit the amount of text that you can stream into a rich edit control using the EM_STREAMIN message.
Bruce
It appears that the documentation for the scrollbar control is very limited, so I would like to do a spying to see how they accomplish the task above.
Bruce
At first I was going to say a 32K limit looked like you were reading an old doc file for a 16bit version of the control but on second glance maybe it is
a 32bit control and has a setting to keep the text size low.
When I think of using an edit control, Memo RichEdit etc, as the terminal window I am using it in a known controlled way. In order to use the edit control
I have to add lines to it as they come in. I watch the serial Rx buffer for available characters and build a string waiting for an end of line, that being a cr or crlf.
When I have a complete line I execute something like TMemo.Lines.Add(mystring);
What I mean by in a controlled way is that I know somewhat how many lines I will get at any given time. For example when you are createing a debug window
connected serially. In your prop code you have added statements at various places to use a serial object to send status to you windows debug terminal indicating
I got this far in the code and some var values . The key is your going to clear the lines of the edit control in your windows terminal each time you run a test.
I would think the richedit in 32 bit windows would hold a whole lot of lines more than you care to have it hold .
Maybe the way to do it is have a save to file option, if enabled as the lines come in stream ,append them to a file and if it is disabled do not save them either way
after so many lines clear the memo and they are gone. This way if someone just leaves it running with something sending in line after line and a rich edit with
millions of lines and msoft virtualizing the hard drive to get more memory to save them in.
I seem to remember you saying your serial lib uses a rich edit, maybe there are options in that class to do this. Do you pass a pointer to your rich edit or
does the serial lib create an instance and give you a pointer to it
Tom
Tom
The serial port object becomes a member of the rich edit control as shown below.
int CChildView::OnCreate(LPCREATESTRUCT lpCreateStruct) { // Call base class if (CWnd::OnCreate(lpCreateStruct) == -1) return -1; // Create the rich edit control VERIFY(m_wndEdit.Create(WS_VISIBLE|WS_CHILD|WS_BORDER|ES_AUTOHSCROLL|ES_AUTOVSCROLL|ES_LEFT|ES_MULTILINE,CRect(0,0,0,0),this,0)); // Obtain the requested COM port CComSelectDlg dlgComSelect(this); dlgComSelect.DoModal(); // Open the serial port if (m_serial.Open(dlgComSelect.m_strComPort,this) != ERROR_SUCCESS) { AfxMessageBox(_T("Unable to open COM-port"),MB_ICONSTOP|MB_OK); GetParent()->PostMessage(WM_CLOSE); return 0; } // Set the serial port in the RichCommEdit control m_wndEdit.m_pSerial = &m_serial; return 0; }If you are not familiar with VC++:
m_serial is being passed as a pointer to a serial member of the rich edit control
Having a simple stack (Up/Dn arrows + line edit) of commands, is what I am used to on the calculator I use.
It also allows select-copy of any part of the scrolling display, and I often grab an 'Eqn and result' set, to paste into source code.
All of those are useful features, but they do not have to require a separate entry window.
See http://www.zoesoft.com/console-calculator/ - very nice piece of work.
I think the same model, would work quite well in a terminal ?
- and large scrolling size could be important, 32K could come up very fast
I have been trying to use an external scrollbar for the rich edit control of the input window because I could not get the native attached scrollbar to work the way I wanted. While making coffee this morning, before diving into some serious scrollbar math and programming, I had a flash of an idea on how to make the native scrollbar work the way I wanted. So I decided to give it a try, and to my ultimate surprise, it works perfectly and just exactly the way I want it.
I was not looking forward to the scrollbar work that was in front of me, so today is my LUCKY DAY
Now I can move forward with much greater speed and ambition.
Bruce
Bruce
I have some C++ knowledge from the distant past and did see what was going on in your post.
The ChildView creates an instance of m_wndEdit and tells it that it's parent is the ChildView thru the
this parameter. m_serial then tries to open a serial port and if success as you indicate a pointer to
it is passed to m_wndEdit.
m_wndEdit must be part of your serial lib.
Looking at your last jpg today is this assigning the serial to the termial user input line richedit or
is it the richedit that will display what came in on the serial port.
Tom
Here is how it works.
There is a subclassed rich edit control named CRichCommEdit. Within the header file for CRichCommEdit there is the following declaration:
CSerialMFC m_serial
CSerialMFC m_serial object is created. Since serial communication use the file IO APIs, m_serial opens a file for IO, which is then passed as a pointer back to m_pSerial in the CRichCommEdit class object, to enable output to the rich edit control. The original view is just a view with no edit control, so during sizing of the view window the rich edit control obtains this sizing dimension and is then placed on top of the original view.
In reality these are different class objects, but in this instance, since there is a declaration of CSerial* m_pSerial in the CRichCommEdit class object, m_pSerial becomes a member of the CRichCommEdit class.
This is for displaying the output.
Bruce
It should not be too much longer until you have access to a new serial terminal and source code, perhaps as early as tomorrow evening. As you should be aware, this will be the first version. It is my intention to update versions in small increments as my knowledge in serial communication grows and as new ideas for a better interface present themselves.
As for providing open source code, I have a couple requests, which are:
- If you provide an application to the public which is derived from the source code that I provide, please provide your source code with the application.
- If you provide an application to the public which is derived from the source code that I provide, please provide a notice that your source code and application are a derivative of PropCom.
- If you provide an application to the public which is derived from the source code that I provide, please provide a different name for your application, so that the public will not confuse it with my original and any future update versions.
PropCom will be arriving soon. It is my sincerest hope that you will find it useful and delightful to use.Bruce
You should probably release the source under one of the "official" GPL licenses, others here can probably point you to the one that fullfills your requests.
I think it would be GPLv3.0, but I'm not positive.
C.W.
I am sure that Parallax will probably have a prefered license for this activity. I will probably ask them what kind of license they want attached to it. I normally just write my own copyright restrictions and licensing requirements, but they have there requests as a content provider. As for this particular project, I have now special licensing requirements or restrictions, they were just merely requests.
Bruce
Here is a new pic to feast your eyes upon. Since the last pic, background color and font color support has been added. Additionally, the scrollbars are now working 100%. Earlier in this thread I mentioned a program called ClipList, which is a program that I wrote many years ago. I have incorporated the ClipList program into PropCom. This enables you to create text files with titles to selectable text for pasting, which is pretty cool for this terminal.
The text actually looks much better than as shown in the pic.
Bruce
You wanted to know the file size of the executable. The size currently stands at 236 kb for a "Release Build", but I am sure some excess fat could be cut off.
Bruce
Bruce: Looks nice. Here is an idea. Perhaps you could allow options to display the user input window to also display this in the main window, optionally in a different color. The other option that would be nice is for the main visible window to act as a full terminal. By full terminal, I mean a fixed size like the VGA and TV drivers on the prop, so that this could be an alternative display to the VGA/TV driver.
BTW I noted on an earlier pic you had RLSD. IMHO you should use DCD as I doubt many would recall RLSD these days.
Thanks for the compliment Ray. This time around, I am just trying to make a very nice replacement to the Parallax Serial Terminal that I am accustomed to using. I don't know how many people here actually program in VC++, but I am sure there will be several terminals built after I post the source code. It will be a very good start for anyone wanting to make their own.
In most instances, when I create a piece of software, I generally create it for myself, and I try to include all the things that I think would be handy. However in this case, I am also trying to keep other forum members in mind. Some suggestions to making software are quick and easy accommodations, while others would take a greate deal of time to implement. Please remember that the first terminal will be a learning experience for me.
Let me discuss some of the issues that you brought up.
This suggestion really is unclear to me, especially the phrase "to display the user input window to also display". However, I am going to assume that you want something like the current serial terminal, which shows text in the output window as type, but you want the input that shows up in the output to be a different color than the standard output color. If this what you mean?
Fixing the window size and line length is no big deal, and that would be very easy to implement, but I also believe that should be a completely different piece of software, instead of trying to combine both into one piece of software. With the source code files, it would probably take someone a couple hours to figure it out. That being said, I would have no problem after the release of this version, to create a fixed sized version, but I would probably name it something else.
As for the RLSD, the sample source code that I have provides support for this, but it does not provide support for DCD. At this point, I don't know what either of them are, but I am still learning as I go.
Attached below is a new pic with a couple more command buttons and more buttons will fill the toolbar. At this time, I am contemplating two other suggestions:
- Beau's suggestion about having the ability to run a selection of files at the press of a button.
- And I think it was bsnut that suggested visual indication of I/O pin status. Although I don't know how useful this will be.
BruceThanks Bruce
I have decided to tell you a little about the terminal before it actually is delivered. I did not want to make the first version too complicated, otherwise it would probably never get done. So it is fair to say that it has it's limitations, but I still think it has quite a few nice things, and more nice things will be added later.
I know you guys are just dying to know what all the buttons are for and that will be the topic of this post. Referencing the attached pic below and reading from left to right, here is what the buttons are supposed to do.
- Of course this is your ordinary copy symbol, but this one operates a little differently. PropCom has two rich edit controls and this button reads both edit controls to see which one has selected text, and then it copies it to the clipboard. The difference is that it has two potential inputs, one from the input area and the other from the output area.
- I have decided to make the output area "read only", this means that you will not be able to type or paste in this area. Once again, this is a semi-ordinary paste symbol. It will allow you to paste text based content into the input area.
- This is another semi-ordinary paste symbol, but this button will give you some nice pasting power. This is the ClipList button
You can create numerous text based files with the following format: TITLE\PASTABLE TEXT. Each file can have numerous lines. When you click the ClipList button, a dialog box opens which allows you to select any text based file. Providing it has the proper format, ClipList will read the file, and add the titles to a list based control. When you want to paste a commonly typed item, just click on the title, and ClipList will add the pastable text to the clipboard.
- This button is for searching through the output text.
- Clicking this button will sweep away the text from the input window.
- Clicking this button will sweep away the text from the output window.
- The print button will print the output.
- This button will open a new terminal window.
- This is the send file button.
- This is the send break button.
- This is the font color button.
- This is the background color button
- This is a button for a floating, but dockable toolbar. It is my intention to some how show the high and low states of the various I/O pins through graphically represented LEDs. I am not sure if it is possible, but the button is there if it is.
- Last but not least, we have the About button.
I must admit that I do not have these button all wired up yet, but I am getting close. There will probably still be a few more added.Bruce
Yes, exactly
Yes, it is not complicated to do. I have done it in a single cog together with the bitmap and TV driver in my 1pin TV.
They are the same thing. RLSD is just an older name.
Simple pin-status display is very useful, when first wiring a system, and you are not sure which pin is which...
It is also good for students, as they can flip states on a connector, and see a change on the PC.
Brings the real world onto the screen.
Baud rates:
Further to my earlier Top baud comments, I've fired up a FT2232H I have here (on a Lattice $29 Eval board) , and they have EE Config set as one channel SPI/JTAG, and one as UART. So it shows on my PC as a single UART (COM8)
Scope and counter tests, confirm you can ask this to go to 12MBaud, with a standard COM call, and it will burst at that. Quite Impressive.
( I think also legal are 6MBd, 4MBd, 8MBd, (7MBd aliases to 8Mbd), and 5MBd is off by 0.3%, as they go for closest fit. I did not bother to test lower Baud rates
With my 96 byte send blocks, (sending 'U' which toggles every bit ) the counter does not go above ~ 3.6MHz which is a average baud of 7.2Mbit. Counter is stable below around 4MBd (counter gives 1.999xMHz there).
Updated:
Bumping that Block size to 255, and now 4MBd, 6MBd, and 8MBd all show solid numbers, just 18ppm high.
(ie they are streaming without breaks).
12MBd is ~10.5 on counter, so the system/code almost keeps up with the hardware.
Other suggestions:
One of my tests, for scope/counter work, is to simply repeat send a defined string.
In my case 96 x 'U' (but that's likely small for the 2232H, which has 4K buffers, and , so I would suggest an option, to repeat-send, if that is not already there.
Edit: Just to check the throttle point, I recoded for a larger Send Block, and on my PC system, a Block Size of anything over 296 bytes gives a stable 6MHz on the counter, at 12MBaud.