Modern 486...

[Lasse Langwadt Christensen]

fredag den 11. marts 2022 kl. 22.11.02 UTC+1 skrev gnuarm.del...@gmail.com:

On Friday, March 11, 2022 at 3:04:25 PM UTC-5, Jan Panteltje wrote:
On a sunny day (Fri, 11 Mar 2022 10:16:00 -0800 (PST)) it happened Rick C
gnuarm.del...@gmail.com> wrote in
84793350-1403-44bb...@googlegroups.com>:
On Friday, March 11, 2022 at 12:01:09 PM UTC-5, lang...@fonz.dk wrote:
fredag den 11. marts 2022 kl. 13.48.20 UTC+1 skrev gnuarm.del...@gmail.com:

On Thursday, March 10, 2022 at 11:45:42 AM UTC-5, lang...@fonz.dk wrote:

torsdag den 10. marts 2022 kl. 13.18.55 UTC+1 skrev John Doe:
The below description is pretty good but somewhat of an understatement.


There are LOTS of programs, very important programs, that do not run
on
Linux.
how many people need much more than a browser and maybe an \"office\" suite?

Absolutely true, but they use them under Windows. Ask them to use a Linux
machine and you have to start training all over again. That may not be more
significant than updating to a new version of office tools, but it is an
expense most companies won\'t suffer.
A few of those being able to run thru \"Wine\" or whatever makes little

difference, nobody wants their programs to run slower.
the difference is usually minor

Linux is a server operating system.
and many other things, it\'s greats for servers, desktops, all kind of
embedded stuff
and there\'s about 3 billion Android devices
Beta was a better video tape format. Windows is what people use. Linux is
for geeks and nerds. You know I\'m right.
when was the last time you tried something like ubuntu, 15 years ago?

You still fail to understand my point. WINDOWS USERS ARE NOT GOING TO TRY UBUNTU,
because Windows is what they know and it works very well for them.

Here\'s
an example. Everyone knows how to download an app from the web. Click
the download link and run the file that shows up. Done.

Under Linux... well, uh, sudo apt get something? I only know that from using
an rPi. Does Linux have automatic installation from a web site link? I
dunno. Most other people don\'t either. It\'s not about whether it is easy
or not. It\'s about what people know about it. Most people don\'t even know
the name Linux, thinking you mean that character from Peanuts.

Most people who would want to have a music server or a file server know how
to do things under Windows. They can find software on the web, open source
or not, download and install it and get something to work. I remember using
Win2K and finding a really useful web site on networking, World Of Windows
Networking, WOWN. Someone bought the site and ruined it. But I had
a home network up and running like clockwork. I struggled mightily to do
the same thing with the rPi. Heck, just finding out how to run a terminal
emulation that would support REPL with file download was no picnic. I got
it done eventually, but I would need to do the research again as I don\'t remember
the many complications and tricks I had to pull off to get it to work.
Or, on a Windows box, I can just use a remote desktop, done.

I suppose I could run a remote desktop so I can operate the rPi from the laptop,
maybe? Again, I don\'t know and it would take a bunch of research.

Is this all out of date?
Well you could read - and ask in comp.sys.raspbery-pi
The conversation is here. I suppose you can call this a conversation.
But google will tell you in a seoond, I use it all the time.
No, little is found through a web search in a \"second\". It often take many minutes or even hours to wade through the ever increasing dross to find a topic you are looking for. I was just trying to find the market cost of lithium carbonate and it brought up many pages telling me how great lithium batteries are or what\'s going on with the latest lithium powered gadget, etc.. God forbid you use a search term that is in the title of a song or movie, you\'ll never get past that.
All these thing you just mentioned exist for Pi
That said I wrote most of my own,
from this newsreader to media player / music center to video stuff.
A LOT more - email client, irc client, navigtion program, some is on my website
In Debian (variant of that is raspi OS) apt-get install will
install things for you.
I run and program raspies all the time via SSH from my laptop as the keyboard
is faster than the other wireless ones I have here on the table connected to the raspberries.
I do have a 5 channel HDMI switch on a big monitor to select raspis or
security cameras or TV...
But those raspies are so fast even via ssh I can just watch video too that way.

Home network? 3 8 port switches here, everything wired:
http://panteltje.com/pub/computer_table_IMX_IMG_0679.JPG
old picture, more has been added.. more groundwarts

And, if you look close you can see several RTL-SDR USB sticks and antennas.
Everything talks to everything else.
And that in only downstairs in the back, upstairs is the soldering station and a big PC (seldom used these day).
The black PC is no longer used...
Its what you make of it.
This is a triple ssh example:
http://panteltje.com/pub/xgpspc_mon_via_ssh.gif
navigation server with receiver rt-sdr runs on PI address ..73
laptop is on ...20
I connect via ssh with ...96 (is also 95) from ....20
and start cient program xgpspc_mon (you could use web browser too, but this is faster smaller better)
and now have the display on the laptop I use to type this with my own editor in an other full screen xterm in my NewsFleX Usenet newsreader
and take a screenshot with
import -screen xgpspc_mon_via_ssh.gif
from that terminal (I have 9 virtual screens with 8 rxvt terminals open on the fvwm filemanager on the laptop)
and then send it to my webserver\'s \'pub\' directory in \'merrica via ssh like this:
#to_website2 xgpspc_mon_via_ssh.gif
so the world can see it.
You can just see an airplane coming in belonging to United Arab Emirates I think (UAE) likely heading for Germany.

Scripts is the solution to everything so you do not have to remember every detail of all the thousands of commands
zsh is a much more pleasant shell to use than bash at least for sysadmins.
I don\'t really care what is available for Linux... well, not at the moment, although this conversation is making me want to fire up the rPi and pickup where I left off a few years ago.

My point is there is a market for people who would like to do some of the things you did, but using Windows because that\'s what they know. Why swim upstream and learn a new OS? Not everyone is a geek or wants to learn all the gory details of how to do the things you can do. I do a print screen by pressing a button on the keyboard, with the ALT key if I only want the window in focus rather than the whole screen. Why would I want to bother to learn \"import -screen xgpspc_mon_via_ssh.gif\"??? Learn it? I don\'t even want to type it! Click, click.

and you can do exactly the same in Ubuntu et. al.

printscreen for the whole desktop, alt-printscreen for a window, shift-printscreen for a selectable area

or, just like on windows, you can hit the start/windows key and start typing screenshoot and you get a window
with all the settings, what you want to copy, where you want to save it, if you want the pointer hidden etc.

 

[Rick C]

On Friday, March 11, 2022 at 4:45:17 PM UTC-5, lang...@fonz.dk wrote:

fredag den 11. marts 2022 kl. 22.11.02 UTC+1 skrev gnuarm.del...@gmail.com:
On Friday, March 11, 2022 at 3:04:25 PM UTC-5, Jan Panteltje wrote:
On a sunny day (Fri, 11 Mar 2022 10:16:00 -0800 (PST)) it happened Rick C
gnuarm.del...@gmail.com> wrote in
84793350-1403-44bb...@googlegroups.com>:
On Friday, March 11, 2022 at 12:01:09 PM UTC-5, lang...@fonz.dk wrote:
fredag den 11. marts 2022 kl. 13.48.20 UTC+1 skrev gnuarm.del...@gmail.com:

On Thursday, March 10, 2022 at 11:45:42 AM UTC-5, lang...@fonz.dk wrote:

torsdag den 10. marts 2022 kl. 13.18.55 UTC+1 skrev John Doe:
The below description is pretty good but somewhat of an understatement.


There are LOTS of programs, very important programs, that do not run
on
Linux.
how many people need much more than a browser and maybe an \"office\" suite?

Absolutely true, but they use them under Windows. Ask them to use a Linux
machine and you have to start training all over again. That may not be more
significant than updating to a new version of office tools, but it is an
expense most companies won\'t suffer.
A few of those being able to run thru \"Wine\" or whatever makes little

difference, nobody wants their programs to run slower.
the difference is usually minor

Linux is a server operating system.
and many other things, it\'s greats for servers, desktops, all kind of
embedded stuff
and there\'s about 3 billion Android devices
Beta was a better video tape format. Windows is what people use. Linux is
for geeks and nerds. You know I\'m right.
when was the last time you tried something like ubuntu, 15 years ago?

You still fail to understand my point. WINDOWS USERS ARE NOT GOING TO TRY UBUNTU,
because Windows is what they know and it works very well for them.

Here\'s
an example. Everyone knows how to download an app from the web. Click
the download link and run the file that shows up. Done.

Under Linux... well, uh, sudo apt get something? I only know that from using
an rPi. Does Linux have automatic installation from a web site link? I
dunno. Most other people don\'t either. It\'s not about whether it is easy
or not. It\'s about what people know about it. Most people don\'t even know
the name Linux, thinking you mean that character from Peanuts.

Most people who would want to have a music server or a file server know how
to do things under Windows. They can find software on the web, open source
or not, download and install it and get something to work. I remember using
Win2K and finding a really useful web site on networking, World Of Windows
Networking, WOWN. Someone bought the site and ruined it. But I had
a home network up and running like clockwork. I struggled mightily to do
the same thing with the rPi. Heck, just finding out how to run a terminal
emulation that would support REPL with file download was no picnic. I got
it done eventually, but I would need to do the research again as I don\'t remember
the many complications and tricks I had to pull off to get it to work.
Or, on a Windows box, I can just use a remote desktop, done.

I suppose I could run a remote desktop so I can operate the rPi from the laptop,
maybe? Again, I don\'t know and it would take a bunch of research.

Is this all out of date?
Well you could read - and ask in comp.sys.raspbery-pi
The conversation is here. I suppose you can call this a conversation.
But google will tell you in a seoond, I use it all the time.
No, little is found through a web search in a \"second\". It often take many minutes or even hours to wade through the ever increasing dross to find a topic you are looking for. I was just trying to find the market cost of lithium carbonate and it brought up many pages telling me how great lithium batteries are or what\'s going on with the latest lithium powered gadget, etc. God forbid you use a search term that is in the title of a song or movie, you\'ll never get past that.
All these thing you just mentioned exist for Pi
That said I wrote most of my own,
from this newsreader to media player / music center to video stuff.
A LOT more - email client, irc client, navigtion program, some is on my website
In Debian (variant of that is raspi OS) apt-get install will
install things for you.
I run and program raspies all the time via SSH from my laptop as the keyboard
is faster than the other wireless ones I have here on the table connected to the raspberries.
I do have a 5 channel HDMI switch on a big monitor to select raspis or
security cameras or TV...
But those raspies are so fast even via ssh I can just watch video too that way.

Home network? 3 8 port switches here, everything wired:
http://panteltje.com/pub/computer_table_IMX_IMG_0679.JPG
old picture, more has been added.. more groundwarts

And, if you look close you can see several RTL-SDR USB sticks and antennas.
Everything talks to everything else.
And that in only downstairs in the back, upstairs is the soldering station and a big PC (seldom used these day).
The black PC is no longer used...
Its what you make of it.
This is a triple ssh example:
http://panteltje.com/pub/xgpspc_mon_via_ssh.gif
navigation server with receiver rt-sdr runs on PI address ..73
laptop is on ...20
I connect via ssh with ...96 (is also 95) from ....20
and start cient program xgpspc_mon (you could use web browser too, but this is faster smaller better)
and now have the display on the laptop I use to type this with my own editor in an other full screen xterm in my NewsFleX Usenet newsreader
and take a screenshot with
import -screen xgpspc_mon_via_ssh.gif
from that terminal (I have 9 virtual screens with 8 rxvt terminals open on the fvwm filemanager on the laptop)
and then send it to my webserver\'s \'pub\' directory in \'merrica via ssh like this:
#to_website2 xgpspc_mon_via_ssh.gif
so the world can see it.
You can just see an airplane coming in belonging to United Arab Emirates I think (UAE) likely heading for Germany.

Scripts is the solution to everything so you do not have to remember every detail of all the thousands of commands
zsh is a much more pleasant shell to use than bash at least for sysadmins.
I don\'t really care what is available for Linux... well, not at the moment, although this conversation is making me want to fire up the rPi and pickup where I left off a few years ago.

