Welcome to the Parallax Discussion Forums, sign-up to participate.
binfile(fname): send a binary file to the P2 pauseafter(N): insert a 1ms pause after every N characters transmitted pausems(N): delay for N milliseconds recv(string): wait until string is received recvtimeout(N): set a timeout in ms for the recv() command scriptfile(fname): read script commands from file "fname" send(string): send a string to the P2 textfile(fname): send contents of a text file to the P2
loadp2 -b230400 -xTAQOZ -e "recv(TAQOZ# ) send{2 2 + . ^M}" -tThe script waits for the P2 to send the string "TAQOZ#", then sends "2 2 + ." and a carriage return (ctrl-M).
loadp2 -b230400 upython.binary -e "recv(>>> ) send(^E) textfile{myfile.py} send(^D)" -tThat script waits for the P2 to send the >>> sequence which is its prompt, then sends a ctrl-E (to enter paste mode), then sends the contents of the file "myfile.py", then sends a ctrl-D (to exit paste mode).
Can the delay time be made variable ?
A means to toggle DTR & RTS could be useful ? (in UB3, RTS reloads the Si5351A, and currently increments the upper control reply bits)
Can the script be contained in a file ? I see a send-file, but not a run file as script ?
That'll reset the chip on most P2 boards, so sounds dangerous.
No, for now the script is self contained. I guess having an option to run it from a file would be feasible. I'm not trying to solve every scripting problem here, just providing a simple way to get scripts to run in TAQOZ, micropython, and proplisp.
Thanks for the suggestions!
micropython takes up most of the P2, although my version does leave the debug area at the top of HUB ram free. Invoking it from another COG is probably possible. ozpropdev did some interesting things with running other programs alongside micropython.
My changes have mostly been in the platform independent code, and don't generally care what kind of transport is used underneath. I don't think it would be difficult to put all of this over a network instead of the serial layer, but obviously there would be some work involved on both the hardware and software sides.
When testing using TAQOZ I found it very useful to save such script files, as easy to read names, (done for the terminal pgm I use), and those include variable delays.
The flip to TAQOZ takes a finite amount of time
Here is an example of one of those tests, shows how useful terminal scripts can be...
{// is a comment, and {250} is a delay of 250ms {5} is a delay of 5ms strings inside quotes send directly, $ is hex prefix.
Some named files like this, would give users a quick series of board check operations than can do.
I copied the new loadp2 into the flexgui bin directory.
I also copied upython.py from \samples\upython\ to here as well, plus I added myfile.py which is just a single line "print('hello')"
I am on W10 and here is what I get from the command line... What did I break?
This is brilliant
Also, you probably don't strictly have to wait for the >>> prompt, there is some buffering going on and I think you could leave off the "^/>>>/" part of the script (that's the script command which waits for the prompt).
BTW I note when you exit from the >>> prompt in the command line, the terminal is left in an unusable state which means I cannot now do any more loadp2, etc. Is this fixable?
Currently I am trying to run this but I get caught up in what I think is loadp2 resetting the P2 and I have an SD Card in the slot causing the ROM to try and boot the P2. Have to step out so I will try this again when I get home.
Usually the loadp2 times out with no >>> received.
When it works, I get the os.mount(sd,'/sd') failing as below (note the sd.present() works fine).
Is the sd already mounted? I have noticed that os.mount(sd, '/sd') causes a whole lot of grief if /sd is already mounted, but if I do os.mount(sd, '/mysd') then micropython is happy and actually creates two different views of the SD card (/sd and /mysd).
After the script times out you should still be able to type commands at micropython. Is the ls function defined?
I think I need to step back and look at this some more. Perhaps a better approach would be to (optionally) have loadp2 listen on a socket for commands of things to send to the terminal and/or things to do such as resetting the board. Then it would be easy to have GUIs send scripts to the P2 at any point (as long as loadp2 is still running).
I haven’t tried entering any python after the failure. But I don’t think it’s already mounted as I retried this a number of times with everything starting from scratch and powering up the P2. Once I power the P2 I insert the SD card and then run the loadp2 command.
As to whether it’s the right approach, I don’t know.
What I would like is to launch python from the P2 from my OS ie run the upython binary from the P2. But this requires my P2 OS and I haven’t had time to get this running by recompiling the P1 spin code to p2asm yet. I’ve been hoping Chip might release a limited version of spin2 as it would be so much easier.
Have you tried fastspin? It does support compiling Spin1 on the P2.
Sorry, yes, "for" the P2. And maybe @Cluso99 is waiting for Chip's Spin2 so he can compile "on" the P2 using his OS? But I don't think the initial Spin2 release will support that.
It'll certainly be interesting to see what Chip comes up with. But in the meantime it is still possible to program the P2 in Spin.
I'm not sure how the spin1 to P2ASM would work. I haven't had time to try yet. My OS stays partially resident so there are a few gotchas that I need to rework, and I need to get Kye's spin FAT32 code converted. I've done but not tested the SD pasm driver. That was weeks ago
There is always something better to do when I get a chance - such as trying uPython.
Huh, I had forgotten that I ever did binary releases of loadp2. I guess I can do a new one, but loadp2 is still in flux. For now I suggest you use the loadp2.exe from the .zip file earlier in this thread -- it's based on the newest sources.
So, I downloaded latest FlexGUI and can't get it to load flash or RAM.
This is with my own board, so maybe that's an issue, but I don't think so.
Strange thing about this is that with SpinEdit, I can load RAM just fine using your Fastspin and loadp2.
Also, the Taqoz stuff seems to work in FlexGUI.
But, when trying to load RAM or Flash, I get:
Any idea what I might be doing wrong?
Does your board use the standard protocol for reset, using DTR/RTS? loadp2 resets the board then downloads a small helper program, which then changes the clock mode and frequency to do a fast download.
Hmmm, maybe that's the trouble; how is the clock set up on your board?
I think my clock and FTDI is exactly the same as Eval board...
I'll try a direct connection...
That didn't help...
That might slow it down a bit...
What baud is it trying to do?
Also, I have the FTDI I/O at 5V instead of 3.3 V...
This is what I get in verbose mode:
Works at 921600 too...