On 27/02/2019 22:12, A.P.Richelieu wrote:> Den 2019-02-27 kl. 21:25, skrev David Brown: >> On 27/02/2019 18:45, A.P.Richelieu wrote: >> >>> If you have a set of stuff on the Pi, dedicated for the test, >>> that should be refreshed, then just create a git repo somewhere with >>> the test code, and let the Pi do a "git pull --rebase" periodically. >> >> If the test program(s) are running on the Pi, then you need some way >> to get them onto the Pi and to keep them updated with any changes. >> git is one way to share a set of source files. But there is nothing >> special about it - the OP should use whatever makes sense to him and >> whatever suits his current practices. >> >> One thing for sure is that automatic rebases are probably a very bad >> idea - just like any other automatic updates. Connect to the Pi with >> ssh, and do an update when you are ready to test the new software - >> not before. >> >> >> One thing I didn't mention earlier - when running programs via ssh on >> a setup like this, run them within "screen" (or "tmux") on the Pi. >> Then the terminals and programs stay alive even if you disconnect the >> ssh and connect again later. >> >> >> > The Pi should only have read access to the repo. >> > >> >> That is an arbitrary restriction which may not be appropriate. (It >> doesn't even make much sense - /users/ have access to a repo, not >> /computers/.) If the OP is happy fiddling with the software using >> nano over ssh, then he should be able to check in changes - there is >> no reason to force a specific direction to the development process. > > Not really, if you give write access, it will be possible for anyone > that can break into the Pi to get write access to your repo. > Breaking in, consists of removing the SD-Card and mounting it in your > laptop, after which you can copy the ssh private key. > Not a good idea.First, you don't have to store ssh keys to make git work. You can put in the password manually, without storing it. Secondly, you can have more than one account - storing a user on the Pi with ssh keys that has write access to relevant repository, does not mean using the users main ssh keys. They can be used solely for this purpose. Third, the aim is to keep the Pi secure despite being accessible from the net. No security is ever perfect, but people hacking in over the net should be a very low risk problem. Fourth, if someone is physically breaking into the guy's office, then it is extremely unlikely that they will be interested in stealing the SD-Card from the Pi in order to copy the ssh keys. And this is unlikely to reach high on the OP's list of concerns if he has had a physical break-in. Fifthly, if the git master is set up correctly and you are using appropriate keys, then all the ssh key thief can do is commit to that one repository of test code. That is not going to be a big issue - and all changes are tracked, logged, and reversible. Sixth, if you think it is not possible to set up git to give safe and reliable write access like this, then you should not be recommending git for the job.> > The important part of git is that this is something that the Pi > starts, not something that is pushed into the Pi. >No. The Pi does not start anything. The user, logged into the Pi by ssh, starts the update or pull. And that same user can edit files directly on the Pi, and should be able to commit and push the changes.> It is certainly a good idea to update the Pi automatically > with the latest test suite.Nonsense. It is a good idea to know exactly what you are running on the test system, and update it when it is time to update it, not based on some periodic pulls.> If you find you have a problem, you can easily revert to an older commit.Yes, that's easy - if you are in control of your updates and haven't set an automatic job for it.> Obviously you should be able to disable the automatic update, > if for some reason you do not like to use the latest version. >You have it ass-backwards.
Remote Debugging
Started by ●February 26, 2019
Reply by ●February 27, 20192019-02-27
Reply by ●February 27, 20192019-02-27
Den 2019-02-27 kl. 23:00, skrev David Brown:> On 27/02/2019 22:12, A.P.Richelieu wrote: >> Den 2019-02-27 kl. 21:25, skrev David Brown: >>> On 27/02/2019 18:45, A.P.Richelieu wrote: >>> >>>> If you have a set of stuff on the Pi, dedicated for the test, >>>> that should be refreshed, then just create a git repo somewhere with >>>> the test code, and let the Pi do a "git pull --rebase" periodically. >>> >>> If the test program(s) are running on the Pi, then you need some way >>> to get them onto the Pi and to keep them updated with any changes. >>> git is one way to share a set of source files. But there is nothing >>> special about it - the OP should use whatever makes sense to him and >>> whatever suits his current practices. >>> >>> One thing for sure is that automatic rebases are probably a very bad >>> idea - just like any other automatic updates. Connect to the Pi with >>> ssh, and do an update when you are ready to test the new software - >>> not before. >>> >>> >>> One thing I didn't mention earlier - when running programs via ssh on >>> a setup like this, run them within "screen" (or "tmux") on the Pi. >>> Then the terminals and programs stay alive even if you disconnect the >>> ssh and connect again later. >>> >>> >>> > The Pi should only have read access to the repo. >>> > >>> >>> That is an arbitrary restriction which may not be appropriate. (It >>> doesn't even make much sense - /users/ have access to a repo, not >>> /computers/.) If the OP is happy fiddling with the software using >>> nano over ssh, then he should be able to check in changes - there is >>> no reason to force a specific direction to the development process. >> >> Not really, if you give write access, it will be possible for anyone >> that can break into the Pi to get write access to your repo. >> Breaking in, consists of removing the SD-Card and mounting it in your >> laptop, after which you can copy the ssh private key. >> Not a good idea. > > First, you don't have to store ssh keys to make git work. You can put > in the password manually, without storing it.Which is totally unneccessary, if you only give read access.> > Secondly, you can have more than one account - storing a user on the Pi > with ssh keys that has write access to relevant repository, does not > mean using the users main ssh keys. They can be used solely for this > purpose. > > Third, the aim is to keep the Pi secure despite being accessible from > the net. No security is ever perfect, but people hacking in over the > net should be a very low risk problem. >Not really.> Fourth, if someone is physically breaking into the guy's office, then it > is extremely unlikely that they will be interested in stealing the > SD-Card from the Pi in order to copy the ssh keys. And this is unlikely > to reach high on the OP's list of concerns if he has had a physical > break-in. >> Fifthly, if the git master is set up correctly and you are using > appropriate keys, then all the ssh key thief can do is commit to that > one repository of test code. That is not going to be a big issue - and > all changes are tracked, logged, and reversible. >That is unneccessary trouble.> Sixth, if you think it is not possible to set up git to give safe and > reliable write access like this, then you should not be recommending git > for the job.I am recommending read only git, and you say that git is useless, if you do not have write access from all over the world. I beg to disagree. The proper procedure is to have a test setup in your office where the Pi has write access. In this setup, you test and verify that it works. Only after testing there, is the test system released. Pi's at remote locations should not have write access. All experiments should be done on the local system. If need to, a remote system could be made to use a dedicated branch.> >> >> The important part of git is that this is something that the Pi >> starts, not something that is pushed into the Pi. >> > > No. The Pi does not start anything.The update is started by running code on the Pi.> > The user, logged into the Pi by ssh, starts the update or pull. And > that same user can edit files directly on the Pi, and should be able to > commit and push the changes.The used should commit and push the stuff in a controlled environment, not in a customer system.> >> It is certainly a good idea to update the Pi automatically >> with the latest test suite. > > Nonsense. It is a good idea to know exactly what you are running on the > test system, and update it when it is time to update it, not based on > some periodic pulls.Automatic, does not neccessarily mean that there is a periodic pull. It might do the pull every time you reset the target.>> If you find you have a problem, you can easily revert to an older commit. > > Yes, that's easy - if you are in control of your updates and haven't set > an automatic job for it. >You are in control of the main repo. Noone will pull in something, which is not part of that repo.>> Obviously you should be able to disable the automatic update, >> if for some reason you do not like to use the latest version. >> > > You have it ass-backwards. >No I don't. AP
Reply by ●February 27, 20192019-02-27
On 27/02/2019 23:28, A.P.Richelieu wrote:> Den 2019-02-27 kl. 23:00, skrev David Brown: >> On 27/02/2019 22:12, A.P.Richelieu wrote: >>> Den 2019-02-27 kl. 21:25, skrev David Brown: >>>> On 27/02/2019 18:45, A.P.Richelieu wrote: >>>> >>>>> If you have a set of stuff on the Pi, dedicated for the test, >>>>> that should be refreshed, then just create a git repo somewhere >>>>> with the test code, and let the Pi do a "git pull --rebase" >>>>> periodically. >>>> >>>> If the test program(s) are running on the Pi, then you need some way >>>> to get them onto the Pi and to keep them updated with any changes. >>>> git is one way to share a set of source files. But there is nothing >>>> special about it - the OP should use whatever makes sense to him and >>>> whatever suits his current practices. >>>> >>>> One thing for sure is that automatic rebases are probably a very bad >>>> idea - just like any other automatic updates. Connect to the Pi >>>> with ssh, and do an update when you are ready to test the new >>>> software - not before. >>>> >>>> >>>> One thing I didn't mention earlier - when running programs via ssh >>>> on a setup like this, run them within "screen" (or "tmux") on the >>>> Pi. Then the terminals and programs stay alive even if you >>>> disconnect the ssh and connect again later. >>>> >>>> >>>> > The Pi should only have read access to the repo. >>>> > >>>> >>>> That is an arbitrary restriction which may not be appropriate. (It >>>> doesn't even make much sense - /users/ have access to a repo, not >>>> /computers/.) If the OP is happy fiddling with the software using >>>> nano over ssh, then he should be able to check in changes - there is >>>> no reason to force a specific direction to the development process. >>> >>> Not really, if you give write access, it will be possible for anyone >>> that can break into the Pi to get write access to your repo. >>> Breaking in, consists of removing the SD-Card and mounting it in your >>> laptop, after which you can copy the ssh private key. >>> Not a good idea. >> >> First, you don't have to store ssh keys to make git work. You can put >> in the password manually, without storing it. > > Which is totally unneccessary, if you only give read access.Yes - assuming that you don't mind hackers getting read access to your files (if you are realistically worried about hackers), and you don't mind the limitations of being read-only. Personally, I would find read-only access too limiting.> >> >> Secondly, you can have more than one account - storing a user on the >> Pi with ssh keys that has write access to relevant repository, does >> not mean using the users main ssh keys. They can be used solely for >> this purpose. >> >> Third, the aim is to keep the Pi secure despite being accessible from >> the net. No security is ever perfect, but people hacking in over the >> net should be a very low risk problem. >> > Not really.If is a realistic issue, then the OP should drop the whole idea.> >> Fourth, if someone is physically breaking into the guy's office, then >> it is extremely unlikely that they will be interested in stealing the >> SD-Card from the Pi in order to copy the ssh keys. And this is >> unlikely to reach high on the OP's list of concerns if he has had a >> physical break-in. >> > > >> Fifthly, if the git master is set up correctly and you are using >> appropriate keys, then all the ssh key thief can do is commit to that >> one repository of test code. That is not going to be a big issue - >> and all changes are tracked, logged, and reversible. >> > That is unneccessary trouble.If you don't let in the hackers in the first place, there is no problem - and this gives you a plan B if you need it.> >> Sixth, if you think it is not possible to set up git to give safe and >> reliable write access like this, then you should not be recommending >> git for the job. > I am recommending read only git, and you say that git is useless, if you > do not have write access from all over the world. > I beg to disagree.That is not what I said. I said that if git won't do an appropriate job here, which I expect will include write access in a secure manner, then it is not the right tool for this job. That does not make git useless - it would make it a poor choice here. (git /can/ give you write access in a secure way here, so it could be a good choice.) Of course, the question of git or alternative ways to share files is totally irrelevant to what the OP has been asking about.> > The proper procedure is to have a test setup in your office where > the Pi has write access. In this setup, you test and verify that it > works. Only after testing there, is the test system released. > > Pi's at remote locations should not have write access.I believe I may have found the source of your confusion. The Pi is staying put - it is the developer who is moving around.> All experiments should be done on the local system. > If need to, a remote system could be made to use a dedicated branch. > > >> >>> >>> The important part of git is that this is something that the Pi >>> starts, not something that is pushed into the Pi. >>> >> >> No. The Pi does not start anything. > > The update is started by running code on the Pi. >That code is run by the user, when /they/ decide to run it.> >> >> The user, logged into the Pi by ssh, starts the update or pull. And >> that same user can edit files directly on the Pi, and should be able >> to commit and push the changes. > > The used should commit and push the stuff in a controlled environment, > not in a customer system. >You are misunderstanding the setup. Also, customer systems may be a controlled environment - at least, controlled enough for that purpose.>> >>> It is certainly a good idea to update the Pi automatically >>> with the latest test suite. >> >> Nonsense. It is a good idea to know exactly what you are running on >> the test system, and update it when it is time to update it, not based >> on some periodic pulls. > > Automatic, does not neccessarily mean that there is a periodic pull. > It might do the pull every time you reset the target. >True. But my answer is unchanged.> > >>> If you find you have a problem, you can easily revert to an older >>> commit. >> >> Yes, that's easy - if you are in control of your updates and haven't >> set an automatic job for it. >> > You are in control of the main repo. > Noone will pull in something, which is not part of that repo. > >>> Obviously you should be able to disable the automatic update, >>> if for some reason you do not like to use the latest version. >>> >> >> You have it ass-backwards. >> > No I don't. >Well, we must leave it to the OP to decide what he wants to do. I am sure that if we were in the same room, discussing plans for a real setup, we'd be much closer to agreement - I think we are making different kinds of assumptions about the OP's situation here.
Reply by ●February 27, 20192019-02-27
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.
Reply by ●February 27, 20192019-02-27
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?
Reply by ●February 27, 20192019-02-27
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.
Reply by ●February 27, 20192019-02-27
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.
Reply by ●February 27, 20192019-02-27
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.
Reply by ●February 27, 20192019-02-27
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.
Reply by ●February 28, 20192019-02-28
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
