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

Download PropBASIC here... 00.01.14 LAST VERSION FOR BST

12324252628

Comments

  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2013-03-03 01:24
    Hi Maxwin,

    It took me quite a while to figure out how to load libraries into tasks, but I managed to find a way that works. You actually have to create two libraries: one library with ONLY the SUB and FUNC definitions which go at the top of the Task BEFORE your own SUB and FUNC definitions and another library with ONLY the SUB and FUNC code which go at the bottom of the Task AFTER your own SUB and FUNC difinitions.
    I have attached an example of how to do this.

    Sometimes programs become just too long to easily work on, so I also found a way to write Tasks as separate code and then also just include them in the main program (including loading Libraries into the Task). I have attached an example if this as well.

    The Attachment is a zip file.

    I hope this helps.

    Regards
    Andre
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2013-03-03 01:43
    One of those days :-(

    Here is the attachment.
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2013-03-03 03:51
    Hi Everybody,

    Following on from Maxwin's question on how to include Libraries in Tasks, I though the I should perhaps share some of the Libraries which I have written.

    The first example is for an I2C Library which allows you to read or write either one or two Bytes (i.e. either a BYTE or a WORD) as well as using Data Addresses consisting of one Byte or two Bytes by assigning the appropriate value to the Address_Len Variable. It also caters for devices like the PCF8574 which do not have a Data Address, in which case you would assign zero to the Address_Len Variable. The I2C Pin Labels (I2C_SDA and I2C_SCL) are hardcoded in the I2C Library, but using variables, it is possible to dynamically change the Pin Numbers which are assigned to the hardcoded Pin Labels. Have a look at the TX_RX example of how to dynamically assign different Pin Numbers to the hardcoded Pin Labels.
    Note that you ONLY have to define the Control Byte for the I2C WRITE operation - the Library code will do the necessary for I2C READs.

    Secondly, because the TX_RX Library does not allow us to use variable Pins and Baud Rates, I have modified the TX_RX Library to so that we can use variables in the Main Program or Tasks for the TX and RX baud rates making it is possible to dynamically change the Baud Rates. Note that Labels TX_Pin, RX_Pin, TX_Baud and RX_Baud are hardcoded in the TX_RX Library. I have attached an example of how to use variable Baud Rates as well as changing the Pin Numbers assigned to the TX_Pin and RX_Pin Labels. This means that you can use the same TX_RX Library to write to many different Serial devices connected to different Pins and with different Baud Rates.

    Please let me know if you get stuck with anything.

    Regards
    Andre

    PS. The files with the _SUBS and _CODE names are for inclusion in Tasks. See my reply to Maxwin on how to include Libraries in Tasks.
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2013-03-03 04:55
    Something which I forget to mention about the modified TX_RX library: I have written a new subroutine called TX_DECX which is based on the “standard” TX_DEC, except the new subroutine allows you to specify the number of digits that you want to display, especially useful for something like LCDs where you want a fixed number of digits displayed. TX_DECX will pad with leading zeroes if necessary, but take note, it will truncate leading digits if the number is larger than the number of digits to display. I have attached a sample program.
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2013-03-03 06:08
    Finally, I have attached a library of Subroutines and Functions which I originally started writing mainly to get some of the .BIT and .BYTE alias functionality which we have in PBasic for the Basic Stamps, but it has expanded over the past 2 years and now contains all sorts of stuff.

    Most of the subroutines and functions are fairly simple and their usage should be easily understood from the comments.

    I have attached sample programs for most of the utilities. Note that these are my original test programs and are not always verbosely commented, but if you run them, you will get an idea of how it works.

    Once again, the libraries with the _SUBS and _CODE in their names are for inclusion in TASKS.

    Perhaps someone finds this useful.

    Regards
    Andre
  • VonSzarvasVonSzarvas Posts: 2,712
    edited 2013-03-03 06:35
    Wow Andre !

    That's a lot of great material... Thank you.
    Will feedback later on the task libs once I can run some tests.
    Max.
  • VonSzarvasVonSzarvas Posts: 2,712
    edited 2013-03-03 07:32
    Yes, great, that solves the matter by splitting into head and code files. Although 1 extra code line "load", its not a big effort- and is especially nice that the same technique can be used in the main cog and the tasks. That keeps things much simpler.

    For reference, here is the update of my previous example, now working fine calling the same library code from both the main cog and task cog.

    Thanks again Andre (and for TX_DEC also-- that was missing from my tx-lib) :)


    TestLibs.pbas
    DEVICE          P8X32A, XTAL1, PLL16XXIN             5_000_000
    
    LOAD "lib_delays.h.pbas"
    
    LED1            PIN   1    LOW
    
    TASK_BLINKLED     TASK AUTO
    
    
    PROGRAM Start
    
    Start:
    
    DO
          TOGGLE LED1
          DELAY_MS 1000
    LOOP
    
    
    END
    
    
    LOAD "lib_delays.pbas"
    
    ' Task code
    
    
    TASK TASK_BLINKLED
    
    LED2            PIN   2    LOW
    
    LOAD "lib_delays.h.pbas"
    
    DO
    
          TOGGLE LED2
          DELAY_MS 1000
          
    LOOP
    
    
    
    
    LOAD "lib_delays.pbas"
    
    
    ENDTASK
    

    lib_delays.h.pbas
    ' Delays Library for PropBASIC by Jon McPhalen
    DELAY_MS        SUB     1                       ' shell for PAUSE
    DELAY_US        SUB     1                       ' shell for PAUSEUS
    

    lib_delays.pbas
    ' Use: DELAY_MS duration' -- shell for PAUSE
    
    
    '{$IFUSED DELAY_MS}
    SUB DELAY_MS
    
      PAUSE __param1
      
    ENDSUB
    '{$ENDIF}
    
    
    ' ----------------------------------------------------------------------
    
    
    ' Use: DELAY_US duration
    ' -- shell for PAUSEUS
    
    
    '{$IFUSED DELAY_US}
    SUB DELAY_US
    
      PAUSEUS __param1
    
    ENDSUB
    '{$ENDIF}
    
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2013-03-03 08:46
    And finally, finally, here is another library which I have been working on for a while and decided to finish at long last. It is for Parallel LCDs connected DIRECTLY to the Propeller (Can not use TX_RX Lib for Parallel LCDs :-( )

    The library contains SUBS for:

    * Sending an LCD Control Code
    * Writing a Byte
    * Writing a String (DATA or a Literal e.g. "My name is Andre"). It also allows for using the "@" character as a DATA terminator instead of zero because sometimes DATA strings have zeroes in them. The "@" is hardcoded in the Library, but you can change it to something else if you like.
    * Writing a specified number of Digits without Leading Zeroes or Spaces for a Number (Constant, Variable or Literal)
    * Writing a specified number of Digits with Leading Zeroes for a Number (Constant, Variable or Literal)
    * Writing a specified number of Digits with Leading Spaces for a Number (Constant, Variable or Literal)

    I have attached a sample program.

    If you are going to use an IO Expander instead of connecting the LCD Pins directly e.g. 74HC595, MCP23008, MCP23S08, PCF8574, etc. you will have to modify the "LCD_CMD" and "LCD_BYTE" subroutines of the Library (and your program, obviously) to cater for the different output methods. If anybody gets stuck with this, let me know. I have sample programs for all these IO Expanders.

    I also use the SparkFun Serial LCD Backpack often to save Pins (With the added advantage that you can use the modified TX_RX Lib), so if anybody requires help with this backpack, I will probably be able to assist. They are a little finicky to get to work properly. I have not had much success with Baud Rates higher than the default 9600. I have managed to get them to talk to the propeller at 115200 baud, but the comms is very eratic, so I tend to stick to the default 9600 Baud. In any case, changing the Baud Rate is a MISSION!

    I hope this is useful.

    Regards
    Andre
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2013-03-03 12:20
    Something which I have to mention specifically regarding UTILS_LIB.pbas for the Look_Down and Look_Up Functions is that the DATA needs to be enclosed by "[" at the start and "]" at the end, e.g. Char0 DATA "[ABCDE]".

    I have attached an Example program.

    Regards
    Andre
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2013-04-03 12:50
    Hi Bean,

    If I define variables in a subroutine as per the sample code below, am I correct in assuming that when the subroutine has finished executing, the variables defined in the subroutine are deleted or released? In other words, these variables exist only for the duration of the subroutine?
    SUB LCD_STR
    
    LCD_STR_Index      VAR    LONG
    LCD_STR_Delimit    VAR    LONG
    
    ' Do Stuff
        
    ENDSUB
    

    Regards
    Andre
  • VonSzarvasVonSzarvas Posts: 2,712
    edited 2013-04-03 23:23
    Hi Bean,

    If I define variables in a subroutine as per the sample code below, am I correct in assuming that when the subroutine has finished executing, the variables defined in the subroutine are deleted or released? In other words, these variables exist only for the duration of the subroutine?
    SUB LCD_STR
    
    LCD_STR_Index      VAR    LONG
    LCD_STR_Delimit    VAR    LONG
    
    ' Do Stuff
        
    ENDSUB
    

    Regards
    Andre

    Hi Andre,

    I think you will find they are common to the source file they exist in (common to the cog).
    If you try to define the same var name in another sub, you will get an error that the var already exists.
    For that reason, I usually prefix the sub-var name with the sub name, just to ensure they don't get re-used / conflict later

    such as:
    SUB getFishCount
    
       getFishCount_idx    VAR    LONG
       getFishCount_tmp    VAR    LONG
    
    


    (oops, I can see you already used the prefix in your example!)
    Anyhow, the vars are not specifically released or destroyed. The values remain as last set. They could be read or changed by any other code in the same cog.
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2013-04-04 03:46
    Hi Maxwin,

    Thanks for the reply :-)

    I ran a small test program and found that variables defined in a sub are not cleared but that they are local to the sub - If you reference a variable which was defined IN a sub OUTSIDE of the sub, the compiler generates an error.
    ' LCD_STR_Index = 0    ' <== This generates a compiler error: ERROR 10  UNKNOWN COMMAND "LCD_STR_Index"
    
    DO 
      LCD_STR 
    LOOP
    
     
    SUB LCD_STR
    
      LCD_STR_Index    VAR  LONG
      
      TX_DEC LCD_STR_Index
      TX_BYTE 13
      
      INC LCD_STR_Index    ' The variable is incremented with every pass
      
      PAUSE 1000
      
    ENDSUB
    

    Problem solved :-)

    Regards
    Andre
  • BeanBean Posts: 8,122
    edited 2013-04-04 04:44
    Andre,
    All VARs "in a cog" are common. So VARs in other TASKs can have the same name (but not HUB variables, they are common to ALL cogs).

    PropBasic is a single pass compiler. So it doesn't know LCD_STR_Index exists before it is declared. Hence the error...

    Bean
  • tritoniumtritonium Posts: 522
    edited 2013-05-04 05:42
    Hi
    I've been monitoring this board for quite a long time and have only just discovered PropBasic!!!!
    I've read people mention Basic but assumed it was to to with the stamp!!!! :thumb:

    What a great facility - and if I understand the compiled code can be viewed and tweeked as well!!!
    Ah well I have some catching up to do...
    I expect everyone but me knows, BUT, will a version be available for the prop2??? :innocent:

    Dave
  • BeanBean Posts: 8,122
    edited 2013-05-04 05:47
    Dave,
    Not unless the Prop2 IDE supports external compilers.
    I've put a lot of work into PropBasic and I've come the conclusion that unless you can use the Parallax IDE, the language will never really take off and be used by the masses.

    Bean
  • VonSzarvasVonSzarvas Posts: 2,712
    edited 2013-05-04 09:20
    Bean wrote: »
    Dave,
    Not unless the Prop2 IDE supports external compilers.
    I've put a lot of work into PropBasic and I've come the conclusion that unless you can use the Parallax IDE, the language will never really take off and be used by the masses.

    Bean

    I really hope that PropBASIC can be supported in the future version of the Parallax IDE.

    The work that Bean has put into PropBASIC is faultless, and being at a loss without it, I would support any paid or community-effort initiative to keep it alive.

    Bean - your great efforts have not been fruitless... rather an amazing work which (for me) is the only reason I continue to Propeller since the SX days. I really hope many more closet PropBASIC fans are out there, and can voice support to help PropBASIC remain and develop alongside future Parallax Propeller Languages.

    It seems to me that PropBASIC is a more logical choice for new-user education, as it (BASIC) is a widely understood concept; and the fact that PropBASIC compiles to PASM provides the steps to the next level for all users- especially the young with brains made of sponge. Please find a way to keep the dream alive. Long Live PropBASIC!

    Hajr
  • tritoniumtritonium Posts: 522
    edited 2013-05-04 14:54
    I cant claim to be lost without Beans Basic (better name) because I have only just found it, but now that I have I will dust off my chameleon and give it a try.
    Why dust it off - because the learning curve was too steep to achieve useful results.
    From the manuals I am reading it seems to be a resource that Parallax would be foolish not to support.
    If its half as good as it seems at first reading, then it makes a soft entry possible into the unique world called Propellar, showing quickly how powerful the processor(s) is(are), and how flexible a system it is having ONLY those I/O services installed that are required, and how fast and predictable those services are.
    The ability (it appears) to view the pasm that Beans Basic produces has got to be a great educational tool.
    How many processor companies have people like Bean ready to provide programming tools like this for FREE!!


    Dave
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2013-05-05 07:18
    I gave up on Basic Stamps a long time ago because of the exorbitant prices and started looking for something else. The propeller is unbeatable value for money, but were it nor for PropBasic, I would not have have moved to the propeller. At this stage of my life I have no interest whatsoever in learning Spin (or C, for that matter). In any case, here in South Africa I can buy eight 40-pin PDIP Propeller chips including EEPROM, Crystals and IC sockets for the price of one BS2PX! Talk about a no-brainer. Instead of Basic Stamps, I now use the Basic Micro Nano 8 and Nano 18 for the smaller projects for which a Propeller is a bit of an "overkill".

    Bean deserves the utmost recognition for PropBasic. Sure, there are a few things that I personally miss in PropBasic, such as the ability to use mathematical expressions (please, please please, Bean?) and using multiple values with SERxxx, SHIFTxxx and I2Cxxx, and perhaps even floating-point math, but otherwise, as far as I am concerned, PropBasic is a fully-fledged, powerful, and above all, user-friendly programming language. I do not know the politics at Parallax, but their disregard in general for Basic as a programming language for the Propeller is, to say the least, both unfathomable and disconcerting.

    An integrated IDE for PropBasic would be nice, but the lack of such is not an issue for me. I have set up Notepad++ to my liking with syntax colouring as well as shortcut keys for compiling and loading and since I ( beladly :-( ) discovered the /P and /E PropBasic command line switches, I hardly use ViewPort for syntax checking anymore (ever since I had to re-install my PC, I just cannot get BST IDE to work).

    May both Bean and PropBasic yet have long lives ahead of them, and Bean, if you should ever decide to start charging money for PropBasic, I would gladly pay! Without PropBasic, I would be lost!

    Andre
  • pmrobertpmrobert Posts: 660
    edited 2013-05-05 14:38
    I am in full agreement with Andre's statements.

    -Mike
  • PaulPaul Posts: 263
    edited 2013-05-06 17:57
    Bean wrote: »
    Dave,
    Not unless the Prop2 IDE supports external compilers.
    I've put a lot of work into PropBasic and I've come the conclusion that unless you can use the Parallax IDE, the language will never really take off and be used by the masses.

    Bean

    I'm also an admirer of all the work that Bean (and friends) has put into the PropBasic project. It is my opinion that somewhere, someday SimpleIDE (the new, soon to be, defacto IDE) will have PropBasic on the "Properties" tab. I know many people are working hard on PropGCC and Spin so its just a matter of time before the right people "get around to it". Lets face it, probably the second Spin program ever written was "BS2-functions.spin". This was because the transition from Pbasic to Spin was a bit overwhelming and there wasn't all the great documents that there is now. I remember that all of us Pbasicers were excited to be using this strange "parallel processor" chip. There has always been a need for some form of Basic and there will always be a need.
    I personally do not posess the skills to make something like this happen. I wish I did.

    Paul
  • KC_RobKC_Rob Posts: 465
    edited 2013-05-10 11:03
    Reading the last several comments here further confirms to my mind that interest in BASIC is far from dead. Maybe PropBASIC will get some love from Parallax soon, after some of the other fires have been put out.
  • ColeyColey Posts: 1,101
    edited 2013-05-10 11:48
    I hope it get's the love from Parallax it deserves too, it's a great compiler, helped me win a couple of big jobs :D

    Thanks Bean! :cool:
  • BatangBatang Posts: 234
    edited 2013-05-16 20:49
    Hi Bean,

    I see there is a BST version, what is different about this version as opposed to a non BST version?

    Azlan.

    Edit: I have not read all the documentation, does it support #IF #ELSE #END etc?
  • pmrobertpmrobert Posts: 660
    edited 2013-06-17 05:01
    Hi Maxwin,

    It took me quite a while to figure out how to load libraries into tasks, but I managed to find a way that works. You actually have to create two libraries: one library with ONLY the SUB and FUNC definitions which go at the top of the Task BEFORE your own SUB and FUNC definitions and another library with ONLY the SUB and FUNC code which go at the bottom of the Task AFTER your own SUB and FUNC difinitions.
    I have attached an example of how to do this.

    Sometimes programs become just too long to easily work on, so I also found a way to write Tasks as separate code and then also just include them in the main program (including loading Libraries into the Task). I have attached an example if this as well.

    The Attachment is a zip file.

    I hope this helps.

    Regards
    Andre
    Andre, just wanted to thank you for sharing this technique!

    -Mike
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2013-07-06 08:15
    Bean wrote: »

    P.S.S. The zip file also contains the latest version of PropBasic 1.30

    Hi Bean,

    Is 1.30 still the latest version of PropBasic? I had a look at the PropBasic for Viewport thread, but that still shows 1.27.

    Regards
    Andre
  • andre.nieuwoudtandre.nieuwoudt Posts: 65
    edited 2013-07-06 08:19
    Hi Mike,

    It is a pleasure - glad you found this useful.

    Regards
    Andre
  • BeanBean Posts: 8,122
    edited 2013-07-07 05:15
    Hi Bean,

    Is 1.30 still the latest version of PropBasic? I had a look at the PropBasic for Viewport thread, but that still shows 1.27.

    Regards
    Andre

    Yes, 1.30 is the latest.
    Here are the changes since 1.27
    Version 00.01.28
      Added: Support floating point constants with # prefix
      Fixed: FREQ command caused abort if DEVICE is misspelled
      Fixed: Allow constant with COGSTOP (was NOT fixed in 1.11)
      Fixed: tempStr = STR temp (needs ",len" but causes abort) [Oct 10,2012]
    
    Version 00.01.29
      Fixed: PAUSE XXXX does not cause an error
    
    Version 00.01.30
      Added: Directive VIEWPORT defined if using viewport
      NEED TO FIX: DO...LOOP x => y ' should be >= but no error
    
    
  • simonlsimonl Posts: 866
    edited 2013-08-26 13:07
    @Bean: Once again, many thanks for all your efforts with the excellent PropBASIC. I really hope you will continue to support it and develop it for Prop2.

    @ParallaxKen: PLEASE make sure that PropBASIC gets full support from Parallax. Without PropBASIC I would likely have given-up on the Propeller long ago - it's the simplest way for me to learn PASM, and I find PropBASIC much simpler to learn than C.

    C'mon - what say you?
  • TrapperBobTrapperBob Posts: 139
    edited 2013-08-26 14:06
    I say the exact same hing. PropBasic is fantastic! I hope that you find a way to make it part of the "full development package" for Prop2.

    3Cheers,
    Bob
  • DL7PNPDL7PNP Posts: 18
    edited 2013-08-26 14:16
    Yes thats right. there are exactly 3 great languages: Spin, PASM and PropBasic!
    I would love to see PropBasic support in the PropellerTool for both Propeller I and Propeller II

    73
Sign In or Register to comment.