Shop OBEX P1 Docs P2 Docs Learn Events
P2 Experiments- P1 source to P2 Fastspin - Page 2 — Parallax Forums

P2 Experiments- P1 source to P2 Fastspin

2»

Comments

  • 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)
    
  • cheezuscheezus Posts: 295
    edited 2019-12-07 08:42
    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.
    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
    '	crlfcrlf
    

    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. :lol:

    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 :|
  • Sorry, I can't seem to build the project you posted. But I am able to run the TextHex routine and it works fine:
    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.nl
    
    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.
  • cheezuscheezus Posts: 295
    edited 2019-12-12 04:03
    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?
    
        'SetCursor(long[@displayXSample][n],long[@displayYSample][n])
           SetCursor(long[@ @ @displayXSample][n],long[@ @ @displayYSample][n])    
    

    *edit- STUPID FORUM SOFTWARE
  • 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 :lol:
  • kwinnkwinn Posts: 8,697
    cheezus wrote: »
    ......

    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:

    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. :cookie: 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 :smiley:

    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!
  • kwinnkwinn Posts: 8,697
    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.
  • RaymanRayman Posts: 13,805
    edited 2019-12-16 16:54
    Here's my list of things to do:

    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
  • Rayman wrote: »
    Here's my list of things to do:

    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. :smile: 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.
  • cheezuscheezus Posts: 295
    edited 2020-01-19 19:33
    I've come across something I don't quite understand so hopefully someone can point out the difference in the usage of LONG[address][offset] .
        long[samplePtr][n+cal#_offset_display_x]
    

    Works as expected. However, if I try to isolate the OFFSET
        long[samplePtr+cal#_offset_display_x][n]
    

    I thought these should be equivalent but I guess they're not?
  • Wuerfel_21Wuerfel_21 Posts: 4,374
    edited 2020-01-19 19:15
    The equivalent of
    long[samplePtr][n+cal#_offset_display_x]
    
    is
    long[samplePtr + ((n+cal#_offset_display_x)<<2)]
    
  • msrobotsmsrobots Posts: 3,701
    edited 2020-01-19 19:21
    a long has 4 bytes per index so you need to do long[samplePtr+(n+cal#_offset_display_x)<<2]

    edit: @Wuerfel_21 beat me, gosh this forum is fast...

    Mike
  • Silly question: Was the omission of N in the second chunk intentional?
  • cheezuscheezus Posts: 295
    edited 2020-01-19 20:30
    JRoark wrote: »
    Silly question: Was the omission of N in the second chunk intentional?

    It was not. Fixed :smile:

    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?

    Okay, I understand it now.. DUH :smile:
Sign In or Register to comment.