Spin2

cgracey

Rayman, if you want to send me the files that you're working on, I can get them working under PNut and tell you what I did.

Ariba

Chip
here is a code that compiles fine, but not works correct. It's a compact version extracted from a serial object, I tried to make.
The string("") pseudo methode seems not to return a valid pointer. And the dec methode does really strange things, which I was not able to debug.

Andy

Rayman

I can send the files. But, I'll take a look first to see what is not working...
There is some VGA output, it's just a blank screen though...
Update: I might be wrong about that... On a different setup, there appears to be no VGA output after all...

BTW: I think it is a mistake not to allow users to select clock dividers and multipliers.
For example, if I set:

CON _clkfreq = 250_000_001

I'd guess there's no way for your algorithm to get that last digit exactly right.
So what'd it pick? There's no way to tell...

Also, I think people just want to have their own control over the clock settings...

Rayman

I have to say that the PASM2 instructions like DRVH, DRVL, DIRL are really great to have and it's a shame they can't be accessed directly from Spin2.
But, I guess I can just do inline assembly to use them, so that's good.

Rayman

It's nice to use the EvalBoard's LEDs for debugging...

Using inline assembly to do DRVL to turn them on.
But, something appears strange here....
This second inline assembly does not appear to work:

CON _clkfreq = 297_000_000
  
    
PUB Main()|i,j,k,x,y

    org
        drvl    #57
	drvl	#56
    end

    i:=1
    
    org
        drvl    #58
    end
    
    repeat

Rayman

Chip, here are the set of files I'm working with.
You don't need all the files in this zip, some are the original FastSpin versions.
The filenames that end in "_Spin2" are ones I've tried to adapt to Spin2.

The main file is "1080p_TileDriver_Test3o.spin2".
It compiles, but doesn't appear to be working properly...

This is a fairly large code that includes several assembly cogs and garryj's USB kb/mouse too.

Note: That I gave up on trying to adapt SmartSerial and just commented that part all out...

cgracey

Rayman, at this time, inline assembly code needs a RET, which could be a _RET_.

Maybe I should add a RET after the user's code.

cgracey

> @Rayman said:
> I can send the files. But, I'll take a look first to see what is not working...
> There is some VGA output, it's just a blank screen though...
> Update: I might be wrong about that... On a different setup, there appears to be no VGA output after all...
>
> BTW: I think it is a mistake not to allow users to select clock dividers and multipliers.
> For example, if I set: CON _clkfreq = 250_000_001
>
>
> I'd guess there's no way for your algorithm to get that last digit exactly right.
> So what'd it pick? There's no way to tell...
>
> Also, I think people just want to have their own control over the clock settings...

You can specify frequency tolerance through (I think, will confirm in a bit) _FREQTOL, which can be set to zero. The compiler will error if it can't meet the requirement.

I went through a lot of deliberation about allowing any user setting, but it becomes very complex to validate what somebody might put in. This way, it's validated and optimal. If you want to do strange things, you can do them at run time.

cgracey

> @Rayman said:
> I have to say that the PASM2 instructions like DRVH, DRVL, DIRL are really great to have and it's a shame they can't be accessed directly from Spin2.
> But, I guess I can just do inline assembly to use them, so that's good.

For setting the LEDs in Spin2, it's easy to use PINWRITE(56 ADDPINS 7, value). There are quite few PASM instructions for doing pin operations, but for Spin2, I boiled them down to a few high-level instructions.

Rayman

cgracey wrote: »

Rayman, at this time, inline assembly code needs a RET, which could be a _RET_.

Maybe I should add a RET after the user's code.

Ok, I see now. You need the RET and the END to both be there, like this:

    org
        drvl    #57
	drvl	#56
    	ret
    end
    i:=1
    
    org
        drvl    #58
    	ret
    end
    repeat

Rayman

I troubleshooted the files I posted using the leds a bit and find two issues so far...

One is that vga.print("C") doesn't produce the expected result (actually, doesn't appear to do anything).

More serious is that:

vga.print_string(string("Hello, welcome to the P2 tile driver"))

Makes it go off the rails... All the LEDS go off and it sometimes doesn't want to reload...
Maybe this is related to the string issue that Ariba mentioned...

cgracey

Here is how you can set up the clock in PNut:

CON
  _clkfreq = 250_000_000	'Set 20MHz-crystal + PLL mode (%10_11)
' _errfreq = 1_000		'(optional error tolerance)

CON
  _xtlfreq =  12_000_000	'Set crystal + PLL mode (_xtlfreq >= 16MHz ? %10_11 : %11_11)
  _clkfreq = 148_500_000
