Shop OBEX P1 Docs P2 Docs Learn Events
Project In Progress - New Serial Terminal, Taking Suggestions - Page 2 — Parallax Forums

Project In Progress - New Serial Terminal, Taking Suggestions

24567

Comments

  • idbruceidbruce Posts: 6,197
    edited 2011-08-22 08:35
    I don't remember anyone mention printing. Creating a bug free application that can print is a real pain. MFC is supposed to make it simple, but don't you believe that. However, I will see what I can do pertaining to the ability of printing complete or selected text.

    Bruce
  • HumanoidoHumanoido Posts: 5,770
    edited 2011-08-22 09:51
    Whatever you build (similar to the PST) should work with the Mac and BST for proper diversification.
  • idbruceidbruce Posts: 6,197
    edited 2011-08-22 10:21
    Humanoido

    I have never touched a Mac system in my entire life, nor have I ever wrote a program for a Mac. I would not even know where to begin.

    Bruce
  • ctwardellctwardell Posts: 1,716
    edited 2011-08-22 11:03
    Humanoido wrote: »
    Whatever you build (similar to the PST) should work with the Mac and BST for proper diversification.

    It seems to me that every time someone wants to offer something up they get beat about the head if it won't run under every OS under the sun. The OP in this case made it clear that they choose to work in VC++ 6.0 so it seems counterproductive to raise this point.

    C.W.
  • potatoheadpotatohead Posts: 10,253
    edited 2011-08-22 11:05
    The features I like and have used with various terminals in the past are:

    VT100 emulation; write session to file, with option for received only, output only, both; ANSI Color, basic terminal width, font, etc.. selection; take input from file, optionally on hot key, like "F8 sends file X to terminal as if typed" kind of thing; input macro, where a specific input can be recorded and repeated on hot key or menu pick.

    Erna was showing a terminal at UPEW that would write graphics to a window serially. That was pretty cool. Might be worth it to understand how that works.

    Digression = 1

    I wonder if a dual display Prop setup might not be worth it? Do, say 80x50 text, or 80x24, and a nice monochrome, or 4 color graphics display on a second screen?

    Dedicate the entire prop to that, and serial comms.

    Here's where I'm musing about that. Say the terminal can reproduce the same graphics serially? Now you've got both a PC output scenario, and or dedicated bench terminal output device using the same basic graphics data.

    Digression = 0

    Cool beans Bruce. Terminals are always good. I just rattled off the things I enjoy, though I very frequently use the minimum terminal, and actually that is sometimes just my TRS-80 Model 100 :), or other classic Apple, CoCo computer.
  • idbruceidbruce Posts: 6,197
    edited 2011-08-22 11:14
    There are a few C++ programmers that particpate in the forum. When I finish the initial framework and post it as open source, providing Parallax will let me upload the given file types, perhaps a few other people will jump in and add some more functionality. For now, I am just going to concentrate on making a very nice GUI for a working terminal app.

    Perhaps I should have asked for suggestions that pertain to a WINDOWS GUI. :) I have got to learn to be more specific :)

    However I want to thank everyone for their suggestions.

    Bruce
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-08-22 11:21
    idbruce wrote:
    ... providing Parallax will let me upload the given file types, ...
    You can upload anything that's in a zip.

    -Phil
  • idbruceidbruce Posts: 6,197
    edited 2011-08-22 11:21
    I just want to add that this is not like riding a bike. I have not done any serious C++ programming in several years and I have been going in circles since I started this project yesterday. However, I do believe that I am finally starting to make progress.

    Bruce
  • idbruceidbruce Posts: 6,197
    edited 2011-08-22 11:22
    @Phil

    Including executables?
  • potatoheadpotatohead Posts: 10,253
    edited 2011-08-22 11:39
    Re: Windows GUI.

    For terminal, the least GUI possible. :)
  • idbruceidbruce Posts: 6,197
    edited 2011-08-22 11:47
    @potatohead

    I am curious why you say that. The GUI encompasses a lot of attributes, functionality, and capabilities.

    From radio buttons to check boxes to drop down menus to rich edit controls to edit boxes to spin controls to scroll bars..............The list goes on

    Andy presented your desired app a little earlier in the thread :)
    ; 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()
    End
    

    EDIT: Can't forget those selectable fonts and those beautiful colors :)
  • potatoheadpotatohead Posts: 10,253
    edited 2011-08-22 12:07
    Honestly, both are good.

    Where I enjoy a GUI is the "one off" kind of computing where I need to get in, decide the things that need to be decided, input those, perform the task, output and exit. Where that varies considerably, the GUI can be a very nice thing.

    Where I don't enjoy a GUI is where things need to be repeated, or integrated as part of a process. It then becomes limiting. Much prefer keys, files, etc... for settings, leaving the GUI either working in tandem with files, so that either can make the change, or simply out of the way, minimal, so that the streams of data can just happen without that layer.

    A great example of what I was talking about is this: Say there are two devices, each with a terminal needed, each with a serial. Run the program, connect to device 1, configure and discover, repeat for device two. So far so good, but what was learned, and what must be repeated and what must be remembered?

    If there were, "write options to file", or the options were just files to begin with, then the good stuff was captured. Simply short cut the terminal for each device onto the desktop, each short cut referencing the environment or file needed for the terminal to understand it's configuration.

    Two clicks later, I'm looking at the white on blue one, lucida fonts for my Propeller number 1, and two more clicks later, I'm looking at my yellow on red one, Courier, connected to my Linux tty device, etc....

    Another device shows up, and it's a Prop! Great, copy the file, change blue to green, etc....

    That's just a standard preference. It's my opinion the best programs are written to deal with files, and or are command line applications. From there, "wrap" the GUI around them such that it's optional. The GUI users don't know better, or don't care to know better, or even know! They just run the GUI, life is good. Those that do use their operating system at a command level get to do so.

    So then, "minimal" is just all about lean operation options, not necessities.

    One last thing. Archiving text / command data is easy! Archiving GUI data isn't so easy, requiring pictures and lots of thick descriptive elements to communicate configuration state.

    All that said, please go for it in your GUI. My comment was not intended otherwise, nor is this post, which is just the explanation you asked for.
  • MagIO2MagIO2 Posts: 2,243
    edited 2011-08-22 12:07
    The thing I'd have on the wishlist is: use the propeller font

    ;o)

    You could easily create boxed menus, simple windows, in system schematics, signal diagrams .....
  • potatoheadpotatohead Posts: 10,253
    edited 2011-08-22 12:08
    I second this.
  • idbruceidbruce Posts: 6,197
    edited 2011-08-22 12:13
    Andreas

    I am glad you brought up the propeller font, I have seen several requests and/or complaints pertaining to that issue. I will definitely try to address that one also.

    Bruce
  • Kirk FraserKirk Fraser Posts: 364
    edited 2011-08-22 12:24
    I haven't read the whole thread but my 2 wants are:
    1) Automatic enable (no need to press the button for each new code test).
    2) Copy or Cut to clipboard so I can copy some values to report on this forum.
  • idbruceidbruce Posts: 6,197
    edited 2011-08-22 12:34
    @Kirk Fraser

    I have also seen several requests and/or complaints pertaining to issue #1, however I am unsure whether this is a general consensus. We'll see what others have to say, but I suppose it would be fairly easy to accomplish.

    As for issue #2, the main view will be comprised of a rich edit view, so selecting and copying text should be a non-issue.

    Bruce
  • TubularTubular Posts: 4,620
    edited 2011-08-22 12:34
    Ariba wrote: »
    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()
    End
    
    This 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

    Super good effort, Andy. I'll see if I can make it work, and take a look at PropTerminal too

    I want to put it on a USB PIC micro that presents as a mass storage drive when connected to a PC, then once connected it will function like a combined FTDI serial chip and adc.

    Looks like that Purebasic has some cross platform credentials too. Nice!

    cheers
    tubular
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-08-22 12:58
    Bruce,

    Yes, including executables.

    -Phil
  • tdlivingstdlivings Posts: 437
    edited 2011-08-22 13:33
    Handling the propeller font means Unicode characters and all the complexity that goes with that, I say leave that out for the future walk before you try to run.
    Just see if you can receive good old 8 bit ASCII from the serial port and display it in a text memo control, I think called multiline text box in the MFC world.

    Tom
  • idbruceidbruce Posts: 6,197
    edited 2011-08-22 21:42
    @tdlivings

    Now that you mention it, I do remember reading that the Propeller font was unicode, and that makes sense, so I would have to agree. I believe I will leave the Propeller font for a more ambitious young man.

    As for text display in MFC, you have EditView (like Notepad) and RichEditView (like Microsoft Word), each of these views originate from controls, being EditControl and RichEditControl respectively. Without looking it up, I believe multi-line capabilities are passed from the parent controls to the respective associated views.

    The serial communication wrappers that I will be using rely on the RichEditView/RichEditControl for displaying text text. This is a good thing for those that like to control background color and font color, as well as other things.

    However, I will agree that in the Parallax Serial Terminal, the input area has a class name of TMemo, but I believe this is a Delphi thing, not Microsoft.

    Bruce
  • jmgjmg Posts: 15,140
    edited 2011-08-23 00:01
    idbruce wrote: »
    @jmg
    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.

    That would be fine.

    idbruce wrote:
    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.

    I was a little too brief there, the IP (input) and OP (output) pins means the handshake lines.
    Pin 1	IP Data Carrier Detect	DCD     
    Pin 2	IP Received Data		RxData  
    Pin 3	OP Transmitted Data	TxData  
    Pin 4	OP Data Terminal Ready	DTR     
    Pin 5	-  Signal Ground		Gnd
    Pin 6	IP Data Set Ready		DSR     
    Pin 7	OP Request To Send	RTS     
    Pin 8	IP Clear To Send		CTS     
    Pin 9	IP Ring Indicator		RI      
    

    The SW library I was using, allows these simple and direct accesses
           ser.RTS := (True);
           ser.DTR := (False);
           ser.SendString(SomeString); 
           Sleep(2);                             // vary this, until we see pauses in String ?
           IF ser.DSR     THEN ...
           IF ser.CTS     THEN ...
           IF ser.Carrier THEN ..
           IF ser.Ring    THEN ..
    

    idbruce wrote:
    Add a Byte-rate Tx Test, that confirms Baud rates.
    As for this request or suggestion, it sounds a little complicated, and it will require some thought.

    In the simplest form, very easy : Take the time, send continually for eg 4 seconds, then take the time again, and report the Byte Rate = TotalCharsSent/TimeTaken.
    Issues with the buffers make this simple code report high, so we found a better method, is to set up a stream, and AVOID the ends.
    ie Transmit for 5 seconds, and sample [Time & Count] at 500ms and 4.5s, while it is streaming.
    That's usually within 0.2% of the freq counter baud.

    Better precision may be possible, but this was using simple calls. It's good enough to catch stop bit errors, and it will reveal creeping byte-gaps, as the USB ports have at the highest BAUD rates.
  • idbruceidbruce Posts: 6,197
    edited 2011-08-23 00:07
    jmg

    That all sounds like it could be fairly easily obtained.

    Bruce
  • bsnutbsnut Posts: 521
    edited 2011-08-23 01:12
    Bruce,

    Cool project that you are doing and understand that you are looking for suggestions and here's one.

    I love GUI programs and yours gives me an idea for you. What, if you come up with a way you can see what Propeller I/O pin is on ether a input that you turn in the Spin code or an output that was turned on from the spin code. All this would be displayed similar to Parallax's View Port, which shows you Propeller chip I/O.

    The programs that I write are automation based (like my ship monitoring system), were I need to sometimes look at the I/O to see what I/O is on or off and it will help in the. A GUI with features like that are helpful and I do realize that I would need to write some Spin code in order for it to work.

    I will continue to follow you as you continue to work your project.
  • idbruceidbruce Posts: 6,197
    edited 2011-08-23 01:38
    bsnut

    I could be mistaken, but I believe in order for something like that to work, you would need to send command strings from the Propeller, and the software for the terminal would have to parse all the received data looking for those command strings. I believe it could be done, but I am not that ambitious, because it sounds pretty time consuming to implement. But just in case someone wants to tackle the job when I post it as open source, I am willing to discuss it.

    In order for it to be useful to most people, the commands would need a standard. Additionally, I think it would be best to have a simple visual representation on the PC side, perhaps a dialog box with 32 LED bitmaps of alternating dk green and lt green. If a command is received for a pin going high, then a lt green bitmap is displayed and if a command is received for a pin going low, then a dk green bitmap is displayed.

    Also 32 visual representations of LEDs would take up a bit of screen space, so I would suggest that the dialog box actually be a docking toolbar instead, which could be toggled on or off by a menu selection. And that way the box is not floating on top of the main window, it actually becomes part of it, providing that it is docked.

    Bruce

    EDIT: I would also recommend that if something like this is implemented, another thead should be created for parsing and displaying the I/O pin status, so it would not slow down the main thread of the application.
  • idbruceidbruce Posts: 6,197
    edited 2011-08-23 04:15
    Just an update.

    Getting those tab controls to just show up and be displayed properly in association with a RichEditView was very troublesome. However that was the first order of business for this project and it took me a day and half to accomplish that task :(

    I now think that I have it beaten fairly into shape, so I can now move on to creating the actual interface and application. Like I said before, coming back to this after not having messed with it for several years... Well, lets just say that it has been a challenge.

    Additionally, I found an update for the tab control (which helped speed things up), and the update can be found here:

    http://msdn.microsoft.com/en-us/magazine/cc188936.aspx

    Bruce
  • tdlivingstdlivings Posts: 437
    edited 2011-08-23 07:14
    Bruce
    As for text display in MFC, you have EditView (like Notepad) and RichEditView (like Microsoft Word), each of these views originate from controls, being EditControl and RichEditControl respectively. Without looking it up, I believe multi-line capabilities are passed from the parent controls to the respective associated views.

    The serial communication wrappers that I will be using rely on the RichEditView/RichEditControl for displaying text text. This is a good thing for those that like to control background color and font color, as well as other things.

    However, I will agree that in the Parallax Serial Terminal, the input area has a class name of TMemo, but I believe this is a Delphi thing, not Microsoft.

    TMemo in Delphi is for making Notepad applications like your MFC EditControl and Delphi also has a
    RichEditControl.

    The Parallax Serial Terminal is not using either one for displaying text however. It is using a PaintBox.
    A TPaintbox in Delphi is a component which gives you a canvas to draw on using GDI functions.
    Actually Paintbox methods which wrap GDI functions.

    Here is a code snip from the open source Parallax Serial Terminal from Debug.pas which is the main pas
    file for this project.
    In the code Receiver is a TPaintbox component.
        {Need to render whole screen}
        begin
        for Idx := ScrTopLine to ScrTopLine+ScrHeight-1 do
          begin  {For all lines that need to be redrawn...}
          {First draw the entire line unhighlighted}
          Receiver.Canvas.TextOut(3,1+(Idx-ScrTopLine)*TxHeight,copy(ScrBuf.Line[Idx]^.Text,ScrLeftCol+1,ScrWidth));
          if (Idx >= RxSelStart.y) and (Idx <= RxSelEnd.y) then
            begin {If this is a highlighted line, draw the proper characters highlighted}
            Receiver.Canvas.Font.Color := CPrefs[RxBgColor].IValue;
            Receiver.Canvas.Brush.Color := CPrefs[RxFtColor].IValue;
            Receiver.Canvas.TextOut(3+max(0,ord(Idx=RxSelStart.y)*((RxSelStart.x-ScrLeftCol)*TxWidth)),1+(Idx-ScrTopLine)*TxHeight,
                                    copy(ScrBuf.Line[Idx]^.Text,max(ord(Idx=RxSelStart.y)*RxSelStart.x,ScrLeftCol)+1,(ord(Idx<>RxSelEnd.y)*(ScrWidth+ScrLeftCol))+(ord(Idx=RxSelEnd.y)*min(RxSelEnd.x,ScrWidth+ScrLeftCol))-(ord((RxSelStart.y=RxSelEnd.y) or (Idx=RxSelStart.y))*RxSelStart.x)-(max(ScrLeftCol-(RxSelStart.x*ord(Idx=RxSelStart.y)),0))));
            Receiver.Canvas.Font.Color := CPrefs[RxFtColor].IValue;
            Receiver.Canvas.Brush.Color := CPrefs[RxBgColor].IValue;
    

    Note the text is being drawn on a Canvas using GDI Canvas.Textout
    The reason this is done is it is difficult to do a serial terminal display using a component designed for
    making a text editor or word processor.
    There are two problems you cannot do goxy style actions where you need to move the cursor to some
    XY location and Display text. Your terminal would be responding to say the position(x,y) string from
    Parallax Serial Terminal.spin or your parsing VT100 ESC sequences.
    Components like EditView and RichEdit want to scroll lines .
    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. By using a Paintbox Canvas you are only using it for display of the lines you
    serially received and keep in your own data structures . You decide how many lines you want to keep in a back buffer that have scrolled off the top of you display window if any and can receive lines all day into your
    80x25 display screen done using a Paintbox Canvas you draw the text on.

    Maybe the code you have does this, I do not know so I sent this so you would have some info to think
    about as you design your terminal.

    Tom
  • idbruceidbruce Posts: 6,197
    edited 2011-08-23 07:42
    Tom

    That was a very interesting post. I have never come across this "choking issue" in past applications, but it is definitely food for thought. However I do believe I am going to stick with the RichEditControl, because that sounds like some major reprogramming alterations to pass it all onto the GDI. Additionally, at that point, you also lose the option for any copy and paste operations you may want to achieve. The guy that wrote the article and wrappers sure sounds like he knows what he is doing, and other people have recommended it, and the code looks clean. I guess I will just build it, keep my fingers crossed, and see what happens. I am sure it will be useful for something :)

    The TMemo class in the PST is being used for the input of text and TPanel is being used to display the output, or at least that is what Spy++ reads.

    Thanks for your post Tom.

    Bruce
  • tdlivingstdlivings Posts: 437
    edited 2011-08-23 08:02
    Bruce
    The TMemo in the PST is the single line where you enter text to be sent out serially.
    The received text is drawn in the large area below that line which is a TPaintbox.
    TPanel components are used to partition a form into sections and are also
    containers of other components. The TPaintbox is contained in a TPanel as well
    as many other parts of the PST form.

    Also I like your idea of build it your way and see, nothing like doing that to see for yourself.
    To many get talked out of doing anything , nothing like doing it and seeing the issues and
    even if you get it working and learned alot one can also be thinking I never want to do that again .

    Tom
  • idbruceidbruce Posts: 6,197
    edited 2011-08-23 08:05
    TPaintbox is contained in a TPanel as well as many other parts of the PST form

    I see says Bruce :)
Sign In or Register to comment.