Still, strange that I can use SmartSerial at 3 Mbaud with this board, in receive mode anyway...
I'll have to bring in the Eval board tomorrow and try it...
Now that I think about it, I do have 10k resistors between FTDI Tx/Rx and P2 pins...
That might slow it down a bit...
That's quite high a protection resistor, as 10k and 15pF will be 330ns rise time.
3k3 is faster and still only 1mA, 1k5 is faster still, and ~ 2mA max contention current.
Still, strange that I can use SmartSerial at 3 Mbaud with this board, in receive mode anyway...
I'll have to bring in the Eval board tomorrow and try it...
The Eval B I think includes parallel peaking capacitors
Bugger! I've been editing the wrong source file. doh!
EDIT: Okay, got it working ... yep pretty sure it's the PTRA indexing differences between v32 and v33 ... yep, proven now. Replaced all the PTRA++ with extra instruction of either ADD #4 or ADD #1 depending on whether it was a RDLONG or RDBYTE operation.
I won't post it though because I've edited too many things that didn't need editing.
I've updated the first post with a new loadp2. I've completely re-worked the scripting language. Previously it was focused on what characters to send to the P2, with cryptic escapes to implement other commands. Now it's command oriented, with a "send" command to send characters. The list of supported commands are:
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
For example, to launch micropython and tell it to print hello:
Ah, right, yeah, I noticed that at couple of days back too. It's to do with Eric's fancy multi part loading he's added to loadp2. The feature only works when not using -SINGLE.
-SINGLE loading uses the loader built into the ROM, which can only load 1 file and always loads it to 0. So it can't be used for the multi-part loading. It should be throwing an error if you try to use it with @, is it not doing that?
Oh, and I've reduced the delay to 1 second, 4 was excessive (can't remember why I did that). The short delay is to make sure the status messages have been written to serial and the user gets a chance to read them before the reset.
I've updated the first post with a new loadp2. I've completely re-worked the scripting language. Previously it was focused on what characters to send to the P2, with cryptic escapes to implement other commands. Now it's command oriented, with a "send" command to send characters. The list of supported commands are:
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
For example, to launch micropython and tell it to print hello:
Wow, very nice.
That is going to create some very nice P2 demo - wrappers, that will load-and-go.
Few questions on Terminal modes :
Can you add a simple comment echo to the terminal ? For longer board test script files, running multiple little test pgms, it's nice to say what test is being done.
I guess here simple strings, and date/time are useful tags
It is easy to capture the terminal output to a file ? I'm thinking here of logging board tests.
Is there a list somewhere of the terminal commands supported, in the 2 terminal modes ?
For more general 'quick instrument' use, I've often thought it would be nice to have a terminal mode with fewer chars/larger font, so you can read it across a room.
Not sure how easy that is to do & keep the simplicity of command line ?
Few questions on Terminal modes :
Can you add a simple comment echo to the terminal ? For longer board test script files, running multiple little test pgms, it's nice to say what test is being done.
loadp2 itself can only run one program on the P2 per invocation. The script commands are to send data to that program. For running multiple tests you would put multiple loadp2 calls into a .bat file, and you could then put "echo" commands or something similar in that .bat file to say which test you were running.
It is easy to capture the terminal output to a file ? I'm thinking here of logging board tests.
That depends on your environment. loadp2 itself is just a command line program, and all its output goes to the standard output, so you can use the usual > and | file redirection operators on it.
Is there a list somewhere of the terminal commands supported, in the 2 terminal modes ?
For more general 'quick instrument' use, I've often thought it would be nice to have a terminal mode with fewer chars/larger font, so you can read it across a room.
Not sure how easy that is to do & keep the simplicity of command line ?
loadp2 itself does no terminal emulation, that's up to whatever program runs it. FlexGUI on Windows launches a new copy of the usual Windows command terminal. I think there are registry settings and/or menu items to change the font of that. You could alternatively configure FlexGUI to use a different shell program for launching loadp2.
Is there a list somewhere of the terminal commands supported, in the 2 terminal modes ?
loadp2 itself does no terminal emulation, that's up to whatever program runs it. FlexGUI on Windows launches a new copy of the usual Windows command terminal. I think there are registry settings and/or menu items to change the font of that. You could alternatively configure FlexGUI to use a different shell program for launching loadp2.
I was looking for more info for these modes - I was guessing they at least echo the serial port to the standard output ?
[ -t ] enter terminal mode after running the program
[ -T ] enter PST-compatible terminal mode
Is there a list somewhere of the terminal commands supported, in the 2 terminal modes ?
loadp2 itself does no terminal emulation, that's up to whatever program runs it. FlexGUI on Windows launches a new copy of the usual Windows command terminal. I think there are registry settings and/or menu items to change the font of that. You could alternatively configure FlexGUI to use a different shell program for launching loadp2.
I was looking for more info for these modes - I was guessing they at least echo the serial port to the standard output ?
[ -t ] enter terminal mode after running the program
[ -T ] enter PST-compatible terminal mode
Yeah, all they do is echo the serial port to standard output. I thought I had removed the -T option, since it didn't do anything different from -t. I'll fix that, thanks.
Comments
Where I just renamed the .bin file and put it in my SpinEdit folder...
So, looks like it will work for me, thanks.
I'll have to bring in the Eval board tomorrow and try it...
3k3 is faster and still only 1mA, 1k5 is faster still, and ~ 2mA max contention current.
The Eval B I think includes parallel peaking capacitors
I just copied that over here...
No, it's for Rev B only.
EDIT: Okay, got it working ... yep pretty sure it's the PTRA indexing differences between v32 and v33 ... yep, proven now. Replaced all the PTRA++ with extra instruction of either ADD #4 or ADD #1 depending on whether it was a RDLONG or RDBYTE operation.
I won't post it though because I've edited too many things that didn't need editing.
For example, to launch micropython and tell it to print hello:
loadp2 -b230400 upython.binary -e "recv(>>> ) send{print('hello')^M}" -tIs using the flashloader still the same?
Still like this:
Doesn't seem like it does now...
I'm pretty sure when you load eeprom on P1 it reboots when done...
Maybe zero seconds is better? Why wait? I don't get it...
Is it loadp2.exe that is resetting the P2 after loading flash? Doesn't seem to...
Wait, I think I see something...
I had a "-m 010c1f08 -SINGLE" in there...
loadp2 doesn't seem to like that anymore...
Works and reboots after 4 seconds now...
Eric,
I've got one more minor fix: The smartpins are currently left engaged at the end of the second stage loading. I recommend clearing the pin configs for them. See - https://forums.parallax.com/discussion/comment/1484025/#Comment_1484025
Wow, very nice.
That is going to create some very nice P2 demo - wrappers, that will load-and-go.
Few questions on Terminal modes :
Can you add a simple comment echo to the terminal ? For longer board test script files, running multiple little test pgms, it's nice to say what test is being done.
I guess here simple strings, and date/time are useful tags
It is easy to capture the terminal output to a file ? I'm thinking here of logging board tests.
Is there a list somewhere of the terminal commands supported, in the 2 terminal modes ?
For more general 'quick instrument' use, I've often thought it would be nice to have a terminal mode with fewer chars/larger font, so you can read it across a room.
Not sure how easy that is to do & keep the simplicity of command line ?
loadp2 itself can only run one program on the P2 per invocation. The script commands are to send data to that program. For running multiple tests you would put multiple loadp2 calls into a .bat file, and you could then put "echo" commands or something similar in that .bat file to say which test you were running.
That depends on your environment. loadp2 itself is just a command line program, and all its output goes to the standard output, so you can use the usual > and | file redirection operators on it.
loadp2 itself does no terminal emulation, that's up to whatever program runs it. FlexGUI on Windows launches a new copy of the usual Windows command terminal. I think there are registry settings and/or menu items to change the font of that. You could alternatively configure FlexGUI to use a different shell program for launching loadp2.
[ -t ] enter terminal mode after running the program
[ -T ] enter PST-compatible terminal mode
Yeah, all they do is echo the serial port to standard output. I thought I had removed the -T option, since it didn't do anything different from -t. I'll fix that, thanks.