My point is there is a market for people who would like to do some of the things you did, but using Windows because that\'s what they know. Why swim upstream and learn a new OS? Not everyone is a geek or wants to learn all the gory details of how to do the things you can do. I do a print screen by pressing a button on the keyboard, with the ALT key if I only want the window in focus rather than the whole screen. Why would I want to bother to learn \"import -screen xgpspc_mon_via_ssh.gif\"??? Learn it? I don\'t even want to type it! Click, click.

and you can do exactly the same in Ubuntu et. al.

printscreen for the whole desktop, alt-printscreen for a window, shift-printscreen for a selectable area

or, just like on windows, you can hit the start/windows key and start typing screenshoot and you get a window
with all the settings, what you want to copy, where you want to save it, if you want the pointer hidden etc.

You still aren\'t grasping the concept. If I\'m not a Linux user, (and I\'m not, really) I don\'t know that. If I\'m a Windows user, I know how to do it. Why would I want to change?

Windows has actually improved greatly over the last decade or two. It\'s very stable, easy to use and there are tons and tons of help in figuring out how to get your work done. People may not like the idea of using Microsoft, but it works. I had a problem with LibreOffice the other day and I ended up in an exchange with a couple of the nerds who appear to be developers or something. The bottom line was they blamed it on the file format for MS Office files and said I should use MS Office if I need to share MS Office format files! Ok, if that\'s the non-Microsoft approach, I\'ll use Windows and stick with what works for me.

--

Rick C.

++- Get 1,000 miles of free Supercharging
++- Tesla referral code - https://ts.la/richard11209

 

