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.
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...
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.
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...
> @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.
> @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.
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...
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)
...
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.
...
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.
> @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.
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:
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.)
> @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.
> @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.
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.
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
Comments
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
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:
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...
But, I guess I can just do inline assembly to use them, so that's good.
Using inline assembly to do DRVL to turn them on.
But, something appears strange here....
This second inline assembly does not appear to work:
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...
Maybe I should add a RET after the user's code.
> 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.
> 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.
Ok, I see now. You need the RET and the END to both be there, like this:
One is that vga.print("C") doesn't produce the expected result (actually, doesn't appear to do anything).
More serious is that:
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...
https://drive.google.com/file/d/1-46ja-PQFA0BOErJ0mWvS3miaNUAX0UO/view?usp=sharing
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:
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...
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.
Okay. It should work fine now. No known problems, at this point.
Yes, certainly there should be a report or listing file somewhere, that shows exactly what the compiler chose to do.
This: Produces this listing:
But it's not really that big...
> 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.
Can that also report the chosen values for PFD, XtalDiv, VCODiv, etc and the error from requested MHz ?
But this time I have found the problematic codeline. It's the elseif that does weird things.
If I write: then it works. If I write then i gets overwritten with 0 or -1
Andy
> 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.
> 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.
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.
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.