On 01/03/2019 00:27, gnuarm.deletethisbit@gmail.com wrote:
> On Thursday, February 28, 2019 at 2:09:25 AM UTC-6, David Brown
> wrote:
>> On 28/02/2019 02:49, gnuarm.deletethisbit@gmail.com wrote:
>>> On Wednesday, February 27, 2019 at 6:23:56 PM UTC-6, David Brown
>>> wrote:
>>>> On 28/02/2019 00:41, gnuarm.deletethisbit@gmail.com wrote:
>>>>> On Tuesday, February 26, 2019 at 3:42:58 PM UTC-6,
>>>>> gnuarm.del...@gmail.com wrote:
>>>>>> I am working on a test fixture that uses an RS-232 port for
>>>>>> control.  I travel a lot and don't want to have to drag the
>>>>>> test fixture around with me.
>>>>>> 
>>>>>> Some time ago I was working with an eval board via serial
>>>>>> port and used an rPi (Raspberry Pi) to put the serial port
>>>>>> on the network and work from another room.  That worked
>>>>>> pretty well.  I didn't have a means of rebooting the target
>>>>>> however.  This time I will add a capability of removing
>>>>>> power from the test fixture to provide a reset.
>>>>>> 
>>>>>> What I didn't try before was using this rig over the
>>>>>> Internet.  I'm not even sure where to being digging into
>>>>>> how to do that.  I expect it is not complicated to make the
>>>>>> serial port accessible through the router and modem, but
>>>>>> I'm not sure where to begin.  Or does the router even get
>>>>>> involved and is just transparent and I only need the local
>>>>>> IP address?  None of the sources I've found address the
>>>>>> issue of getting through the router, etc.
>>>>>> 
>>>>>> Essentially I want the serial port on the rPi to become a
>>>>>> virtual serial port on a PC located anywhere else on the
>>>>>> planet.  :)
>>>>>> 
>>>>>> Rick C.
>>>>> 
>>>>> Just to make things more clear...
>>>>> 
>>>>> Conventional Use of Test Fixture
>>>>> 
>>>>> +---------+        +--------+ | +-----+ |        |        | |
>>>>> | UUT | |        |   PC   | | +-----+ | RS-232 |        | |
>>>>> Test   |<======>|  Cntl  | | Fixture |        |  Prog  | 
>>>>> +---------+        +--------+
>>>>> 
>>>>> 
>>>>> Desired use of Test Fixture
>>>>> 
>>>>> +---------+        +--------+ | +-----+ |        |        |
>>>>> /-----\ | | UUT | |        |   rPi  |     (       ) | +-----+
>>>>> | RS-232 |        |     ( Inter ) |  Test   |<======>|
>>>>> |<===>(  net  ) | Fixture |        |        |     (       ) 
>>>>> +---------+        +--------+      \-----/
>>>>> 
>>>>> +--------+ |        |      /-----\ |   PC   |     (       ) |
>>>>> |     ( Inter ) |  Cntl  |<===>(  net  ) |  Prog  |     (
>>>>> ) +--------+      \-----/
>>>>> 
>>>>> I hope this clears up any confusion.
>>>>> 
>>>>> Rick C.
>>>>> 
>>>> 
>>>> This clears up a few points.  But there are some questions that
>>>> could make this easier.
>>>> 
>>>> 1. Is the PC running Windows or Linux?
>>>> 
>>>> 2. Are you reasonably confident about Linux, ssh, etc.?
>>>> 
>>>> 3. Does the control program have to run on the PC, or can it
>>>> run on the Pi?
>>>> 
>>>> 4. Do you have source for the control program, and can you
>>>> modify it to use a TCP/IP port instead of a serial port?
>>> 
>>> 
>>> Sorry, my other post didn't address all of your questions.
>>> 
>>> 1) Windows 10 now.  Most likely it was Win Vista or Win 8 before.
>>> 
>> 
>> OK, so it is putty or msys2 ssh for the ssh client (depending on
>> your preferences).  If you want to go for the OpenVPN route, that
>> will work too.
>> 
>>> 
>>> 2) If you mean using Linux, I'm not afraid to learn.  But Linux
>>> is not easy to learn because there are so many assumptions of
>>> existing knowledge.  I've actually had people tell me I shouldn't
>>> be working with Linux if I'm not interested in becoming a guru.
>>> I did the remote thing before and I am sure I can do it again.
>>> Besides, the more I putz with this issue, the longer I can put
>>> off working on the actual test code.  The only difference is
>>> involving the Internet vs. the local network.
>>> 
>> 
>> Once you have the port forward in place, there should be little 
>> difference between local net and internet.  If you are using a
>> TCP/IP port between the client and the Pi, you can use ssh port
>> forwarding to pass that over the ssh link securely.
>> 
>> Learning Linux does not have assumptions of existing knowledge, and
>> it is not particularly hard to learn.  The people who have most
>> difficulty with it are usually Windows gurus - many of their
>> assumptions, and much of their expertise, becomes wrong in the
>> Linux world.  For people just using programs on Linux, it is easy -
>> my 75 year old mother in law uses it, and my kids have used it
>> since they were old enough for TuxPaint. Some things are easier in
>> the Windows world, and some things are easier in the Linux world -
>> I need both for my work.  But when I have the choice, it's Linux
>> all the way - it is just so much more efficient and flexible for
>> most of what I do.  (I am not saying you need to "learn Linux" or
>> switch to Linux - merely that you should not be afraid of it. And
>> listen to this random guy off the internet, not the people who
>> told you to avoid it.)
>> 
>>> 3) The control program can possibly run on the rPi, but it would
>>> require some Windows specific code to be modified and this
>>> version would only be for my development.  This is a test fixture
>>> that provides test results by copying them into the Windows paste
>>> buffer for the user to copy into a spread sheet.  Everyone using
>>> this program is very happy with it, so little interest in
>>> changing our methods.  Remember, what I am doing now is just so I
>>> can do further development in a flexible work environment.
>>> 
>> 
>> OK.  There is probably a dozen ways to make a system that works as
>> well or better for users, without requiring anything in particular
>> on the client machine (i.e., any authorised user can do it from
>> their own system).  But all of them require work, and changing the
>> software setup significantly.  When you want to make "version 2" of
>> the system, post again for more advice.
>> 
>>> 4) Yes, I wrote the control program, but I have no interest in
>>> modifying it for this purpose.  I shouldn't need to I am pretty
>>> sure.
>>> 
>> 
>> If you had it all working locally on the net before, you should not
>> need to change things to get it working over the internet.  The
>> only visible difference would be in the timings - you get longer
>> latencies over the internet.
> 
> I'm not sure you read everything I write or maybe you forgot what I
> wrote earlier.  I know I have that trouble in some threads.  Or maybe
> I'm not following what you are saying.  It sounds like you think the
> rPi will be used by users.