' _errfreq = 100		'(optional error tolerance)

CON
  _xinfreq =   4_000_000	'Set input + PLL mode (%01_11)
  _clkfreq = 320_000_000
' _errfreq = 0			'(optional error tolerance)

CON
  _xtlfreq =  24_000_000	'Set crystal mode (_xtlfreq >= 16MHz ? %10_10 : %11_10)

CON
  _xinfreq =  50_000_000	'Set input mode (%01_10)

CON
  _rcfast			'Set RCFAST mode (%00_00) - this is the default clock mode

CON
  _rcslow			'Set RCSLOW mode (%00_01)

After compilation:

clkmode_			'constant which contains the clock mode for HUBSET use
clkfreq_			'constant which contains the clock frequency

clkmode				'Spin2 variable which contains the current clock mode (LONG[$40])
clkfreq				'Spin2 variable which contains the current clock mode (LONG[$44])


For Spin2 programs, PASM code can do 'RDLONG/WRLONG data,#@clkmode/@clkfreq'.

Pure PASM programs can use clkmode_/clkfreq_:

	HUBSET	##clkmode_ & !3		'start crystal/PLL, stay in RCFAST
	WAITX	##20_000_000/100	'wait 10ms
	HUBSET	##clkmode_		'switch to crystal/PLL

cgracey

I am fixing the string() problem. I had overlooked updating this when I made changes to the compiler for Spin2.

cgracey

Here is the newest, with STRING() working properly:

https://drive.google.com/file/d/1-46ja-PQFA0BOErJ0mWvS3miaNUAX0UO/view?usp=sharing

cgracey

Ariba wrote: »

Chip
here is a code that compiles fine, but not works correct. It's a compact version extracted from a serial object, I tried to make.
The string("") pseudo methode seems not to return a valid pointer. And the dec methode does really strange things, which I was not able to debug.

Andy

Andy, there was a problem with the string() thing. I posted a new version just above this post. Download that one.

Here is your code working. I changed the dec() method to make it easier for me to understand:

CON
  _clkfreq = 160_000_000
  baud     = 115200

PUB MyTest() | n
  waitms(1000)
  pinstart(62, %0000_0000_000_0000000000000_01_11110_0, (clkfreq/baud)<<16 + 7, 0)
  waitms(2000)
  hex($ABCDEF,8)
  str(string(13,10,"Hello",13,10))
  dec(-54321)
  repeat n from 32 to 127
    tx(n)

PUB tx(c)
  wypin(62,c)
  repeat until pinread(62)
  akpin(62)

PUB str(stringptr)
  repeat strsize(stringptr)
    tx(byte[stringptr++])

