Can't Wait for PropGCC on the P2?

1679111224

Comments

  • jmgjmg Posts: 13,247
    Heater. wrote: »
    Is it OK if we don't make Python a dependency for using the P2?
    Of course, there are already other loaders out there, that are not Python...
    Python appeals as being highly portable, and it can be made fast enough.

  • ersmith wrote: »
    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.

  • jmgjmg Posts: 13,247
    Dave Hein wrote: »
    ersmith wrote: »
    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 ?
  • Dave Hein wrote: »
    ersmith wrote: »
    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.
  • evanhevanh Posts: 6,623
    edited 2018-12-10 - 05:54:30
    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.

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • Dave HeinDave Hein Posts: 5,865
    edited 2018-12-10 - 16:37:54
    Could someone send a link that compares the P1 instructions to the P2? Hopefully, it also shows the new P2 local variable operator.



    @evanh, you'll probably need to convert most if the P1 code, unless Eric has added an auto-convert feature to fastspin.
  • evanhevanh Posts: 6,623
    edited 2018-12-10 - 16:39:23
    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.

    Amusingly, GETNIB is fine in the aliased syntax.

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • Got another one from a piece of Chip's test code:
    0: ERROR: Symbol p^1 is undefined when evaluating an expression
    Segmentation fault (core dumped)
    is emitted at this line
    wrpin	dacmode,#p^1		'output test level on adjacent pin DAC for ADC input
    
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • "p" is a constant so I believe that's a compile time XOR.
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • evanhevanh Posts: 6,623
    edited 2018-12-11 - 02:44:51
    Dave Hein wrote: »
    @evanh, you'll probably need to convert most if the P1 code, unless Eric has added an auto-convert feature to fastspin.

    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.

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • 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.

    I've made a note for it already: https://forums.parallax.com/discussion/comment/1457051/#Comment_1457051

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • evanh wrote: »
    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.

    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.
  • evanhevanh Posts: 6,623
    edited 2018-12-15 - 16:00:38
    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.

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • evanh wrote: »
    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.

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • Eric,
    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.

    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • I just tried building and running loadp2 on the Mac and got the following error message when I tried to load a program:
    Davids-Mac-mini:Test dbetz$ loadp2 -p /dev/cu.usbserial-DA01LDZP all_cogs_blink.binary 
    Unsupported baudrate. Use tcsetattr failed
    
    The odd thing is that the program loaded and ran fine. Is there something I can do to eliminate this error though?

    And thanks Dave for all of your work on P2 tools!
  • 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.

    dgately
    Livermore, CA (50 miles SE of San Francisco)
  • David Betz wrote: »
    I just tried building and running loadp2 on the Mac and got the following error message when I tried to load a program:
    Davids-Mac-mini:Test dbetz$ loadp2 -p /dev/cu.usbserial-DA01LDZP all_cogs_blink.binary 
    Unsupported baudrate. Use tcsetattr failed
    
    The odd thing is that the program loaded and ran fine. Is there something I can do to eliminate this error though?

    I get the same output, but my simple LED blinking code does not run...
    $ loadp2 -p /dev/cu.usbserial-P2EEI8V LED.bin 
    Unsupported baudrate. Use tcsetattr failed
    

    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
    Livermore, CA (50 miles SE of San Francisco)
  • P2Eval-Running-TAQOZ.png
    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
    934 x 818 - 2M
    Livermore, CA (50 miles SE of San Francisco)
  • 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. ]
    
    

    Help?
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: http://david.zemon.name:8111/?guest=1
  • 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
    
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: http://david.zemon.name:8111/?guest=1
  • 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.
  • Try 010C1F0B. Maybe that will work.
  • Dave Hein wrote: »
    Try 010C1F0B. Maybe that will work.

    I 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.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: http://david.zemon.name:8111/?guest=1
  • Dave HeinDave Hein Posts: 5,865
    edited 2018-12-27 - 22:14:33
    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.
  • jmgjmg Posts: 13,247
    Dave Hein wrote: »
    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 ?

    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)
Sign In or Register to comment.