I was extrapolating from your description of using the test program
(running on Windows, but getting data from the test system via the Pi)
and the user copying the data into a spreadsheet.  You haven't said
anything about who the "user" might be here, so maybe I have made
unwarranted assumptions.

> 
> When the test fixture is used, a serial port directly connects the
> test fixture to the PC running the test program.  This is needed
> because the user has to plug and unplug UUTs to/from the text
> fixture.  There is no rPi and there is no need for access via the
> Internet or even a local network.
> 
> The need for Internet access via an rPi is purely because I want to
> do significant development work on the test fixture control program
> but don't want to lug a test fixture around with me while I travel,
> which is pretty much all the time these days.

Ah, so this is just for you to be able to do development work on the
test fixture even when you are not at the office?  I think I am getting
a clearer picture now.

> 
> I had a different target controlled via serial port set up so I could
> use the rPi to provide remote access to the serial port from a
> Windows PC via Putty over my local network only.
> 
> The differences between these two systems are that I need to account
> for getting through the router/modem and instead of using Putty which
> knows about IP addresses and SSH, my control program only knows about
> serial ports.  So this system needs to emulate a serial port on the
> Windows PC.
> 
> There may be enough info in this thread to make this work, but I'm
> not sure since I do have the test fixture with me, but not the rPi.
> I should be able to work on this a bit later this week.
> 

If you have a port forward from your internet connection to the Pi, and
the internet connection has a fixed global IP address, then the setup
should work the same as now.  Instead of connecting to <Pi's IP><port
22> you connect to <Modem's IP><port 54321>, and set up port forwarding
on the modem from external port 54321 to the Pi's IP and port 22.

