Lookupz itself seems fine to me (see the test program below). So if there is a bug it's something more subtle, like in some interaction with the rest of your code. Could you post the whole thing? And/or maybe describe what's happening and what you expected to happen?
In general fastspin has been used enough now that the "obvious" bugs have mostly been found, and the main features probably work OK (I have to say "probably" because obviously there's always the chance that I've introduced new bugs, but that's not where I would look first). The remaining bugs are mostly in rarely used features or in unusual combinations of things. The discussion earlier in the thread was an example: fastspin and "standard" spin differed in the value they returned for division by 0. Not many programs deliberately divide by 0, so it's not surprising that we hadn't noticed that one before. If lookupz were just plain broken I think we'd have seen that already. If it fails under some edge case or in particular circumstances, then that's a different story.
CON
mode = $010007f8
freq = 160_000_000
OBJ
ser: "spin/SmartSerial"
PUB main | x, c
clkset(mode, freq)
ser.start(63, 62, 0, 230_400)
repeat x from $123 to $134
ser.printf("x=%x showhex=", x, c)
showhex(x)
ser.nl
ser.printf("done\n")
PUB showhex(value) | c
repeat 8
c := lookupz( (value <-= 4) & $F : "0".."9", "A".."F")
ser.tx(c)
I'm more than happy to post the entire project, although it may be hard to debug without the hardware?. I had a chance to debug TextHex a little and it appears that the first line is actually the offender. Not quite sure what's going on but TextDec seems to be working fine.
I can't quite understand why the lookupz is returning -1 either, although lookup(z) are instructions I don't really use a lot.
It could very well be some other bug in the large project. All my friend are sending the "99 bugs in the code mug" gif to me the last couple days.
Things are a mess, I apologize. I'm trying to get everything actually working and then I'm going to do a major code cleanup. Not sure about the number of files I've split Touch.spin into. It feels like a lot, but then again compared to a lot of C projects...
The Text functions are in RamStuff.Spin2 since the font is stored on the RAM, but are also in DisplayStuff.spin2.
"C:/Users/cheez/Downloads/flexgui/flexgui/bin/fastspin" -2a -l -O1 -I "C:/Users/cheez/Downloads/flexgui/flexgui/include" "C:/Users/cheez/Desktop/P2Touch/Touch.spin2"
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
Version 4.0.3 Compiled on: Nov 9 2019
Touch.spin2
|-ramCog.spin2
|-XPT2046.spin2
|-ASCII0_STREngine.spin
|-cal.spin
|-font.spin
|-fsrw.spin2
|-|-sdspi_asm.spin2
Touch.p2asm
Done.
Program size is 31616 bytes
C:/Users/cheez/Desktop/P2Touch/RamStuff.spin2:80: warning: Label is dereferenced with greater alignment than it was declared with
C:/Users/cheez/Desktop/P2Touch/RamStuff.spin2:81: warning: Label is dereferenced with greater alignment than it was declared with
C:/Users/cheez/Desktop/P2Touch/RamStuff.spin2:83: warning: Label is dereferenced with greater alignment than it was declared with
C:/Users/cheez/Desktop/P2Touch/RamStuff.spin2:84: warning: Label is dereferenced with greater alignment than it was declared with
C:/Users/cheez/Desktop/P2Touch/RamStuff.spin2:85: warning: Label is dereferenced with greater alignment than it was declared with
C:/Users/cheez/Desktop/P2Touch/RamStuff.spin2:86: warning: Label is dereferenced with greater alignment than it was declared with
C:/Users/cheez/Desktop/P2Touch/RamStuff.spin2:441: warning: Label is dereferenced with greater alignment than it was declared with
C:/Users/cheez/Desktop/P2Touch/RamStuff.spin2:446: warning: Label is dereferenced with greater alignment than it was declared with
C:/Users/cheez/Desktop/P2Touch/RamStuff.spin2:460: warning: Label is dereferenced with greater alignment than it was declared with
C:/Users/cheez/Desktop/P2Touch/RamStuff.spin2:470: warning: Label is dereferenced with greater alignment than it was declared with
C:/Users/cheez/Desktop/P2Touch/RamStuff.spin2:474: warning: Label is dereferenced with greater alignment than it was declared with
Finished at Fri Dec 6 20:51:22 2019
I'd also like to suppress those warnings, as it's intentional... I use WORD[prt] to access bytes, words or longs since the bus is 16 bits.
Other the Hex functions and a couple odd things,most of this is working finally. It's not optimized but making progress slowly. I think the desktop app would probably function with 2 changes. I'm trying to improve the calibration program and add in some debugging stuff since I might need it in the future. It's a good exercise to make sure everything is working with the system.
*edit - forgot to attach file
*aedit - disregard tests, seems the SPI broke again along the way
So the error is somewhere else, either in your TextDec routine or perhaps in one of your printing routines. Or, maybe the values you're sending into TextHex aren't what you expect?
As for the alignment warnings, those may safely be ignored since in fact your data is long aligned. You can get rid of them by declaring the buffers as "buffer2 long 0[512/4]" instead of "buffer2 byte 0[512]". Those warnings aren't really an issue on P2 anyway (where the read instructions can access unaligned memory) so I'll probably get rid of them when compiling for the P2.
I'm not entirely sure what the issue is here but printing routines seem okay, as does TextDec. I have a working Hex, and I have an example of one that doesn't (for me). At least I have something working.
Thanks for the advice on the warnings. I'll implement that fix on my next cleanup. As you can see, there's a few lines of code to dig through. I could have posted a bad copy, not sure if you were trying to compile Touch_OS.Spin2 as that's the working file. I can repost the entire project again now that I have things working.
PUB TextHex(font, value, digits) ' this one works
'' Print a hexadecimal number
' DebugChar("O")
' DebugChar("x")
value <<= (8 - digits) << 2
repeat digits
curx := TextChar(font,lookupz((value <-= 4) & $F : "0".."9", "A".."F"),curx,cury)
{
PUB TextHex(font, value, digits) ' this one doesn't
TextT(font,str.integerToHexadecimal(value, digits)) ' prints nothing
}
PUB integerToHexadecimal(number, length) '' 5 Stack Longs
'kye's ASCII string engine
'' ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
'' // Converts an integer number to the hexadecimal string of that number padded with zeros.
'' //
'' // Returns a pointer to the converted string.
'' //
'' // Number - A 32 bit signed integer number to be converted to a string.
'' // Length - The length of the converted string, negative numbers need a length of 8 for sign extension.
'' ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
repeat result from 7 to 0
hexadecimalString[result] := lookupz((number & $F): "0".."9", "A".."F")
number >>= 4
return @hexadecimalString[8 - ((length <# 8) #> 0)]
I was also porting the touchscreen calibration program over and couldn't figure out why the cursor wasn't moving to the proper position. I fixed it by using the absolute addressing and am wondering if this is causing me issues in other places?
In Spin code (i.e. inside PUB and PRI) the absolute address operator (three at signs) should be identical to the regular address operator (one at sign). They're only different inside PASM code. So I'm very surprised that you found a difference. Are you sure that's the only change you made?
This is very strange indeed! I just tried to replicate the behavior and I'm beginning to think my addressing is faulty somewhere, or perhaps it's a buffer over-run issue. I'm almost 100% sure that was the only line I changed related to that portion of code. In fact, I'm pretty sure that was the only change I made between successive tests. I could be wrong though.
I'm at a loss to explain why I'm unable to replicate the behavior. I also can't explain why the same Hex method works for you but not me. Maybe I should just give up electronics and stick to wiring houses
I'm at a loss to explain why I'm unable to replicate the behavior. I also can't explain why the same Hex method works for you but not me. Maybe I should just give up electronics and stick to wiring houses
LOL, Oh come on now, what's the fun in wiring houses when you can spend hours and hours scratching your head and tearing out your hair to find a minor mistake in the code or the hardware. Finding that gaffe is such a high.
Wiring houses can be a lot of fun. I spent several hours this evening splicing a 4-conductor 4/0 cable. While the splice wasn't that hard (just needed to make sure the socket was all the way in the bolts before torquing them), the tape wrap afterwards took the majority of the time.
It's just nice when everything works the first time I guess. I also get a lot of cool ideas from things I see as a service electrician. The 14,000 sqft we just finished roughing is going to be pretty cool to have on the resume. Driving by a really nice house and saying "that's one of mine" feels pretty good. Still, finding that bug is quite addicting.
We do a lot of residential and some light commercial. I'm beginning to hate the commercial end because it's always so dirty. Service calls are usually interesting, always nice when it's just a tripped breaker. Or a 3 way that was never trimmed out properly (5 years ago). Still, roughing houses in the middle of winter makes me think it's time to find a new line of work. That and lighting manufactures are getting downright sadistic.
I'm still not quite sure what's causing my moving target bug. I went through some things that were suspect but can't find anything obvious.
I've incorporated the touchscreen spi driver into the ram driver, since the data bus is shared and only one can be accessed at a time. I implemented the simple noise filtering I found in an Arduino library that averages the 2 closest sample points of 3 samples. I still need to implement the rotation function, which also urges me to extend the display rotation to allow all 4 rotations. I have not tested things but I'm sure it will work better than my previous method of just averaging 2 samples. I'm also working on implementing pressure detection. X and Y will be 12 bit and Z is 8.
One of the things I'd like to implement is auto-sampling of the touch panel when the driver is idle, and perhaps at the end of most commands. This has got me thinking about various ways of handling the command loop and maybe it's time to learn SKIP. I can't wait until I get to play with LUT sharing
I think programming is actually enjoyable for me BECAUSE of the Propeller. When programming other chips, I find myself rage quitting way more often. It's so nice to not have gotchas everywhere. While implementing the noise filtering, I found myself tempted to just use the C code. If FlexGUI had been around during the early P1 days, who knows!
Wiring houses can be a lot of fun. I spent several hours this evening splicing a 4-conductor 4/0 cable. While the splice wasn't that hard (just needed to make sure the socket was all the way in the bolts before torquing them), the tape wrap afterwards took the majority of the time.
I agree, making repairs or building anything can be fun whether it is wiring, plumbing, carpentry, electronics, or writing code. It can also be frustrating. Just finished fixing a leaking pipe and replacing a bathroom floor with a new sub floor and ceramic tiles. Lots of "fun" with that, and this morning found a tiny tiny leak somewhere between the hot water shut off valve and the sink faucet. Nothing harder or more frustrating in plumbing work than trying to connect old fixtures and pipes to new ones. Of course it's very satisfying once it's all done.
Filename extension to .spin2
Change clock settings
In ASM:
Chip’s code uses a lot of local variables, like “:Loop”, these must be changed to “.Loop”
Change waitcnt to waitct1 as explained in Tricks&Traps or just waitx
Waitx count needs to account for faster P2… for P1 at 80 MHz and P2 at 160 MHz
Change MOVD to SETD, Change MOVS to SETS
The PAR register (and many others) is no more. The coginit parameter goes to PTRB instead.
Change wc,wz and wz,wc to wcz
Filename extension to .spin2
Change clock settings
In ASM:
Chip’s code uses a lot of local variables, like “:Loop”, these must be changed to “.Loop”
Change waitcnt to waitct1 as explained in Tricks&Traps or just waitx
Waitx count needs to account for faster P2… for P1 at 80 MHz and P2 at 160 MHz
Change MOVD to SETD, Change MOVS to SETS
The PAR register (and many others) is no more. The coginit parameter goes to PTRB instead.
Change wc,wz and wz,wc to wcz
I was trying to convert some code and got hung up on a piece of self modifying code.
I really like auto-incrementing pointers for hub access. I've been using it a lot
pasmhubtodisplay mov lv, lv_h2d ' group2 | display en
call #set_mode
mov ptrb, _par1 ' move to ptr
hubtodisplay_loop andn OUT, ##$ffff ' clear for output
rdword t1, ptrb ++ ' get the word from hub
or OUT, t1 ' send out the byte to P0-P15
andn OUT, dispW_pin ' ILI write low
or OUT, dispW_pin ' ILI write high
djnz _par3, #hubtodisplay_loop ' do this many times
jmp #done
I guess the next step would be using REP where I can. I also need to get literals back down to 9 bits, for sanity's sake. I'm sure I can find more savings as I go but still trying to get things "just working" again.
The next thing I want to focus on is the touchscreen calibration. It looks like the P1 code will work, but what's the fun in that? The current calibration matrix uses 32 bit integer math but could be much improved. It also has a limit of 10 bit touch digitizer. Worked pretty good on the old display but the new one is proving much more difficult.
Silly question: Was the omission of N in the second chunk intentional?
It was not. Fixed
Thanks guys, I'm still trying to understand. This is a difference between fastspin and pnut? From propeller manual ;
The LONG designator treats it properly by taking the Offset value (units of longs), multiplies it by 4 (number of bytes per long), and adds that result to the BaseAddress to determine the correct long of memory to read. It also clears the lowest two bits of BaseAddress to ensure the address referenced is a long-aligned one.
But it sounds like fastspin ALWAYS applies the offset of LONG/WORD designator as a byte offset?
Comments
In general fastspin has been used enough now that the "obvious" bugs have mostly been found, and the main features probably work OK (I have to say "probably" because obviously there's always the chance that I've introduced new bugs, but that's not where I would look first). The remaining bugs are mostly in rarely used features or in unusual combinations of things. The discussion earlier in the thread was an example: fastspin and "standard" spin differed in the value they returned for division by 0. Not many programs deliberately divide by 0, so it's not surprising that we hadn't noticed that one before. If lookupz were just plain broken I think we'd have seen that already. If it fails under some edge case or in particular circumstances, then that's a different story.
CON mode = $010007f8 freq = 160_000_000 OBJ ser: "spin/SmartSerial" PUB main | x, c clkset(mode, freq) ser.start(63, 62, 0, 230_400) repeat x from $123 to $134 ser.printf("x=%x showhex=", x, c) showhex(x) ser.nl ser.printf("done\n") PUB showhex(value) | c repeat 8 c := lookupz( (value <-= 4) & $F : "0".."9", "A".."F") ser.tx(c)PUB TextHex(font,value,digits) '' Print a hexadecimal number value <<= (8 - digits) << 2 ' TextDec(font,value) ' always 0 repeat digits curx := TextChar(font,lookupz((value <-= 4) & $F : "0".."9", "A".."F"),Curx,Cury) ' TextDec(font,lookupz((value <-= 4) & $F : "0".."9", "A".."F") ' always -1 ' crlfcrlfI can't quite understand why the lookupz is returning -1 either, although lookup(z) are instructions I don't really use a lot.
It could very well be some other bug in the large project. All my friend are sending the "99 bugs in the code mug" gif to me the last couple days.
Things are a mess, I apologize. I'm trying to get everything actually working and then I'm going to do a major code cleanup. Not sure about the number of files I've split Touch.spin into. It feels like a lot, but then again compared to a lot of C projects...
The Text functions are in RamStuff.Spin2 since the font is stored on the RAM, but are also in DisplayStuff.spin2.
I'd also like to suppress those warnings, as it's intentional... I use WORD[prt] to access bytes, words or longs since the bus is 16 bits.
Other the Hex functions and a couple odd things,most of this is working finally. It's not optimized but making progress slowly. I think the desktop app would probably function with 2 changes. I'm trying to improve the calibration program and add in some debugging stuff since I might need it in the future. It's a good exercise to make sure everything is working with the system.
*edit - forgot to attach file
*aedit - disregard tests, seems the SPI broke again along the way
CON mode = $010007f8 freq = 160_000_000 baud = 230_400 rx_pin = 63 tx_pin = 62 OBJ ser: "spin/SmartSerial" PUB hello clkset(mode, freq) ser.start(rx_pin, tx_pin, 0, baud) ser.printf("Hello, world!\n") TextHex($12345678, 8) TextHex($ABCD, 6) TextHex($ABCD, 4) waitx_(80_000_000) PUB TextHex(value, digits) value <<= (8 - digits) << 2 repeat digits ser.tx(lookupz((value <-= 4) & $F : "0".."9", "A".."F")) ser.nlSo the error is somewhere else, either in your TextDec routine or perhaps in one of your printing routines. Or, maybe the values you're sending into TextHex aren't what you expect?As for the alignment warnings, those may safely be ignored since in fact your data is long aligned. You can get rid of them by declaring the buffers as "buffer2 long 0[512/4]" instead of "buffer2 byte 0[512]". Those warnings aren't really an issue on P2 anyway (where the read instructions can access unaligned memory) so I'll probably get rid of them when compiling for the P2.
Thanks for the advice on the warnings. I'll implement that fix on my next cleanup. As you can see, there's a few lines of code to dig through. I could have posted a bad copy, not sure if you were trying to compile Touch_OS.Spin2 as that's the working file. I can repost the entire project again now that I have things working.
PUB TextHex(font, value, digits) ' this one works '' Print a hexadecimal number ' DebugChar("O") ' DebugChar("x") value <<= (8 - digits) << 2 repeat digits curx := TextChar(font,lookupz((value <-= 4) & $F : "0".."9", "A".."F"),curx,cury) { PUB TextHex(font, value, digits) ' this one doesn't TextT(font,str.integerToHexadecimal(value, digits)) ' prints nothing } PUB integerToHexadecimal(number, length) '' 5 Stack Longs 'kye's ASCII string engine '' //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// '' // Converts an integer number to the hexadecimal string of that number padded with zeros. '' // '' // Returns a pointer to the converted string. '' // '' // Number - A 32 bit signed integer number to be converted to a string. '' // Length - The length of the converted string, negative numbers need a length of 8 for sign extension. '' //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// repeat result from 7 to 0 hexadecimalString[result] := lookupz((number & $F): "0".."9", "A".."F") number >>= 4 return @hexadecimalString[8 - ((length <# 8) #> 0)]I was also porting the touchscreen calibration program over and couldn't figure out why the cursor wasn't moving to the proper position. I fixed it by using the absolute addressing and am wondering if this is causing me issues in other places?
'SetCursor(long[@displayXSample][n],long[@displayYSample][n]) SetCursor(long[@ @ @displayXSample][n],long[@ @ @displayYSample][n])*edit- STUPID FORUM SOFTWARE
I'm at a loss to explain why I'm unable to replicate the behavior. I also can't explain why the same Hex method works for you but not me. Maybe I should just give up electronics and stick to wiring houses
LOL, Oh come on now, what's the fun in wiring houses when you can spend hours and hours scratching your head and tearing out your hair to find a minor mistake in the code or the hardware. Finding that gaffe is such a high.
We do a lot of residential and some light commercial. I'm beginning to hate the commercial end because it's always so dirty. Service calls are usually interesting, always nice when it's just a tripped breaker. Or a 3 way that was never trimmed out properly (5 years ago). Still, roughing houses in the middle of winter makes me think it's time to find a new line of work. That and lighting manufactures are getting downright sadistic.
I'm still not quite sure what's causing my moving target bug. I went through some things that were suspect but can't find anything obvious.
I've incorporated the touchscreen spi driver into the ram driver, since the data bus is shared and only one can be accessed at a time. I implemented the simple noise filtering I found in an Arduino library that averages the 2 closest sample points of 3 samples. I still need to implement the rotation function, which also urges me to extend the display rotation to allow all 4 rotations. I have not tested things but I'm sure it will work better than my previous method of just averaging 2 samples. I'm also working on implementing pressure detection. X and Y will be 12 bit and Z is 8.
One of the things I'd like to implement is auto-sampling of the touch panel when the driver is idle, and perhaps at the end of most commands. This has got me thinking about various ways of handling the command loop and maybe it's time to learn SKIP. I can't wait until I get to play with LUT sharing
I think programming is actually enjoyable for me BECAUSE of the Propeller. When programming other chips, I find myself rage quitting way more often. It's so nice to not have gotchas everywhere. While implementing the noise filtering, I found myself tempted to just use the C code. If FlexGUI had been around during the early P1 days, who knows!
I agree, making repairs or building anything can be fun whether it is wiring, plumbing, carpentry, electronics, or writing code. It can also be frustrating. Just finished fixing a leaking pipe and replacing a bathroom floor with a new sub floor and ceramic tiles. Lots of "fun" with that, and this morning found a tiny tiny leak somewhere between the hot water shut off valve and the sink faucet. Nothing harder or more frustrating in plumbing work than trying to connect old fixtures and pipes to new ones. Of course it's very satisfying once it's all done.
Filename extension to .spin2
Change clock settings
In ASM:
Chip’s code uses a lot of local variables, like “:Loop”, these must be changed to “.Loop”
Change waitcnt to waitct1 as explained in Tricks&Traps or just waitx
Waitx count needs to account for faster P2… for P1 at 80 MHz and P2 at 160 MHz
Change MOVD to SETD, Change MOVS to SETS
The PAR register (and many others) is no more. The coginit parameter goes to PTRB instead.
Change wc,wz and wz,wc to wcz
I was trying to convert some code and got hung up on a piece of self modifying code.
I really like auto-incrementing pointers for hub access. I've been using it a lot
pasmhubtodisplay mov lv, lv_h2d ' group2 | display en call #set_mode mov ptrb, _par1 ' move to ptr hubtodisplay_loop andn OUT, ##$ffff ' clear for output rdword t1, ptrb ++ ' get the word from hub or OUT, t1 ' send out the byte to P0-P15 andn OUT, dispW_pin ' ILI write low or OUT, dispW_pin ' ILI write high djnz _par3, #hubtodisplay_loop ' do this many times jmp #doneI guess the next step would be using REP where I can. I also need to get literals back down to 9 bits, for sanity's sake.
The next thing I want to focus on is the touchscreen calibration. It looks like the P1 code will work, but what's the fun in that? The current calibration matrix uses 32 bit integer math but could be much improved. It also has a limit of 10 bit touch digitizer. Worked pretty good on the old display but the new one is proving much more difficult.
Works as expected. However, if I try to isolate the OFFSET
I thought these should be equivalent but I guess they're not?
edit: @Wuerfel_21 beat me, gosh this forum is fast...
Mike
It was not. Fixed
Thanks guys, I'm still trying to understand. This is a difference between fastspin and pnut? From propeller manual ;
But it sounds like fastspin ALWAYS applies the offset of LONG/WORD designator as a byte offset?
Okay, I understand it now.. DUH