[Dan Purgert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Rick C wrote:

On Friday, March 11, 2022 at 12:01:09 PM UTC-5, lang...@fonz.dk wrote:
when was the last time you tried something like ubuntu, 15 years ago?

You still fail to understand my point. WINDOWS USERS ARE NOT GOING TO
TRY UBUNTU, because Windows is what they know and it works very well
for them.

I see \"hey I\'m a new Linux user\" almost daily on the linux IRC channels
I frequent, so at least some Windows users are trying it out.

[...]
Under Linux... well, uh, sudo apt get something? I only know that
from using an rPi. Does Linux have automatic installation from a web
site link? I dunno. Most other people don\'t either. It\'s not about
whether it is easy or not. It\'s about what people know about it.
Most people don\'t even know the name Linux, thinking you mean that
character from Peanuts.

You use the package manager (\"app store\"); same as your trusty iOS /
Android device. I hear Windows / Microsoft also has a builtin \"store\"
now too. No hunting all over the internet or downloading random \"trust
me\" software from some guy\'s blog.

Most people who would want to have a music server or a file server
know how to do things under Windows. They can find software on the
web, open source or not, download and install it and get something to
work. I remember using Win2K and finding a really useful web site on
networking, World Of Windows Networking, WOWN. Someone bought the
site and ruined it. But I had a home network up and running like
clockwork. I struggled mightily to do the same thing with the rPi.
Heck, just finding out how to run a terminal emulation that would
support REPL with file download was no picnic. I got it done
eventually, but I would need to do the research again as I don\'t
remember the many complications and tricks I had to pull off to get it
to work. Or, on a Windows box, I can just use a remote desktop, done.

Quick read on google makes REPL look like a python-based ... IDE maybe?
I dunno, the site really isn\'t that descriptive beyond \"this is a crutch
for beginners\". Not going to make any judgement of it one way or the
other.

If it IS just a python-based program, I\'d wager that the difficulty came
from \"which version of Python is installed\" -- that\'s always a stumbling
block (especially with Python 2 -> 3 conversions).

I suppose I could run a remote desktop so I can operate the rPi from
the laptop, maybe? Again, I don\'t know and it would take a bunch of
research.

Depends \"why\" you\'re accessing the rPi remotely -- a graphical interface
isn\'t necessarily always the best answer (then again, it might be for
you, I dunno).

> Is this all out of date?

Partially.


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIr7dIACgkQbWVw5Uzn
KGAT2Q//bQ1Xc/n4px8cOvjfEA8tYgPZ7nSecOvlFxiTiX9cQscS0NPeXLVjOHsA
OWJBZVLO15GoKNa8nx0DjxAtL4nXn7OyxgoHPq3SWOCbk45FYoXxOVzRp5rXl+0h
HQl/XxXLsurhTsbYCzvHk45H3kXOz2IatGJRvV2XHXWHglg51BM3uYYHI26yecvO
6r5pM4NW7G3Sj47+B2D7hULWXmPR4hL0QpKAx39KR0WLa/B2qF2mUwaH09KRydoz
wGKDm7h74d2HcVKM8AhZIkB0S19+gX2HlzM2V2BA2Xf8KRAT84nl+WpCSFN3+xM5
3gRSRlt3c4w5g1pE2IRSCJnainN6jGwwQydpOU/sfkWyCd0S+QxbWf07G6j/8iOE
JSztEQSoM6Ei0VwBCUfyvLBkELGfVqm3vXAHldMCIZm7TD3eBZtw0IQBdGZZvRiw
vIbwoV5w7k06IoiHndNVeBJbBMQBbHSsfWefLe16f/z0q+zjt6lOL7eTrP/7cmhO
gUMMe035QDOlPasaON+cSjVVUlnpeOR/rV+5nME2nEYfnHZGby099E/WhV1SDRA6
U4kYU7LwgT/HbfkdK588epCz4uVXd07UkYPQZWM/+od5fcRkACwSaRF2I1KDMajD
m5d1l1UtusNzNKYZjMCJW003fgUKFQvqQvrnZK+LSqZ10TdTe98=
=TYjt
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

 

[Rick C]

On Friday, March 11, 2022 at 7:47:38 PM UTC-5, Dan Purgert wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rick C wrote:
On Friday, March 11, 2022 at 12:01:09 PM UTC-5, lang...@fonz.dk wrote:
when was the last time you tried something like ubuntu, 15 years ago?

You still fail to understand my point. WINDOWS USERS ARE NOT GOING TO
TRY UBUNTU, because Windows is what they know and it works very well
for them.
I see \"hey I\'m a new Linux user\" almost daily on the linux IRC channels
I frequent, so at least some Windows users are trying it out.

[...]
Under Linux... well, uh, sudo apt get something? I only know that
from using an rPi. Does Linux have automatic installation from a web
site link? I dunno. Most other people don\'t either. It\'s not about
whether it is easy or not. It\'s about what people know about it.
Most people don\'t even know the name Linux, thinking you mean that
character from Peanuts.
You use the package manager (\"app store\"); same as your trusty iOS /
Android device. I hear Windows / Microsoft also has a builtin \"store\"
now too. No hunting all over the internet or downloading random \"trust
me\" software from some guy\'s blog.

Most people who would want to have a music server or a file server
know how to do things under Windows. They can find software on the
web, open source or not, download and install it and get something to
work. I remember using Win2K and finding a really useful web site on
networking, World Of Windows Networking, WOWN. Someone bought the
site and ruined it. But I had a home network up and running like
clockwork. I struggled mightily to do the same thing with the rPi.
Heck, just finding out how to run a terminal emulation that would
support REPL with file download was no picnic. I got it done
eventually, but I would need to do the research again as I don\'t
remember the many complications and tricks I had to pull off to get it
to work. Or, on a Windows box, I can just use a remote desktop, done.
Quick read on google makes REPL look like a python-based ... IDE maybe?
I dunno, the site really isn\'t that descriptive beyond \"this is a crutch
for beginners\". Not going to make any judgement of it one way or the
other.

If it IS just a python-based program, I\'d wager that the difficulty came
from \"which version of Python is installed\" -- that\'s always a stumbling
block (especially with Python 2 -> 3 conversions).

I think you have the wrong REPL. It\'s really just a way to say an interpretive interface.

https://www.google.com/search?q=REPL+loop+read%E2%80%93eval%E2%80%93print

I work with Forth which has a command line. Code can be executed from the bottom up as it is written. Typically word definitions (Forth\'s idea of subroutines) are small, often only one or two lines and can be tested interactively. So you write the word defintion, execute it and print out the stack to see if it did what you expected. This would seem to be simple debugging, but when you construct your code in small definitions, it works very effectively.

It often is done via a serial port interface, often emulated through USB, but can be done with network protocols. It does require a terminal emulator to be running somewhere to provide the user interface to the user.

I suppose I could run a remote desktop so I can operate the rPi from
the laptop, maybe? Again, I don\'t know and it would take a bunch of
research.
Depends \"why\" you\'re accessing the rPi remotely -- a graphical interface
isn\'t necessarily always the best answer (then again, it might be for
you, I dunno).
Is this all out of date?
Partially.

Yes, as others have told me. I think the scheme I used before was to run a terminal emulator on the laptop using sockets perhaps? But I don\'t recall how that connection to the rPi was connected to the USB serial cable on the rPi. Somewhere in the process I was trying to use a terminal emulator on the rPi, but that is an alien concept under Linux because a command line is a terminal interface (or so I was repeatedly told)... just not what I needed. I don\'t remember the details. I just recall it was a huge PITA to get running because of Linux. If I had plugged the serial port into the laptop, it would have been a slam dunk. But I wanted the unit under test to be in another room. Maybe I should have bought a 50 foot serial cable and run the interface at 9600 bps rather than 200,000, or was it 2 Mbps? The speed was fast enough that the screen would blink and was completely rewritten..

In the Forth group some guy is talking about trying to make hardware as easy to interface at a modular level as software. I\'d like to make software as easy to interface as hardware.

--

Rick C.

+++ Get 1,000 miles of free Supercharging
+++ Tesla referral code - https://ts.la/richard11209

 

[Jan Panteltje]

On a sunny day (Fri, 11 Mar 2022 13:10:53 -0800 (PST)) it happened Rick C
<gnuarm.deletethisbit@gmail.com> wrote in
<79268cfe-04a0-4e40-a92c-db8f47e3d785n@googlegroups.com>:

I
don\'t really care what is available for Linux... well, not at the moment,
although this conversation is making me want to fire up the rPi and pickup
where I left off a few years ago.

My point is there is a market for people who would like to do some of the things
you did, but using Windows because that\'s what they know. Why swim upstream
and learn a new OS? Not everyone is a geek or wants to learn all the
gory details of how to do the things you can do. I do a print screen by
pressing a button on the keyboard, with the ALT key if I only want the window
in focus rather than the whole screen. Why would I want to bother to learn
\"import -screen xgpspc_mon_via_ssh.gif\"??? Learn it? I don\'t even want
to type it! Click, click.

This is why people don\'t use DOS.

When [if] you install a standard Rasoi OS you can do the click thing for
almost anything.
Not much new to learn, just like going to a new supermarket
and the first time you find things are in a different place,
get used to it fast...
I have the GUI too in one of the 9 virtual screens on any system I run.

The advantage of a \'command line\' is like going to hardware shop and saying
\"I need whatever\" and the guy will put it in front of you in a second.
When you have a million things to chose from a click menu is so silly and slow.
And not to mention voice input for the visual disabled,
What is it these days? \"Siri where ..\" sort of things.
I have voice input on my old PC for teefee
Show BBC1
works.
I never use it, remote on my cheap HD Chinese sat box is faster and more quiet.

In this world everything has a learning curve,
I have been in foreign countries and trying to convey something
by pointing or drawing is possible but a difficult way to communicate
Learn the language, something US folks seem not to be busy with.
Here at high school 4 languages are already required
Dutch, French, German, English, and some also have Latin.
So I always say: \'My computer speaks English\' typing is faster than working
through silly menus
You can make your own language; by naming the command scripts you write.

Now you could argue that learning is so hard, well then you are dead
Life is learning

\"He who is nit busy being born is busy dying\"
https://www.bobdylan.com/songs/its-alright-ma-im-only-bleeding/

 

[Rick C]

On Saturday, March 12, 2022 at 2:44:24 AM UTC-5, Jan Panteltje wrote:

On a sunny day (Fri, 11 Mar 2022 13:10:53 -0800 (PST)) it happened Rick C
gnuarm.del...@gmail.com> wrote in
79268cfe-04a0-4e40...@googlegroups.com>:
I
don\'t really care what is available for Linux... well, not at the moment,
although this conversation is making me want to fire up the rPi and pickup
where I left off a few years ago.

My point is there is a market for people who would like to do some of the things
you did, but using Windows because that\'s what they know. Why swim upstream
and learn a new OS? Not everyone is a geek or wants to learn all the
gory details of how to do the things you can do. I do a print screen by
pressing a button on the keyboard, with the ALT key if I only want the window
in focus rather than the whole screen. Why would I want to bother to learn
\"import -screen xgpspc_mon_via_ssh.gif\"??? Learn it? I don\'t even want
to type it! Click, click.

This is why people don\'t use DOS.
When [if] you install a standard Rasoi OS you can do the click thing for
almost anything.
Not much new to learn, just like going to a new supermarket
and the first time you find things are in a different place,
get used to it fast...

But I like the supermarket that is right next to my neighborhood. I have no reason to drive across town to check out a market that doesn\'t seem to offer anything I don\'t have.

I have the GUI too in one of the 9 virtual screens on any system I run.

The advantage of a \'command line\' is like going to hardware shop and saying
\"I need whatever\" and the guy will put it in front of you in a second.

No, the guy was very rude to me because I didn\'t know the proper name of the thing I wanted. It\'s the long, round, flexible thingy that goes from the pipe under the sink to the little pipe that runs up into the sink. He keeps telling me he can\'t find any long, round, flexible thingies.


> When you have a million things to chose from a click menu is so silly and slow.

Yes, and trying to figure out the name and details of the one thingy of a million is even harder and slower, in fact, it takes forever because I have to go to another machine that is working to look up the name of the thingy if I can find it even then. Without the Windows machine that is working, I would have zero chance of getting the other machine to do what I want... or even know that I might want to try it.

And not to mention voice input for the visual disabled,
What is it these days? \"Siri where ..\" sort of things.
I have voice input on my old PC for teefee
Show BBC1
works.
I never use it, remote on my cheap HD Chinese sat box is faster and more quiet.

In this world everything has a learning curve,

No learning curve for the things you already know how to use.

I have been in foreign countries and trying to convey something
by pointing or drawing is possible but a difficult way to communicate
Learn the language, something US folks seem not to be busy with.

We don\'t interface with other languages much. So very little utility in knowing one of the many, many other languages that might be useful.

Here at high school 4 languages are already required
Dutch, French, German, English, and some also have Latin.
So I always say: \'My computer speaks English\' typing is faster than working
through silly menus
You can make your own language; by naming the command scripts you write.

Jack of all trades, master of none.

Now you could argue that learning is so hard, well then you are dead
Life is learning

\"He who is nit busy being born is busy dying\"
https://www.bobdylan.com/songs/its-alright-ma-im-only-bleeding/

You still fail to grasp the most basic principle involved in this discussion. Perhaps it is a language problem???

No, it\'s just a matter of you not being able to put yourself in others\' positions. If you aren\'t a nerd, and you already know something about Windows, it will be rare that you will think, \"Rather than learn more about Windows, I think I\'ll learn an entirely different OS I know nothing about\".

Are we done here? This really has become a pretty silly conversation.

--

Rick C.

---- Get 1,000 miles of free Supercharging
---- Tesla referral code - https://ts.la/richard11209

 

[Dan Purgert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


Rick C wrote:

On Friday, March 11, 2022 at 7:47:38 PM UTC-5, Dan Purgert wrote:
Quick read on google makes REPL look like a python-based ... IDE maybe?
I dunno, the site really isn\'t that descriptive beyond \"this is a crutch
for beginners\". Not going to make any judgement of it one way or the
other.

If it IS just a python-based program, I\'d wager that the difficulty came
from \"which version of Python is installed\" -- that\'s always a stumbling
block (especially with Python 2 -> 3 conversions).

I think you have the wrong REPL. It\'s really just a way to say an
interpretive interface.

Ah, yeah, I skipped over those initial hits, as I thought you were
talking about an actual piece of software; instead of a \"concept\" (which
isn\'t really that good of a word, but I can\'t really think of anything
better).

I work with Forth which has a command line. Code can be executed from
the bottom up as it is written. Typically word definitions (Forth\'s
idea of subroutines) are small, often only one or two lines and can be
tested interactively. So you write the word defintion, execute it and
print out the stack to see if it did what you expected. This would
seem to be simple debugging, but when you construct your code in small
definitions, it works very effectively.

I\'ve not done Forth, but it sounds a lot like connecting to an
interactive shell, such as bash or python (others exist).

It often is done via a serial port interface, often emulated through
USB, but can be done with network protocols. It does require a
terminal emulator to be running somewhere to provide the user
interface to the user.

Quite similar to the aforementioned shells (although more likely these
days to be ssh than serial/usb when it comes to interacting with a Linux
shell).

Is this all out of date?
Partially.

Yes, as others have told me. I think the scheme I used before was to
run a terminal emulator on the laptop using sockets perhaps? But I
don\'t recall how that connection to the rPi was connected to the USB
serial cable on the rPi. Somewhere in the process I was trying to use
a terminal emulator on the rPi, but that is an alien concept under
Linux because a command line is a terminal interface (or so I was
repeatedly told)... just not what I needed. I don\'t remember the

It\'s messy, mostly because of how things have changed since the 60s/70s.

Assuming you\'re running something graphical (e.g. xfce); then your
*terminal emulator* (commandline) will be xterm or xfce4-terminal or
gnome-terminal (or a few other options). This application will connect
to a pseudo-teletype (pty) instance that the kernel is running. When it
is spun up, you get an instance of your interactive shell (e.g. bash)
spawned, so you can give the computer commands.

While it is possible to read from / write to a serial interface directly
from your shell (e.g. \'cat /dev/ttyS0\' to read whatever it\'s printing
back or \'echo C > /dev/ttyS0\' to write the character \'C\' to it),
normally you\'d want to use something like _minicom_ or _screen_ (they\'re
analogous to the windows tools HyperTerm or PuTTY).

details. I just recall it was a huge PITA to get running because of
Linux. If I had plugged the serial port into the laptop, it would
have been a slam dunk. But I wanted the unit under test to be in
another room. Maybe I should have bought a 50 foot serial cable and
run the interface at 9600 bps rather than 200,000, or was it 2 Mbps?
The speed was fast enough that the screen would blink and was
completely rewritten.

I don\'t think I saw that specific question. For the sake of discussion
and assuming a generally hypothetical scenario ... for this scenario,
you have three devices in play:

1. a PC in some room
2. a DUT in another room
3. a rPi in the same room as DUT, which you\'re connecting to via ssh.

So in that case, I\'d ssh into the rPi; then fire up whatever application
I was using to perform the test (Forth, python, whatever) with
appropriate parameters to connect to /dev/ttyS0 (assuming that\'s the
correct serial port on the rPi, of course).

Again -- I\'m considering this a hypothetical, as I don\'t know all the
specifics you ran into / what you\'ve already done / tried / etc, and
don\'t want to waste your time telling you to do things that you\'ve
already tried.

In the Forth group some guy is talking about trying to make hardware
as easy to interface at a modular level as software. I\'d like to make
software as easy to interface as hardware.

They\'re both easy, in their own ways. Each has its caveats though
software is getting _harder_ nowadays, when we\'re talking \"old comms\"
such as serial or parallel ... I mean it\'s been a good 20-25 years since
serial was truly \"required\" in the general case.


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmItAPAACgkQbWVw5Uzn
KGBibhAAr+8/WPa+HHFdgiML+hJOm6xxFa5EcOQWnO+fYpufJ3J3S3LhCQ6HJxWq
NB3L6H3/Q2pgRouUIPZpciuBHiQs9ck1Rd9pi5cSxuQEKVfq8m3lwMkqB3zonyuF
7OnfYHaqnTu1XzXTv8GnC9+ooFRiIPmvp36EaPk9N2N2GphV4uYlb17NesPRjnc9
7cB9nZRPCD2maBwQI+yn69hBupgafcKUnJ6Knka6yOw1+yww4OTCKyshXOviRO1c
h8zhaayzGLf/QdeWmSOrY4BEMgS8u7OQt6HSmwdQiZ33W5wCDtAcrHkVZDy7h217
XP7/QhcQmrANZxumR5doQq+1Rnjw6YS/oK8HpjRgCwBuRYPyp6mxIktLultGU5m4
nBuM6XTljnJ3UwuyEbC8im0+kdkI3BamrVjYzvagmLAJqiOuevsg2gYqCoM2bO4R
UWo8u8PqaLUhE3DmxLCM5sJw0RFTGV7cC7fOlFwrQ0UY+Ylty2K0TaqjorZepk6+
WOLAp+URoynZw302+R4jql1TjUBs1VW2d2fqbf4Ron2kGwVPhQkh7S+EwW51w8qS
IKEEY4lo+QBlx2Isjgw5TgOlm539f8vwZY/oghdFYoK6Roiwp8X2IYLYioCslIIJ
Nbym+NzfXhfwqG8ZEmjK4SpvI5g17AnSfBIV4AT48AcmKUdcdtI=
=rHZ0
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

 

[Rick C]

On Saturday, March 12, 2022 at 3:21:33 PM UTC-5, Dan Purgert wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


Rick C wrote:
On Friday, March 11, 2022 at 7:47:38 PM UTC-5, Dan Purgert wrote:
Quick read on google makes REPL look like a python-based ... IDE maybe?
I dunno, the site really isn\'t that descriptive beyond \"this is a crutch
for beginners\". Not going to make any judgement of it one way or the
other.

If it IS just a python-based program, I\'d wager that the difficulty came
from \"which version of Python is installed\" -- that\'s always a stumbling
block (especially with Python 2 -> 3 conversions).

I think you have the wrong REPL. It\'s really just a way to say an
interpretive interface.
Ah, yeah, I skipped over those initial hits, as I thought you were
talking about an actual piece of software; instead of a \"concept\" (which
isn\'t really that good of a word, but I can\'t really think of anything
better).

I work with Forth which has a command line. Code can be executed from
the bottom up as it is written. Typically word definitions (Forth\'s
idea of subroutines) are small, often only one or two lines and can be
tested interactively. So you write the word defintion, execute it and
print out the stack to see if it did what you expected. This would
seem to be simple debugging, but when you construct your code in small
definitions, it works very effectively.
I\'ve not done Forth, but it sounds a lot like connecting to an
interactive shell, such as bash or python (others exist).

Not really a shell. It\'s a programming language based on a virtual stack machine. I\'m sure you seen those before. The difference this one uses the virtual stack machine as the programming language. No parameter lists, data is pushed onto the stack (or left from previous words) and each word gets its inputs from the stack, leaves outputs on the stack. The fact that it is interpretive is just icing on the cake. It is also compiled, so the best of both worlds.

It often is done via a serial port interface, often emulated through
USB, but can be done with network protocols. It does require a
terminal emulator to be running somewhere to provide the user
interface to the user.
Quite similar to the aforementioned shells (although more likely these
days to be ssh than serial/usb when it comes to interacting with a Linux
shell).

Yeah, SSH rings a bell. Like I said, it\'s been years since I ran this from other parts of the house. In my case the rPi was not the client, but an intermediary to provide the serial port to the small MCU target.

Is this all out of date?
Partially.

Yes, as others have told me. I think the scheme I used before was to
run a terminal emulator on the laptop using sockets perhaps? But I
don\'t recall how that connection to the rPi was connected to the USB
serial cable on the rPi. Somewhere in the process I was trying to use
a terminal emulator on the rPi, but that is an alien concept under
Linux because a command line is a terminal interface (or so I was
repeatedly told)... just not what I needed. I don\'t remember the
It\'s messy, mostly because of how things have changed since the 60s/70s.

Assuming you\'re running something graphical (e.g. xfce); then your
*terminal emulator* (commandline) will be xterm or xfce4-terminal or
gnome-terminal (or a few other options). This application will connect
to a pseudo-teletype (pty) instance that the kernel is running. When it
is spun up, you get an instance of your interactive shell (e.g. bash)
spawned, so you can give the computer commands.

Most of that means little to me. Under Windows you just run a terminal emulator program and done.

While it is possible to read from / write to a serial interface directly
from your shell (e.g. \'cat /dev/ttyS0\' to read whatever it\'s printing
back or \'echo C > /dev/ttyS0\' to write the character \'C\' to it),
normally you\'d want to use something like _minicom_ or _screen_ (they\'re
analogous to the windows tools HyperTerm or PuTTY).

Minicom rings a bell too. Whatever I used on the rPi was not very full featured. It needs to be able to link the keyboard and screen to the serial port, but also send files to the target for compilation. Forth runs on the target and you send source code over the serial port or other comms channel.. Sometimes if the target is more capable, the target has a file system, so can act as the entire development system running an editor. This case was a little TI MCU with maybe 4kB of RAM and some 32 or 64kB of Flash. So the files were edited on the PC or rPi and downloaded for each compile.

details. I just recall it was a huge PITA to get running because of
Linux. If I had plugged the serial port into the laptop, it would
have been a slam dunk. But I wanted the unit under test to be in
another room. Maybe I should have bought a 50 foot serial cable and
run the interface at 9600 bps rather than 200,000, or was it 2 Mbps?
The speed was fast enough that the screen would blink and was
completely rewritten.
I don\'t think I saw that specific question. For the sake of discussion
and assuming a generally hypothetical scenario ... for this scenario,
you have three devices in play:

1. a PC in some room
2. a DUT in another room
3. a rPi in the same room as DUT, which you\'re connecting to via ssh.

Yeah, that\'s right.

So in that case, I\'d ssh into the rPi; then fire up whatever application
I was using to perform the test (Forth, python, whatever) with
appropriate parameters to connect to /dev/ttyS0 (assuming that\'s the
correct serial port on the rPi, of course).

That sounds like what I did, except there\'s nothing to run on the rPi other than connecting the link from the PC to the serial port to the target. Forth runs on the target. I like Codewright for an editor, so I would have been editing the files on the PC and shooting them down to the target. I seem to recall that was the part I had the most trouble with. Trying to make all this work like it was one pipe between the PC and the target.

Again -- I\'m considering this a hypothetical, as I don\'t know all the
specifics you ran into / what you\'ve already done / tried / etc, and
don\'t want to waste your time telling you to do things that you\'ve
already tried.
In the Forth group some guy is talking about trying to make hardware
as easy to interface at a modular level as software. I\'d like to make
software as easy to interface as hardware.
They\'re both easy, in their own ways. Each has its caveats though
software is getting _harder_ nowadays, when we\'re talking \"old comms\"
such as serial or parallel ... I mean it\'s been a good 20-25 years since
serial was truly \"required\" in the general case.

Hardware has gotten mostly to the point of interconnecting large blocks called ASICs, much as software has done the same. Both require some amount of glue to make everything play nicely together. When you really need to design digital hardware, that\'s mostly done in FPGAs, so we are back to software, kinda, sorta.

There is analog hardware, but mostly hardware is inside chips unless you are designing the 1 in 1,000 things that haven\'t been done a million times before.

--

Rick C.

---+ Get 1,000 miles of free Supercharging
---+ Tesla referral code - https://ts.la/richard11209

 

[Dan Purgert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Rick C wrote:

On Saturday, March 12, 2022 at 3:21:33 PM UTC-5, Dan Purgert wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


Rick C wrote:
On Friday, March 11, 2022 at 7:47:38 PM UTC-5, Dan Purgert wrote:
Quick read on google makes REPL look like a python-based ... IDE maybe?
I dunno, the site really isn\'t that descriptive beyond \"this is a crutch
for beginners\". Not going to make any judgement of it one way or the
other.

If it IS just a python-based program, I\'d wager that the difficulty came
from \"which version of Python is installed\" -- that\'s always a stumbling
block (especially with Python 2 -> 3 conversions).

I think you have the wrong REPL. It\'s really just a way to say an
interpretive interface.
Ah, yeah, I skipped over those initial hits, as I thought you were
talking about an actual piece of software; instead of a \"concept\" (which
isn\'t really that good of a word, but I can\'t really think of anything
better).

I work with Forth which has a command line. Code can be executed from
the bottom up as it is written. Typically word definitions (Forth\'s
idea of subroutines) are small, often only one or two lines and can be
tested interactively. So you write the word defintion, execute it and
print out the stack to see if it did what you expected. This would
seem to be simple debugging, but when you construct your code in small
definitions, it works very effectively.
I\'ve not done Forth, but it sounds a lot like connecting to an
interactive shell, such as bash or python (others exist).

Not really a shell. It\'s a programming language based on a virtual
stack machine. I\'m sure you seen those before. The difference this
one uses the virtual stack machine as the programming language. No
parameter lists, data is pushed onto the stack (or left from previous
words) and each word gets its inputs from the stack, leaves outputs on
the stack. The fact that it is interpretive is just icing on the
cake. It is also compiled, so the best of both worlds.

Okay so closer to the interactive Python interpreter you get when
running \"python\" .

It often is done via a serial port interface, often emulated through
USB, but can be done with network protocols. It does require a
terminal emulator to be running somewhere to provide the user
interface to the user.
Quite similar to the aforementioned shells (although more likely these
days to be ssh than serial/usb when it comes to interacting with a Linux
shell).

Yeah, SSH rings a bell. Like I said, it\'s been years since I ran this
from other parts of the house. In my case the rPi was not the client,
but an intermediary to provide the serial port to the small MCU
target.

SSH = \"S\"ecure \"SH\"ell. Sparknotes description is it\'s a (secure)
methodology for connecting to remote shell instances on other computers.

Is this all out of date?
Partially.

Yes, as others have told me. I think the scheme I used before was to
run a terminal emulator on the laptop using sockets perhaps? But I
don\'t recall how that connection to the rPi was connected to the USB
serial cable on the rPi. Somewhere in the process I was trying to use
a terminal emulator on the rPi, but that is an alien concept under
Linux because a command line is a terminal interface (or so I was
repeatedly told)... just not what I needed. I don\'t remember the
It\'s messy, mostly because of how things have changed since the 60s/70s.

Assuming you\'re running something graphical (e.g. xfce); then your
*terminal emulator* (commandline) will be xterm or xfce4-terminal or
gnome-terminal (or a few other options). This application will connect
to a pseudo-teletype (pty) instance that the kernel is running. When it
is spun up, you get an instance of your interactive shell (e.g. bash)
spawned, so you can give the computer commands.

Most of that means little to me. Under Windows you just run a terminal emulator program and done.

Ugh, editing error on my part. The programs mentioned are the GUI
equivalent of running the Windows command interpreter (it\'s still \"cmd\",
right?)

While it is possible to read from / write to a serial interface directly
from your shell (e.g. \'cat /dev/ttyS0\' to read whatever it\'s printing
back or \'echo C > /dev/ttyS0\' to write the character \'C\' to it),
normally you\'d want to use something like _minicom_ or _screen_ (they\'re
analogous to the windows tools HyperTerm or PuTTY).

Minicom rings a bell too. Whatever I used on the rPi was not very
full featured. It needs to be able to link the keyboard and screen to
the serial port, but also send files to the target for compilation.
Forth runs on the target and you send source code over the serial port
or other comms channel. Sometimes if the target is more capable, the

Given the description here, definitely sounds like minicom with
probably a zmodem helper for sending files.

target has a file system, so can act as the entire development system
running an editor. This case was a little TI MCU with maybe 4kB of
RAM and some 32 or 64kB of Flash. So the files were edited on the PC
or rPi and downloaded for each compile.

Ooh, which one? I haven\'t played with any TI MCUs yet ... mostly play
around with AVR parts.

details. I just recall it was a huge PITA to get running because of
Linux. If I had plugged the serial port into the laptop, it would
have been a slam dunk. But I wanted the unit under test to be in
another room. Maybe I should have bought a 50 foot serial cable and
run the interface at 9600 bps rather than 200,000, or was it 2 Mbps?
The speed was fast enough that the screen would blink and was
completely rewritten.
I don\'t think I saw that specific question. For the sake of discussion
and assuming a generally hypothetical scenario ... for this scenario,
you have three devices in play:

1. a PC in some room
2. a DUT in another room
3. a rPi in the same room as DUT, which you\'re connecting to via ssh.

Yeah, that\'s right.


So in that case, I\'d ssh into the rPi; then fire up whatever application
I was using to perform the test (Forth, python, whatever) with
appropriate parameters to connect to /dev/ttyS0 (assuming that\'s the
correct serial port on the rPi, of course).

That sounds like what I did, except there\'s nothing to run on the rPi
other than connecting the link from the PC to the serial port to the
target. Forth runs on the target. I like Codewright for an editor,

OH -- okay so then the corrected approach would be to ssh to the pi,
then launch whatever serial modem application (e.g. minicom) is
necessary to talk to the DUT on /dev/ttyS0 .

NOTE -- I keep writing /dev/ttyS0 since that\'s the first serial port
(\"COM0\" in windows, if I\'m remembering correctly). Big difference with
Linux and Windows in this regard is that if you have USB serial devices,
they\'ll probably enumerate as \"/dev/ttyUSBn\" or \"/dev/ttyACMn\"; whereas
windows would (IIRC) just keep calling them \"COMn\"

so I would have been editing the files on the PC and shooting them
down to the target. I seem to recall that was the part I had the most
trouble with. Trying to make all this work like it was one pipe
between the PC and the target.

Yes, sticking the intermediary would be a source of \"fun(tm)\",
regardless of OS. Any OS is going to be something like

1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port

They\'re both easy, in their own ways. Each has its caveats though
software is getting _harder_ nowadays, when we\'re talking \"old comms\"
such as serial or parallel ... I mean it\'s been a good 20-25 years since
serial was truly \"required\" in the general case.

Hardware has gotten mostly to the point of interconnecting large
blocks called ASICs, much as software has done the same. Both require
some amount of glue to make everything play nicely together. When you
really need to design digital hardware, that\'s mostly done in FPGAs,
so we are back to software, kinda, sorta.

FPGAs (and [C]PLDs) are still new territory for me. Have a something or
other devboard that plays nice on Linux and has an open devchain ... but
I haven\'t gotten much farther than \"here\'s a blinkenLED\".


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIt77YACgkQbWVw5Uzn
KGAvCxAAjO+iU8cWyDtn+MA5tq26MAzVngAxd6JeeH8LNFvBMTbpvmKAFBQVk+2W
n4PT9YSYYFnCkv+9EyF94wWO9Mh8G2FTvlL9KlHyHLC6PZlGx0rebjeVBNjUaxJP
k2G1DsDH7zo8jFD/DDEnIU+Ot8LyVE9iR5yc2iHu6C2VvnGS3WOIUoAbqwFvSBsP
o/6opCqHKndlfJcWXOs5Q1c1mY6WN/7jfNodBkJsxWCDlsufojriIzVfdiv65AXv
iltaM4+dmsUu87WxtAbTLFfanho72M2LkvDOnyaaGwal3+AP02MZ33fEsnBv1BUK
ASHG1cCe9KNqFK7z8wIrR9ezp3JQXW2TkD4rP/HFnTVxRjKtm0rXM2jPfwuFoaGd
FX0laJNFQEvLPUAIscc3nqTG5yEeiETU/jXJTK1qrbluWGnwo+MLm4Gl6gd5kaua
2WXqMMTqJp04mANlXFg31BX2ZcGZbfszZHPCZvzE+g7HVAO4WNWLQRg13RFsTump
5m1JbsnoqGRca97/GtMbwp/pZkyureOUhF+U3ljOkMYYEIfqcC/5zD9cgLFxGfHO
UdXwJUPkVpw0meVX9f3gZQ9YFTmZ7koL2A1Ylf424toizp5qp0GnT7k+kZGbEjar
VWxoyzkRL/lJww3P9VjG4zWUAxguzcsbhBeRmkBKafpha1X3hRc=
=XeZI
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

 

[Rick C]

On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:

Rick C wrote:
On Saturday, March 12, 2022 at 3:21:33 PM UTC-5, Dan Purgert wrote:
Assuming you\'re running something graphical (e.g. xfce); then your
*terminal emulator* (commandline) will be xterm or xfce4-terminal or
gnome-terminal (or a few other options). This application will connect
to a pseudo-teletype (pty) instance that the kernel is running. When it
is spun up, you get an instance of your interactive shell (e.g. bash)
spawned, so you can give the computer commands.

Most of that means little to me. Under Windows you just run a terminal emulator program and done.
Ugh, editing error on my part. The programs mentioned are the GUI
equivalent of running the Windows command interpreter (it\'s still \"cmd\",
right?)

CMD is what I use, but the new one is Powershell.

While it is possible to read from / write to a serial interface directly
from your shell (e.g. \'cat /dev/ttyS0\' to read whatever it\'s printing
back or \'echo C > /dev/ttyS0\' to write the character \'C\' to it),
normally you\'d want to use something like _minicom_ or _screen_ (they\'re
analogous to the windows tools HyperTerm or PuTTY).

Minicom rings a bell too. Whatever I used on the rPi was not very
full featured. It needs to be able to link the keyboard and screen to
the serial port, but also send files to the target for compilation.
Forth runs on the target and you send source code over the serial port
or other comms channel. Sometimes if the target is more capable, the
Given the description here, definitely sounds like minicom with
probably a zmodem helper for sending files.

I think the file send was transparent to the rPi. The files are text source code, as if they were being typed at the console. So it is dumped to the SSH pipe from the PC. No protocol needed.

target has a file system, so can act as the entire development system
running an editor. This case was a little TI MCU with maybe 4kB of
RAM and some 32 or 64kB of Flash. So the files were edited on the PC
or rPi and downloaded for each compile.
Ooh, which one? I haven\'t played with any TI MCUs yet ... mostly play
around with AVR parts.

I don\'t recall. It could have been a n MSP430, or it might have been one of their ARM chips. TI muddied the waters by putting some of the ARMs under the MSP430 moniker because they were \"targeted\" to similar applications. Stupid marketeers don\'t understand this makes life harder for engineers causing them to shy away from their parts.

I don\'t think I saw that specific question. For the sake of discussion
and assuming a generally hypothetical scenario ... for this scenario,
you have three devices in play:

1. a PC in some room
2. a DUT in another room
3. a rPi in the same room as DUT, which you\'re connecting to via ssh.

Yeah, that\'s right.


So in that case, I\'d ssh into the rPi; then fire up whatever application
I was using to perform the test (Forth, python, whatever) with
appropriate parameters to connect to /dev/ttyS0 (assuming that\'s the
correct serial port on the rPi, of course).

That sounds like what I did, except there\'s nothing to run on the rPi
other than connecting the link from the PC to the serial port to the
target. Forth runs on the target. I like Codewright for an editor,
OH -- okay so then the corrected approach would be to ssh to the pi,
then launch whatever serial modem application (e.g. minicom) is
necessary to talk to the DUT on /dev/ttyS0 .

So running a SSH program on the PC would give me a console that is actually the minicom on the rPi? I should try to resurrect this as I may need to use it again. I am living in Puerto Rico and it would be nice to operate a target in the mainland. Other than the need to reset the target when things get really fouled up. That\'s why I wanted a USB hub that could cut power to individual plugs.. or even the whole hub. Doesn\'t matter. I just need it to be controllable from the rPi so it can reboot the target. I guess in theory I could tie an output from the rPi to the reset line on the target, but there are times when a power cycle is useful too.

NOTE -- I keep writing /dev/ttyS0 since that\'s the first serial port
(\"COM0\" in windows, if I\'m remembering correctly). Big difference with
Linux and Windows in this regard is that if you have USB serial devices,
they\'ll probably enumerate as \"/dev/ttyUSBn\" or \"/dev/ttyACMn\"; whereas
windows would (IIRC) just keep calling them \"COMn\"
so I would have been editing the files on the PC and shooting them
down to the target. I seem to recall that was the part I had the most
trouble with. Trying to make all this work like it was one pipe
between the PC and the target.
Yes, sticking the intermediary would be a source of \"fun(tm)\",
regardless of OS. Any OS is going to be something like

1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port

More like,

1) Run terminal emulator on PC
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)

This is starting to come back to me now. The comms program on the PC gives me a Linux shell, so I can do other things if I want, like toggle the reset line on the target or even the power source.

They\'re both easy, in their own ways. Each has its caveats though
software is getting _harder_ nowadays, when we\'re talking \"old comms\"
such as serial or parallel ... I mean it\'s been a good 20-25 years since
serial was truly \"required\" in the general case.

Hardware has gotten mostly to the point of interconnecting large
blocks called ASICs, much as software has done the same. Both require
some amount of glue to make everything play nicely together. When you
really need to design digital hardware, that\'s mostly done in FPGAs,
so we are back to software, kinda, sorta.
FPGAs (and [C]PLDs) are still new territory for me. Have a something or
other devboard that plays nice on Linux and has an open devchain ... but
I haven\'t gotten much farther than \"here\'s a blinkenLED\".

I\'m old school, so I think hardware should be designing in the mind as if it was hardware. The HDL is a necessary evil for implementing it. I was helping a software guy learn HDL and he ended up creating a \"Hello, world!\" program with a software approach, because he didn\'t need to optimize anything. You can\'t argue with success.

What sort of things are you interested in doing in FPGAs?

--

Rick C.

--+- Get 1,000 miles of free Supercharging
--+- Tesla referral code - https://ts.la/richard11209

 

[David Brown]

On 13/03/2022 15:38, Rick C wrote:

On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:


Yes, sticking the intermediary would be a source of \"fun(tm)\",
regardless of OS. Any OS is going to be something like

1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port

More like,

1) Run terminal emulator on PC
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)

