P1 -> P2 compatibility

knivd

I apologise in advance if this sounds like a stupid question. Still learning the software side of the Propeller.
Are objects originally written for P1, directly usable with P2, or they need porting in some way?
Thanks

Rayman

Anything useful probably needs porting.

However, there’s a slight chance that Flexprop can program P2 with P1 code and have it work.

But, Spin2 isn’t all that different from Spin1 and shouldn’t be all that hard to upgrade.

pik33

Spin is similar, but there are differences in the hardware. This means any code which use hardware components of P1 (PLLs, counters, video generators) will not work and will be hard to port (=need to write from scratch for P2 hardware).

JonnyMac

If the P1 code doesn't involve the counters or video hardware, it's usually very easy to translate. Spin2 is a super-set of Spin1, and in some cases eliminates the need for special libraries or cog-driven code. For example, I have a library for the P1 called time.spin that handles delays and delta-timing assignments. The features in the P2 make that library unnecessary.

P1 --> P2 conversion reminders

• Every method must be defined & used with parenthesis, even with no parameters.
• If a method returns a value, the name of that value must be declared after the colon on the method definition line.
• -- Bonus: The P2 can return multiple values from a method.
• Essential IO control is simplified with pinhigh(), pinlow(), pintoggle(), pinread().
• Access the cnt register through getct().
• To create a delay with system ticks use waitct().
• Smart pins can simplify complex IO.

For me, the best thing about Spin2 is the ability to run inline assembly. In some cases this allows me to free a cog. For example, I have a Dynamixel driver for the P1 that requires a cog to synthesize the high-speed UART. With P2 smart pins I now do this inline. Cogs are precious and I try to save them when I can -- the P2 feature set makes