PNut/Spin2 Latest Version (v34z - Lots of DEBUG display stuff)

17810121334

Comments

  • I fixed the @var MSB's problem. Just had to add a ZEROX instruction:
    callptrh	mov	vbase,x		'      d e		set vbase to ptr
    		rdlong	pbase,vbase	'      d e		read pbase from vbase
    callinit	mov	v,vbase		'      d e   g		get sub index from vbase[31:20]
    		shr	v,#20		'      d e   g
    		zerox	vbase,#19	'      d e   g		clear vbase msb's so they don't show up in @var
    		jmp	#calloffh	'      d e   g
    
  • cgraceycgracey Posts: 13,079
    edited 2020-03-28 - 12:22:47
    A new v34p was posted at the top of this thread.
    v34p - 2020.03.28 - CORDIC operations in interpreter now protected from interrupts
                        REG changed to now support PASM symbols: REG[pasm_register]
                        Upper bits of VBASE cleared for clean @var addresses
                        More constant symbols added to bring current with doc file
    
  • Great thanks! Chip, great timing , I had planned on updating to the latest version today.:)
  • cgracey wrote: »
    EDIT: Only the lower 20 bits of addresses matter in Spin2. The upper bits get ignored by the interpreter. But I will get this cleaned up.

    Yes, not a major issue. But I found it when I was trying to determine if the address was in a specific range during debugging. Thanks for fixing it.
  • Wasn't adding an automatic infinite loop to the Spin2 main method discussed at one time?
    Does Spin2 do this now?

    I think this catches a lot of people off guard in Spin1...
  • Rayman wrote: »
    Wasn't adding an automatic infinite loop to the Spin2 main method discussed at one time?
    Does Spin2 do this now?

    I think this catches a lot of people off guard in Spin1...

    Wouldn't it do people good to teach them that your program only does what you tell it to do, and that you need to tell it to do it again if you want it to do it again? It would help teach people something, as opposed to just letting them live in the ignorance of Arduino's setup() and main().
  • I posted a new PNut_v34Q at the top of this thread. It fixes the 'REPEAT variable[constant]' bug that Ozpropdev found earlier.
  • I finished the ABORT description in the Spin2 documentation.

    Next to document is method pointers and the SEND special method pointer.
  • Hi Chip
    I found an issue with PNut when referencing constants from an object.
    If the constant doesn[t exist an error would be expected.
    'file1
    con
    	#oz.val2
    	fred
    	barney
    
    obj
    oz: "file2"
    
    pub main()|x
    	x := oz.val4	' *** val4 doesn't exist, but no error generated!
    	repeat
    

    and
    'file2
    con
    	#100
    	val1
    	val2
    
    pub dummy()
    
    Not a deal breaker just FYI
    Cheers
    Brian
  • Thanks, Brian. I will fix that.
  • I just covered method pointers, including SEND, in the Spin2 documentation at the top of this thread.
  • Today has been frustrating: the local pharmacy screwed up my prescription (again!) and now, I can't get a handle on pulse output from a smart pin. I know it works because I tested through TAQOZ. Reading the docs, it doesn't seem like it should be complicated.

    For example, I want to output five, 100us pulses with a 100us gap on pin 38. This is the code.
    pub main() | pin, x, y 
     
      pin := 38
      
      x.word[0] := US_001 * 200                                     ' period  
      x.word[1] := US_001 * 100                                     ' off time
      
      y := 5
      
      pinstart(pin, P_PULSE | P_OE, x, y)
       
      pinl(56)
      
      repeat
        waitct(0)
    
    I know the pin works and my 'scope is configured properly because I can sub in this loop and it's fine:
      repeat 5
        pinh(38)
        waitus(100)
        pinl(38)
        waitus(100)
    
    Again, the docs make it seem quite straightforward, and I dug through the TAQOZ source to compare. What am I missing? BTW, I am running at 200MHz so I know I am no overflowing the high and low words of x in my setup (I've also tried constant values in x).
  • I think you need to do the WYPIN when the pin is not in reset mode. So, do the WYPIN after the PINSTART.
  • That did the trick, thank you. Question: Since the Y does act like a trigger mechanism for some smart pin modes, should the instruction that updates y in pinstart() come after the drvl instruction?
      org
                      fltl      pin
                      wrpin     mode, pin
                      wxpin     x, pin
                      drvl      pin
                      wypin     y, pin
      end
    
  • JonnyMac wrote: »
    That did the trick, thank you. Question: Since the Y does act like a trigger mechanism for some smart pin modes, should the instruction that updates y in pinstart() come after the drvl instruction?
      org
                      fltl      pin
                      wrpin     mode, pin
                      wxpin     x, pin
                      drvl      pin
                      wypin     y, pin
      end
    

    For some modes, Y needs to be set up during reset. There are a few counting modes in which the LSBs of Y are used to set a sub mode. In the case of what you are doing, just use 0 for Y in the PINSTART instruction.
  • Windows 10 is saying that PNut_v34Q.exe has Trojan:Win32/Fuerboos.C!cl and it keeps deleting it.

    Has anyone else run into this ? Or is it maybe just something on my computer ?

    Bean
  • very unlikely to be infected, just a new, unsigned .exe file..
  • Bean wrote: »
    Windows 10 is saying that PNut_v34Q.exe has Trojan:Win32/Fuerboos.C!cl and it keeps deleting it.

    Has anyone else run into this ? Or is it maybe just something on my computer ?

    Bean

    Yep, I did. It's a false positive. It's save to use.
  • cgracey wrote: »
    Thanks, Brian. I will fix that.[/quot
    ozpropdev wrote: »
    Hi Chip
    I found an issue with PNut when referencing constants from an object.
    If the constant doesn[t exist an error would be expected.

    There was also an issue with underscores in constant name references being ignored. So for the constant VALUE_ONE you could use VALUEONE or VAL_UE_O_NE. I posted a comment a while back on this but can't find it now.
  • I posted a new v34r at the top of this thread which traps invalid symbols in Object.Constant instances.
  • cgracey wrote: »
    I posted a new v34r at the top of this thread which traps invalid symbols in Object.Constant instances.

    Thanks Chip!
  • wmosscrop wrote: »
    Bean wrote: »
    Windows 10 is saying that PNut_v34Q.exe has Trojan:Win32/Fuerboos.C!cl and it keeps deleting it.

    Has anyone else run into this ? Or is it maybe just something on my computer ?

    Bean

    Yep, I did. It's a false positive. It's save to use.

    Okay, Thanks.

    Bean
  • JonnyMacJonnyMac Posts: 7,008
    edited 2020-04-11 - 03:18:47
    I found that NCO FREQ mode followed the P1 formula if we treat Y as the P1 FRQx register, and set X to one. Easy peasy; works great.

    I'm now a bit frazzled because I thought NCO DUTY mode would similarly follow the P1 model. In the P1 the FRQx register is set to duty% * 2^32 for duty mode.

    Here's a bit of test code that should give 25% duty cycle. There is no output
      duty := 25
      
      y := muldiv64(duty << 1, $8000_0000, 100)
      
      pinstart(38, P_NCO_DUTY | P_OE, 1, y)
    
    Clearly, I've missed something, but I don't know what it is. I did try a wypin() command after pinstart() but that made no difference.
  • JonnyMac wrote: »
    I found that NCO FREQ mode followed the P1 formula if we treat Y as the P1 FRQx register, and set X to one. Easy peasy; works great.

    I'm now a bit frazzled because I thought NCO DUTY mode would similarly follow the P1 model. In the P1 the FRQx register is set to duty% * 2^32 for duty mode.

    Here's a bit of test code that should give 25% duty cycle. There is no output
      duty := 25
      
      y := muldiv64(duty << 1, $8000_0000, 100)
      
      pinstart(38, P_NCO_DUTY | P_OE, 1, y)
    
    Clearly, I've missed something, but I don't know what it is. I did try a wypin() command after pinstart() but that made no difference.

    Hmm, this works Ok
    	org
    	setq	duty
    	qdiv	#0,#100
    	getqx	y
    	end  
    
    
  • Signed multiply me thinks, this works
    	y := muldiv64(duty << 1, $7fff_ffff, 100)
    
  • evanhevanh Posts: 9,983
    edited 2020-04-11 - 04:33:50
    Ha, yeah, I hadn't even looked at Jon's numbers. On that note
    QFRAC duty, #100
    GETQX y
    
    should be the same. Don't need the SETQ then.

  • Hmmm. I thought the duty mode treated all values as unsigned -- seems to on the P1.

    Thanks, guys.
  • JonnyMacJonnyMac Posts: 7,008
    edited 2020-04-11 - 16:26:44
    Still not getting anything out of NCO_DUTY mode. As you guys have suggested, and Andy pointed out in another thread, using frac simplifies things here.
    The code becomes...
      pinstart(38, P_NCO_DUTY | P_OE, 1, duty frac 100)
    
    ...but there is still nothing on the 'scope.

    And just for sanity checking, I toss in a little pin wiggling to ensure my 'scope is working.
      pin := 38
      duty := 50
      
      repeat 100
        pinh(pin)
        waitus(50)
        pinl(pin)
        waitus(50)
      
      pinstart(pin, P_NCO_DUTY | P_OE, 1, duty frac 100)
    
    The pin wiggling shows up, but it's just low-level noise after (as if pin is floating).
  • JonnyMacJonnyMac Posts: 7,008
    edited 2020-04-11 - 16:31:47
    As I continue to *play* I am getting very odd results from NCO_DUTY -- hopefully @cgracey can pop in and sort me out.
  • Does what Chip said on April 8 (scroll up) also apply here? Does the first y in pinstart have to be 0?

    Should pinstart( ) be modified to have two y values? (Before and after?)
Sign In or Register to comment.