This is starting to come back to me now. The comms program on the PC
gives me a Linux shell, so I can do other things if I want, like
toggle the reset line on the target or even the power source.

You are describing quite a common way to arrange things.

I assume your \"terminal emulator\" on the PC is something like Putty or
Tera Term Pro. Both are fine for the purpose. In each case, you will
be using the terminal as an ssh client to log into the device.

It is possible to edit things directly on the Pi, using a text-based
editor such as nano. That works fine for small changes, but is less
than ideal for big development. (You can also use vim or emacs - I
personally have never liked either, but they are immensely powerful for
those that have invested the time and effort into learning them.)

And there are many other ways to transfer files to the Pi. The best
ways, for development purposes, is not transfer them at all - use
network filesystems of some kind. Use Windows shares on your PC and
mount the share on the Pi, or have both use a common file server. With
a *nix host system you can also use NFS or even sshfs - file share over
ssh. (This is less efficient than \"real\" network file systems, but very
easy to set up ad-hoc.) With a Windows development system, standard
Windows CIFS sharing is probably the easiest. And you can do it either
way - it works fine to use the Pi as the server and the PC as the client.

That way you have the same view of the files on your development PC and
the Pi, and you can skip the file transfer step.

 

[Rick C]

On Sunday, March 13, 2022 at 4:16:06 PM UTC-4, David Brown wrote:

