fastspin Basic simple stuff

This is really straight forward stuff, or so I thought. When I run the program I expect the LED to turn on, it does not. When I add the pausems 4000, then the LED stays on for four seconds, and turns off. What do you have to do too keep the LED on, and then give it another command to turn it off.

Ray
const pin = 26

direction(pin) = output
output(pin) = 1    ' LED turns on.

'pausems 4000

Comments

  • At the end of a program FlexBASIC stops the cog which disables its influence on the pins too.
    You can add an empty
    do : loop
    
    to keep the cog twiddle its thumbs forever.
    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ No Source – No Go! ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷
  • I did a fastspin --code=cog on the program and got the PASM code below. Looking at the print out the PASM code, it looks so orderly, you do not have any jmp far or jmpret or any of that stuff. Looking at it you can just about tell what is going on, except for things like 'or dira,imm_67108864' and 'hubexit', which I do not see it being called. It sort of does a call '#_program', comes back and does a 'cogexit', end of code run. Not sure what all the other code lines supposed to be doing.

    Not sure if I could tweak the code, and besides if you did tweak it, how would you be able to run the tweaked code.

    Ray
    con
    	pin = 26
    pub main
      coginit(0, @entry, 0)
    dat
    	org	0
    entry
    	mov	arg01, par wz
    	call	#_program
    cogexit
    	cogid	arg01
    	cogstop	arg01
    
    _program
    	or	dira, imm_67108864_
    	or	outa, imm_67108864_
    _program_ret
    	ret
    
    imm_67108864_
    	long	67108864
    COG_BSS_START
    	fit	496
    hubexit
    	jmp	#cogexit
    	org	COG_BSS_START
    arg01
    	res	1
    	fit	496
    
  • If you add a "-l" (lowercase "L") you'll get a listing file that has more info.
    The difference between theory and practice is that, in theory, there is no difference between theory and practice, but in practice, there is.
  • Today I decided to run a simple 'print "hello!"', and I got a compilation error failure. I did a fastspin --code=cog on the program, not sure why it's not compiling.

    Ray
    print "hello!"
    
    F:\fastspin\spin2gui\bin\fastspin --code=cog -l "test_cog_mem.bas" (in directory: F:\flexbasic\test_cog_mem)
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
    Version 3.9.25 Compiled on: Apr 14 2019
    test_cog_mem.bas
    test_cog_mem.pasm
    Done.
    test_cog_mem.pasm(378) error: Unknown symbol arg02_ret
    Compilation failed.
    pub main
      coginit(0, @entry, 0)
    dat
    	org	0
    entry
    	mov	arg01, par wz
    	call	#_program
    cogexit
    	cogid	arg01
    	cogstop	arg01
    
    _program
    	mov	arg02, ptr_L__0023_
    	mov	arg01, #0
    	mov	arg03, #0
    	call	#__system___basic_print_string
    	mov	arg01, #0
    	call	#__system___basic_print_nl
    _program_ret
    	ret
    
    ' ''
    ' pri _gc_ptrs | base, end, size
    __system___tx
    	mov	__system___tx_val, arg01
    '   base := @__system__dat_ + 4
    '-' dat
    	byte	$00[28]
    '-'         long
    '-' _gc_heap_base
    	byte	$00[32]
    '-'         long
    '-' _gc_heap_base
    '-' 	byte 0[__real_heapsize__]
    	byte	$00[256]
    objmem
    	long	0[0]
    stackspace
    	long	0[1]
    	org	COG_BSS_START
    __system___basic_print_char_c
    	res	1
    __system___basic_print_char_f
    	res	1
    __system___basic_print_char_fmt
    	res	1
    __system___basic_print_char_h
    	res	1
    __system___basic_print_char_o
    	res	1
    __system___basic_print_char_t
    	res	1
    __system___basic_print_nl_h
    	res	1
    __system___basic_print_string_c
    	res	1
    __system___basic_print_string_fmt
    	res	1
    __system___basic_print_string_h
    	res	1
    __system___basic_print_string_justify
    	res	1
    __system___basic_print_string_len
    	res	1
    __system___basic_print_string_ptr
    	res	1
    __system___basic_print_string_w
    	res	1
    __system___basic_print_string_wleft
    	res	1
    __system___basic_print_string_wright
    	res	1
    __system___tx__idx__90001
    	res	1
    __system___tx_bitcycles
    	res	1
    __system___tx_nextcnt
    	res	1
    __system___tx_val
    	res	1
    _system___basic_print_char_tmp001_
    	res	1
    _system___basic_print_char_tmp002_
    	res	1
    _system___basic_print_string_tmp001_
    	res	1
    _system___basic_print_string_tmp002_
    	res	1
    _system___basic_print_string_tmp003_
    	res	1
    _var01
    	res	1
    _var02
    	res	1
    arg01
    	res	1
    arg02
    	res	1
    arg03
    	res	1
    	fit	496
    
  • I think the print routine and associated variables is too big to fit into cog memory. If you view the .lst file that that generated you'll see there's a fair amount of instructions associated with "print". On P1 cog code is generally for small, hand coded chores that are very timing critical -or- the compiler will use it for smaller, tight loops via the fcache mechanism. I usually use standard old LMM with fcache, the compiler is pretty smart about identifying what's a good candidate. Here's a routine of mine that the compiler automatically uses fcache for:
    void arm_mic_a()
    {
      DIRA |= 0 << mic_a_pin;             // Set to input
      CTRA = (0b01110  << 26) + mic_a_pin; // Set CTRA to NegEdge mode
      FRQA = 1;                    // Adds 1 to PHSA on each rising edge
      while (PHSA == 0);        // Wait for negedge on mic A
      mic_a_cnt = CNT;
    }
    
    which generates
    @LR__0001)
    00310 0bc             | ' {
    00310 0bc             | '   _DIRA  |= 0 << mic_a_pin;
    00310 0bc             | ' 
    00310 0bc             | '   _CTRA  = (0b01110 << 26) + mic_a_pin;
    00310 0bc             | '   _FRQA  = 1;
    00310 0bc             | '   while ( _PHSA  == 0);
    00310 0bc 
    00310 0bc             | LR__0001
    00310 0bc 00 F8 7F 86 | 	cmp	phsa, #0 wz
    00314 0bd EA 00 68 5C |  if_e	jmp	#LMM_FCACHE_START + (LR__0001 - LR__0001)
    00318 0be 
    00318 0be             | LR__0002
    00318 0be F1 AB BD A0 | 	mov	_var04, cnt
    0031c 0bf D4 56 FD 80 | 	add	ptr__dat__, #212
    00320 0c0 AB AA 3D 08 | 	wrlong	_var04, ptr__dat__
    00324 0c1 D4 56 FD 84 | 	sub	ptr__dat__, #212
    00328 0c2 
    00328 0c2             | _arm_mic_a_ret
    00328 0c2 3C 86 FC 5C | 	call	#LMM_RET
    
    Works wonderfully with sub microsecond resolution though the counter takes care of that, to be fair.

    Mike R.
    The difference between theory and practice is that, in theory, there is no difference between theory and practice, but in practice, there is.
  • pmrobert wrote: »
    I think the print routine and associated variables is too big to fit into cog memory.
    That would throw a different error.
    Fits using LMM:
    $ fastspin mandelbrot-float-using-printf.c 
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
    Version 3.9.26-beta-dbdaa382 Compiled on: Apr 28 2019
    mandelbrot-float-using-printf.c
    mandelbrot-float-using-printf.pasm
    Done.
    Program size is 3240 bytes
    
    Error with "--code=cog":
    $ fastspin --code=cog mandelbrot-float-using-printf.c 
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
    Version 3.9.26-beta-dbdaa382 Compiled on: Apr 28 2019
    mandelbrot-float-using-printf.c
    mandelbrot-float-using-printf.pasm
    mandelbrot-float-using-printf.pasm(616) error: fit 496 failed: pc is 501
    mandelbrot-float-using-printf.pasm(827) error: fit 496 failed: pc is 597
    Done.
    

    The problem with BASIC's "print" has a different flavour.
    Let's ask the master: @ersmith ;-)
    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ No Source – No Go! ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷
  • yeti wrote: »
    pmrobert wrote: »
    I think the print routine and associated variables is too big to fit into cog memory.
    That would throw a different error.
    Ah, I see. I didn't know that it would throw a different error. Thank you for that.
    The problem with BASIC's "print" has a different flavour.
    Let's ask the master: @ersmith ;-)
    Yes, most certainly he'll know.

    Mike R.


    The difference between theory and practice is that, in theory, there is no difference between theory and practice, but in practice, there is.
  • Rsadeika wrote: »
    Today I decided to run a simple 'print "hello!"', and I got a compilation error failure. I did a fastspin --code=cog on the program, not sure why it's not compiling.
    There's a bug in --code=cog that generates incorrect code for indirect calls (as used by the "print" internals). It's kind of moot because even if you could get past that bug you'd run out of space in the COG -- the print code is too big to fit in there.
  • ersmith wrote: »
    There's a bug in --code=cog that generates incorrect code for indirect calls (as used by the "print" internals). It's kind of moot because even if you could get past that bug you'd run out of space in the COG -- the print code is too big to fit in there.
    Can shorter code which should fit with "--code=cog" trigger the same problem?
    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ No Source – No Go! ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷
  • yeti wrote: »
    ersmith wrote: »
    There's a bug in --code=cog that generates incorrect code for indirect calls (as used by the "print" internals). It's kind of moot because even if you could get past that bug you'd run out of space in the COG -- the print code is too big to fit in there.
    Can shorter code which should fit with "--code=cog" trigger the same problem?

    Yes. Actually any attempt to call a function through a pointer will fail with --code=cog on P1. I don't think I will fix that, but I will add an error. (The root cause is the calling convention for COG code; on P1 doing "call #foo" actually generates "jmpret foo_ret, #foo". This doesn't support indirect calls. It is possible to generate the "jmpret" directly, but it would have to be done for all functions and would make the COG code a lot less readable, and it's an edge case (--code=cog isn't really practical for BASIC code anyway).
  • ersmith wrote: »
    I don't think I will fix that, but I will add an error.
    That's ok.
    Getting a hint what's going on will be enough in this context.
    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ No Source – No Go! ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷
  • ersmith wrote: »
    I don't think I will fix that, but I will add an error.
    $ cat hw.bas 
    print"Hello, world!"
    $ fastspin hw.bas --code=cog
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
    Version 3.9.26-beta-d6b911c3 Compiled on: May  1 2019
    hw.bas
    warning: : indirect function calls are not supported in COG mode
    hw.pasm
    hw.pasm(286) error: Unknown symbol arg02_ret
    Done.
    
    That warning really helps... \o/
    Thanks!
    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ No Source – No Go! ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷
Sign In or Register to comment.