On Thursday, February 28, 2019 at 2:09:25 AM UTC-6, David Brown wrote:
> On 28/02/2019 02:49, gnuarm.deletethisbit@gmail.com wrote:
> > On Wednesday, February 27, 2019 at 6:23:56 PM UTC-6, David Brown wrote:
> >> On 28/02/2019 00:41, gnuarm.deletethisbit@gmail.com wrote:
> >>> On Tuesday, February 26, 2019 at 3:42:58 PM UTC-6, gnuarm.del...@gmail.com wrote:
> >>>> I am working on a test fixture that uses an RS-232 port for control.  I travel a lot and don't want to have to drag the test fixture around with me.
> >>>>
> >>>> Some time ago I was working with an eval board via serial port and used an rPi (Raspberry Pi) to put the serial port on the network and work from another room.  That worked pretty well.  I didn't have a means of rebooting the target however.  This time I will add a capability of removing power from the test fixture to provide a reset.
> >>>>
> >>>> What I didn't try before was using this rig over the Internet.  I'm not even sure where to being digging into how to do that.  I expect it is not complicated to make the serial port accessible through the router and modem, but I'm not sure where to begin.  Or does the router even get involved and is just transparent and I only need the local IP address?  None of the sources I've found address the issue of getting through the router, etc.
> >>>>
> >>>> Essentially I want the serial port on the rPi to become a virtual serial port on a PC located anywhere else on the planet.  :)
> >>>>
> >>>> Rick C.
> >>>
> >>> Just to make things more clear...
> >>>
> >>> Conventional Use of Test Fixture
> >>>
> >>>    +---------+        +--------+
> >>>    | +-----+ |        |        |
> >>>    | | UUT | |        |   PC   |
> >>>    | +-----+ | RS-232 |        |
> >>>    |  Test   |<======>|  Cntl  |
> >>>    | Fixture |        |  Prog  |
> >>>    +---------+        +--------+
> >>>
> >>>
> >>> Desired use of Test Fixture
> >>>
> >>>    +---------+        +--------+
> >>>    | +-----+ |        |        |      /-----\
> >>>    | | UUT | |        |   rPi  |     (       )
> >>>    | +-----+ | RS-232 |        |     ( Inter )
> >>>    |  Test   |<======>|        |<===>(  net  )
> >>>    | Fixture |        |        |     (       )
> >>>    +---------+        +--------+      \-----/
> >>>
> >>>    +--------+
> >>>    |        |      /-----\
> >>>    |   PC   |     (       )
> >>>    |        |     ( Inter )
> >>>    |  Cntl  |<===>(  net  )
> >>>    |  Prog  |     (       )
> >>>    +--------+      \-----/
> >>>
> >>> I hope this clears up any confusion.
> >>>
> >>> Rick C.
> >>>
> >>
> >> This clears up a few points.  But there are some questions that could 
> >> make this easier.
> >>
> >> 1. Is the PC running Windows or Linux?
> >>
> >> 2. Are you reasonably confident about Linux, ssh, etc.?
> >>
> >> 3. Does the control program have to run on the PC, or can it run on the Pi?
> >>
> >> 4. Do you have source for the control program, and can you modify it to 
> >> use a TCP/IP port instead of a serial port?
> > 
> > 
> > Sorry, my other post didn't address all of your questions. 
> > 
> > 1) Windows 10 now.  Most likely it was Win Vista or Win 8 before. 
> 
> OK, so it is putty or msys2 ssh for the ssh client (depending on your
> preferences).  If you want to go for the OpenVPN route, that will work too.
> 
> > 
> > 2) If you mean using Linux, I'm not afraid to learn.  But Linux is not easy to learn because there are so many assumptions of existing knowledge.  I've actually had people tell me I shouldn't be working with Linux if I'm not interested in becoming a guru.  I did the remote thing before and I am sure I can do it again.  Besides, the more I putz with this issue, the longer I can put off working on the actual test code.  The only difference is involving the Internet vs. the local network. 
> > 
> 
> Once you have the port forward in place, there should be little
> difference between local net and internet.  If you are using a TCP/IP
> port between the client and the Pi, you can use ssh port forwarding to
> pass that over the ssh link securely.
> 
> Learning Linux does not have assumptions of existing knowledge, and it
> is not particularly hard to learn.  The people who have most difficulty
> with it are usually Windows gurus - many of their assumptions, and much
> of their expertise, becomes wrong in the Linux world.  For people just
> using programs on Linux, it is easy - my 75 year old mother in law uses
> it, and my kids have used it since they were old enough for TuxPaint.
> Some things are easier in the Windows world, and some things are easier
> in the Linux world - I need both for my work.  But when I have the
> choice, it's Linux all the way - it is just so much more efficient and
> flexible for most of what I do.  (I am not saying you need to "learn
> Linux" or switch to Linux - merely that you should not be afraid of it.
>  And listen to this random guy off the internet, not the people who told
> you to avoid it.)
> 
> > 3) The control program can possibly run on the rPi, but it would require some Windows specific code to be modified and this version would only be for my development.  This is a test fixture that provides test results by copying them into the Windows paste buffer for the user to copy into a spread sheet.  Everyone using this program is very happy with it, so little interest in changing our methods.  Remember, what I am doing now is just so I can do further development in a flexible work environment. 
> > 
> 
> OK.  There is probably a dozen ways to make a system that works as well
> or better for users, without requiring anything in particular on the
> client machine (i.e., any authorised user can do it from their own
> system).  But all of them require work, and changing the software setup
> significantly.  When you want to make "version 2" of the system, post
> again for more advice.
> 
> > 4) Yes, I wrote the control program, but I have no interest in modifying it for this purpose.  I shouldn't need to I am pretty sure.
> > 
> 
> If you had it all working locally on the net before, you should not need
> to change things to get it working over the internet.  The only visible
> difference would be in the timings - you get longer latencies over the
> internet.