On 13/03/2022 15:38, Rick C wrote:
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:


Yes, sticking the intermediary would be a source of \"fun(tm)\",
regardless of OS. Any OS is going to be something like

1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port

More like,

1) Run terminal emulator on PC
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)

This is starting to come back to me now. The comms program on the PC
gives me a Linux shell, so I can do other things if I want, like
toggle the reset line on the target or even the power source.

You are describing quite a common way to arrange things.

I assume your \"terminal emulator\" on the PC is something like Putty or
Tera Term Pro. Both are fine for the purpose. In each case, you will
be using the terminal as an ssh client to log into the device.

It is possible to edit things directly on the Pi, using a text-based
editor such as nano. That works fine for small changes, but is less
than ideal for big development. (You can also use vim or emacs - I
personally have never liked either, but they are immensely powerful for
those that have invested the time and effort into learning them.)

And there are many other ways to transfer files to the Pi. The best
ways, for development purposes, is not transfer them at all - use
network filesystems of some kind. Use Windows shares on your PC and
mount the share on the Pi, or have both use a common file server. With
a *nix host system you can also use NFS or even sshfs - file share over
ssh. (This is less efficient than \"real\" network file systems, but very
easy to set up ad-hoc.) With a Windows development system, standard
Windows CIFS sharing is probably the easiest. And you can do it either
way - it works fine to use the Pi as the server and the PC as the client.

That way you have the same view of the files on your development PC and
the Pi, and you can skip the file transfer step.

There\'s nothing on the rPi to edit. No files live on the rPi. The work is done on the PC talking to the compiler on the target. The rPi is there to connect the target serial port to the network. It\'s just a pipe. I could use anything for this that runs an OS, including another laptop. I have a netbook running Windows 7, but it is so under powered it can barely run a browser. Good thing I don\'t need to run a browser on it. I think the mail limitation is the limited memory actually.

The latest rPi is available with 8 GB I believe. Sounding more like a Windows machine every day. I should try booting the netbook under Linux. The screen is rather tiny for my eyes though, but using it remote the screen doesn\'t matter.

I\'m pretty sure I ran something on the rPi that was like a terminal emulator. Is there a way to easily connect the serial port on the rPi to the connection from the PC? I\'m trying to remember and it seems like there was a problem that had to do with someone capturing a special keystroke that didn\'t work out ok. I don\'t think it had to do with the target as that is strictly a TTY type connection. No need for special keys of any sort. Forth either responds, or you have to reboot the target. I don\'t recall.

--

Rick C.

--++ Get 1,000 miles of free Supercharging
--++ Tesla referral code - https://ts.la/richard11209

 

[David Brown]

On 13/03/2022 22:03, Rick C wrote:

On Sunday, March 13, 2022 at 4:16:06 PM UTC-4, David Brown wrote:
On 13/03/2022 15:38, Rick C wrote:
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:


Yes, sticking the intermediary would be a source of \"fun(tm)\",
regardless of OS. Any OS is going to be something like

1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port

More like,

1) Run terminal emulator on PC
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)

This is starting to come back to me now. The comms program on the PC
gives me a Linux shell, so I can do other things if I want, like
toggle the reset line on the target or even the power source.

You are describing quite a common way to arrange things.

I assume your \"terminal emulator\" on the PC is something like Putty or
Tera Term Pro. Both are fine for the purpose. In each case, you will
be using the terminal as an ssh client to log into the device.

It is possible to edit things directly on the Pi, using a text-based
editor such as nano. That works fine for small changes, but is less
than ideal for big development. (You can also use vim or emacs - I
personally have never liked either, but they are immensely powerful for
those that have invested the time and effort into learning them.)

And there are many other ways to transfer files to the Pi. The best
ways, for development purposes, is not transfer them at all - use
network filesystems of some kind. Use Windows shares on your PC and
mount the share on the Pi, or have both use a common file server. With
a *nix host system you can also use NFS or even sshfs - file share over
ssh. (This is less efficient than \"real\" network file systems, but very
easy to set up ad-hoc.) With a Windows development system, standard
Windows CIFS sharing is probably the easiest. And you can do it either
way - it works fine to use the Pi as the server and the PC as the client.

That way you have the same view of the files on your development PC and
the Pi, and you can skip the file transfer step.

There\'s nothing on the rPi to edit. No files live on the rPi. The
work is done on the PC talking to the compiler on the target.

OK. You didn\'t include any compilation stage in your description - a
lot of people use Python on the Pi.

The
rPi is there to connect the target serial port to the network. It\'s
just a pipe. I could use anything for this that runs an OS,
including another laptop. I have a netbook running Windows 7, but it
is so under powered it can barely run a browser. Good thing I don\'t
need to run a browser on it. I think the mail limitation is the
limited memory actually.

The latest rPi is available with 8 GB I believe. Sounding more like
a Windows machine every day. I should try booting the netbook under
Linux. The screen is rather tiny for my eyes though, but using it
remote the screen doesn\'t matter.

My standard source of laptops is left-overs from the sales folk or other
administration people. When they get too slow running Windows, I wipe
the disks and install Linux - the machines are faster than they were
when new. (If only Linux could make them as thin and light as modern
machines, and reverse the battery wear!)

I\'m pretty sure I ran something on the rPi that was like a terminal
emulator. Is there a way to easily connect the serial port on the
rPi to the connection from the PC? I\'m trying to remember and it
seems like there was a problem that had to do with someone capturing
a special keystroke that didn\'t work out ok. I don\'t think it had to
do with the target as that is strictly a TTY type connection. No
need for special keys of any sort. Forth either responds, or you
have to reboot the target. I don\'t recall.

I\'m not quite sure what you are trying to do, but these links might have
some ideas:

<https://unix.stackexchange.com/questions/96718/how-do-i-use-a-serial-port-on-linux-like-a-pipe-or-netcat>

<https://www.brainboxes.com/faq/how-to-use-netcat-to-pipe-serial-data-over-tcp>

