Shop Learn
Is there a "Migration Guide" for PASM1 --> PASM2? — Parallax Forums

Is there a "Migration Guide" for PASM1 --> PASM2?

Hi there,

I'm new to the P2 but I'm familiar with PASM1 and I'd like to continue by learning PASM2 in the same way on the new chip.

Is there such a thing as a tutorial that discusses the differences (syntax and such) between PASM1 and PASM2? Perhaps with some worked examples of translating very basic PASM1 programs into PASM2, or perhaps a generic PASM2 boilerplate code file?

I used to have a 10-line PASM1 boilerplate that had the bare minimum PASM1 code to start up a cog running PASM1 code and also setting up the clock PLL and blinking a led etc. with minimal SPIN code. It'd be good to have something like that again for P2, it made things so much easier.

Comments

  • The main differences are:

    • the instructions are different (duh). Even some that have the same name as a P1 instruction may behave differently.
    • local labels look like .foobar instead of :foobar
    • use wcz instead of wc,wz
    • There's no nr and wr
    • You can switch between assembling for hubexec mode or cogexec mode using orgh or org, respectively
    • You can use double hashes to assemble a long immediate. Note that this inserts a hidden AUGS/AUGD instruction and thus is to be avoided in performance-critical code

    A nice thing about the P2 is that it doesn't need a spin stub. A basic pin toggling program looks like this:

    CON
    _CLKFREQ = 100_000_000
    DAT
            org
            asmclk ' macro to setup clock
            rep @.loop,#0 ' infinite loop
            drvnot #56
            waitx ##20_000_000
    .loop
    

    Someone wrote a thing about converting existing PASM1 to PASM2, I think it's linked in one of the sticky posts.

  • Thanks for the example code, the Prop Tool seems to demand a "PUB routine" though.

    This is the kind of thing that isn't obvious to new users. And it's hard to find answers in the docs.

  • Wuerfel_21Wuerfel_21 Posts: 1,645
    edited 2021-04-06 18:36

    To get the Prop Tool to compile for P2, you need to actually save the file with a .spin2 extension.

    Most of this is in the documents, but you kindof have to read them top-to-bottom. A proper P2 manual is in the works, I hear.

  • Yes I'm absorbing as much of the existing official document as I can but there's a lot to take in. I've got your code working now, that's a good starting point, thank you for that :). I figured out the dipswitches on the "P2 Eval" board so I can save it to flash and then try things out quickly by downloading to RAM instead. That's sort-of like it used to be, but not quite.

    I understand the code you provided all apart from the "asmclk" thing which appears to be some kind of magic. I'll trust it for now but that's a real weird one! Not an instruction as such by the look of things. Is the Prop Tool writing some code for us in the background to simplify clock setup?

    The "rep" instruction is pretty awesome though. Looping without jump penalties? Wow.

  • JonnyMacJonnyMac Posts: 7,568
    edited 2021-04-06 19:12

    I'm not nearly as skilled at PASM as Ada, but I can say that I find PASM2 easier -- especially in terms of IO and moving values between the cog and the hub. You'll find as you peruse the P2 instruction set that there are many new instructions that take the place of two or more PASM1 instructions. In Ada's example she uses drvnot to toggle the pin. In the P1 you'd have to create a pin mask and set the dira bit, and then you could manipulate the output. While you can still do that (I believe), the new instructions make things easier. I actually chuckled out loud when I came across the movbyts instruction; with it you can rearrange the bytes in a long using a single instruction. For example, this will flip the order of the bytes but preserve the bit order within those bytes.

                    movbyts   value, #%%0123
    

    My best effort in the P1 -- while keeping the code somewhat friendly -- took six or seven instructions and a scratch variable (maybe two).

    Finally, if you're using Propeller Tool (I do), I found that doing tests with inline assembly is helping me to learn -- especially when I see a fragment posted by one of the PASM pros that I cannot immediately wrap my head around. This is a Spin2 test snippet that I start with.

    pub test_inst(value, param1, param2, flagsin) : result, flagsout
    
      org
                    testb     flagsin, #1                   wc      ' setup flags inputs
                    testb     flagsin, #0                   wz
    
                    mov       result, #0                            ' update result
    
                    bitc      flagsout, #1                          ' return updated flags
                    bitz      flagsout, #0
      end
    
  • CabbageCabbage Posts: 12
    edited 2021-04-06 20:12

    Hi Jon,

    Yes the new instruction set is the main driving force for me learning the new system. I know it's marvellous :)

    I'm not looking to inline PASM2, I mostly want to remove all SPIN entirely and just learn the bare metal stuff.

  • JonnyMacJonnyMac Posts: 7,568

    I'm not looking to inline PASM2, I mostly want to remove all SPIN entirely and just learn the bare metal stuff.

    I understand. While I do inline methods, I really enjoy being able to test small sections of PASM code without the trouble of manually launching a cog. I recently wrote an SBUS driver by first checking sections using an inline method. The finished project uses a PASM2 cog.

  • __deets____deets__ Posts: 27
    edited 2021-04-06 21:12

    @Cabbage said:
    I figured out the dipswitches on the "P2 Eval" board so I can save it to flash and then try things out quickly by downloading to RAM instead. That's sort-of like it used to be, but not quite.

    I’m on Linux using flexspin and loadp2, but from batch files. At the beginning I could only load into ram. Until I figured out that it’s just a little tweak using this https://github.com/totalspectrum/loadp2/blob/030cf2bc04a478161b10cf49cb4da493b68889cf/board/P2ES_flashloader.spin2 that enables loadp2 to also flash. This works nicely for me now, without fiddling with dip switches anymore. Just depending on a command line switch now.

  • I'm tremendously amused by the simplest of things apparently...

    DAT
            org
    
            '###############################################
            'Configure the P2's clock settings.
            'We want to run at 200 MHz as far as the code is concerned,
            '  but we're using a 20 MHz crystal, so we need to calculate the correct
            '  multiplyer, divider and PLL tap to achieve a 10x increase...
    
            'select the standard external 20 MHz crystal
            hubset          #$F0
    
            '------------------0000_000E_DDDDDD_MMMMMMMMMM_PPPP_CC_SS
            hubset          ##%0000_0001_000000_0000001001_1111_10_00  'PLL = 10x
    
            waitx           ##20_000_000 / 200      'wait for the PLL to stabilise
    
            '------------------0000_000E_DDDDDD_MMMMMMMMMM_PPPP_CC_SS
            hubset          ##%0000_0001_000000_0000001001_1111_10_11  'switch to PLL
    
            'now the P2 is running at 200 MHz !
            '###############################################
    
            rep             @.loop, #0 ' infinite loop
            drvnot          #56
            waitx           ##1_000    '~100 KHz (a bit less due to instruction overheads)
    .loop
    
    

    What a revelation! Granular control of system clock speed. Makes the math of hum-drum protocol timings something I can do in my head rather than scribbling pages of calculations. I feel sorry for my trusty old 1st-generation Saleae Logic analyser, it can't remotely keep up with the P2 at higher speeds. Might have to invest in a newer model :)

    I like writing code like this, down at the bare register level, because I know what is going on at each stage.

    The P2 is a complete beast.

  • @Cabbage said:
    I'm tremendously amused by the simplest of things apparently...

    ...

    What a revelation! Granular control of system clock speed. Makes the math of hum-drum protocol timings something I can do in my head rather than scribbling pages of calculations. I feel sorry for my trusty old 1st-generation Saleae Logic analyser, it can't remotely keep up with the P2 at higher speeds. Might have to invest in a newer model :)

    I like writing code like this, down at the bare register level, because I know what is going on at each stage.

    The P2 is a complete beast.

    Looks like the TAQOZ threads might interest you as well but beware, it's much more and it's addictive once you start using it.

  • roglohrogloh Posts: 3,219

    @Cabbage said:

    What a revelation! Granular control of system clock speed. Makes the math of hum-drum protocol timings something I can do in my head rather than scribbling pages of calculations. I feel sorry for my trusty old 1st-generation Saleae Logic analyser, it can't remotely keep up with the P2 at higher speeds. Might have to invest in a newer model :)

    I'm still using my 1st generation and have used it to debug HyperRAM and PSRAM and HDMI driver etc. The trick is to clock the P2 slowly (like at 4MHz or so). Then you can capture P2 pin state. Pin logic typically scales up in frequency. So basically debug at a slow clock speed (if you can).

Sign In or Register to comment.