Modern 486

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.

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

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?

OK, I see what you are getting at now.

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

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).

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).

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

DUT = Target SerialHost = rPi PC = PC

Ok

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>

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.

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.

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).

Yes

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

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?

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.

David Brown snipped-for-privacy@hesbynett.no wrote in news:t0m311$u6l$ snipped-for-privacy@dont-email.me:

Putty rules!

Maybe you would know. How do you sent a file to the serial port in Putty? No, xmodem or protocol, just a dump of the file contents. I assume there's a command/control for that?

You don't.

You sftp file to rPi, then "cat file > /dev/ttyUSB" from ssh on rPi.

A simple "I don't know" would suffice.

Thanks anyway.

But i do know.

Even if you have a version of putty that can transparently forward file. It's not going to solve the delays and errors in your device. Your dumb device (without full buffering) will need time to process commands. Otherwise, it will be dropping characters. At the very minimum, insert delay between lines:

#include <stdio.h>

main() { char buf[80]; while(fgets(buf, 80, stdin) != 0) { fputs(buf, stdout); sleep(1); } }

The proper way is to read the prompt from your device and process accordingly.

Ed, you know nothing about my application. So you certainly can't predict the failures. I have done this. I'm 99% sure I used ExtraPutty. I know it works. So please stop embarrassing yourself.

Did you use it on a PC connected to your device?

Now, you are talking about PC -> rPi -> device.

You are asking for a Putty to forward from file to connection on the window, and a second Putty to forward from connection 1 to connection 2 on the rPi, which i know it does not support. If you think that's possible, please tell us how.

Rick C snipped-for-privacy@gmail.com wrote in news: snipped-for-privacy@googlegroups.com:

There needs to be a protocol. You are connecting to devices together over a connection. That is one thing, but passing files is another, and one still needs a packet routine.

The shell process is still the parent of the background process. Any output (stdout, stderr) goes to the same shell unless it was redirected. When the process terminates, its return code is given to the shell - as any process's return code is passed to its parent process. If the shell is terminated, all its child processes are terminated too - as usual in process trees.

That can depend on the ISP and the setup. The "traditional" arrangement is that you have a NAT router which gets assigned a globally valid IP by your ISP. On the LAN side of the router, you have a local network - typically something like 192.168.0.x. However, to save on IP addresses, some ISP's have NAT at a higher level too - then your router gets a local IP address on its WAN side. Basically, you have two levels of NAT routers.

If you are trying to connect from the inside of one NAT router to the inside of a different one, over the internet, then you need to know the global IP of one of the sides. That side becomes your server, and needs to have a port-forward configured so that you can get to the device or computer on the inside. (This in turn means that the device needs a fixed IP on the local network.)

If you don't have consistent IP addresses, or might have double NATing, or don't have full access to the routers, or need multiple ports, then it can be easier to have a server somewhere with a VPN setup. Then both systems connect as clients to that one server.

It's difficult to give concrete recommendations without a lot more information about what you have, what you want to achieve, and how much control you have over the systems.

Especially silly putty :-)

Yes, putty can be very useful both on Windows and Linux (but especially on Windows where you typically don't have a native ssh or telnet).