<https://stackoverflow.com/questions/22624653/create-a-virtual-serial-port-connection-over-tcp>

<https://serverfault.com/questions/384741/forwarding-serial-port-over-network-and-back-to-serial-char-device-on-remote-hos>


If you want to run programs on the Pi and let them keep running after
you disconnect, an extremely useful program is \"screen\" (especially with
the \"byobu\" program that makes it a little nicer).

<https://en.wikipedia.org/wiki/GNU_Screen>

 

[Rick C]

On Sunday, March 13, 2022 at 7:17:16 PM UTC-4, David Brown wrote:

On 13/03/2022 22:03, Rick C wrote:
On Sunday, March 13, 2022 at 4:16:06 PM UTC-4, David Brown wrote:
On 13/03/2022 15:38, Rick C wrote:
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:


Yes, sticking the intermediary would be a source of \"fun(tm)\",
regardless of OS. Any OS is going to be something like

1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port

More like,

1) Run terminal emulator on PC
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)

This is starting to come back to me now. The comms program on the PC
gives me a Linux shell, so I can do other things if I want, like
toggle the reset line on the target or even the power source.

You are describing quite a common way to arrange things.

I assume your \"terminal emulator\" on the PC is something like Putty or
Tera Term Pro. Both are fine for the purpose. In each case, you will
be using the terminal as an ssh client to log into the device.

It is possible to edit things directly on the Pi, using a text-based
editor such as nano. That works fine for small changes, but is less
than ideal for big development. (You can also use vim or emacs - I
personally have never liked either, but they are immensely powerful for
those that have invested the time and effort into learning them.)

And there are many other ways to transfer files to the Pi. The best
ways, for development purposes, is not transfer them at all - use
network filesystems of some kind. Use Windows shares on your PC and
mount the share on the Pi, or have both use a common file server. With
a *nix host system you can also use NFS or even sshfs - file share over
ssh. (This is less efficient than \"real\" network file systems, but very
easy to set up ad-hoc.) With a Windows development system, standard
Windows CIFS sharing is probably the easiest. And you can do it either
way - it works fine to use the Pi as the server and the PC as the client.

That way you have the same view of the files on your development PC and
the Pi, and you can skip the file transfer step.

There\'s nothing on the rPi to edit. No files live on the rPi. The
work is done on the PC talking to the compiler on the target.
OK. You didn\'t include any compilation stage in your description - a
lot of people use Python on the Pi.

Yes, I did. I said to send it to the target. The target compiles it. I\'m sure I mentioned that the compiler is in the flash of the target. That\'s why I think it has 16kB of flash. 8kB is a bit cramped for a Forth compiler although many exist in that size.

The
rPi is there to connect the target serial port to the network. It\'s
just a pipe. I could use anything for this that runs an OS,
including another laptop. I have a netbook running Windows 7, but it
is so under powered it can barely run a browser. Good thing I don\'t
need to run a browser on it. I think the mail limitation is the
limited memory actually.

The latest rPi is available with 8 GB I believe. Sounding more like
a Windows machine every day. I should try booting the netbook under
Linux. The screen is rather tiny for my eyes though, but using it
remote the screen doesn\'t matter.

My standard source of laptops is left-overs from the sales folk or other
administration people.

I am the admin and sales force. I am done with a laptop when it no longer works.

When they get too slow running Windows, I wipe
the disks and install Linux - the machines are faster than they were
when new. (If only Linux could make them as thin and light as modern
machines, and reverse the battery wear!)
I\'m pretty sure I ran something on the rPi that was like a terminal
emulator. Is there a way to easily connect the serial port on the
rPi to the connection from the PC? I\'m trying to remember and it
seems like there was a problem that had to do with someone capturing
a special keystroke that didn\'t work out ok. I don\'t think it had to
do with the target as that is strictly a TTY type connection. No
need for special keys of any sort. Forth either responds, or you
have to reboot the target. I don\'t recall.

I\'m not quite sure what you are trying to do, but these links might have
some ideas:

https://unix.stackexchange.com/questions/96718/how-do-i-use-a-serial-port-on-linux-like-a-pipe-or-netcat

https://www.brainboxes.com/faq/how-to-use-netcat-to-pipe-serial-data-over-tcp

https://stackoverflow.com/questions/22624653/create-a-virtual-serial-port-connection-over-tcp

https://serverfault.com/questions/384741/forwarding-serial-port-over-network-and-back-to-serial-char-device-on-remote-hos


If you want to run programs on the Pi and let them keep running after
you disconnect, an extremely useful program is \"screen\" (especially with
the \"byobu\" program that makes it a little nicer).

https://en.wikipedia.org/wiki/GNU_Screen

What part of what I\'m doing is not clear? I wish to establish the equivalent of a serial port connection from my PC to the target that is physically connected to an rPi. That\'s it. The terminal emulator on the PC does everything I need, typing to the command line on the target, sending a file through the pipe as if I had done a cat to stdio or whatever the command would be under Linux. I have used terminal emulators on the PC for that. As someone mentioned, I think it used SSH to get to the rPi, I just don\'t recall the details of what was happening on the rPi. It may have been running minicom. I recall having issues with the rPi part that connected the incoming connection from the PC to the serial port, but I don\'t recall the details. This was some years ago.

I want the terminal emulator program on the PC to work as if the target was connected to the PC. As far as I\'m concerned, the rPi can be invisible... other than wanting a way to boot the target, and by boot the target, I mean cycle power to the USB port powering it. I never found a good way to do that. I tried to find a USB hub with that capability, but the ones I found were either a bit expensive or didn\'t really do what I wanted.

I would also like to be able to do this remotely as in across the Internet. But that\'s a whole \'nother thing. I\'ve never figured out how to get past the router. I used to play with that stuff, but it never seemed to work reliably. Especially using dedicated IP addresses on different routers. The durn thing would mess with me and give me an address I didn\'t ask for.

Am I correct in thinking on a Linux command line the ampersand spawns the command off as a new process and returns for a new command? The explanation for this talked about Bash, but is this true for other command interpreters as well?

--

Rick C.

-+-- Get 1,000 miles of free Supercharging
-+-- Tesla referral code - https://ts.la/richard11209

 

[Dan Purgert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Rick C wrote:

On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:
Rick C wrote:
That sounds like what I did, except there\'s nothing to run on the rPi
other than connecting the link from the PC to the serial port to the
target. Forth runs on the target. I like Codewright for an editor,
OH -- okay so then the corrected approach would be to ssh to the pi,
then launch whatever serial modem application (e.g. minicom) is
necessary to talk to the DUT on /dev/ttyS0 .

So running a SSH program on the PC would give me a console that is
actually the minicom on the rPi? I should try to resurrect this as I

Not really. Things are gonna get a little ugly here, as I haven\'t used
Windows since WindowsXP ... so ... bear with me.

For the sake of discussion / explanation:

DUT = Device Under Test
SerialHost = The machine with a serial port, connected to DUT
PC = Other PC not connected at all to DUT


In an all-windows setup, your workflow is \"probably\" something like this
(or, well, close enough for the sake of discussion)

1. On PC, open up RemoteDesktop, and connect to SerialHost
2. On SerialHost, open up HyperTerm (whatever) and open connection to
COM0, or whatever serial port the DUT is connected to.
3. Tell DUT to start executing your test suite


Since you\'re using an rPi running linux however, your workflow will be
more like this:

1. On PC, open up PowerShell, PuTTY or (if linux) your terminal
emulator; and SSH into SerialHost
2. On SerialHost, open up minicom, and connect to /dev/ttyS0, or
whatever serial port the DUT is connected to
3. Tell the DUT to start executing the test suite

may need to use it again. I am living in Puerto Rico and it would be
nice to operate a target in the mainland. Other than the need to
reset the target when things get really fouled up. That\'s why I
wanted a USB hub that could cut power to individual plugs.. or even
the whole hub. Doesn\'t matter. I just need it to be controllable
from the rPi so it can reboot the target. I guess in theory I could
tie an output from the rPi to the reset line on the target, but there
are times when a power cycle is useful too.

Indeed. Offhand I\'m not aware of any USB hubs where you can cycle the
power like that. I\'d probably just break out VUSB from the cable, and
control a FET or something via the Pi\'s GPIO pins.

[...]
Yes, sticking the intermediary would be a source of \"fun(tm)\",
regardless of OS. Any OS is going to be something like

1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port

More like,

1) Run terminal emulator on PC
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)

Fair enough -- I seemed to pick up at about your step3.

One thing to keep in mind, you\'re not very likely to send straight from
PC to DUT via your rPi. Rather you\'ll have to do it in two stages:

4.1 -> Transfer new payload from PC to rPi with SFTP (or other comms
program. SFTP is just kind of \"dead simple\" because you\'re
already using ssh to access the rPi in the first place.
4.2 -> Using an appropriate serial protocol, transfer the file from
the rPi to the DUT.

This is starting to come back to me now. The comms program on the PC
gives me a Linux shell, so I can do other things if I want, like
toggle the reset line on the target or even the power source.

[...]
What sort of things are you interested in doing in FPGAs?

Mostly just learning about them. I have no true use for the things
right now (hence devboard thing I have); but they seem to be a decent
tool to have in the toolbox ... one of these days, anyway.


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIuj3oACgkQbWVw5Uzn
KGBHsw/+K4hX8A3BYPP+s/1CKtHP6PeHKi1wZ9FdVheybBv466O1Y2C5WqzqftbJ
61f3e8EQ9p5EWsa/x00ADW4B4RX9qxCk/82rsm7dmmUDPaYFyj84EBmojd12OHqs
GeKqtfa6jMnxdjquZQFUjCae4ab86gb1VcMoxBMNraDJsRP0s1oac6P+xiASU6DN
udkPh2VP5wEIUqLhCDeYdrbcVfJE7jys6mMmwsTVKH+GK+QREHYNEuPohPzcIS8/
x5sszCBlG+m3n/qFqXDfOT6SJlfsRdy1HJCQG0vzD3lG0HdNZapSiHRF9n9y8wIR
WQGIB4K1qQTfD3jpnJ6F4aRjRFEImnjeLrzLO6nr1LtQrMwQGfQy6CljH4+fhs04
Q0vVSSH8qpZ8L73Ld6fhkTYvDmVxMX3BAJQjuugjNGRpHlfzYKanoKoaqppAI6GL
gIUmZaRAYQ+FhSj98dqmNCzUWfkDqd5UbXWtO+bi+lN8DT9IBQT0E7rARTX5mHT7
cgzJtlO/dJM23or6/Sg2vA0hRNQnMMGzj0gb8Mpti0RWuqdsvnKh9RSl/Tnd6XZc
ffpMBKVLc2rNYrfSsuwp1KLbUYdoE1cO+YOmZWC77Yvhvj819KDuKxgbhfK5+83r
Ue6/XDJnhZdfSA9+vnhEkGMvsh2jSiHlCDLRjzmK/vNjODwx5cw=
=f9zj
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

 

[David Brown]

On 14/03/2022 01:12, Rick C wrote:

On Sunday, March 13, 2022 at 7:17:16 PM UTC-4, David Brown wrote:
On 13/03/2022 22:03, Rick C wrote:
On Sunday, March 13, 2022 at 4:16:06 PM UTC-4, David Brown wrote:
On 13/03/2022 15:38, Rick C wrote:
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:


Yes, sticking the intermediary would be a source of \"fun(tm)\",
regardless of OS. Any OS is going to be something like

1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port

More like,

1) Run terminal emulator on PC
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)

This is starting to come back to me now. The comms program on the PC
gives me a Linux shell, so I can do other things if I want, like
toggle the reset line on the target or even the power source.

You are describing quite a common way to arrange things.

I assume your \"terminal emulator\" on the PC is something like Putty or
Tera Term Pro. Both are fine for the purpose. In each case, you will
be using the terminal as an ssh client to log into the device.

It is possible to edit things directly on the Pi, using a text-based
editor such as nano. That works fine for small changes, but is less
than ideal for big development. (You can also use vim or emacs - I
personally have never liked either, but they are immensely powerful for
those that have invested the time and effort into learning them.)