I'm not sure you read everything I write or maybe you forgot what I wrote earlier.  I know I have that trouble in some threads.  Or maybe I'm not following what you are saying.  It sounds like you think the rPi will be used by users.  

When the test fixture is used, a serial port directly connects the test fixture to the PC running the test program.  This is needed because the user has to plug and unplug UUTs to/from the text fixture.  There is no rPi and there is no need for access via the Internet or even a local network.  

The need for Internet access via an rPi is purely because I want to do significant development work on the test fixture control program but don't want to lug a test fixture around with me while I travel, which is pretty much all the time these days.  

I had a different target controlled via serial port set up so I could use the rPi to provide remote access to the serial port from a Windows PC via Putty over my local network only.  

The differences between these two systems are that I need to account for getting through the router/modem and instead of using Putty which knows about IP addresses and SSH, my control program only knows about serial ports.  So this system needs to emulate a serial port on the Windows PC.  

There may be enough info in this thread to make this work, but I'm not sure since I do have the test fixture with me, but not the rPi.  I should be able to work on this a bit later this week.  

Thanks, 

Rick C.

On 28.2.19 04:08, gnuarm.deletethisbit@gmail.com wrote:
> On Wednesday, February 27, 2019 at 8:00:25 PM UTC-6, edward....@gmail.com wrote:
>>
>> RPi runs a version of Linux.  So, you don't have a choose.  You are working with Linux anyway.  Basically, you ssh into the rPi and minicom/screen/etc to your test fixture.
> 
> Of course I have a choice.  The rPi is there to connect the target serial port to the network.  There is nothing that says I have to use an rPi.  Or even if I use an rPi there is nothing that says I have to run Linux.
> 
> Given the tremendous knowledge pool with Linux on the rPi, I expect Linux will be the path of least resistance.
> 
> Rick C.
> 

I'm a late comer to this discussion ...

I'm running a Rpi with one RS-232 USB dongle and one
OpenOCD JTAG dongle connected. I connect to the Rpi
with SSH and use the RS-232 and JTAG connections like
I were directly on the Rpi.

It seems that you're having a problem to access the Rpi
via the Net. There are at least two ways to do it:

  - have the Pi in a local network which is accessible
    via VPN,

  - have a publicly visible IP address on the Pi and
    access it directly.

Anyway, you do need an IP address publicly visible to
your PC. My solution to this is DynDNS, as most of
the DHCP client networks are still accessible from
the outside, if the IP address is known, although the
address is not fixed.

Both access solutions have security implications, as
the badly behaving members of the Net will attack it
within half an hour after connecting. The VPN solution
is better walled off from the wild part of the Net.

-- 

-TV

On 28/02/2019 02:49, gnuarm.deletethisbit@gmail.com wrote:
> On Wednesday, February 27, 2019 at 6:23:56 PM UTC-6, David Brown wrote:
>> On 28/02/2019 00:41, gnuarm.deletethisbit@gmail.com wrote:
>>> On Tuesday, February 26, 2019 at 3:42:58 PM UTC-6, gnuarm.del...@gmail.com wrote:
>>>> I am working on a test fixture that uses an RS-232 port for control.  I travel a lot and don't want to have to drag the test fixture around with me.
>>>>
>>>> Some time ago I was working with an eval board via serial port and used an rPi (Raspberry Pi) to put the serial port on the network and work from another room.  That worked pretty well.  I didn't have a means of rebooting the target however.  This time I will add a capability of removing power from the test fixture to provide a reset.
>>>>
>>>> What I didn't try before was using this rig over the Internet.  I'm not even sure where to being digging into how to do that.  I expect it is not complicated to make the serial port accessible through the router and modem, but I'm not sure where to begin.  Or does the router even get involved and is just transparent and I only need the local IP address?  None of the sources I've found address the issue of getting through the router, etc.
>>>>
>>>> Essentially I want the serial port on the rPi to become a virtual serial port on a PC located anywhere else on the planet.  :)
>>>>
>>>> Rick C.
>>>
>>> Just to make things more clear...
>>>
>>> Conventional Use of Test Fixture
>>>
>>>    +---------+        +--------+
>>>    | +-----+ |        |        |
>>>    | | UUT | |        |   PC   |
>>>    | +-----+ | RS-232 |        |
>>>    |  Test   |<======>|  Cntl  |
>>>    | Fixture |        |  Prog  |
>>>    +---------+        +--------+
>>>
>>>
>>> Desired use of Test Fixture
>>>
>>>    +---------+        +--------+
>>>    | +-----+ |        |        |      /-----\
>>>    | | UUT | |        |   rPi  |     (       )
>>>    | +-----+ | RS-232 |        |     ( Inter )
>>>    |  Test   |<======>|        |<===>(  net  )
>>>    | Fixture |        |        |     (       )
>>>    +---------+        +--------+      \-----/
>>>
>>>    +--------+
>>>    |        |      /-----\
>>>    |   PC   |     (       )
>>>    |        |     ( Inter )
>>>    |  Cntl  |<===>(  net  )
>>>    |  Prog  |     (       )
>>>    +--------+      \-----/
>>>
>>> I hope this clears up any confusion.
>>>
>>> Rick C.
>>>
>>
>> This clears up a few points.  But there are some questions that could 
>> make this easier.
>>
>> 1. Is the PC running Windows or Linux?
>>
>> 2. Are you reasonably confident about Linux, ssh, etc.?
>>
>> 3. Does the control program have to run on the PC, or can it run on the Pi?
>>
>> 4. Do you have source for the control program, and can you modify it to 
>> use a TCP/IP port instead of a serial port?
> 
> 
> Sorry, my other post didn't address all of your questions. 
> 
> 1) Windows 10 now.  Most likely it was Win Vista or Win 8 before. 

