Shop Learn
Download PropBASIC here... 00.01.14 LAST VERSION FOR BST - Page 23 — Parallax Forums

Download PropBASIC here... 00.01.14 LAST VERSION FOR BST

1202123252629

Comments

  • Wolfgang EbersbachWolfgang Ebersbach Posts: 10
    edited 2011-02-11 05:58
    Hi,

    I admit that I have another problem. I use WAITCNT but have learned, that WAITCNT waits for the given system counter value to EXACTLY MATCH the param.
    This leads to problems if your code is such that you MAY arrive at the WAITCNT a few clock cycles "to late" because then the program is blocked 2^32 cycles (until ctr reaches your value again after an overflow)

    I did therefore try this:
    Led PIN 27 HIGH
    delta VAR LONG
    target VAR LONG
    
    RDLONG 0, delta                                       ' read system frequency
    delta = delta >> 2                                      ' divide by 4
    target = cnt + delta                                    ' sync with system counter
    
      DO
        target = cnt + delta                                 ' this is of course not helpful if using WAITCNT :-)
        TOGGLE LED ' toggle led on P16
        'WAITCNT target, delta                             ' wait 1/4s (synchronized) - this does work as intended
        DO WHILE cnt < target                          ' this does not work but halt the cog forever. Why ?
        LOOP
      LOOP
    END
    

    The above code works as expected if using WAITCNT but not if I try to wait by using an empty loop until cnt becomes greater than target. Why ?
  • BeanBean Posts: 8,122
    edited 2011-02-11 06:21
    Wolfgang,
    Because "cnt" is signed. So it counts up to it's maximum positive value, then the next clock it becomes it's maximum negative value counts to zero, then start up the positive number again.

    You could just use PAUSE 250
    or you could do
        DO
          __param1 = cnt - target
        LOOP UNTIL __param1 > 0
    

    Bean
  • Wolfgang EbersbachWolfgang Ebersbach Posts: 10
    edited 2011-03-09 23:41
    Dear all,
    sorry for the next question. BUT it also includes an offer..

    The question first: I read in an 74lv165 ( shift register) with the prop and did try "SHIFTIN' for this purpose. This is very slow, around 60kBits/sec. Why is this so ?
    In the manual, there is a parameter "speed" mentioned for the SHIFTIN and SHIFTOUT commands, but it is not explained what format it is . Bits per second ? Hertz ? Kbits per second ? uSec pulse-duration ?
    Right now, I read the register "by hand" - set CLK pin high, read data pin, set clk pin low ... This is way faster than SHIFTIN. Which makes "shiftin" somewhat useless...

    And now the Offer:
    I learned that Propbasic, albeit beeing version 00.01... is already very usable and very powerful. Unfortunately, the manual is obviously behind the code. Some commands are not explained and often, the really interesting details are not explained or mentioned ( e.g. the whole String handling stuff, the fact that COGSTOP does not accept literal numbers and lots of other small but good-to-know things)
    I would offer to extend the manual with those details. Everytime I find out some confusing (for me) thing , I will write it down in the manual.
    Maybe this leads to sort of "propbasic for dummies" but in my opinion that is better than an non-complete manual.

    Dont get me wrong, I do really appreciate all the effort gone into ProbBasic, BST and the manual. But for beginners (like me) it is really very time-consuming to crawl all the details via searches in this forum.

    Anyhow, if you are interested in this offer, let me know. I will write down my findings anyhow, but it would be nice for the community if they would be used to extend the manual.

    With best regards,
    Wolfgang
  • BeanBean Posts: 8,122
    edited 2011-03-10 04:58
    Wolfgang,
    Your comments are very welcome.
    I would appreciate your help with a manual for PropBasic.
    I suggest we start a blog here so we can communicate without cluttering up the forums.
    Let me know and I'll start a blog if you are interested.

    P.S. The speed value is a multipiler. So a value of 2 would be twice as fast.

    Bean
  • BeanBean Posts: 8,122
    edited 2011-03-22 04:50
    Brad has posted version 00.01.08

    Changes are:

    Allows some escape sequences inside strings \r = return; \n = Enter; \\ = backslash; \" = embedded quote; \123 = char(123); \xEA = char($EA)
    If you have ANY strings with a backslash in them, you will need to change it to a double backslash.

    Added CLKSET mode,freq

    Allows more nested loops (raised limit from 127 to 1024)

    If a pingroup starts at pin zero, the pasm code no longer contains "shl xxx,#0"

    HIGH,LOW,TOGGLE,INPUT,OUTPUT,REVERSE if pin # is a constant < 9 then do shift as literal

    Allow I2C pins to be variables

    Changed LMM to use @@@ this makes jumps faster

    Bean
  • jonesjones Posts: 281
    edited 2011-04-02 14:48
    I'm a complete newbie to the Prop, and to PropBasic. I have used Basic, though it's probably been 20 years ago, and I'm not familiar with the Stamp or SX/B dialects. I'm extremely impressed by the compiler and the BST environment, however, and it looks perfect for the project I have in mind. I've used C to program the PIC line, though I wouldn't call myself a particularly experienced programmer (I write code only when I have to) and my problem could easily be operator stupidity.

    I have BST and PropBasic up and running and am working through the demos. Most have worked fine, but when I tried Serial_to_NTSC.pbas I ran into a problem. I get compile errors, and couldn't quite work through them.

    In line 44 I got an "unknown command" error, referring to "TV_SendChar". Looking at TV.lib I found that the command is really TV_Char, and changing the call to that name cleared the error.

    In lines 95 and 112 I got "Invalid parameter" errors complaining about two references to "vidmem". Again looking at TV.lib, it appears the array is actually TV_VidMem, and making that change cleared those errors.

    Finally, I got similar "invalid parameter" errors in lines 90 and 122 complaining about "Font". The character array in hub RAM in TV.lib is really TV_Font, so I expected when I changed the array reference in Serial_to_NTSC those errors would clear as well, but they didn't. In both cases it's a call to GetAddr, in one case to the base address of the array (i.e. no index specified), and in the other case it's also a call to GetAddr, but offset into the array with the parameter Font(__param1). I think I understand what's supposed to be happening, but I'm a bit confused by the fact that I can't clear the invalid parameter error. Since I never got the code to compile, I really don't know if my "fixes" really fixed anything. Based on what I think the code is doing, I believe they are OK. You know what they say about assumptions, however.

    Incidentally, the other demo programs that call TV.lib work fine. I think I have the current versions of everything, downloaded from the link at the beginning of this very long thread.

    Any guidance for the rookie would be appreciated. And thanks for the incredible effort and generosity to make the tools available!

    Bob
  • BeanBean Posts: 8,122
    edited 2011-04-02 15:02
    Jones,
    Yeah sorry about that.
    PropBasic is a work in progress and as things get changed sometimes the old demos need some changes too.
    You have the right idea...Look at the library file and make the changes needed.
    I've been trying to name library files as "xxx_lib.pbas" so you can double-click on them and BST will open.

    Bean
  • jonesjones Posts: 281
    edited 2011-04-02 15:10
    I just (think) I figured out that the call to "TV_SendChar" that I "corrected" to TV_Char, actually refers to the SendChar subroutine in the source file. That still clears the invalid command error, but I'm still scratching my head over the Font array reference. Maybe I need to scratch harder...

    Bob
  • GerryKeelyGerryKeely Posts: 12
    edited 2011-04-02 17:48
    Hi Bob

    I think the problem with Font is it should be TV_Font also the TV_Font data in TV.lib is incorrectly located in the $CODE section. Move the DATA section starting with

    ' Define DATA (DATA, WDATA, LDATA) and ending with
    DATA $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF ' Block
    up above the ' Define Subroutines section.

    the line '{$IFUSED TV_Char} should be just above
    SUB TV_Char ' character value

    This will clear the errors on lines 90 and 122.

    regards
    Gerry
  • jonesjones Posts: 281
    edited 2011-04-02 18:57
    Gerry -

    Thanks, indeed it did. I hadn't figured out how the compiler directives worked in the .lib file, and assumed (there's that word again) that because the other demos using TV.lib worked that it was OK. So it appears that the font table was being created correctly in hub RAM since the other demos had access to the fonts, it was just that when the source file referred to the TV_Font array the compiler couldn't find it in the .lib file because it was not where it was supposed to be. None of the other demos referred to the font table directly but called functions that could find it so they were OK.

    Thanks again for the help. I don't think I would've found that problem no matter how long I stared at it.

    I'm finding that the program still doesn't work right, but at least it compiles! For now I think I'll leave it at that and maybe revisit it when I know more.

    Cheers
    Bob
  • bsnutbsnut Posts: 521
    edited 2011-04-03 19:04
    Bean,

    I have entered into the Spinneret Contest and was thinking about doing the top object file in PropBasic. I have this one question for you. Can, I call variables that are done in Spin so they can be used in the PropBasic program, which is ASM code? The variables I am calling are all "LONG" and were created by an ladder logic program called PICoPLC.
  • BeanBean Posts: 8,122
    edited 2011-04-04 07:20
    Not sure what you mean by "calling" variables ???

    You can read/write spin variables my passing their address to PropBasic.

    Here is a simple example:
    DEVICE P8X32A,XTAL1,PLL16X
    FREQ 80_000_000
    
    ASM
    
    ' Spin code goes here
    
    VAR
      LONG myVar
    
    PUB Main
      myVarAddr := @myVar ' Tell PropBasic "myVar"'s address
      myvar := 0
    
      CogInit(1, @__Init, @__DATASTART) ' Start PropBasic code in COG 1
    
      REPEAT
        waitcnt(cnt+8000000) ' Wait 100mSec
        myVar+=1
    
      ' End of spin code
    ENDASM
    
    PROGRAM Start
    
    myVarAddr HUB LONG
    ascii     HUB STRING(20)
    
    temp      VAR LONG
    
    Start:
      RDLONG myVarAddr, temp ' temp=address of "myVar"
      DO
        RDLONG temp,__param1 ' get value of "myVar"
    
        ' Convert value to ascii and output to PST
        ascii = STR __param1, 10, 3
        ascii = ascii + 13
        SEROUT 30, T115200, ascii
    
      LOOP
    END
    
    

    Bean
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2011-04-04 09:06
    Hi Bean,

    I found a problem with Propbasic SHIFTIN modes which use the rev instruction: rev is done for the same number of Bits as shifted in, but it should actually be for 32 minus the number of Bits shifted in. I attach screen snips to illustrate. I tested with versions 1.04 and 1.08.

    Regards
    Andre Nieuwoudt
  • BeanBean Posts: 8,122
    edited 2011-04-04 13:46
    Andre, Yes you are right. I will correct that in the next release.

    Bean
  • bsnutbsnut Posts: 521
    edited 2011-04-04 15:35
    Bean,

    Good guess:smile:. So, is this the only way to move variables from spin file (non ASM) into PropBasic program? My goal was to make my spin file an Task, because my spin file (non ASM) runs in it's own cog with Start and Stop methods. Below is what I am kind of talking about.
    { This is auto-generated code from PICoPLC. Do not edit this file! Go
       back to the ladder diagram source for changes in the logic, and compile }
    
    CON
    _CLKFREQ = 4000000 'Hz
    _CLKMODE = XTAL1 + PLL16X
    CycleTime = 100 '1/sec
    var
     BYTE I_mcr
    var
     BYTE I_rung_top
    con
     U_Yclock = 1
    var
     WORD U_Tpulse
    var
     BYTE I_parOut_0000
    var
     BYTE I_parThis_0000
    var
     BYTE I_oneShot_0000
    var
     WORD U_Cshift
    var
     WORD I_scratch2
    var
     WORD U_buttons
    con
     U_Xdata = 0
    
    
    VAR
      LONG stack[100]
      LONG cog
    
    PUB Start
      cog := cognew(PlcCycle, @stack) +1
    
    PUB Stop
      if (cog)
        cogstop(cog~ - 1)
      cog~
    
    PRI PlcCycle | timing
      DIRA := $00000002
      DIRB := $00000000
    
      timing := cnt + clkfreq / CycleTime
      repeat
        I_mcr~~
        
        { start rung 2 }
        I_rung_top := I_mcr
        
        { start series [ }
        { Negated contact }
        if (OUTA[U_Yclock])
          I_rung_top~
        
        
        { TON element }
        if (I_rung_top)
          if (U_Tpulse < 9) 
            U_Tpulse++
            I_rung_top~
          
        else
          U_Tpulse := 0
        
        
        { start parallel [ }
        I_parOut_0000~
        I_parThis_0000 := I_rung_top
        { Normal coil }
        OUTA[U_Yclock] := I_parThis_0000
        
        if (I_parThis_0000)
          I_parOut_0000~~
        
        I_parThis_0000 := I_rung_top
        { CTC element }
        if (I_parThis_0000)
          ifnot (I_oneShot_0000)
            U_Cshift++
            if (U_Cshift < 9) 
            else
              U_Cshift := 0
            
          
        
        I_oneShot_0000 := I_parThis_0000
        
        if (I_parThis_0000)
          I_parOut_0000~~
        
        I_rung_top := I_parOut_0000
        { ] finish parallel }
        { ] finish series }
        
        { start rung 3 }
        I_rung_top := I_mcr
        
        { start series [ }
        I_scratch2 := 0
        { EQU element }
        if (U_Cshift == I_scratch2)
        else
          I_rung_top~
        
        
        { MOVE element }
        if (I_rung_top)
          U_buttons := 0
        
        
        { ] finish series }
        
        { start rung 4 }
        I_rung_top := I_mcr
        
        { start series [ }
        I_scratch2 := 1
        { EQU element }
        if (U_Cshift == I_scratch2)
        else
          I_rung_top~
        
        
        { Contact }
        ifnot (INA[U_Xdata])
          I_rung_top~
        
        
        { MOVE element }
        if (I_rung_top)
          U_buttons := 1
        
        
        { ] finish series }
        
        { start rung 5 }
        I_rung_top := I_mcr
        
        { start series [ }
        I_scratch2 := 2
        { EQU element }
        if (U_Cshift == I_scratch2)
        else
          I_rung_top~
        
        
        { Contact }
        ifnot (INA[U_Xdata])
          I_rung_top~
        
        
        { MOVE element }
        if (I_rung_top)
          U_buttons := 2
        
        
        { ] finish series }
        
        { start rung 6 }
        I_rung_top := I_mcr
        
        { start series [ }
        I_scratch2 := 3
        { EQU element }
        if (U_Cshift == I_scratch2)
        else
          I_rung_top~
        
        
        { Contact }
        ifnot (INA[U_Xdata])
          I_rung_top~
        
        
        { MOVE element }
        if (I_rung_top)
          U_buttons := 4
        
        
        { ] finish series }
        
        { start rung 7 }
        I_rung_top := I_mcr
        
        { start series [ }
        I_scratch2 := 4
        { EQU element }
        if (U_Cshift == I_scratch2)
        else
          I_rung_top~
        
        
        { Contact }
        ifnot (INA[U_Xdata])
          I_rung_top~
        
        
        { MOVE element }
        if (I_rung_top)
          U_buttons := 16
        
        
        { ] finish series }
        
        { start rung 8 }
        I_rung_top := I_mcr
        
        { start series [ }
        I_scratch2 := 5
        { EQU element }
        if (U_Cshift == I_scratch2)
        else
          I_rung_top~
        
        
        { Contact }
        ifnot (INA[U_Xdata])
          I_rung_top~
        
        
        { MOVE element }
        if (I_rung_top)
          U_buttons := 32
        
        
        { ] finish series }
        
        { start rung 9 }
        I_rung_top := I_mcr
        
        { start series [ }
        I_scratch2 := 6
        { EQU element }
        if (U_Cshift == I_scratch2)
        else
          I_rung_top~
        
        
        { Contact }
        ifnot (INA[U_Xdata])
          I_rung_top~
        
        
        { MOVE element }
        if (I_rung_top)
          U_buttons := 64
        
        
        { ] finish series }
        
        { start rung 10 }
        I_rung_top := I_mcr
        
        { start series [ }
        I_scratch2 := 7
        { EQU element }
        if (U_Cshift == I_scratch2)
        else
          I_rung_top~
        
        
        { Contact }
        ifnot (INA[U_Xdata])
          I_rung_top~
        
        
        { MOVE element }
        if (I_rung_top)
          U_buttons := 128
        
        
        { ] finish series }
        
        { start rung 11 }
        I_rung_top := I_mcr
        
        { start series [ }
        I_scratch2 := 8
        { EQU element }
        if (U_Cshift == I_scratch2)
        else
          I_rung_top~
        
        
        { Contact }
        ifnot (INA[U_Xdata])
          I_rung_top~
        
        
        { MOVE element }
        if (I_rung_top)
          U_buttons := 256
        
        
        { ] finish series }
        waitcnt(timing)
        timing += clkfreq / CycleTime
    
    .
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2011-04-05 06:28
    Bean wrote: »
    Andre, Yes you are right. I will correct that in the next release.

    Bean

    Hi Bean,

    Cool, thanks. In the mean time the work-around is fortunately very simple.

    Just one other thing: Is there a way around Propellent's problem with Propbasic LMM? Especially in version 00.01.08 which uses @@@? BST and BSTC work perfectly fine, though.

    Andre
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2011-04-09 12:47
    Hi Bean,

    I am afraid I have discovered another bug in Ver. 00.01.08: When using variables for the SDA and SCL Pins, the I2C_Start routine uses the SDA variable for SCL (__temp2) as well, instead of using the SCL variable.

    Example Code:

    SUB I2C_START

    __param1 = 29
    __param2 = 28

    I2CSTART __param1, __param2
    ENDSUB


    produces the following result:

    I2C_START 'SUB I2C_START


    mov __param1,#29 ' __param1 = 29

    mov __param2,#28 ' __param2 = 28


    mov __temp1,#1 ' I2CSTART __param1, __param2
    shl __temp1,__param1
    mov __temp2,#1
    shl __temp2,__param1


    The line "shl __temp2,__param1" should be "shl __temp2,__param2".

    It is only the I2C_START routine which has the problem, the other I2C routines are OK.

    Regards
    Andre Nieuwoudt
  • BeanBean Posts: 8,122
    edited 2011-04-09 14:25
    Andre,
    Yeah, I had caught that one already. But BradC hasn't responded to my update yet.

    Thanks anyway. It's good to know that someone is paying attention ;)

    Bean
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2011-04-10 03:30
    Hi Bean,

    I am systematically re-writing all my PBASIC code in PropBasic, so I have a suspicion that you will hear from me often.

    I am also creating Libraries for often-used code and right now I am trying to create a library for SHIFTIN and SHIFTOUT routines using Variables for the Data and Clock Pins, but it does not work because the Data Pin Variable is also used for the Clock Pin. Is this a bug or have you perhaps not yet enabled this functionality?

    Samples for SHIFTOUT and SHIFTIN:

    Shift_Out 'SUB Shift_Out

    mov __temp1,#1 ' SHIFTOUT __param1, __param2, LSBFIRST, __param3\8 ' DataIO, Clock,
    shl __temp1,__param1
    or dira,__temp1
    mov __temp2,#1
    shl __temp2,__param1
    or dira,__temp2
    mov __temp3,__param3


    Shift_In 'FUNC Shift_In

    mov __temp1,#1 ' SHIFTIN __param1, __param2, LSBPRE, __param3\8 ' DataIO, Clock,
    shl __temp1,__param1
    andn dira,__temp1
    mov __temp2,#1
    shl __temp2,__param1

    In both cases "shl __temp2,__param1" should be "shl __temp2,__param2".

    Regards
    Andre

    PS. SERIN and SEROUT work correctly when using a Variable for the Serial Pin.
  • BeanBean Posts: 8,122
    edited 2011-04-10 08:20
    That is another bug...
    I will fix that one too.

    Bean
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2011-04-11 09:38
    Bean wrote: »
    That is another bug...
    I will fix that one too.

    Bean

    Cool, thanks. I promise I won't find another bug for at least a week (hee-hee). But, jesting aside, PropBasic is GREAT !!!
  • TheBeefiestTheBeefiest Posts: 1
    edited 2011-04-11 21:18
    Hello, I was wondering if this tool supports 9-bit serial? (trailing address or parity bit manipulation)
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2011-04-13 11:43
    Hi Bean,

    I am really sorry for doing this to you, but I have found another problem. When using command "ON var GOSUB label1, label2 [, label3, [, etc]]", BST generates the following error: "Compiler crashed with run time error: 217 : Unhandled Exception". Propellent generates the following error: "Line (nnn) Undefined Symbol. mov dira, __InitDirA"

    These commands work fine,though:
    ON var = value1, value2, value3 GOSUB label1, label2, label3
    ON var GOTO label1, label2 [, label3, [, etc]]
    ON var = value1, value2, value3 GOTO label1, label2, label3

    Regards
    Andre
  • BeanBean Posts: 8,122
    edited 2011-04-13 14:19
    Andre,
    Okay, you are now the OFFICAL PropBasic tester...
    Yeah, I had a variable that was never initialized in there, it worked in the development environment because it was set to zero, but was a random value in the real-world.

    I fixed it, but I'm still waiting to hear from BradC... Hopefully the fix will be in the next release.

    Thanks again for your finds...

    Bean
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2011-04-14 04:34
    Always a pleasure! :thumb:
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2011-04-14 12:09
    Hi Bean

    Firstly I must say that I am absolutely thrilled by the fact that it is possible to alias VAR arrays! Thanks!
    Aliasing a HUB variable or array generates a syntax error, though.

    As for pre-initializing arrays, I found that this works: "myVar HUB LONG(4) = 0".

    But this generates a syntax error: "myVar VAR LONG(4) = 0". Admittedly, the Syntax Guide Ver. 00.01.04 does not specifically state that it is possible to pre-initilize a VAR array.

    Am I being too optimistic here?

    Regards
    Andre
  • VonSzarvasVonSzarvas Posts: 2,712
    edited 2011-04-21 01:59
    Is it possible that cogstop does not work? I seem to get an error thrown at compile time:
    COGSTOP 1
    

    throws...
    ERROR: INVALID PARAMETER "1"
    
  • VonSzarvasVonSzarvas Posts: 2,712
    edited 2011-04-21 02:02
    May I also ask...

    If I call this command from cogid 0
    COGINIT MyTask, 0
    

    Should this stop the code currently running in cog0, then start the new task code in cog0 (ie. restart the new cog/task over itself)
    OR - should this not work like that ?

    Thanks, Max.
  • BeanBean Posts: 8,122
    edited 2011-04-21 05:02
    Concerning "COGSTOP 1" that is bug. I'm not allowing a constant for the parameter. I'll fix that.

    Concerning "COGINIT MyTask, 0". Yes that should work like you said. It will start the task in the same cog as the main code.

    Bean
  • VonSzarvasVonSzarvas Posts: 2,712
    edited 2011-04-21 07:09
    Concerning "COGINIT MyTask, 0". Yes that should work like you said. It will start the task in the same cog as the main code.

    OK, I will cross that one off the list of possible showstoppers. BIG thanks !
Sign In or Register to comment.