And there are many other ways to transfer files to the Pi. The best
ways, for development purposes, is not transfer them at all - use
network filesystems of some kind. Use Windows shares on your PC and
mount the share on the Pi, or have both use a common file server. With
a *nix host system you can also use NFS or even sshfs - file share over
ssh. (This is less efficient than \"real\" network file systems, but very
easy to set up ad-hoc.) With a Windows development system, standard
Windows CIFS sharing is probably the easiest. And you can do it either
way - it works fine to use the Pi as the server and the PC as the client.

That way you have the same view of the files on your development PC and
the Pi, and you can skip the file transfer step.

There\'s nothing on the rPi to edit. No files live on the rPi. The
work is done on the PC talking to the compiler on the target.
OK. You didn\'t include any compilation stage in your description - a
lot of people use Python on the Pi.

Yes, I did. I said to send it to the target. The target compiles it. I\'m sure I mentioned that the compiler is in the flash of the target. That\'s why I think it has 16kB of flash. 8kB is a bit cramped for a Forth compiler although many exist in that size.

OK, I see what you are getting at now.

Is there no hosted Forth cross-compiler for your target?

The
rPi is there to connect the target serial port to the network. It\'s
just a pipe. I could use anything for this that runs an OS,
including another laptop. I have a netbook running Windows 7, but it
is so under powered it can barely run a browser. Good thing I don\'t
need to run a browser on it. I think the mail limitation is the
limited memory actually.

The latest rPi is available with 8 GB I believe. Sounding more like
a Windows machine every day. I should try booting the netbook under
Linux. The screen is rather tiny for my eyes though, but using it
remote the screen doesn\'t matter.

My standard source of laptops is left-overs from the sales folk or other
administration people.

I am the admin and sales force. I am done with a laptop when it no longer works.


When they get too slow running Windows, I wipe
the disks and install Linux - the machines are faster than they were
when new. (If only Linux could make them as thin and light as modern
machines, and reverse the battery wear!)
I\'m pretty sure I ran something on the rPi that was like a terminal
emulator. Is there a way to easily connect the serial port on the
rPi to the connection from the PC? I\'m trying to remember and it
seems like there was a problem that had to do with someone capturing
a special keystroke that didn\'t work out ok. I don\'t think it had to
do with the target as that is strictly a TTY type connection. No
need for special keys of any sort. Forth either responds, or you
have to reboot the target. I don\'t recall.

I\'m not quite sure what you are trying to do, but these links might have
some ideas:

https://unix.stackexchange.com/questions/96718/how-do-i-use-a-serial-port-on-linux-like-a-pipe-or-netcat

https://www.brainboxes.com/faq/how-to-use-netcat-to-pipe-serial-data-over-tcp

https://stackoverflow.com/questions/22624653/create-a-virtual-serial-port-connection-over-tcp

https://serverfault.com/questions/384741/forwarding-serial-port-over-network-and-back-to-serial-char-device-on-remote-hos


If you want to run programs on the Pi and let them keep running after
you disconnect, an extremely useful program is \"screen\" (especially with
the \"byobu\" program that makes it a little nicer).

https://en.wikipedia.org/wiki/GNU_Screen



What part of what I\'m doing is not clear? I wish to establish the
equivalent of a serial port connection from my PC to the target that
is physically connected to an rPi. That\'s it.

Your target is connected to the serial port on the Pi. The Pi is
connected to your PC by network (I presume). Is that not correct? If
it is, then the links I gave you could be useful. You make a
serial-to-tcpip connection on the Pi, then from the PC you can use
telnet (standard Windows application, or something like Putty or Tera
Term Pro) to connect to the Pi. What you type in the terminal, goes out
on the serial port, and vice versa. Downloading a file to the target is
just netcat, or whatever equivalent there is on Windows (there\'s bound
to be a port of netcat).

The terminal emulator
on the PC does everything I need, typing to the command line on the
target, sending a file through the pipe as if I had done a cat to
stdio or whatever the command would be under Linux. I have used
terminal emulators on the PC for that. As someone mentioned, I think
it used SSH to get to the rPi, I just don\'t recall the details of
what was happening on the rPi. It may have been running minicom. I
recall having issues with the rPi part that connected the incoming
connection from the PC to the serial port, but I don\'t recall the
details. This was some years ago.

I want the terminal emulator program on the PC to work as if the
target was connected to the PC. As far as I\'m concerned, the rPi can
be invisible... other than wanting a way to boot the target, and by
boot the target, I mean cycle power to the USB port powering it. I
never found a good way to do that. I tried to find a USB hub with
that capability, but the ones I found were either a bit expensive or
didn\'t really do what I wanted.

I would also like to be able to do this remotely as in across the
Internet. But that\'s a whole \'nother thing. I\'ve never figured out
how to get past the router. I used to play with that stuff, but it
never seemed to work reliably. Especially using dedicated IP
addresses on different routers. The durn thing would mess with me
and give me an address I didn\'t ask for.

Am I correct in thinking on a Linux command line the ampersand spawns
the command off as a new process and returns for a new command? The
explanation for this talked about Bash, but is this true for other
command interpreters as well?

Yes, that works on all shells for *nix - at least, all standard ones.
There\'s rarely much reason to use something other than bash, however,
unless you have a minimal Linux system (and then you use Busybox\'s shell).

 

[Rick C]

On Sunday, March 13, 2022 at 8:41:57 PM UTC-4, Dan Purgert wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Rick C wrote:
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:
Rick C wrote:
That sounds like what I did, except there\'s nothing to run on the rPi
other than connecting the link from the PC to the serial port to the
target. Forth runs on the target. I like Codewright for an editor,
OH -- okay so then the corrected approach would be to ssh to the pi,
then launch whatever serial modem application (e.g. minicom) is
necessary to talk to the DUT on /dev/ttyS0 .

So running a SSH program on the PC would give me a console that is
actually the minicom on the rPi? I should try to resurrect this as I
Not really. Things are gonna get a little ugly here, as I haven\'t used
Windows since WindowsXP ... so ... bear with me.

For the sake of discussion / explanation:

DUT = Device Under Test
SerialHost = The machine with a serial port, connected to DUT
PC = Other PC not connected at all to DUT

Not sure why you need to rename everything, but ok.

DUT = Target
SerialHost = rPi
PC = PC

In an all-windows setup, your workflow is \"probably\" something like this
(or, well, close enough for the sake of discussion)

1. On PC, open up RemoteDesktop, and connect to SerialHost
2. On SerialHost, open up HyperTerm (whatever) and open connection to
COM0, or whatever serial port the DUT is connected to.
3. Tell DUT to start executing your test suite

Ok

Since you\'re using an rPi running linux however, your workflow will be
more like this:

1. On PC, open up PowerShell, PuTTY or (if linux) your terminal
emulator; and SSH into SerialHost
2. On SerialHost, open up minicom, and connect to /dev/ttyS0, or
whatever serial port the DUT is connected to

2.5) Send file from PC to DUT using a feature in Putty. rPi simply transfers the bytes from the file the same as if you typed them.

3. Tell the DUT to start executing the test suite

may need to use it again. I am living in Puerto Rico and it would be
nice to operate a target in the mainland. Other than the need to
reset the target when things get really fouled up. That\'s why I
wanted a USB hub that could cut power to individual plugs.. or even
the whole hub. Doesn\'t matter. I just need it to be controllable
from the rPi so it can reboot the target. I guess in theory I could
tie an output from the rPi to the reset line on the target, but there
are times when a power cycle is useful too.
Indeed. Offhand I\'m not aware of any USB hubs where you can cycle the
power like that. I\'d probably just break out VUSB from the cable, and
control a FET or something via the Pi\'s GPIO pins.

If I\'m doing that, I can just use an rPi I/O pin to toggle the reset on the target... I mean DUT. I\'d prefer to toggle power, but it\'s not essential. It\'s just to get out of an infinite loop and restore the state of the DUT>

[...]
Yes, sticking the intermediary would be a source of \"fun(tm)\",
regardless of OS. Any OS is going to be something like

1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port

More like,

1) Run terminal emulator on PC
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)
Fair enough -- I seemed to pick up at about your step3.

One thing to keep in mind, you\'re not very likely to send straight from
PC to DUT via your rPi. Rather you\'ll have to do it in two stages:

4.1 -> Transfer new payload from PC to rPi with SFTP (or other comms
program. SFTP is just kind of \"dead simple\" because you\'re
already using ssh to access the rPi in the first place.
4.2 -> Using an appropriate serial protocol, transfer the file from
the rPi to the DUT.

Protocol? You aren\'t grasping the situation. From the rPi the file would would be sent by

cat file.f >blah.blah/ttys0 or whatever the syntax is to simply send the bytes out the serial port. But that\'s not important because the file will never be on the rPi. It\'s sent from the PC directly through the connection to the terminal. The same putty or other terminal program will let me dump the file as if it were a text stream. That\'s how you compile a Forth program on a target. Just type it into the console. Of course, a Forth on the PC would have a command to load a file, but the target has no file system. It\'s an MCU with 16kB of flash and probably about 2kB of RAM.

This is starting to come back to me now. The comms program on the PC
gives me a Linux shell, so I can do other things if I want, like
toggle the reset line on the target or even the power source.
[...]
What sort of things are you interested in doing in FPGAs?
Mostly just learning about them. I have no true use for the things
right now (hence devboard thing I have); but they seem to be a decent
tool to have in the toolbox ... one of these days, anyway.

Yeah, people mostly don\'t get FPGAs. Often people think they are only large, power hungry beasts, only useful for massive number crunching tasks or insanely parallel problems. The last 20 years I\'ve used nearly nothing but, small, low power, inexpensive FPGAs that are easy to work with in 100 pin QFP packages.

--

Rick C.

-+-+ Get 1,000 miles of free Supercharging
-+-+ Tesla referral code - https://ts.la/richard11209

 

[Rick C]

On Sunday, March 13, 2022 at 8:42:20 PM UTC-4, David Brown wrote:

On 14/03/2022 01:12, Rick C wrote:
On Sunday, March 13, 2022 at 7:17:16 PM UTC-4, David Brown wrote:
On 13/03/2022 22:03, Rick C wrote:
On Sunday, March 13, 2022 at 4:16:06 PM UTC-4, David Brown wrote:
On 13/03/2022 15:38, Rick C wrote:
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:


Yes, sticking the intermediary would be a source of \"fun(tm)\",
regardless of OS. Any OS is going to be something like

1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port

More like,

1) Run terminal emulator on PC
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)

This is starting to come back to me now. The comms program on the PC
gives me a Linux shell, so I can do other things if I want, like
toggle the reset line on the target or even the power source.

You are describing quite a common way to arrange things.

I assume your \"terminal emulator\" on the PC is something like Putty or
Tera Term Pro. Both are fine for the purpose. In each case, you will
be using the terminal as an ssh client to log into the device.

It is possible to edit things directly on the Pi, using a text-based
editor such as nano. That works fine for small changes, but is less
than ideal for big development. (You can also use vim or emacs - I
personally have never liked either, but they are immensely powerful for
those that have invested the time and effort into learning them.)

And there are many other ways to transfer files to the Pi. The best
ways, for development purposes, is not transfer them at all - use
network filesystems of some kind. Use Windows shares on your PC and
mount the share on the Pi, or have both use a common file server. With
a *nix host system you can also use NFS or even sshfs - file share over
ssh. (This is less efficient than \"real\" network file systems, but very
easy to set up ad-hoc.) With a Windows development system, standard
Windows CIFS sharing is probably the easiest. And you can do it either
way - it works fine to use the Pi as the server and the PC as the client.

That way you have the same view of the files on your development PC and
the Pi, and you can skip the file transfer step.

There\'s nothing on the rPi to edit. No files live on the rPi. The
work is done on the PC talking to the compiler on the target.
OK. You didn\'t include any compilation stage in your description - a
lot of people use Python on the Pi.

Yes, I did. I said to send it to the target. The target compiles it. I\'m sure I mentioned that the compiler is in the flash of the target. That\'s why I think it has 16kB of flash. 8kB is a bit cramped for a Forth compiler although many exist in that size.

OK, I see what you are getting at now.

Is there no hosted Forth cross-compiler for your target?

That\'s a funny segue. At first, I thought you had it, but then you talk like it is preferred to have the compiler on a host.

I\'m sure there are Forth cross compilers for many MCUs including the one I was using (don\'t recall if it was an MSP430 or a TI ARM), but that is less preferable. You are thinking of the complexities of having to describe the memory map, get addresses for the I/Os and the many other tasks you have to do to use a C cross-compiler from a host along with the specialized programming cable. What a bother!