OK, so it is putty or msys2 ssh for the ssh client (depending on your
preferences).  If you want to go for the OpenVPN route, that will work too.

> 
> 2) If you mean using Linux, I'm not afraid to learn.  But Linux is not easy to learn because there are so many assumptions of existing knowledge.  I've actually had people tell me I shouldn't be working with Linux if I'm not interested in becoming a guru.  I did the remote thing before and I am sure I can do it again.  Besides, the more I putz with this issue, the longer I can put off working on the actual test code.  The only difference is involving the Internet vs. the local network. 
> 

Once you have the port forward in place, there should be little
difference between local net and internet.  If you are using a TCP/IP
port between the client and the Pi, you can use ssh port forwarding to
pass that over the ssh link securely.

Learning Linux does not have assumptions of existing knowledge, and it
is not particularly hard to learn.  The people who have most difficulty
with it are usually Windows gurus - many of their assumptions, and much
of their expertise, becomes wrong in the Linux world.  For people just
using programs on Linux, it is easy - my 75 year old mother in law uses
it, and my kids have used it since they were old enough for TuxPaint.
Some things are easier in the Windows world, and some things are easier
in the Linux world - I need both for my work.  But when I have the
choice, it's Linux all the way - it is just so much more efficient and
flexible for most of what I do.  (I am not saying you need to "learn
Linux" or switch to Linux - merely that you should not be afraid of it.
 And listen to this random guy off the internet, not the people who told
you to avoid it.)

> 3) The control program can possibly run on the rPi, but it would require some Windows specific code to be modified and this version would only be for my development.  This is a test fixture that provides test results by copying them into the Windows paste buffer for the user to copy into a spread sheet.  Everyone using this program is very happy with it, so little interest in changing our methods.  Remember, what I am doing now is just so I can do further development in a flexible work environment. 
> 

OK.  There is probably a dozen ways to make a system that works as well
or better for users, without requiring anything in particular on the
client machine (i.e., any authorised user can do it from their own
system).  But all of them require work, and changing the software setup
significantly.  When you want to make "version 2" of the system, post
again for more advice.

> 4) Yes, I wrote the control program, but I have no interest in modifying it for this purpose.  I shouldn't need to I am pretty sure.
> 

If you had it all working locally on the net before, you should not need
to change things to get it working over the internet.  The only visible
difference would be in the timings - you get longer latencies over the
internet.

gnuarm.deletethisbit@gmail.com writes:
> Essentially I want the serial port on the rPi to become a virtual
> serial port on a PC located anywhere else on the planet.  :)

The main issues here are bypassing your home firewall and the possible
lack of a static IP address on your home internet.

The approach I would suggest is

1) rent a virtual private server (VPS) with a static IP address: this
starts around $15 a year for a dedicated address and I can email you
some recommendations if you want.

2) set up a reverse ssh proxy on your raspberry pi, to connect an
inbound port on the VPS to the login port on the raspberry pi.
See here for how to do this:  https://serverfault.com/a/227268
But you want to forward to port 22 instead of 

3) You will need to set up systemd or some other supervision system on
the rpi to restart the proxy in case of a reboot (power interruption at
home while you are travelling etc.)  What OS distro are you running on
the Pi (Raspian?)  I don't know the exact command for this offhand but
someone else here might, or I can research it a little.

4. You probably want to assign a domain or subdomain name to the VPS.
So you'll run something like

    ssh yourproxy@yourdomain.com:1234

if the proxy port is 1234.  That will then forward to port 22 on your
pi, and you can login to the pi normally and run something like minicom
or whatever other serial comm program you like.

