Is there a "Migration Guide" for PASM1 --> PASM2?
Cabbage
Posts: 37
in Propeller 2
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:
.foobarinstead of:foobarwczinstead ofwc,wznrandwrorghororg, respectivelyA 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 .loopSomeone 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.
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.
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.
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 endHi 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.
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.
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) .loopWhat 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.
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).