Spin2 for P1

Rayman

This is probably a very remote use case, but liking the idea of using Spin2 with P1.

Just tested this basic code using FlexProp (this is probably the only option) and it works.
Code just toggles two pins on and off:

PUB Main()
    repeat
        pinh(26)
        pinl(27)
        _waitms(1000)
        pinl(26)
        pinh(27)
        _waitms(1000)

Liking that Main() has parenthesis (forced to really). This makes complex code a lot more readable.

Also, nice to be able to use pinh() and pinl() without dealing with OUTA/DIRA.

Also nice to have built in _waitms() (and probably some other things like this).

I'll have to look up how to set the clock to 80 MHz...
Maybe it does this automatically, not sure...

Rayman

The problem is that there are years and years of Spin1 code built up. And also, the third party compiler.
Still might look into this some more, just for fun...

JonnyMac

More and more I find myself programming the P1 in the style of the P2 where I can. For example, I always use a named result variable if the method returns something. In my basic P` IO library I have added pinhigh(p), pinlow(p), pintoggle(p), and pinfloat(p).

Rayman

Think "pinh" was actually supposed to be "_pinh", and so forth. Not sure why that worked anyway...

Debug seems to work in FlexProp, that is interesting:

CON
    _clkfreq = 320_000_000

PUB Main()|n
    repeat
        n++
        debug(udec(n))
        _pinh(26)
        _pinl(27)
        _waitms(1000)
        _pinl(26)
        _pinh(27)
        _waitms(1000)

Don't seem to have a handle on clock control though, this shouldn't work at 320 MHz on P1, obviously....
Can't find anything in the manual...

Wuerfel_21

@Rayman said:
The problem is that there are years and years of Spin1 code built up.

Do note that nothing stops you from using Spin1 libraries in a Spin2 top file. It's all interoperable. You do need to explicitly add the ".spin" extension to the filenames in the OBJ section, it defaults to assuming libraries have the same extension as your top file.

Rayman

@Wuerfel_21 That is a good point.

Rayman

Guess have handle on clock now, it's just the regular P1 way:

CON
  _clkmode = xtal1 + pll16x
  _clkfreq = 80_000_000

PUB Main()|n
    repeat
        n++
        debug(udec(n))
        debug(udec(cnt))
        _pinh(26)
        _pinl(27)
        _waitms(1000)
        _pinl(26)
        _pinh(27)
        _waitms(1000)

But, debug doesn't seem to work except at 80 MHz. Guess that means it was already defaulting to 80 MHz...

Rayman

Testing out some P2 accessories on P1 board with Eval style headers...

First test is LED Matrix with CONTROL.

Didn't take too much to make this Spin2 code and P2 accessories work on P1...
Had to make some changes:

• Change RX and TX for P1
• Replace serial with fullduplexserial (as P1 does not have smartpins for serial)
• In the matrix driver, just had to explicitly float the pins as Spin2 on P1 cannot apparently use pinfields
• In the random driver, had to remove the P2 style random as P1 doesn't have that
• In control, had to comment out the wrpin as P1 doesn't have smartpins

Think that was pretty much it... Should remove the clock setting code, but FlexProp appears to be ignoring that, so not a big deal.
Not actually sure if random driver is working, but maybe it is.

The CONTROL buttons seem to work, except for the one that is supposed to show "2" on the display. Should look into how to better adapt the control board...

The LED matrix looks dim to me, but also dim on P2. Think they should not have added all those 470 Ohm resistors...

Anyway, this seems like a good sign that converting P2 code (at least simple things that don't use P2 specific hardware) to work on P1 is fairly easy.

JonnyMac

Anyway, this seems like a good sign that converting P2 code (at least simple things that don't use P2 specific hardware) to work on P1 is fairly easy.

Agreed. I make a lot of my own P2-type accessory boards, and as I have a FLiP board with P2 accessory headers, I'm careful with compatibility -- for example, adding pull-ups and pull-downs since the P1 does not have those internally.

Rayman

Here's another thing that could be useful... The Spin2 way of setting individual bits in any variable seems to work:

PUB Main()|n,x
    repeat n from 0 to 31
        x.[n]~~
        debug(ubin(x))
        _waitms(1000)
    repeat

Rayman

Think have control accessory working now.
Just doing the usual thing of pulling down the pin and then floating just before reading...

This should work for P2 as well, but P2 has the internal pulldowns, which is better...

pub rd_btn(ch) : result

'' Return state of specified button
'' -- returns 1 if pressed, 0 if not pressed or invalid

    'RJA:  For P1, pulling down first and then floating and then reading
    pinl(ch)
    pinf(ch)

  case ch
    0 : result := pinread(base+5)   
    1 : result := pinread(base+4)   
    2 : result := pinread(base+7)   
    3 : result := pinread(base+6)             


pub rd_btns() : result

'' Return state of control buttons as a 4-bit value

    pinl(0)
    pinf(0)
  result.[0] := pinread(base+5) 
  pinl(1)
    pinf(1)
  result.[1] := pinread(base+4) 
  pinl(2)
    pinf(2)
  result.[2] := pinread(base+7) 
  pinl(3)
    pinf(3)
  result.[3] := pinread(base+6) 

Rayman

Inline assembly seems to work, at least one form:

PUB Main()|n,x
    x:=1<<26
    asm
        mov dira, x
        mov outa, x
    endasm
    repeat

org/end doesn't seem to work. Have to read the docs some more to remind myself of the difference...

Still, inline assembly for P1? Seems very nice.

ersmith

@Rayman said:
Inline assembly seems to work, at least one form:
org/end doesn't seem to work. Have to read the docs some more to remind myself of the difference...

That's odd, org/end should work on P1 (as long as you use P2 assembly, and as long as you're compiling to P1 asm rather than bytecode). But I just tried and there's a fit 96 being inserted there that's messing something up. I'll look into it, thanks for noticing.