Set your home firewall to block incoming connections (your tunnel works
over an outbound one from the pi) and use public key authentication (if
you can) or strong passwords (if you have to) on both of the ssh ports.
You WILL get bad guys trying to connect to the ports and brute force the
password.  Using the nonstandard port (1234 or whatever; "standard"=22)
will help with this but be careful anyway.

The other approach of simply opening the pi's port 22 to incoming
connections works in principle, but you need a static address, and it's
generally safer to firewall off incoming connections completely rather
than open a way for someone to take over your internal home network
(especially scary if you have windows machines etc. on it).

gnuarm.deletethisbit@gmail.com wrote:
> I am working on a test fixture that uses an RS-232 port for control. 
> I travel a lot and don't want to have to drag the test fixture
> around with me.
> 
> Some time ago I was working with an eval board via serial port and 
> used an rPi (Raspberry Pi) to put the serial port on the network and 
> work from another room.  That worked pretty well.  I didn't have a 
> means of rebooting the target however.  This time I will add a 
> capability of removing power from the test fixture to provide a 
> reset.
> 


There exist USB controlled power strips. The ones I used had a crude C
api. The goal there was to automate finding a bootup bug.

> What I didn't try before was using this rig over the Internet.  I'm 
> not even sure where to being digging into how to do that.  I expect 
> it is not complicated to make the serial port accessible through the 
> router and modem, but I'm not sure where to begin.  Or does the 
> router even get involved and is just transparent and I only need the 
> local IP address?  None of the sources I've found address the issue 
> of getting through the router, etc.
> 
> Essentially I want the serial port on the rPi to become a virtual 
> serial port on a PC located anywhere else on the planet.  :)
> 
> Rick C.
> 

Every time I have done this, I write a custom TCP server in Tcl and
use that to drive the serial port. I've had entire simulations of some
fairly complex plant done in this way. A RasPi can have a great many
peripherals. I used a Komodo CAN tester-device with an API to build an
engine/transmission simulator more than once. The API is fairly awful
but it worked out.

The Brent Welch book has a good deal
of detail on how to do this. ISBN-13: 978-0130385604

How you get a route to the device is a seperate problem - you'll have to
negotiate with your service provider.

-- 
Les Cargill

On Wednesday, February 27, 2019 at 8:00:25 PM UTC-6, edward....@gmail.com wrote:
> 
> RPi runs a version of Linux.  So, you don't have a choose.  You are working with Linux anyway.  Basically, you ssh into the rPi and minicom/screen/etc to your test fixture.

Of course I have a choice.  The rPi is there to connect the target serial port to the network.  There is nothing that says I have to use an rPi.  Or even if I use an rPi there is nothing that says I have to run Linux.  

Given the tremendous knowledge pool with Linux on the rPi, I expect Linux will be the path of least resistance.  

Rick C. 

On Wednesday, February 27, 2019 at 5:49:43 PM UTC-8, gnuarm.del...@gmail.com wrote:
> On Wednesday, February 27, 2019 at 6:23:56 PM UTC-6, David Brown wrote:
> > On 28/02/2019 00:41, gnuarm.deletethisbit@gmail.com wrote:
> > > On Tuesday, February 26, 2019 at 3:42:58 PM UTC-6, gnuarm.del...@gmail.com wrote:
> > >> I am working on a test fixture that uses an RS-232 port for control.  I travel a lot and don't want to have to drag the test fixture around with me.
> > >>
> > >> Some time ago I was working with an eval board via serial port and used an rPi (Raspberry Pi) to put the serial port on the network and work from another room.  That worked pretty well.  I didn't have a means of rebooting the target however.  This time I will add a capability of removing power from the test fixture to provide a reset.
> > >>
> > >> What I didn't try before was using this rig over the Internet.  I'm not even sure where to being digging into how to do that.  I expect it is not complicated to make the serial port accessible through the router and modem, but I'm not sure where to begin.  Or does the router even get involved and is just transparent and I only need the local IP address?  None of the sources I've found address the issue of getting through the router, etc.
> > >>
> > >> Essentially I want the serial port on the rPi to become a virtual serial port on a PC located anywhere else on the planet.  :)
> > >>
> > >> Rick C.
> > > 
> > > Just to make things more clear...
> > > 
> > > Conventional Use of Test Fixture
> > > 
> > >    +---------+        +--------+
> > >    | +-----+ |        |        |
> > >    | | UUT | |        |   PC   |
> > >    | +-----+ | RS-232 |        |
> > >    |  Test   |<======>|  Cntl  |
> > >    | Fixture |        |  Prog  |
> > >    +---------+        +--------+
> > > 
> > > 
> > > Desired use of Test Fixture
> > > 
> > >    +---------+        +--------+
> > >    | +-----+ |        |        |      /-----\
> > >    | | UUT | |        |   rPi  |     (       )
> > >    | +-----+ | RS-232 |        |     ( Inter )
> > >    |  Test   |<======>|        |<===>(  net  )
> > >    | Fixture |        |        |     (       )
> > >    +---------+        +--------+      \-----/
> > > 
> > >    +--------+
> > >    |        |      /-----\
> > >    |   PC   |     (       )
> > >    |        |     ( Inter )
> > >    |  Cntl  |<===>(  net  )
> > >    |  Prog  |     (       )
> > >    +--------+      \-----/
> > > 
> > > I hope this clears up any confusion.
> > > 
> > > Rick C.
> > > 
> > 
> > This clears up a few points.  But there are some questions that could 
> > make this easier.
> > 
> > 1. Is the PC running Windows or Linux?
> > 
> > 2. Are you reasonably confident about Linux, ssh, etc.?
> > 
> > 3. Does the control program have to run on the PC, or can it run on the Pi?
> > 
> > 4. Do you have source for the control program, and can you modify it to 
> > use a TCP/IP port instead of a serial port?
> 
> 
> Sorry, my other post didn't address all of your questions. 
> 
> 1) Windows 10 now.  Most likely it was Win Vista or Win 8 before. 
> 
> 2) If you mean using Linux, I'm not afraid to learn.  But Linux is not easy to learn because there are so many assumptions of existing knowledge.  I've actually had people tell me I shouldn't be working with Linux if I'm not interested in becoming a guru.  I did the remote thing before and I am sure I can do it again.  Besides, the more I putz with this issue, the longer I can put off working on the actual test code.  The only difference is involving the Internet vs. the local network. 