All that is needed for Forth is a properly configured kernel, a means to program it into the on board flash, and from then on all you need is a serial port. The Forth has incorporated the means to compiler your source code and if needed, burn it into Flash. Then you have a stand alone application. No need for fancy debuggers or programming (other than to load the kernel).

The
rPi is there to connect the target serial port to the network. It\'s
just a pipe. I could use anything for this that runs an OS,
including another laptop. I have a netbook running Windows 7, but it
is so under powered it can barely run a browser. Good thing I don\'t
need to run a browser on it. I think the mail limitation is the
limited memory actually.

The latest rPi is available with 8 GB I believe. Sounding more like
a Windows machine every day. I should try booting the netbook under
Linux. The screen is rather tiny for my eyes though, but using it
remote the screen doesn\'t matter.

My standard source of laptops is left-overs from the sales folk or other
administration people.

I am the admin and sales force. I am done with a laptop when it no longer works.


When they get too slow running Windows, I wipe
the disks and install Linux - the machines are faster than they were
when new. (If only Linux could make them as thin and light as modern
machines, and reverse the battery wear!)
I\'m pretty sure I ran something on the rPi that was like a terminal
emulator. Is there a way to easily connect the serial port on the
rPi to the connection from the PC? I\'m trying to remember and it
seems like there was a problem that had to do with someone capturing
a special keystroke that didn\'t work out ok. I don\'t think it had to
do with the target as that is strictly a TTY type connection. No
need for special keys of any sort. Forth either responds, or you
have to reboot the target. I don\'t recall.

I\'m not quite sure what you are trying to do, but these links might have
some ideas:

https://unix.stackexchange.com/questions/96718/how-do-i-use-a-serial-port-on-linux-like-a-pipe-or-netcat

https://www.brainboxes.com/faq/how-to-use-netcat-to-pipe-serial-data-over-tcp

https://stackoverflow.com/questions/22624653/create-a-virtual-serial-port-connection-over-tcp

https://serverfault.com/questions/384741/forwarding-serial-port-over-network-and-back-to-serial-char-device-on-remote-hos


If you want to run programs on the Pi and let them keep running after
you disconnect, an extremely useful program is \"screen\" (especially with
the \"byobu\" program that makes it a little nicer).

https://en.wikipedia.org/wiki/GNU_Screen



What part of what I\'m doing is not clear? I wish to establish the
equivalent of a serial port connection from my PC to the target that
is physically connected to an rPi. That\'s it.
Your target is connected to the serial port on the Pi. The Pi is
connected to your PC by network (I presume). Is that not correct?

Yes

If
it is, then the links I gave you could be useful. You make a
serial-to-tcpip connection on the Pi, then from the PC you can use
telnet (standard Windows application, or something like Putty or Tera
Term Pro) to connect to the Pi. What you type in the terminal, goes out
on the serial port, and vice versa. Downloading a file to the target is
just netcat, or whatever equivalent there is on Windows (there\'s bound
to be a port of netcat).

No, it\'s just a feature in the terminal emulator.

The terminal emulator
on the PC does everything I need, typing to the command line on the
target, sending a file through the pipe as if I had done a cat to
stdio or whatever the command would be under Linux. I have used
terminal emulators on the PC for that. As someone mentioned, I think
it used SSH to get to the rPi, I just don\'t recall the details of
what was happening on the rPi. It may have been running minicom. I
recall having issues with the rPi part that connected the incoming
connection from the PC to the serial port, but I don\'t recall the
details. This was some years ago.

I want the terminal emulator program on the PC to work as if the
target was connected to the PC. As far as I\'m concerned, the rPi can
be invisible... other than wanting a way to boot the target, and by
boot the target, I mean cycle power to the USB port powering it. I
never found a good way to do that. I tried to find a USB hub with
that capability, but the ones I found were either a bit expensive or
didn\'t really do what I wanted.

I would also like to be able to do this remotely as in across the
Internet. But that\'s a whole \'nother thing. I\'ve never figured out
how to get past the router. I used to play with that stuff, but it
never seemed to work reliably. Especially using dedicated IP
addresses on different routers. The durn thing would mess with me
and give me an address I didn\'t ask for.

Am I correct in thinking on a Linux command line the ampersand spawns
the command off as a new process and returns for a new command? The
explanation for this talked about Bash, but is this true for other
command interpreters as well?

Yes, that works on all shells for *nix - at least, all standard ones.
There\'s rarely much reason to use something other than bash, however,
unless you have a minimal Linux system (and then you use Busybox\'s shell)..

What terminates the process that was spun off? When it completes and would have otherwise returned to the command line?

I\'m surprised I don\'t remember that. Maybe I didn\'t use that feature before.

I looked for the board today and didn\'t find it. I found the box it came in with some serial port cables and other components. I think I put it in a nice box as I was not going to work with it for a while. But I can\'t recall what it looked like, so I can\'t find it. I need to do some other things the next few days and then will be heading back to Puerto Rico. Maybe I\'ll play with this next week.

The only reason I\'m thinking of this is because I want to work on some software that runs on a board I don\'t want to take to Puerto Rico. I\'m thinking I can do the same thing from Puerto Rico, with the target in the mainland.. But getting through the router, etc. is a whole \'nother animal.

When you check a web site to give you your IP address, that\'s the IP of the router, right? The cable modem is transparent for that?

--

Rick C.

-++- Get 1,000 miles of free Supercharging
-++- Tesla referral code - https://ts.la/richard11209

 

[Ed Lee]

On Sunday, March 13, 2022 at 9:55:06 PM UTC-7, gnuarm.del...@gmail.com wrote:

On Sunday, March 13, 2022 at 8:42:20 PM UTC-4, David Brown wrote:
....
Am I correct in thinking on a Linux command line the ampersand spawns
the command off as a new process and returns for a new command? The
explanation for this talked about Bash, but is this true for other
command interpreters as well?

Yes, that works on all shells for *nix - at least, all standard ones.
There\'s rarely much reason to use something other than bash, however,
unless you have a minimal Linux system (and then you use Busybox\'s shell).
What terminates the process that was spun off? When it completes and would have otherwise returned to the command line?

The shell \"&\" is just implementing the fork(), exec() and wait() system calls. You can do it from any user program as well. If you run with \"nohup\", the new process ignore the SIGHUP (hang up signal). The child process will terminate by itself, whether the parent process wait for it or not.

 

[Dan Purgert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Rick C wrote:

On Sunday, March 13, 2022 at 8:41:57 PM UTC-4, Dan Purgert wrote:
Rick C wrote:
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:
Rick C wrote:
That sounds like what I did, except there\'s nothing to run on the rPi
other than connecting the link from the PC to the serial port to the
target. Forth runs on the target. I like Codewright for an editor,
OH -- okay so then the corrected approach would be to ssh to the pi,
then launch whatever serial modem application (e.g. minicom) is
necessary to talk to the DUT on /dev/ttyS0 .

So running a SSH program on the PC would give me a console that is
actually the minicom on the rPi? I should try to resurrect this as I
Not really. Things are gonna get a little ugly here, as I haven\'t used
Windows since WindowsXP ... so ... bear with me.

For the sake of discussion / explanation:

DUT = Device Under Test
SerialHost = The machine with a serial port, connected to DUT
PC = Other PC not connected at all to DUT

Not sure why you need to rename everything, but ok.

It was merely for the purposes of keeping the three devices \"generic\" in
two scenarios; without getting bogged down too much with specific
devices or not (or whether they could run a given OS, etc).

However, it was written before I had seen your conversation with David
Brown, after reading which this morning, the workflows I presented last
night were not what you were actually describing / attempting to
accomplish.

[...]
Since you\'re using an rPi running linux however, your workflow will be
more like this:

1. On PC, open up PowerShell, PuTTY or (if linux) your terminal
emulator; and SSH into SerialHost
2. On SerialHost, open up minicom, and connect to /dev/ttyS0, or
whatever serial port the DUT is connected to

2.5) Send file from PC to DUT using a feature in Putty. rPi simply
transfers the bytes from the file the same as if you typed them.

I\'ve used PuTTY a bit as an interactive ssh and serial port client, but
I\'m not aware of it being able to handle things non-interactively.

Is it part of the supporting suite of applications (psftp/pscp/plink/
etc)? If so, I admittedly haven\'t used them all that much; but will
happily RTFM if you can point me in the right direction.

[...]
tie an output from the rPi to the reset line on the target, but there
are times when a power cycle is useful too.
Indeed. Offhand I\'m not aware of any USB hubs where you can cycle the
power like that. I\'d probably just break out VUSB from the cable, and
control a FET or something via the Pi\'s GPIO pins.

If I\'m doing that, I can just use an rPi I/O pin to toggle the reset
on the target... I mean DUT. I\'d prefer to toggle power, but it\'s not
essential. It\'s just to get out of an infinite loop and restore the
state of the DUT

I was specifically commenting on \"there are times where a power cycle is
useful\". I should\'ve done better trimming

[...]
4.2 -> Using an appropriate serial protocol, transfer the file from
the rPi to the DUT.

Protocol? You aren\'t grasping the situation. From the rPi the file
would would be sent by cat file.f >blah.blah/ttys0 or whatever the
syntax is to simply send the bytes out the serial port. But that\'s
not important because the file will never be on the rPi. It\'s sent
from the PC directly through the connection to the terminal. The same
putty or other terminal program will let me dump the file as if it
were a text stream.

Indeed -- I was under the impression that you were sending actual files
to the DUT (e.g. using zmodem). I see now that you only intend to send
the file contents.

I think I asked already -- but which feature of PuTTY are you referring
to? The description isn\'t ringing any bells (well, other than
copy/paste the file content into your interactive session).

[...]
What sort of things are you interested in doing in FPGAs?
Mostly just learning about them. I have no true use for the things
right now (hence devboard thing I have); but they seem to be a decent
tool to have in the toolbox ... one of these days, anyway.

Yeah, people mostly don\'t get FPGAs. Often people think they are only
large, power hungry beasts, only useful for massive number crunching
tasks or insanely parallel problems. The last 20 years I\'ve used
nearly nothing but, small, low power, inexpensive FPGAs that are easy
to work with in 100 pin QFP packages.

I\'d consider 100 pins to be on the large side . I mostly play around
with 32-or-fewer pin packages. FPGA (and/or their older PLD/whatever
brethren) seem like they\'re going to be required for a few of my
long-term \"big-project\" ideas (that I\'ll probably never get around to,
but oh well).



-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIvNmYACgkQbWVw5Uzn
KGBz6hAAuAUnqe0qxWv010QpT1LW6/YcoVuK7VAjyWyZuwu+w/1y67PykiNnl3Xb
mprKvuPM4pKk8UwSPodXTA0snJCxtVrgeFllD1nBXC9uEHmE1NGunw5Bnwz3EnGp
4064LBDXToNvoLXE/2+K0dOEMskXOzImeJKgq8HJFfwWNsP6l3TqP/vES8q5DbzC
xIytDKIl5xbyWWNkSD+Atpn5e6OwLOnfEuGZo1VFJv+4uIpP+aWTJJ0exU33Kzqt
eAzg00J2tIFPb6IwxKdamhZ3HGeNa+gdhKrw/zn5+D9Q6d3NV4NSM+estj6KUlUH
vrO3I9X4UxCpgtbRhB/PhK0lla14RaJfjpkx8lkro6roGpV+EPYv6oFGzjP3yXZs
pV1UA20JF9Nai4lAUq+F8HgYeTSGeL+/8+3kaT1dV4es/KdW47E9NzV0jf+rrrkB
pq8s6dhaRDFm3okWVT1BUlc82A0kzcK1PagjhPWQMPKATuLMVNLbcnzvHM6oxUym
fGsJaRQvLepQUG7XEmhPAO8p+BfV5Ou/GyYQ+lJT3yOduEV+8te1e5zd4e1Q9Z8r
iEa/CVdihculDbBEnhPBjHafv9oytceYdYeZP7tgVVM201llwLR9WlGESOH6Qsyu
Vb96ielFCvASPgF5Bo4J+OTejBPRThQ9UgJG0X86qcG9HXbEvoA=
=KeK6
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860