There is a problem with pnut v34r if an SD Card is present (without a valid boot file) and all switches OFF on P2EVAL Rev2, silicon RevB.
pnut cannot find the P2, and hence I cannot test with the SD Driver. It works fine with LoadP2 from Eric's latest Flexgui 4.1.8.
I suspect that pnut is not waiting long enough for the ROM SD boot code to determine there is no valid file and return to the booter serial. I can see the LEDs flashing as the ROM SD boot code tries the SD card (and possibly the Flash boot code too).
Hi Chip I am having issues with Spin2 when using '++' indexing with hub ops.
It works Ok for BYTE but not for WORD and LONG.
Never mid. A bit of isolation craziness.
I'm feeling better now
'This code works fine
pub is_closed()|x,y,z
repeat
x := @patterns
z := byte[x++]
repeat z
pint(byte[x++])
waitms(500)
dat orgh
patterns byte 3
byte 56,57,58
But the following examples fail.
'This code fails
pub is_closed()|x,y,z
repeat
x := @patterns
z := word[x++]
repeat z
pint(word[x++])
waitms(500)
dat orgh
patterns word 3
word 56,57,58
'This code fails too.
pub is_closed()|x,y,z
repeat
x := @patterns
z := long[x++]
repeat z
pint(long[x++])
waitms(500)
dat orgh
patterns long 3
long 56,57,58
Hi Chip I am having issues with Spin2 when using '++' indexing with hub ops.
It works Ok for BYTE but not for WORD and LONG.
Never mid. A bit of isolation craziness.
I'm feeling better now
'This code works fine
pub is_closed()|x,y,z
repeat
x := @patterns
z := byte[x++]
repeat z
pint(byte[x++])
waitms(500)
dat orgh
patterns byte 3
byte 56,57,58
But the following examples fail.
'This code fails
pub is_closed()|x,y,z
repeat
x := @patterns
z := word[x++]
repeat z
pint(word[x++])
waitms(500)
dat orgh
patterns word 3
word 56,57,58
'This code fails too.
pub is_closed()|x,y,z
repeat
x := @patterns
z := long[x++]
repeat z
pint(long[x++])
waitms(500)
dat orgh
patterns long 3
long 56,57,58
That's because x++ always increments by ONE, not two or four. This caught me, too, the other day.
To do what you are thinking, you'd need to do this:
z := long[base][x++]
...where x is an indexed that gets multiplied by four in this case.
Chip,
I have this piece of code where I need the address of the string "testString". How do I do it?
ser.TxHex8(testString) ' print hex value of testString
ser.TxCR()
ser.TxHex8(@testString) ' print hex value of @testString
ser.TxCR()
ser.TxHex8(@@testString) ' print hex value of @@testString
ser.TxCR()
.....
DAT
orgh
byte $3a[64]
testString byte "A test string",10,13,0
In each of the above cases the address of testString is returned as $A0D but I have confirmed that it is at hub $1060 when spin is running.
Please, how do I find out the address of the string in order to print it out?
The @@ is used to add the object's run time base address to some value, which value is intended to be an offset within the object of some resource. If you look in the Spin2 doc file, you can see this demonstrated.
I'm just learning spin2, please be kind with your replies, also trying to understand what is going on with @@SymbolName.
In the spin2 doc file there is this
'@@SymbolName' will convert an '@Symbol' in the data to an absolute address (see "DAT Data Pointers")
and
in Spin2, @@StrList[i] will return address of Str0..
So @@SymbolName returns the absolute address of @SymbolName, and that can be indexed to obtain the value at the indexed position within that object. This seems to mean that without an index it should return the absolute address of @SymbolName only. Am I wrong here?
I took the liberty to modify ozpropdev's code to demonstrate what I am seeing.
teststring returns the value of the first character in teststring, and @teststring returns the address of teststring, they are correct in both Fastspin and PNut.
@@teststring is computed differently though, and it seemingly appears to be incorrect in both, if what the spin doc implied is correct.
The Fastspin values are @teststring=$007c0 and @@teststring=$007c1. The PNut values are @teststring=$01050 and @@teststring=$01039.
con
_clkfreq = 200_000_000
clksperbit = (_clkfreq / 230400) << 16
pub main()
pinstart(62,p_async_tx + p_tt_01,clksperbit | 8-1,0)
hex(teststring,2)
tx_byte(32)
hex(@teststring,5)
tx_byte(32)
hex(@@teststring,5)
tx_byte(10)
print(@teststring)
tx_byte(32)
print(@@teststring)
tx_byte(10)
tx_chars(@teststring,4)
tx_byte(10)
repeat
pub print(x)|c
repeat
c := byte[x++]
if not c
return
tx_byte(c)
pub tx_byte(char)
org
rdpin ina,#62 wc
if_c jmp #$-1
wypin char,#62
end
pub hex(value,digits)
tx_byte("$")
value rol= (8-digits) * 4
repeat digits
tx_byte(lookupz((value rol= 4) & $f:"0".."9","a".."f"))
PUB tx_chars(char,x) | i
i := 0
repeat while i < x
tx_byte(byte[char++])
i++
dat orgh
byte $3a[64]
testString byte "A test string",10,13,0
Ouput of Fastspin .binary
$41 $007c0 $007c1
A test string
test string
A te
Output of PNut .bin
$41 $01050 $01039
A test string
:::::::::::::::::::::::A test string
A te
But it still doesn't answer why the @@teststring addresses are what they are. They don't seem to point correctly to the object in either case. Fastspin points one byte beyond @teststring and PNut points 23 bytes before @teststring. Something seems amiss.
Thought of using C/C++ instead, but am intrigued with spin2 and this chip.
con
_clkfreq = 180_000_000
clksperbit = (_clkfreq / 460800) << 16
pub main()|i
pinstart(62,p_async_tx + p_tt_01,clksperbit | 8-1,0)
repeat
repeat i from 0 to 4
print(@@list[i])
print(string(13,10))
waitms(500)
pub print(x)|c
repeat
c := byte[x++]
if not c
return
tx_byte(c)
pub tx_byte(char)
org
rdpin ina,#62 wc
if_c jmp #$-1
wypin char,#62
end
dat orgh
list word @zero
word @one
word @two
word @three
word @four
zero byte "Zero",0
one byte "One",0
two byte "Two",0
three byte "Three",0
four byte "Four",0
Once you lose confidence in a tool (ie addressing) you tend not to look for a bug in your own code when you have an addressing bug
Found my bug. Simple mistake - always the way!
ozpropdev, I've got it now. I used "list long @teststring" printed the string using print(@@list) , then printed the address using hex(@@list,5) and it matched the start of teststring addresses that I was expecting to see. All is good!
Thanks to everyone,
Larry
EDIT: Much like any pointer, don't use @@something without first assigning a valid address for @@ to use. See my next post below
To close the loop on this I was able to print teststring using this, but it only works in Fastspin this way as, I believe, the relative offset to teststring in PNut is calculated incorrectly in ver 34r. May want to look into that...
print(@@@teststring)
The @teststring is supposed to provide the address that the @@ needs to function correctly as the spin2 doc clearly states. I missed that part, sorry for the noise Chip.
A bug was fixed where nested bitfields weren't compiling correctly.
Size overrides were added for data declarations:
BYTE 0,1,2, WORD 1000, LONG 10_000_000, FVAR 100, FVARS -100
This way, you can embed data of different sizes into BYTE/WORD/LONG declarations. The FVAR/FVARS are variably-size data for reading via RFVAR/RFVARS.
In this new release is a parser for building compilers. It is demonstrated in parser.spin2. You need to have a VGA monitor connected to P8..P15 pins, or change the comments around to enable HDMI or HDTV to see it work.
The parser works with a symbol engine to recognize keywords and operators. It also resolves all integer constant types.
In this picture of the VGA monitor, you can see what it does. It converted the 5-line Spin2 file at the top of the screen into 2-long element records which are elaborated in the list below.
This is the base building block for realizing a complete Spin2 compiler. All the data are present in the CON and DAT blocks which define the symbols used by the Spin2 compiler. You can swap those tables out with your own to make any other compiler.
You just call the elementizer and it goes through your source file, converting everything it sees into 2-long records that look like this:
Element record structure
----------------------------------------------
word offset from last in source
byte length in source
byte type
long value, or symbol hash if type_undefined
Once this is done, you no longer need to look at the source code. Everything is identified, except for undefined symbols, which are pointed to and hash values are kept for, so that a call to find_symbol retrieves the value, once established.
I will write the next layer now which gets the next or previous element, resolving any undefined symbols when possible.
Is it supposed to default back to the original size or sustain the size until a new size?
For example
stuff byte "abcdefgh",long 1,2,3,4,word $11,$22,$33,$44
'has to be written this way for it to work
stuff byte "abcdefgh",long 1,long 2,long 3,long 4,word $11,word $22,word $33,word $44
Is it supposed to default back to the original size or sustain the size until a new size?
For example
stuff byte "abcdefgh",long 1,2,3,4,word $11,$22,$33,$44
'has to be written this way for it to work
stuff byte "abcdefgh",long 1,long 2,long 3,long 4,word $11,word $22,word $33,word $44
When a size override occurs, it's just for that one single value.
A bug was fixed where nested bitfields weren't compiling correctly.
Size overrides were added for data declarations:
BYTE 0,1,2, WORD 1000, LONG 10_000_000, FVAR 100, FVARS -100
This way, you can embed data of different sizes into BYTE/WORD/LONG declarations. The FVAR/FVARS are variably-size data for reading via RFVAR/RFVARS.
In this new release is a parser for building compilers. It is demonstrated in parser.spin2. You need to have a VGA monitor connected to P8..P15 pins, or change the comments around to enable HDMI or HDTV to see it work.
The parser works with a symbol engine to recognize keywords and operators. It also resolves all integer constant types.
In this picture of the VGA monitor, you can see what it does. It converted the 5-line Spin2 file at the top of the screen into 2-long element records which are elaborated in the list below.
This is the base building block for realizing a complete Spin2 compiler. All the data are present in the CON and DAT blocks which define the symbols used by the Spin2 compiler. You can swap those tables out with your own to make any other compiler.
You just call the elementizer and it goes through your source file, converting everything it sees into 2-long records that look like this:
Element record structure
----------------------------------------------
word offset from last in source
byte length in source
byte type
long value, or symbol hash if type_undefined
Once this is done, you no longer need to look at the source code. Everything is identified, except for undefined symbols, which are pointed to and hash values are kept for, so that a call to find_symbol retrieves the value, once established.
I will write the next layer now which gets the next or previous element, resolving any undefined symbols when possible.
Your parser code is interesting. I thought you might extend Spin2 to include object pointers or references to allow you to create the symbol table as a linked list of symbol objects but it looks like you've decided to implement the symbol structures as arrays of bytes and manually pack and unpack them. I'm addicted to structures in C and couldn't live without them.
The file \\MYBOOKLIVEDUO\Network\Robotics\Prop2\PNut_v34s\PNut_v34s.exe is infected with Gen:Variant.Jacard.175961. Bitdefender blocked this item, your device is safe.
I managed to add it as an exception to get it to run but am unable to make a backup on a different drive.
Trying to get PNut command line options to work in either command prompt or powershell on Windows 10. All PNut commands open PNut but do not execute the command.
Perhaps try to upload pnut.exe to virustotal to make sure it is NOT infected on your computer
If it is clean define some exceptions for bitdefender to no scan the original folder
Of pnut.exe and the intended backup folder
I myself use only the Microsoft integrated Vitus engine of win10 with no problem at all
Trying to get PNut command line options to work in either command prompt or powershell on Windows 10. All PNut commands open PNut but do not execute the command.
Trying to get PNut command line options to work in either command prompt or powershell on Windows 10. All PNut commands open PNut but do not execute the command.
EDIT: Interestingly, the bug is not an encoding error but rather something about symbols. If I give it a numerical absolute address then the relative encoding to the instruction is fine.
Comments
Of course there are differences tho' I see some similarities here between spin1 and spin2.
There is a problem with pnut v34r if an SD Card is present (without a valid boot file) and all switches OFF on P2EVAL Rev2, silicon RevB.
pnut cannot find the P2, and hence I cannot test with the SD Driver. It works fine with LoadP2 from Eric's latest Flexgui 4.1.8.
I suspect that pnut is not waiting long enough for the ROM SD boot code to determine there is no valid file and return to the booter serial. I can see the LEDs flashing as the ROM SD boot code tries the SD card (and possibly the Flash boot code too).
Code (while not really relevant) is here. It compiles with both pnut and flexgui(fastspin) but I cannot verify that it works on pnut.
forums.parallax.com/discussion/171539/p2-sd-pasm-driver-demo-using-spin2-also-uses-serial-monitor
I haven't had time to try the switches to force serial - maybe tonight.
I am having issues with Spin2 when using '++' indexing with hub ops.
It works Ok for BYTE but not for WORD and LONG.
Never mid. A bit of isolation craziness.
I'm feeling better now
That's because x++ always increments by ONE, not two or four. This caught me, too, the other day.
To do what you are thinking, you'd need to do this:
z := long[base][x++]
...where x is an indexed that gets multiplied by four in this case.
I have this piece of code where I need the address of the string "testString". How do I do it?
ser.TxHex8(testString) ' print hex value of testString ser.TxCR() ser.TxHex8(@testString) ' print hex value of @testString ser.TxCR() ser.TxHex8(@@testString) ' print hex value of @@testString ser.TxCR() ..... DAT orgh byte $3a[64] testString byte "A test string",10,13,0In each of the above cases the address of testString is returned as $A0D but I have confirmed that it is at hub $1060 when spin is running.Please, how do I find out the address of the string in order to print it out?
Cluso,
I just use '@teststring' in spin2 to get the address.
The following code produces this output The second address is the @teststring address which must be correct for the print method to work properly.
con _clkfreq = 180_000_000 clksperbit = (_clkfreq / 460800) << 16 pub main() pinstart(62,p_async_tx + p_tt_01,clksperbit | 8-1,0) repeat hex(teststring,5) tx_byte(32) hex(@teststring,5) tx_byte(32) hex(@@teststring,5) tx_byte(32) print(@teststring) waitms(500) pub print(x)|c repeat c := byte[x++] if not c return tx_byte(c) pub tx_byte(char) org rdpin ina,#62 wc if_c jmp #$-1 wypin char,#62 end pub hex(value,digits) tx_byte("$") value rol= (8-digits) * 4 repeat digits tx_byte(lookupz((value rol= 4) & $f:"0".."9","a".."f")) dat orgh byte $3a[64] testString byte "A test string",10,13,0The @@ is used to add the object's run time base address to some value, which value is intended to be an offset within the object of some resource. If you look in the Spin2 doc file, you can see this demonstrated.
In the spin2 doc file there is this
and
So @@SymbolName returns the absolute address of @SymbolName, and that can be indexed to obtain the value at the indexed position within that object. This seems to mean that without an index it should return the absolute address of @SymbolName only. Am I wrong here?
I took the liberty to modify ozpropdev's code to demonstrate what I am seeing.
teststring returns the value of the first character in teststring, and @teststring returns the address of teststring, they are correct in both Fastspin and PNut.
@@teststring is computed differently though, and it seemingly appears to be incorrect in both, if what the spin doc implied is correct.
The Fastspin values are @teststring=$007c0 and @@teststring=$007c1. The PNut values are @teststring=$01050 and @@teststring=$01039.
con _clkfreq = 200_000_000 clksperbit = (_clkfreq / 230400) << 16 pub main() pinstart(62,p_async_tx + p_tt_01,clksperbit | 8-1,0) hex(teststring,2) tx_byte(32) hex(@teststring,5) tx_byte(32) hex(@@teststring,5) tx_byte(10) print(@teststring) tx_byte(32) print(@@teststring) tx_byte(10) tx_chars(@teststring,4) tx_byte(10) repeat pub print(x)|c repeat c := byte[x++] if not c return tx_byte(c) pub tx_byte(char) org rdpin ina,#62 wc if_c jmp #$-1 wypin char,#62 end pub hex(value,digits) tx_byte("$") value rol= (8-digits) * 4 repeat digits tx_byte(lookupz((value rol= 4) & $f:"0".."9","a".."f")) PUB tx_chars(char,x) | i i := 0 repeat while i < x tx_byte(byte[char++]) i++ dat orgh byte $3a[64] testString byte "A test string",10,13,0Ouput of Fastspin .binary
Output of PNut .bin
FastSpin is based on absolute addressing whereas pnut is relative addressing...
But it still doesn't answer why the @@teststring addresses are what they are. They don't seem to point correctly to the object in either case. Fastspin points one byte beyond @teststring and PNut points 23 bytes before @teststring. Something seems amiss.
Thought of using C/C++ instead, but am intrigued with spin2 and this chip.
But I think @@ is the same as @ in FastSpin because it’s already an absolute address ...
and eher's the output
Once you lose confidence in a tool (ie addressing) you tend not to look for a bug in your own code when you have an addressing bug
Found my bug. Simple mistake - always the way!
Thanks to everyone,
Larry
EDIT: Much like any pointer, don't use @@something without first assigning a valid address for @@ to use. See my next post below
n is some constant. What's the smallest n that can be used reliably without 'missing' the future wait time?
FastSpin has the waitx function, but PNut doesn't seem to have it. If I write waitx(n), it waits for n+2 clock cycles as I understand it.
Mike
In Pnut @180 MHz the following code results in
935.7 kHz ~1.067uS
A bug was fixed where nested bitfields weren't compiling correctly.
Size overrides were added for data declarations: This way, you can embed data of different sizes into BYTE/WORD/LONG declarations. The FVAR/FVARS are variably-size data for reading via RFVAR/RFVARS.
In this new release is a parser for building compilers. It is demonstrated in parser.spin2. You need to have a VGA monitor connected to P8..P15 pins, or change the comments around to enable HDMI or HDTV to see it work.
The parser works with a symbol engine to recognize keywords and operators. It also resolves all integer constant types.
In this picture of the VGA monitor, you can see what it does. It converted the 5-line Spin2 file at the top of the screen into 2-long element records which are elaborated in the list below.
This is the base building block for realizing a complete Spin2 compiler. All the data are present in the CON and DAT blocks which define the symbols used by the Spin2 compiler. You can swap those tables out with your own to make any other compiler.
You just call the elementizer and it goes through your source file, converting everything it sees into 2-long records that look like this:
Once this is done, you no longer need to look at the source code. Everything is identified, except for undefined symbols, which are pointed to and hash values are kept for, so that a call to find_symbol retrieves the value, once established.
I will write the next layer now which gets the next or previous element, resolving any undefined symbols when possible.
Re: V34s Data sizes
Is it supposed to default back to the original size or sustain the size until a new size?
For example
When a size override occurs, it's just for that one single value.
The file \\MYBOOKLIVEDUO\Network\Robotics\Prop2\PNut_v34s\PNut_v34s.exe is infected with Gen:Variant.Jacard.175961. Bitdefender blocked this item, your device is safe.
I managed to add it as an exception to get it to run but am unable to make a backup on a different drive.
I had same problem with 34r.
John Abshier
d:/Parallax/PNut/PNut.exe -c d:/Parallax/MyCode/demo.spin2
This occurs whether I am in the d:/Parallax/MyCode folder or not, and yes, I have tried using backslash instead.
Any suggestions?
BTW, PNut is PNut_v34s, was the same for v34r.
If it is clean define some exceptions for bitdefender to no scan the original folder
Of pnut.exe and the intended backup folder
I myself use only the Microsoft integrated Vitus engine of win10 with no problem at all
Have a nice day
I think you need to put the filename first, then the "-c" second.
You need to drop the ".Spin2" extension. The doc states that a "Spin2" extension is assumed, but using the extension causes all examples to fail.
Correct. I had tried it with the -c both first and last, it was the .spin2 suffix causing the issue.
Wish list item: Would be nice to have it work with or without the .spin2 suffix.
Thanks
PRI hash_symbol(symbol, size) : hash repeat size hash += uppercase(byte[symbol++]) hash += hash << 10 hash ^= hash >> 6 hash := hash.byte[3] ^ hash.byte[2] ^ hash.byte[1] ^ hash.byte[0]Pnut v34s still has the bug, since v34m, with hubexec 20-bit-immediate relative branching. See https://forums.parallax.com/discussion/comment/1495681/#Comment_1495681
EDIT: Interestingly, the bug is not an encoding error but rather something about symbols. If I give it a numerical absolute address then the relative encoding to the instruction is fine.