PRI dec(value) | flag, place, digit
  if value < 0
    -= value
    tx("-")
  flag~
  place := 1_000_000_000
  repeat
    if flag ||= (digit := value / place // 10) or place == 1
      tx("0" + digit)
  while place /= 10

PUB hex(value, digits)
  value <<= (8 - digits) << 2
  repeat digits
    tx(lookupz((value ROL= 4) & $F : "0".."9", "A".."F"))
  tx(32)

Ariba

cgracey wrote: »

...
Here is your code working. I changed the dec() method to make it easier for me to understand:

Thank you. Sorry if it's hard for you to understand the code, the dec methode I used is taken from the Spin1 TV_Text object (with some modifications to compile with Spin2). The comment at begin in TV_Text says: " Author: Chip Gracey , Copyright (c) 2006 Parallax, Inc.". ;-)

But the real problem is, that this is valid code, and it does not work. Something is wrong with the compiler or the interpreter. If I try to debug it, I get strange intermediate results for the division and the modulo. Also I get different results with i /= 10 and i := i / 10 for example. if I try the same operators separatly in the main methode, they work.

I will try with the newest PNUT version later...

cgracey

Ariba wrote: »

cgracey wrote: »

...
Here is your code working. I changed the dec() method to make it easier for me to understand:

Thank you. Sorry if it's hard for you to understand the code, the dec methode I used is taken from the Spin1 TV_Text object (with some modifications to compile with Spin2). The comment at begin in TV_Text says: " Author: Chip Gracey , Copyright (c) 2006 Parallax, Inc.". ;-)

That sounds about right.

But the real problem is, that this is valid code, and it does not work. Something is wrong with the compiler or the interpreter. If I try to debug it, I get strange intermediate results for the division and the modulo. Also I get different results with i /= 10 and i := i / 10 for example. if I try the same operators separatly in the main methode, they work.

I fixed the multiply-divide-assign bug a few days ago. I had redone the SKIPF patterns a while ago and had an incorrect bit in every one.

I will try with the newest PNUT version later...

Okay. It should work fine now. No known problems, at this point.

jmg

Rayman wrote: »

BTW: I think it is a mistake not to allow users to select clock dividers and multipliers.
For example, if I set:

CON _clkfreq = 250_000_001

I'd guess there's no way for your algorithm to get that last digit exactly right.
So what'd it pick? There's no way to tell...

Yes, certainly there should be a report or listing file somewhere, that shows exactly what the compiler chose to do.

cgracey

jmg wrote: »

Rayman wrote: »

BTW: I think it is a mistake not to allow users to select clock dividers and multipliers.
For example, if I set:

CON _clkfreq = 250_000_001

I'd guess there's no way for your algorithm to get that last digit exactly right.
So what'd it pick? There's no way to tell...

Yes, certainly there should be a report or listing file somewhere, that shows exactly what the compiler chose to do.

This:

CON _clkfreq = 250_000_000

PUB go()

Produces this listing:

TYPE: 40   VALUE: 0EE6B280   NAME: _CLKFREQ
TYPE: 54   VALUE: 00000000   NAME: GO
TYPE: 40   VALUE: 010418FB   NAME: CLKMODE_
TYPE: 40   VALUE: 0EE6B280   NAME: CLKFREQ_


CLKMODE:   $010418FB
CLKFREQ: 250,000,000
XINFREQ:  20,000,000


Redundant OBJ bytes removed:           0

OBJ bytes:          12
VAR bytes:           4

00000- 08 00 00 80 0A 00 00 00 00 04 00 00               '............'

Rayman

I tried the latest, but I get a "Method is too large to accommodate String() instances" error.
But it's not really that big...

cgracey

> @Rayman said:
> I tried the latest, but I get a "Method is too large to accommodate String() instances" error.
> But it's not really that big...

Okay. Sorry about that. It uses an RFVAR word to handle the string offset from the object base. It's range is 0..$3FFF. I need to make it relative to the method, not the entire object. In the meantime, if you can make your object within 16KB, it will work. I should have this fixed within an hour.

jmg

cgracey wrote: »

Produces this listing:

Can that also report the chosen values for PFD, XtalDiv, VCODiv, etc and the error from requested MHz ?

Ariba

Sorry, the dec methode from my example does still not work correct with the version 34c.
But this time I have found the problematic codeline. It's the elseif that does weird things.
If I write:

    else
     if r or i==1
      tx("0")

then it works. If I write

    elseif r or i==1
      tx("0")

then i gets overwritten with 0 or -1

Andy

Wuerfel_21

Isn't RFVAR able to handle much longer values, anyways? Why limit it to 2 bytes? (Is a method larger than 16K ever going to happen though? Maybe if there's a lot strings, I guess.)

cgracey

> @Wuerfel_21 said:
> Isn't RFVAR able to handle much longer values, anyways? Why limit it to 2 bytes? (Is a method larger than 16K ever going to happen though? Maybe if there's a lot strings, I guess.)

It was limited to two bytes because I was going back and patching it later and did not have another pass in which to figure out exactly how big it needed to be. I figured two bytes would be sufficient.

Meanwhile, I just thought of a better way to do this. I'll have a single bytecode followed by a single byte for length which will simply jump over the string and push the string address onto the stack. This will require no fix up after the method is compiled.

cgracey

> @Ariba said:
> Sorry, the dec methode from my example does still not work correct with the version 34c.
> But this time I have found the problematic codeline. It's the elseif that does weird things.
> If I write: else if r or i==1 tx("0")
>
> then it works. If I write elseif r or i==1 tx("0")
>
> then i gets overwritten with 0 or -1
>
> Andy

Andy, Thanks for trying it. I will be back in the shop in a few minutes and will address this. Should be fixed in an hour.

ozpropdev

Hi Chip
In your next release of Pnut can you make it always generate a LST file rather than having to manually do a CTRL L CTRL S every time ypu compile.
This will ensure the symbol data isl always current.

Rayman

Will it be safe to use asm block to setup an interrupt inside the spin2 cog?

ozpropdev

Chip
I'm working on bringing my debugger up to date.
Can you post a list of the symbol type values used by Pnutt V34c.
Here's what I have worked out so far.

Symbol types for Pnut V34c

TYPE:	Description
=========================
40	Constant Integer
41	Constant Float
49	BYTE
4A	WORD
4B	LONG
4C	RES
50	Object
54	PUB/PRI

ozpropdev

and

46	VAR BYTE
47	VAR WORD
48	VAR LONG

and

45	LOCAL LONG?