I thought -T echoed a CRLF after a RETURN is entered and -t didn't do any echoing.
I think propeller-load may do that, but as far as I know loadp2 has never done anything special for -T. I'm not sure what "PST-compatible" terminal mode would mean in the P2 context; we don't emulate the PST control codes, so it's probably better to just stick with a straight pass-through.
Whoops, I'm absolutely wrong there. I'm not sure where I got the idea that -T did nothing, but you're right David, -T mode seems to automatically change \r to \r\n. I must have misread the code earlier. Sorry for the confusion.
Should I just get rid of the -SINGLE and the load crystal setting options in SpinEdit?
That depends on if loadp2's -PATCH is used or not. If it is then the answer is yes, if not then you can keep your existing code as is. The -CHIP option defaults to RCFAST hand-off, same as -SINGLE, these days.
I posted this on another thread, but there's a new loadp2 version with a built-in 9P remote file system server to allow the P2 to access the host's files. I've only tested it under Linux and the sample code is limited (it just opens and prints a file from the host) but the code theoretically should support all file system operations -- the server side is taken from the Plan 9 u9fs.c, which is a complete implementation. Incidentally one of the authors of that code is Ken Thompson, who's also famous as a co-creator of C and Unix.
Interesting... I'm trying to think of a use case for that though...
It lets the P2 read files from the PC for any purpose at all. I think there are some interesting use cases... for example programming flash with files that are too large to fit in the P2's HUB memory. Or putting it in micropython and running Python scripts from the PC. Or loading pictures from a connected Raspberry Pi.
Could this also be used to transfer files from PC to uSD on P2 board?
on macOS, this feature (read files from the PC) returns a segmentation fault... Which is difficult to diagnose as it gives very little data on the actual problem.
You'll have to give the "-9 <dir>" flag to enable the file server (e.g. "-9." to look for files in the current directory). WIthout it the file server protocol data should have been ignored, but there was another bug that caused it to try to process file server events even though the file server wasn't initialized. That was the cause of the segmentation fault, which should be fixed now.
You'll have to give the "-9 <dir>" flag to enable the file server (e.g. "-9." to look for files in the current directory). WIthout it the file server protocol data should have been ignored, but there was another bug that caused it to try to process file server events even though the file server wasn't initialized. That was the cause of the segmentation fault, which should be fixed now.
One is hopefully simple, could you change the Title Bar of the Terminal of loadp2 from "Propeller Output" to the serial port used, or even better make it accessible via cmd-line option?
I am now running multiple P1 and P2 boards from the same computer and get often confused of who is who on my screen.
And the second wish would be to create a binary for windows with your plan9 server in there, I can't make a 'make zip' I have just windows.
I looked at your code and I see a Plan9 server doable on a P2, but the main thing you did is that a P2 now can access Linux/Mac and hopefully Windows as File-System server.
This is huge.
Writing Data of instrumentation, communication to other systems, very promising me thinks.
Mike: I think the new binary release of FlexGUI (4.0.5) should satisfy your requests.
Beware, it does look like the file server is opening files in text mode on Windows (thanks, Microsoft ) so sending binary data to the host might have issues. Text data seems to work fine though.
I've updated the loadp2 binary release on github to have the latest version, which fixes a bug in the -ZERO option to clear memory (it was clearing the debug area, which it shouldn't have) and also made -NOZERO the default. This release also includes the file server test programs to test reading files from the host. You'll need fastspin or FlexGUI to compile those, although the C test program is probably pretty easy to port to another C compiler on the P2.
Comments
Whoops, I'm absolutely wrong there. I'm not sure where I got the idea that -T did nothing, but you're right David, -T mode seems to automatically change \r to \r\n. I must have misread the code earlier. Sorry for the confusion.
Could this also be used to transfer files from PC to uSD on P2 board?
It lets the P2 read files from the PC for any purpose at all. I think there are some interesting use cases... for example programming flash with files that are too large to fit in the P2's HUB memory. Or putting it in micropython and running Python scripts from the PC. Or loading pictures from a connected Raspberry Pi.
Sure, if combined with a uSD driver for the P2.
dgately
Duh, on my part... Works!
dgately
One is hopefully simple, could you change the Title Bar of the Terminal of loadp2 from "Propeller Output" to the serial port used, or even better make it accessible via cmd-line option?
I am now running multiple P1 and P2 boards from the same computer and get often confused of who is who on my screen.
And the second wish would be to create a binary for windows with your plan9 server in there, I can't make a 'make zip' I have just windows.
I looked at your code and I see a Plan9 server doable on a P2, but the main thing you did is that a P2 now can access Linux/Mac and hopefully Windows as File-System server.
This is huge.
Writing Data of instrumentation, communication to other systems, very promising me thinks.
Mike
Beware, it does look like the file server is opening files in text mode on Windows (thanks, Microsoft
Regards,
Eric