RPi runs a version of Linux.  So, you don't have a choose.  You are working with Linux anyway.  Basically, you ssh into the rPi and minicom/screen/etc to your test fixture.

On Wednesday, February 27, 2019 at 6:23:56 PM UTC-6, David Brown wrote:
> On 28/02/2019 00:41, gnuarm.deletethisbit@gmail.com wrote:
> > On Tuesday, February 26, 2019 at 3:42:58 PM UTC-6, gnuarm.del...@gmail.com wrote:
> >> I am working on a test fixture that uses an RS-232 port for control.  I travel a lot and don't want to have to drag the test fixture around with me.
> >>
> >> Some time ago I was working with an eval board via serial port and used an rPi (Raspberry Pi) to put the serial port on the network and work from another room.  That worked pretty well.  I didn't have a means of rebooting the target however.  This time I will add a capability of removing power from the test fixture to provide a reset.
> >>
> >> What I didn't try before was using this rig over the Internet.  I'm not even sure where to being digging into how to do that.  I expect it is not complicated to make the serial port accessible through the router and modem, but I'm not sure where to begin.  Or does the router even get involved and is just transparent and I only need the local IP address?  None of the sources I've found address the issue of getting through the router, etc.
> >>
> >> Essentially I want the serial port on the rPi to become a virtual serial port on a PC located anywhere else on the planet.  :)
> >>
> >> Rick C.
> > 
> > Just to make things more clear...
> > 
> > Conventional Use of Test Fixture
> > 
> >    +---------+        +--------+
> >    | +-----+ |        |        |
> >    | | UUT | |        |   PC   |
> >    | +-----+ | RS-232 |        |
> >    |  Test   |<======>|  Cntl  |
> >    | Fixture |        |  Prog  |
> >    +---------+        +--------+
> > 
> > 
> > Desired use of Test Fixture
> > 
> >    +---------+        +--------+
> >    | +-----+ |        |        |      /-----\
> >    | | UUT | |        |   rPi  |     (       )
> >    | +-----+ | RS-232 |        |     ( Inter )
> >    |  Test   |<======>|        |<===>(  net  )
> >    | Fixture |        |        |     (       )
> >    +---------+        +--------+      \-----/
> > 
> >    +--------+
> >    |        |      /-----\
> >    |   PC   |     (       )
> >    |        |     ( Inter )
> >    |  Cntl  |<===>(  net  )
> >    |  Prog  |     (       )
> >    +--------+      \-----/
> > 
> > I hope this clears up any confusion.
> > 
> > Rick C.
> > 
> 
> This clears up a few points.  But there are some questions that could 
> make this easier.
> 
> 1. Is the PC running Windows or Linux?
> 
> 2. Are you reasonably confident about Linux, ssh, etc.?
> 
> 3. Does the control program have to run on the PC, or can it run on the Pi?
> 
> 4. Do you have source for the control program, and can you modify it to 
> use a TCP/IP port instead of a serial port?


Sorry, my other post didn't address all of your questions. 

1) Windows 10 now.  Most likely it was Win Vista or Win 8 before. 

