Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Terminal Emulator For Talking to Embedded Targets
166 views
Skip to first unread message
Lorem Ipsum
Dec 4, 2022, 6:02:26 PM12/4/22
to
I wish to talk to a target board running Forth, through a serial port. The terminal program I have on my PC is Putty. I've used many over the years, but it seems they have winnowed down in number. It's been a while since I've used one, but Putty would seem to be the one I last used.
The problems I'm having are two. I would like to be able to control how the text is displayed better. Different colors for the two directions would be nice. Also, seeing control characters would be useful. I can't find how to do either of those.
Then to compile a Forth program will require sending the file through the serial port. I know many terminal programs provide a way to do this. I can't find it in Putty.
Should I look for another terminal emulator program? Or can anyone help me make this one more useful?
--
Rick C.
- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
The problems I'm having are two. I would like to be able to control how the text is displayed better. Different colors for the two directions would be nice. Also, seeing control characters would be useful. I can't find how to do either of those.
Then to compile a Forth program will require sending the file through the serial port. I know many terminal programs provide a way to do this. I can't find it in Putty.
Should I look for another terminal emulator program? Or can anyone help me make this one more useful?
--
Rick C.
- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
SpainHackForth
Dec 4, 2022, 6:08:07 PM12/4/22
to
> Then to compile a Forth program will require sending the file through the serial port. I know many terminal programs provide a way to do this. I can't find it in Putty.
>
> Should I look for another terminal emulator program? Or can anyone help me make this one more useful?
Lorem Ipsum
Dec 4, 2022, 6:51:04 PM12/4/22
to
I haven't dug into the support resources yet.
--
Rick C.
+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209
none albert
Dec 5, 2022, 6:18:44 AM12/5/22
to
In article <e08ae203-9355-4d91...@googlegroups.com>,
>Rick C.
Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Lorem Ipsum <gnuarm.del...@gmail.com> wrote:
>I wish to talk to a target board running Forth, through a serial port.
>The terminal program I have on my PC is Putty. I've used many over the
>years, but it seems they have winnowed down in number. It's been a
>while since I've used one, but Putty would seem to be the one I last
>used.
>
>The problems I'm having are two. I would like to be able to control how
>the text is displayed better. Different colors for the two directions
>would be nice. Also, seeing control characters would be useful. I
>can't find how to do either of those.
>
>Then to compile a Forth program will require sending the file through
>the serial port. I know many terminal programs provide a way to do
>this. I can't find it in Putty.
>
>Should I look for another terminal emulator program? Or can anyone help
>me make this one more useful?
On linux picocom is recommended for mecrisp. Works good.
>I wish to talk to a target board running Forth, through a serial port.
>The terminal program I have on my PC is Putty. I've used many over the
>years, but it seems they have winnowed down in number. It's been a
>while since I've used one, but Putty would seem to be the one I last
>used.
>
>The problems I'm having are two. I would like to be able to control how
>the text is displayed better. Different colors for the two directions
>would be nice. Also, seeing control characters would be useful. I
>can't find how to do either of those.
>
>Then to compile a Forth program will require sending the file through
>the serial port. I know many terminal programs provide a way to do
>this. I can't find it in Putty.
>
>Should I look for another terminal emulator program? Or can anyone help
>me make this one more useful?
>Rick C.
Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Pablo PabloC
Dec 5, 2022, 6:43:18 AM12/5/22
to
I have programmed TermFF for that purpose.
Specifically for Forth embedded systems.
https://sourceforge.net/projects/termff/
Specifically for Forth embedded systems.
https://sourceforge.net/projects/termff/
Lorem Ipsum
Dec 5, 2022, 2:17:20 PM12/5/22
to
On Monday, December 5, 2022 at 6:43:18 AM UTC-5, pbl...@gmail.com wrote:
> I have programmed TermFF for that purpose.
> Specifically for Forth embedded systems.
>
> https://sourceforge.net/projects/termff/
Hi Pablo,
> I have programmed TermFF for that purpose.
> Specifically for Forth embedded systems.
>
> https://sourceforge.net/projects/termff/
This looks interesting. Will it do the things I've asked about? Obviously it will download a file to be compiled on the target. Will it show the text in the two directions in different colors? Will it show control characters, as well as execute them?
--
Rick C.
+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209
SpainHackForth
Dec 5, 2022, 4:07:55 PM12/5/22
to
On Monday, December 5, 2022 at 12:43:18 PM UTC+1, pbl...@gmail.com wrote:
> I have programmed TermFF for that purpose.
> Specifically for Forth embedded systems.
>
> https://sourceforge.net/projects/termff/
Very nice!
> I have programmed TermFF for that purpose.
> Specifically for Forth embedded systems.
>
> https://sourceforge.net/projects/termff/
Pablo PabloC
Dec 6, 2022, 4:03:25 PM12/6/22
to
Hi
I don't want to bore you, but about the behavior of the terminal emulator, I try to clarify some issues about development with embedded Forth systems and I contribute my opinion.
To display the sent text in a color and the received text in a different color, first it would be necessary to clarify what is the sent text and what is the received one?
It would seem obvious that the sent is the one that comes out through TX of the serial channel, and the received one that arrives through RX.
But I think it is not so.
In a communication with a Forth system, normally the terminal emulator never presents what is sent.
It is the Forth system that echoes what it receives, and adds the reply.
For example, if we type '1 .<CR>' we send it without displaying anything to the terminal console, and then we receive '1 . 1 ok<CR>'.
How would the system have to behave in order to output color attribute-1 in the part '1 .' and color attribute-2 the part ' ok<CR>'?
(I want to keep it simple, regardless of whether the terminal sends each character or processes the line before.)
There are many possible solutions, but they all involve some code or behavior alteration in the embedded Forth system.
If the terminal emulator supports the input of VT100-type escape sequences, the simplest and most compatible is that the Forth system control and modify the attributes of the text it sends.
I was doing tests with FlashForth from TeraTerm with a PIC18F from the K22 family, programming a Forth and asm debugger, VT100 text attribute control was the best solution for me. Then with TermFF.
Some videos can be seen at https://www.youtube.com/@termff450 and in the final part of 'TermFF showing' how the control of text attributes is handled running a 'debug' in a FlashForth system.
And the predecessor of this debugger with TeraTerm at https://www.youtube.com/watch?v=3L-cOGtUGzg
Some time later I opted to have my own terminal emulator (TermFF) and a Forth with more features, for the Q4x family.
In TermFF I tried several alternatives, and the best option for me was the control of VT100 text attributes from the remote Forth system.
TermFF controls and allows changing different text colors for local mode (in the PC itself) and remote mode (the serial channel). (I am unable to attach a screenshot showing this.)
In the case of managing a buffer of console lines (as TermFF does) the presentation of characters is more complex, since characters are presented as they are typed and when pressing <CR> they are deleted from the screen, to later present the ones that we arrives from the remote Forth system.
On the other hand, when files are sent from the terminal, if the Forth system echoes what it receives, the screen fills up and the console buffer is overrun, without contributing anything. And if there is an error in the compilation and we keep sending the file, everything is full of lines of errors and we have difficulty in looking in the console where the error occurs.
I have chosen to include in the Forth system the option of working without echo. Support in this mode is the ability to count lines and return to echo mode on error. And use some control character to notify the terminal of the status, so it stops sending lines of the file.
This all involves some code on the Forth system side, but will work on any terminal emulator that supports VT100 (except notifying of an error to stop the download of the file).
In summary, I would encourage you to program a few small modifications to the embedded Forth system, to make compilation more comfortable and have better text visibility.
Regarding the control characters, I see even more questions to clarify.
Is it about 'seeing' the recieved characters and executing them?
I would not know how it should behave, for example when CTrl-C or Crtl-Q arrives, or when receiving XON or LF?
There are terminal emulators or serial channel sniffers that can be show in Hex or/and in ascii.
It has been useful for me to display the input flow in a separate window. Different from the ascii-VT100 terminal window itself.
In TermFF, to be able to see the input stream, I have a Dump window of the reception, which is started with F9.
There I present the hexadecimal value of the received bytes and in the right margin the corresponding character, if it is printable.
Pablo
I don't want to bore you, but about the behavior of the terminal emulator, I try to clarify some issues about development with embedded Forth systems and I contribute my opinion.
To display the sent text in a color and the received text in a different color, first it would be necessary to clarify what is the sent text and what is the received one?
It would seem obvious that the sent is the one that comes out through TX of the serial channel, and the received one that arrives through RX.
But I think it is not so.
In a communication with a Forth system, normally the terminal emulator never presents what is sent.
It is the Forth system that echoes what it receives, and adds the reply.
For example, if we type '1 .<CR>' we send it without displaying anything to the terminal console, and then we receive '1 . 1 ok<CR>'.
How would the system have to behave in order to output color attribute-1 in the part '1 .' and color attribute-2 the part ' ok<CR>'?
(I want to keep it simple, regardless of whether the terminal sends each character or processes the line before.)
There are many possible solutions, but they all involve some code or behavior alteration in the embedded Forth system.
If the terminal emulator supports the input of VT100-type escape sequences, the simplest and most compatible is that the Forth system control and modify the attributes of the text it sends.
I was doing tests with FlashForth from TeraTerm with a PIC18F from the K22 family, programming a Forth and asm debugger, VT100 text attribute control was the best solution for me. Then with TermFF.
Some videos can be seen at https://www.youtube.com/@termff450 and in the final part of 'TermFF showing' how the control of text attributes is handled running a 'debug' in a FlashForth system.
And the predecessor of this debugger with TeraTerm at https://www.youtube.com/watch?v=3L-cOGtUGzg
Some time later I opted to have my own terminal emulator (TermFF) and a Forth with more features, for the Q4x family.
In TermFF I tried several alternatives, and the best option for me was the control of VT100 text attributes from the remote Forth system.
TermFF controls and allows changing different text colors for local mode (in the PC itself) and remote mode (the serial channel). (I am unable to attach a screenshot showing this.)
In the case of managing a buffer of console lines (as TermFF does) the presentation of characters is more complex, since characters are presented as they are typed and when pressing <CR> they are deleted from the screen, to later present the ones that we arrives from the remote Forth system.
On the other hand, when files are sent from the terminal, if the Forth system echoes what it receives, the screen fills up and the console buffer is overrun, without contributing anything. And if there is an error in the compilation and we keep sending the file, everything is full of lines of errors and we have difficulty in looking in the console where the error occurs.
I have chosen to include in the Forth system the option of working without echo. Support in this mode is the ability to count lines and return to echo mode on error. And use some control character to notify the terminal of the status, so it stops sending lines of the file.
This all involves some code on the Forth system side, but will work on any terminal emulator that supports VT100 (except notifying of an error to stop the download of the file).
In summary, I would encourage you to program a few small modifications to the embedded Forth system, to make compilation more comfortable and have better text visibility.
Regarding the control characters, I see even more questions to clarify.
Is it about 'seeing' the recieved characters and executing them?
I would not know how it should behave, for example when CTrl-C or Crtl-Q arrives, or when receiving XON or LF?
There are terminal emulators or serial channel sniffers that can be show in Hex or/and in ascii.
It has been useful for me to display the input flow in a separate window. Different from the ascii-VT100 terminal window itself.
In TermFF, to be able to see the input stream, I have a Dump window of the reception, which is started with F9.
There I present the hexadecimal value of the received bytes and in the right margin the corresponding character, if it is printable.
Pablo
Lorem Ipsum
Dec 6, 2022, 9:01:07 PM12/6/22
to
On Tuesday, December 6, 2022 at 5:03:25 PM UTC-4, pbl...@gmail.com wrote:
> Hi
> I don't want to bore you, but about the behavior of the terminal emulator, I try to clarify some issues about development with embedded Forth systems and I contribute my opinion.
> To display the sent text in a color and the received text in a different color, first it would be necessary to clarify what is the sent text and what is the received one?
I don't understand how this could be unclear. This program is talking to an embedded target over a serial port, or something equivalent to one. Characters are sent in two direction. When you type at the keyboard, or dump a file into the serial port, that would be transmit, no? The characters received from the target are the received characters, no?
> Hi
> I don't want to bore you, but about the behavior of the terminal emulator, I try to clarify some issues about development with embedded Forth systems and I contribute my opinion.
> To display the sent text in a color and the received text in a different color, first it would be necessary to clarify what is the sent text and what is the received one?
What are you thinking that would make this other than clear? I'm not understanding. Is this not what your program does?
> It would seem obvious that the sent is the one that comes out through TX of the serial channel, and the received one that arrives through RX.
> But I think it is not so.
> In a communication with a Forth system, normally the terminal emulator never presents what is sent.
> It is the Forth system that echoes what it receives, and adds the reply.
> For example, if we type '1 .<CR>' we send it without displaying anything to the terminal console, and then we receive '1 . 1 ok<CR>'.
> How would the system have to behave in order to output color attribute-1 in the part '1 .' and color attribute-2 the part ' ok<CR>'?
> (I want to keep it simple, regardless of whether the terminal sends each character or processes the line before.)
> There are many possible solutions, but they all involve some code or behavior alteration in the embedded Forth system.
> If the terminal emulator supports the input of VT100-type escape sequences, the simplest and most compatible is that the Forth system control and modify the attributes of the text it sends.
> I was doing tests with FlashForth from TeraTerm with a PIC18F from the K22 family, programming a Forth and asm debugger, VT100 text attribute control was the best solution for me. Then with TermFF.
> Some videos can be seen at https://www.youtube.com/@termff450 and in the final part of 'TermFF showing' how the control of text attributes is handled running a 'debug' in a FlashForth system.
> And the predecessor of this debugger with TeraTerm at https://www.youtube.com/watch?v=3L-cOGtUGzg
> Some time later I opted to have my own terminal emulator (TermFF) and a Forth with more features, for the Q4x family.
> In TermFF I tried several alternatives, and the best option for me was the control of VT100 text attributes from the remote Forth system.
> TermFF controls and allows changing different text colors for local mode (in the PC itself) and remote mode (the serial channel). (I am unable to attach a screenshot showing this.)
> In the case of managing a buffer of console lines (as TermFF does) the presentation of characters is more complex, since characters are presented as they are typed and when pressing <CR> they are deleted from the screen, to later present the ones that we arrives from the remote Forth system.
> On the other hand, when files are sent from the terminal, if the Forth system echoes what it receives, the screen fills up and the console buffer is overrun, without contributing anything. And if there is an error in the compilation and we keep sending the file, everything is full of lines of errors and we have difficulty in looking in the console where the error occurs.
> I have chosen to include in the Forth system the option of working without echo. Support in this mode is the ability to count lines and return to echo mode on error. And use some control character to notify the terminal of the status, so it stops sending lines of the file.
> This all involves some code on the Forth system side, but will work on any terminal emulator that supports VT100 (except notifying of an error to stop the download of the file).
> In summary, I would encourage you to program a few small modifications to the embedded Forth system, to make compilation more comfortable and have better text visibility.
> Regarding the control characters, I see even more questions to clarify.
> Is it about 'seeing' the recieved characters and executing them?
> I would not know how it should behave, for example when CTrl-C or Crtl-Q arrives, or when receiving XON or LF?
> There are terminal emulators or serial channel sniffers that can be show in Hex or/and in ascii.
> It has been useful for me to display the input flow in a separate window. Different from the ascii-VT100 terminal window itself.
> In TermFF, to be able to see the input stream, I have a Dump window of the reception, which is started with F9.
> There I present the hexadecimal value of the received bytes and in the right margin the corresponding character, if it is printable.
>
> Pablo
> > Hi Pablo,
> >
> > This looks interesting. Will it do the things I've asked about? Obviously it will download a file to be compiled on the target. Will it show the text in the two directions in different colors? Will it show control characters, as well as execute them?
--
Rick C.
-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209
Lorem Ipsum
Dec 9, 2022, 3:58:33 AM12/9/22
to
I've had trouble finding a good terminal emulator under Windows, but it seems Hterm checks off all the items on my list. It shows the main six control codes, NUL, Bell, HT, FF, LF, CR and underlines Tx and Rx data with different colors, as well as letting me dump a text file to the serial port as if it were typed.
The only thing I'd like to see some improvement in, is adjusting the fonts in the data display. It lets you adjust the font size, but it would be nice to change the font and/or set bold at least.
--
Rick C.
-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209
The only thing I'd like to see some improvement in, is adjusting the fonts in the data display. It lets you adjust the font size, but it would be nice to change the font and/or set bold at least.
--
Rick C.
-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209
0 new messages