Thanks too for the suggestions. I seem to recall that you had tried spinsim with spin2gui -- did that work OK? Was there anything that I would need to change in spin2gui for this? It should be easy to add a "run with simulator" menu option to the spin2gui TCL code. In general I think TCL makes for an easy to modify GUI, I like it for that.
Eric, you are correct. I did try spinsim with spin2gui a couple of months ago. I had forgotten about that. The latest version of spinsim, 0.99, is required to make it work because of a problem I had simulating the REP command. I tried spinsim with spin2gui again tonight, and it works fine. It might be nice to add a "run with simulator" option, and also an entry that specifies the run command for the simulator. You certainly have my permission to include spinsim with spin2gui if you want.
Thanks too for the suggestions. I seem to recall that you had tried spinsim with spin2gui -- did that work OK? Was there anything that I would need to change in spin2gui for this? It should be easy to add a "run with simulator" menu option to the spin2gui TCL code. In general I think TCL makes for an easy to modify GUI, I like it for that.
Eric, you are correct. I did try spinsim with spin2gui a couple of months ago. I had forgotten about that. The latest version of spinsim, 0.99, is required to make it work because of a problem I had simulating the REP command. I tried spinsim with spin2gui again tonight, and it works fine. It might be nice to add a "run with simulator" option, and also an entry that specifies the run command for the simulator. You certainly have my permission to include spinsim with spin2gui if you want.
If there is spin2gui and spinsim already operating, how close are we to being able to have a gui SIM with watch/step for P2, as in the SASM Screen grab example I posted in another thread ?
Thanks too for the suggestions. I seem to recall that you had tried spinsim with spin2gui -- did that work OK? Was there anything that I would need to change in spin2gui for this? It should be easy to add a "run with simulator" menu option to the spin2gui TCL code. In general I think TCL makes for an easy to modify GUI, I like it for that.
Eric, you are correct. I did try spinsim with spin2gui a couple of months ago. I had forgotten about that. The latest version of spinsim, 0.99, is required to make it work because of a problem I had simulating the REP command. I tried spinsim with spin2gui again tonight, and it works fine. It might be nice to add a "run with simulator" option, and also an entry that specifies the run command for the simulator. You certainly have my permission to include spinsim with spin2gui if you want.
Thank you! spinsim is a great tool. I'd like to integrate it with spin2gui. It may take me a little while to get to it, but I think it will be a good addition.
Dave,
This looks to be as good as any place to report bugs: My first use of p2asm is pooping out a couple of warnings/errors:
$ p2asm -o ad7400.spin2
label .emit is already defined
label .emit is already defined
0: ERROR: Expected ",", but found EOL
setnib char 'file the decimal digit as BCD: bcdstr[bcdi] = chr
Without the -o option the .emit label warning goes away. The resulting ad7400.bin file is runnable although some diag values are wrong. I haven't dug into why.
PS: The source is tested and working via Pnut. Excuse the messiness, I'm just hacking from older sources.
Ah, forgot to update. It was the SETNIB error that was throwing out the prints of the decimal numbers. Once I compensated by reformatting to non-aliased syntax of that one line, then it came right. I'm using p2asm right now.
EDIT: The .emit labels aren't causing any upset as long as I don't use -o option. I don't even know what -o is for really. I still get the needed .bin file to run.
Dave,
I've found a difference between Pnut and p2asm: Using LOC reg, #@NNNNN (numerical immediate) produces code on p2asm, but Pnut gives an error. Ie: The "@" is illegal there.
Dave,
I've found a difference between Pnut and p2asm: Using LOC reg, #@NNNNN (numerical immediate) produces code on p2asm, but Pnut gives an error. Ie: The "@" is illegal there.
Eric,
It caught me out because I just did my "safe" default of #\@ without thinking too hard. p2asm treats it like the numerical value needs to be scaled from a cog address to hub address. So the machine coded number is 4x larger than what's in the source code.
I'm not convinced that that's a useful feature.
EDIT: Or, at least that is how cogexec (ORG) source is treated. Hubexec (ORGH) source might not exhibit the scaling effect.
Eric,
It caught me out because I just did my "safe" default of #\@ without thinking too hard. p2asm treats it like the numerical value needs to be scaled from a cog address to hub address. So the machine coded number is 4x larger than what's in the source code.
I'm not convinced that that's a useful feature.
EDIT: Or, at least that is how cogexec (ORG) source is treated. Hubexec (ORGH) source might not exhibit the scaling effect.
Ah... if it's in COG code then yeah, I can understand that there's lots of room for confusion! Scaling the number does sound like a bug, but it's an interesting question what @1, for example, should mean in COG code; does it mean the hub address 1 (i.e. the constant 1), or does it mean the hub address of cog address 1 (i.e. the constant 4)?
I just checked fastspin, and it errors out with "syntax error, unexpected number"; it doesn't allow @ to be applied to a number at all. I don't remember coding it that way, but perhaps it's for the best .
It was a real struggle for Chip to decide on where the addressing split should architecturally sit. I didn't have any advise at the time, but I think, now, the best answer might have been to have same for both cog space and hub space, ie: multi-scale addressing for data and only longword addressing for program.
I'll clarify what I mean there. The prefix-like ALTx instructions combined with GET/SETxxxx, eg: GETNIB, instructions are great for indexing through cogRAM at many addressing scales.
For hubRAM, the details change a little but, architecturally, the job could be the same. PTRx registers could be an index scale based on the read/write instruction in use. If RDLONG then the PTRx would operate in 32-bit scale. If RDNIB then PTRx would be 4-bit scale.
It does mean that structures with odd internal alignments will be an extra burden but those can be kept to a minimum. There is always some trade-off somewhere.
dgately uses the tools on a Mac, and I haven't heard him report this problem. Maybe it has to do with different versions of the Mac. There's only a few places in osint_linux.c that would produce this error message. It might be good to put a few debug prints to track down the cause of it.
P2ES should arrive today... I'll test and let you know if I get the same message... My FPGAs are not currently set up as P2s, else I would test right now.
Got my board today and was able to blink some LEDs with TAQOZ very happy!!!
But now I need something a little more comfortable. I started with hello.c found in the root directory of p2gcc and then compiled it and loaded it. Unfortunately, nothing showed up in the terminal
david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ cat main.c
#include <stdio.h>
#include <propeller.h>
void main(void)
{
int i;
for (i = 1; i <= 10; i++)
{
waitcnt(CNT+12000000);
printf("Hello World - %d\n", i);
}
printf("Goodbye\n");
}
david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ p2gcc main.c
david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ loadp2 -t a.out -v
Searching serial ports for a P2
P2 version A found on serial port /dev/ttyUSB0
Loading a.out - 2548 bytes
a.out loaded
[ Entering terminal mode. Press ESC to exit. ]
Try "loadp2 -m 010C1F0B -t a.out -v". This should set the P2 Eval board to run at 80MHz. I still don't have my board, so I can't try it myself. I should get the board tomorrow. It's been sitting at a UPS location that's 200 miles away for 3 days. So frustrating. Once I get the board tomorrow I'll try out various clock settings.
No luck on that attempt. I tried blinking one of the LEDs too, and am not having luck there. I tried the following code with and without the WAITCNT, but no light in both cases.
david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ cat blinky.c
#include <propeller.h>
#include <stdint.h>
const uint32_t PIN = 1;
void main () {
const uint32_t DELAY = CLKFREQ / 10;
DIRA |= PIN;
while (1) {
OUTA |= PIN;
waitcnt(CNT + DELAY);
OUTA &= ~PIN;
waitcnt(CNT + DELAY);
}
}
david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ p2gcc blinky.c -o blinky
david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ loadp2 -m 010C1F0B -v blinky
Searching serial ports for a P2
P2 version A found on serial port /dev/ttyUSB0
Loading blinky - 1108 bytes
blinky loaded
Are you sure that the C startup code doesn't set the clock mode to something that doesn't work with the P2 silicon? You may be setting it with the -m option to loadp2 but the C startup code may be overwriting that setting.
I looked at prefix.spin2, and there was a "hubset #$ff", but that was replaced by a nop some time ago. C programs depend on loadp2 to set up the clock.
The code for the secondary loader looks like this:
CON
rxpin = 63
DAT org
begin hubset clkmode 'set the clock mode
wrfast #0,address 'ready to write entire memory starting at address
setse1 #%010_000000 | rxpin 'select negative edge on p63
mainloop pollse1 'clear edge detector
waitse1 'wait for start bit
waitx waitbit1_5 'wait for middle of 1st data bit
rep @loopend,#8 'get 8 bits
testp #rxpin wc 'sample rx
rcr rxbyte,#1 'rotate bit into byte
waitx waitbit 'wait for middle of nth data bit
loopend
shr rxbyte,#32-8 'justify received byte
wfbyte rxbyte 'write to hub
djnz filesize,#mainloop 'loop until all bytes received
rdfast #0,#0 'wait for last byte to be written
coginit #0,address 'launch cog 0 from address
clkmode res 1 'clock mode
waitbit1_5 res 1 '1.5 bit cycles = 3*clock_freq/baud_rate/2 - 6
waitbit res 1 '1 bit cycles = clock_freq/baud_rate - 6
filesize res 1 'binary file size in bytes
address res 1 'starting address
rxbyte res 1 'received byte
I do the hubset at the very beginning. Maybe I need to do the two hubsets with a delay like in Cluso's code. When I get my board tomorrow I'll give that a try.
The code for the secondary loader looks like this:
..
I do the hubset at the very beginning. Maybe I need to do the two hubsets with a delay like in Cluso's code. When I get my board tomorrow I'll give that a try.
I've tested a no-delay (single HUBSET) and that is unreliable, and P2 can lock-out, even RCFAST to XTAL has issues. (more sensitive than expected).
I don't think there is a way to xor or just change lowest bits on hubset ?
Comments
Python appeals as being highly portable, and it can be made fast enough.
If there is spin2gui and spinsim already operating, how close are we to being able to have a gui SIM with watch/step for P2, as in the SASM Screen grab example I posted in another thread ?
Thank you! spinsim is a great tool. I'd like to integrate it with spin2gui. It may take me a little while to get to it, but I think it will be a good addition.
This looks to be as good as any place to report bugs: My first use of p2asm is pooping out a couple of warnings/errors: Without the -o option the .emit label warning goes away. The resulting ad7400.bin file is runnable although some diag values are wrong. I haven't dug into why.
PS: The source is tested and working via Pnut. Excuse the messiness, I'm just hacking from older sources.
@evanh, you'll probably need to convert most if the P1 code, unless Eric has added an auto-convert feature to fastspin.
EDIT: The .emit labels aren't causing any upset as long as I don't use -o option. I don't even know what -o is for really. I still get the needed .bin file to run.
Amusingly, GETNIB is fine in the aliased syntax.
I'm not using Fastspin. I'm crafting my own Prop2 assembly and using your p2asm and loadp2 individually. I had been using Pnut and loadp2.
I've found a difference between Pnut and p2asm: Using LOC reg, #@NNNNN (numerical immediate) produces code on p2asm, but Pnut gives an error. Ie: The "@" is illegal there.
I've made a note for it already: https://forums.parallax.com/discussion/comment/1457051/#Comment_1457051
To me it sounds like p2asm is doing the right thing here: "@NNNN" should mean "hub address NNNN", so I don't see why PNut wouldn't accept it.
It caught me out because I just did my "safe" default of #\@ without thinking too hard. p2asm treats it like the numerical value needs to be scaled from a cog address to hub address. So the machine coded number is 4x larger than what's in the source code.
I'm not convinced that that's a useful feature.
EDIT: Or, at least that is how cogexec (ORG) source is treated. Hubexec (ORGH) source might not exhibit the scaling effect.
Ah... if it's in COG code then yeah, I can understand that there's lots of room for confusion! Scaling the number does sound like a bug, but it's an interesting question what @1, for example, should mean in COG code; does it mean the hub address 1 (i.e. the constant 1), or does it mean the hub address of cog address 1 (i.e. the constant 4)?
I just checked fastspin, and it errors out with "syntax error, unexpected number"; it doesn't allow @ to be applied to a number at all. I don't remember coding it that way, but perhaps it's for the best
I'll clarify what I mean there. The prefix-like ALTx instructions combined with GET/SETxxxx, eg: GETNIB, instructions are great for indexing through cogRAM at many addressing scales.
For hubRAM, the details change a little but, architecturally, the job could be the same. PTRx registers could be an index scale based on the read/write instruction in use. If RDLONG then the PTRx would operate in 32-bit scale. If RDNIB then PTRx would be 4-bit scale.
It does mean that structures with odd internal alignments will be an extra burden but those can be kept to a minimum. There is always some trade-off somewhere.
I just run up fastspin and no problems there.
Only seemed to need a make to build correctly. Easier than I expected for some reason.
And thanks Dave for all of your work on P2 tools!
dgately
I get the same output, but my simple LED blinking code does not run...
TAQOZ does allow me to blink LEDs (56 - 63) at will, so I know that the P2 is running and executing code!
Guess I need to launch Win as a VM and use PNut for today's testing.
dgately
Image: Blinking LEDs in TAQOZ... loadp2 has not been successful yet, on macOS.
PNut, running in a Win VM also succeeds to run all_cogs demo.
dgately
But now I need something a little more comfortable. I started with hello.c found in the root directory of p2gcc and then compiled it and loaded it. Unfortunately, nothing showed up in the terminal
david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ cat main.c #include <stdio.h> #include <propeller.h> void main(void) { int i; for (i = 1; i <= 10; i++) { waitcnt(CNT+12000000); printf("Hello World - %d\n", i); } printf("Goodbye\n"); } david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ p2gcc main.c david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ loadp2 -t a.out -v Searching serial ports for a P2 P2 version A found on serial port /dev/ttyUSB0 Loading a.out - 2548 bytes a.out loaded [ Entering terminal mode. Press ESC to exit. ]Help?
david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ cat blinky.c #include <propeller.h> #include <stdint.h> const uint32_t PIN = 1; void main () { const uint32_t DELAY = CLKFREQ / 10; DIRA |= PIN; while (1) { OUTA |= PIN; waitcnt(CNT + DELAY); OUTA &= ~PIN; waitcnt(CNT + DELAY); } } david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ p2gcc blinky.c -o blinky david@balrog:~/reusable/Documents/Programming/Propeller2/HelloP2GCC$ loadp2 -m 010C1F0B -v blinky Searching serial ports for a P2 P2 version A found on serial port /dev/ttyUSB0 Loading blinky - 1108 bytes blinky loadedI can only SSH in and test out the original hello.c program; it didn't work. When I get home I'll check the blinky program.
CON rxpin = 63 DAT org begin hubset clkmode 'set the clock mode wrfast #0,address 'ready to write entire memory starting at address setse1 #%010_000000 | rxpin 'select negative edge on p63 mainloop pollse1 'clear edge detector waitse1 'wait for start bit waitx waitbit1_5 'wait for middle of 1st data bit rep @loopend,#8 'get 8 bits testp #rxpin wc 'sample rx rcr rxbyte,#1 'rotate bit into byte waitx waitbit 'wait for middle of nth data bit loopend shr rxbyte,#32-8 'justify received byte wfbyte rxbyte 'write to hub djnz filesize,#mainloop 'loop until all bytes received rdfast #0,#0 'wait for last byte to be written coginit #0,address 'launch cog 0 from address clkmode res 1 'clock mode waitbit1_5 res 1 '1.5 bit cycles = 3*clock_freq/baud_rate/2 - 6 waitbit res 1 '1 bit cycles = clock_freq/baud_rate - 6 filesize res 1 'binary file size in bytes address res 1 'starting address rxbyte res 1 'received byteI do the hubset at the very beginning. Maybe I need to do the two hubsets with a delay like in Cluso's code. When I get my board tomorrow I'll give that a try.I've tested a no-delay (single HUBSET) and that is unreliable, and P2 can lock-out, even RCFAST to XTAL has issues. (more sensitive than expected).
I don't think there is a way to xor or just change lowest bits on hubset ?
See the thread http://forums.parallax.com/discussion/169481/p2-eval-crystal-startup-and-capacitance-setting-tests
On my system, a wait of 62000 was roughly the threshold. (I tested with CC set for higher value, as that takes longer to start)