2) If you mean using Linux, I'm not afraid to learn.  But Linux is not easy to learn because there are so many assumptions of existing knowledge.  I've actually had people tell me I shouldn't be working with Linux if I'm not interested in becoming a guru.  I did the remote thing before and I am sure I can do it again.  Besides, the more I putz with this issue, the longer I can put off working on the actual test code.  The only difference is involving the Internet vs. the local network. 

3) The control program can possibly run on the rPi, but it would require some Windows specific code to be modified and this version would only be for my development.  This is a test fixture that provides test results by copying them into the Windows paste buffer for the user to copy into a spread sheet.  Everyone using this program is very happy with it, so little interest in changing our methods.  Remember, what I am doing now is just so I can do further development in a flexible work environment. 

4) Yes, I wrote the control program, but I have no interest in modifying it for this purpose.  I shouldn't need to I am pretty sure.

On Wednesday, February 27, 2019 at 6:23:56 PM UTC-6, David Brown wrote:
> On 28/02/2019 00:41, gnuarm.deletethisbit@gmail.com wrote:
> > On Tuesday, February 26, 2019 at 3:42:58 PM UTC-6, gnuarm.del...@gmail.com wrote:
> >> I am working on a test fixture that uses an RS-232 port for control.  I travel a lot and don't want to have to drag the test fixture around with me.
> >>
> >> Some time ago I was working with an eval board via serial port and used an rPi (Raspberry Pi) to put the serial port on the network and work from another room.  That worked pretty well.  I didn't have a means of rebooting the target however.  This time I will add a capability of removing power from the test fixture to provide a reset.
> >>
> >> What I didn't try before was using this rig over the Internet.  I'm not even sure where to being digging into how to do that.  I expect it is not complicated to make the serial port accessible through the router and modem, but I'm not sure where to begin.  Or does the router even get involved and is just transparent and I only need the local IP address?  None of the sources I've found address the issue of getting through the router, etc.
> >>
> >> Essentially I want the serial port on the rPi to become a virtual serial port on a PC located anywhere else on the planet.  :)
> >>
> >> Rick C.
> > 
> > Just to make things more clear...
> > 
> > Conventional Use of Test Fixture
> > 
> >    +---------+        +--------+
> >    | +-----+ |        |        |
> >    | | UUT | |        |   PC   |
> >    | +-----+ | RS-232 |        |
> >    |  Test   |<======>|  Cntl  |
> >    | Fixture |        |  Prog  |
> >    +---------+        +--------+
> > 
> > 
> > Desired use of Test Fixture
> > 
> >    +---------+        +--------+
> >    | +-----+ |        |        |      /-----\
> >    | | UUT | |        |   rPi  |     (       )
> >    | +-----+ | RS-232 |        |     ( Inter )
> >    |  Test   |<======>|        |<===>(  net  )
> >    | Fixture |        |        |     (       )
> >    +---------+        +--------+      \-----/
> > 
> >    +--------+
> >    |        |      /-----\
> >    |   PC   |     (       )
> >    |        |     ( Inter )
> >    |  Cntl  |<===>(  net  )
> >    |  Prog  |     (       )
> >    +--------+      \-----/
> > 
> > I hope this clears up any confusion.
> > 
> > Rick C.
> > 
> 
> This clears up a few points.  But there are some questions that could 
> make this easier.
> 
> 1. Is the PC running Windows or Linux?
> 
> 2. Are you reasonably confident about Linux, ssh, etc.?
> 
> 3. Does the control program have to run on the PC, or can it run on the Pi?
> 
> 4. Do you have source for the control program, and can you modify it to 
> use a TCP/IP port instead of a serial port?

I have done this before from my Windows PC through my home network, the rPi to the target board.  I don't think I mentioned I used SSH if I remember correctly.  I most likely used Putty or a derivative on the PC.  I had a bunch of trouble finding something on the rPi that would work correctly.  Some of the issues were the differences in line endings I think, but there was something else that I don't recall.  So I'll likely have to research that path again.  

I was running Forth on the target.  This time the target is a command line reader in the FPGA with a syntax that is analogous to the hardware interface to the UUT, data, address, one letter command all separated by spaces ala Forth.  When the target sees the command letter it replies with the data, address, command and a numeric response.  If the command is a write or read it is the data of interest.  If the command is a "select" command (chooses the test fixture or one of two UUTs as the point of communications) the response is the unit selected.  Every command other than the select command is reading or writing a register in the selected target.  I guess that's more info than you need, but there it is. 

The connection over the lan was made by getting the router to assign fixed IP addresses to the devices.  That actually never worked well.  I could tell the router to use "these" assignments and tried to set that up in multiple locations where I used this, but sometimes it would do that, other times it would assign other addresses. 

Rick C.