PropBasic SUBs

This is my first attempt at trying to get a better understanding of how to use PropBasic subroutines. All this program does is, turns on a pin, with an LED attached, for a specified amount of time. I think I put in enough comments to explain things.

In the subroutine itself I used VAR, at this point, I am not sure if some other variable type should have been used, like maybe HUB.

Ray
' led3.pbas
' July 18, 2018


DEVICE P8X32A ' Mandatory

''''' SUB defines '''''
OnOffLed SUB 

PROGRAM Start ' Mandatory

Start:
  OnOffLed 26,2000

END ' End program

''''' Subroutines '''''
' Use OnOffLed pin,time
' Example OnOffLed 26,1000 - turns on pin(led) 26 for
' one second, then turns the pin off.
SUB OnOffLed

  pinum VAR __PARAM1
  time VAR __PARAM2
  
  high pinum
  pause time
  low pinum

ENDSUB

Comments

  • 22 Comments sorted by Date Added Votes
  • BeanBean Posts: 7,954
    edited July 18 Vote Up0Vote Down
    In PropBASIC variables are global to the TASK (including the main TASK). There are no "local" variables for subroutines.
    You can define variables in a SUB but it will be global anyway.
    Note that __PARAMx would be overwritten if your SUB calls another SUB, so it is best to assign the __PARAMx to a variable.
    Also when you declare the SUB you should specify how many parameters there are:
    OnOffLed SUB 2
    
    SUB OnOffLed
      pinum VAR LONG
      time VAR LONG
      pinum = __PARAM1
      time = __PARAM2
    
      HIGH pinum
      PAUSE time
      LOW pinum
    ENDSUB
    

    HUB variables are for arrays, strings and passing values between TASKs.

    Edit:
    Using "pinum VAR __PARAM1" just creates an alias for __PARAM1. If __PARAM1 is changed (by calling another SUB) the value would still be lost.

    Bean
  • In the program below I made the changes that Bean recommended and I also added LMM to the Program Start. I wanted to see what the prop spin obj size(s) would be.
    The code sizes:
    Native - prop spin obj - 5KB
    LMM - prop spin obj - 10KB
    It looks like the spin obj size doubled, but does that really mean that the added LMM code is 5KB, or does it mean that the actual program doubles in size.

    The other surprising thing is the actual Native spin obj size - 5KB. I was expecting, for such a small program, that the size would be way under 1KB. So, what is really all the overhead?

    Ray
    ' led3.pbas
    ' July 18, 2018
    
    
    DEVICE P8X32A ' Mandatory
    
    ''''' SUB defines '''''
    OnOffLed SUB 2
    
    PROGRAM Start LMM ' Mandatory
    
    Start:
      OnOffLed 26,2000
    
    END ' End program
    
    ''''' Subroutines '''''
    ' Use OnOffLed pin,time
    ' Example: OnOffLed 26,1000 - turns on pin(led) 26 for
    ' one second, then turns the pin off.
    SUB OnOffLed
      pinum VAR LONG
      time VAR LONG
    
      pinum = __PARAM1
      time = __PARAM2
      
      high pinum
      pause time
      low pinum
    
    ENDSUB
    
  • I am using the PropellerIDE and the FLiP module for my experimentation. In the program below I added a TASK, which toggles pin 27 LED on the FLiP module. The program runs as expected, but I am curious as to what I am seeing in the folder.

    In the folder I now have four files listed:
    led3 Propeller binary 1KB
    led3 PBAS File 1KB
    led3 Propeller Spin obj 6KB
    led27 Propeller Spin obj 4KB

    Since led27 obj is shown as a separate item, is this a quirk with PropellerIDE, or am I supposed to derive something interesting out of this?

    As for the different file sizes that are listed, if I wanted to compare a program size with a PropGCC program of comparable code, which values would I use.

    Ray
    ' led3.pbas
    ' July 18, 2018
    
    
    DEVICE P8X32A ' Mandatory
    
    ''''' SUB defines '''''
    OnOffLed SUB 2
    
    ''''' Task defines '''''
    led27 TASK AUTO ' Start the task automatically.
    
    PROGRAM Start ' Mandatory
    
    Start:
      OnOffLed 26,2000
    
    END ' End program
    
    ''''' Subroutines '''''
    ' Use OnOffLed pin,time
    ' Example: OnOffLed 26,1000 - turns on pin(led) 26 for
    ' one second, then turns the pin off.
    SUB OnOffLed
      pinum VAR LONG
      time VAR LONG
    
      pinum = __PARAM1
      time = __PARAM2
      
      high pinum
      pause time
      low pinum
    
    ENDSUB
    
    ' This starts in a new core(COG) and toggles pin 27.
    TASK led27
    
    Start:
    
      high 27
      pause 500
      low 27
      pause 500
      
    GOTO Start
    
    ENDTASK
    
  • One of my PropGCC projects that I am considering for a PropBasic conversion is a program that I use for ADC input. In SimpleIDE there is a function for ADC usage, makes life easy. Now, I do not have the slightest idea of what the first steps would be for a PropBasic driver for the ADC, in this case, I guess an ADC0831-8. I believe that is what is used on the Activity Board.

    I am aware that PropBasic has the "include" function, for loading propeller assembly code, would that include a Spin obj file? If so, how would I deal with the ADC0831_DEMO Propeller Spin obj that I downloaded from the OBEX? I guess all this would be simplified if there was a PropBasic ADC driver already available.

    Since I have mentioned the "include" component, how would that work for using all the Spin files that are available in the OBEX with PropBasic. Or at least using the Spin stuff that provides drivers for ADC, SD, Badge, …, etc.

    Ray
  • BeanBean Posts: 7,954
    PropBASIC compiles to assembly. Assembly cannot run SPIN code, therefore PropBASIC cannot run SPIN code.

    It looks like the ADC0831-8 is an SPI device, so you would use the SHIFTIN function in PropBASIC.

    I'll see if I can find some SPIN code that I can convert.

    Bean
  • I guess an ADC0831-8. I believe that is what is used on the Activity Board.
    Swing and a miss. The Activity Board uses the ADC124S021 -- it's critical to know what part you have before writing code. I've attached my Spin object for that component which shouldn't be too difficult to translate.
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • So, I guess, by using an ADC, we need two ADC drivers, one for use with the Activity Board, and one for use with an ADC0831. I would imagine some people would want to experiment with the FLiP module by adding an ADC0831, since those are readily available at the Parallax store.

    @Bean, just for some more detail, what does the "include" component do for you? If it loads and provides access to PASM code, then it would be a great benefit if there was PASM drivers for all the little components that are available to use with the Propeller. Not sure if I am on the right tract with this thought. Of course, now the question is, who is going to write all that PASM code.

    Ray
  • BeanBean Posts: 7,954
    "include" just compiles the code in the file specified as if it were in your program.
    If you want to use PASM in PropBASIC simply use ASM...ENDASM tags.

    P.S. I looked for 10 minutes on the Parallax website and could not find any mention of what ADC was in the Activity Board :(

    Bean
  • Jon says - "The Activity Board uses the ADC124S021...", and he includes a Spin file. Three posts back.

    @Bean, Since you also have a "load" component, what is the difference between the two. What am I missing here?


    Ray
  • JonnyMacJonnyMac Posts: 6,092
    edited July 19 Vote Up0Vote Down
    I looked for 10 minutes on the Parallax website and could not find any mention of what ADC was in the Activity Board :(
    Page 2 of this document: https://www.parallax.com/sites/default/files/downloads/32910-Propeller-Activity-Board-RevA-Schematics.pdf
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • Hi Bean

    As for the Activity Board, I was able to find three schematics, one for each board part number/revision code:

    # 32910 - REV A

    https://parallax.com/sites/default/files/downloads/32910-Propeller-Activity-Board-RevA-Schematics.pdf

    # 32912 - REV A

    https://parallax.com/sites/default/files/downloads/32912-Propeller-Activity-Board-WX-Rev-A-Design-Files.pdf

    # 32912 - REVs B and C

    https://parallax.com/sites/default/files/downloads/32912-Propeller-Activity-Board-WX-Schematic-Rev-B-and-C.pdf

    From the above, two of them does have a parts list, wich uses the same part number for the ADC, # 600-10014; that points to a TI part, ADC 124S021.

    ti.com/lit/ds/symlink/adc124s021.pdf

    Except for the three above, I couldn't find any other part # related to a Propeller Activity Board, thus I hope the one you is talking about fits one of them.

    Hope it helps a bit.

    Henrique
  • In time

    There was also the following '2014 thread about the PAB ADC

    forums.parallax.com/discussion/157723/propeller-activity-board-embedded-adc

    I was not able to find the OBEX entry JonnyMac did mentioned at the following post; perhaps he could jump in and provide some help.

    forums.parallax.com/discussion/comment/1297684/#Comment_1297684

    Henrique
  • BeanBean Posts: 7,954
    "INCLUDE" simply compiles the code in the file as if it was in your program.

    "LOAD" is for libraries. They actually have different sections that get compiled at different times. These are much more complicated to make, but are much more versatile. I haven't made one of these in a long time. I can work on making one for the ADC if you want.

    Bean
  • I removed most of my ObEx contributions. I may restore them later. I did attach the Spin object I wrote for the ADC124S021 in earlier in this thread.
    Jon McPhalen
    Hollywood, CA
    It's Jon or JonnyMac -- please do not call me Jonny.
  • BeanBean Posts: 7,954
    Ok, I didn't realize the pdf didn't have anything about how to create a library. I will add that to it.

    Some of the downloads in the obex for PropBASIC are libraries.

    VGA2 VGA4, TV, TV40.

    Basically you have all the defines (CON PIN VAR "name SUB", "name TASK"), then you put a '{$CODE} directive, then all the code for the SUBs, then a '{$TASKS} directive, then any TASK code.

    Bean
  • JonnyMac wrote: »
    I removed most of my ObEx contributions. I may restore them later. I did attach the Spin object I wrote for the ADC124S021 in earlier in this thread.

    Ouch, my bad. I'm sorry for being so distracted!

    The more I read, the more escapes from my sight.

    Henrique
  • jmgjmg Posts: 12,094
    edited July 21 Vote Up0Vote Down
    Yanomani wrote: »
    ...

    From the above, two of them does have a parts list, wich uses the same part number for the ADC, # 600-10014; that points to a TI part, ADC 124S021.

    ti.com/lit/ds/symlink/adc124s021.pdf

    That part also has faster siblings, up to 1 MSPS - not used by default, but someone might upgrade to them.

    If Bean is doing a support for this ADC, you might like to scan this thread

    https://forums.parallax.com/discussion/168694/help-wanted-oscilloscope#latest
    where Matt is doing the PC-side tests for Web-hosted scope etc displays.

    A useful code-example variant, would be a 1-COG SPI-UART ADC bridge, that simultaneously reads ADC124S021 and writes serial, as fast as P1 can manage, perhaps with a simple DJNZ sample counter ? (512~1M?)
    I did some pencil-paper work on that, and fastest looks to be a paced-bit-copy, that copies the 12 ADC bits into 2 UART bytes, with packers and pauses in the SPI CLK, to align the UART timing.
    PC does the buffering, and P1 side is a quite simple bridge, with a very precise sample rate. (becomes a bit like i2s, but over UARTs)


    Matt reports 921600 looks to work in that Browser-Hosted environment as a continual Baud speed.
    Continual Rx tests I've done on UARTS show FT231X/CP2102N can manage 3MBd continual, and
    EXAR (XR21B1420) can manage 8MBd and a FT2232H (HS-USB) can manage 12 MBd
    A 12b to 2 byte serial send at 3MBd, would give 150k sps for quite good scope work. 921k Baud gives a still useful 46080 sps.


  • Below is my attempt at doing some serial com stuff. I was really trying to create some UI code, but it is not working the way I thought it would.

    Basically I want to set up sort of command respond scenario. As a starting point, maybe when I type in "quit", at the terminal screen, the program stops. The problem, so far is, when I do ' IF inBuff = "quit" THEN EXIT', an error pops up stating there is something wrong with, I guess "quit" not being a 'val'. That is my interpretation, probably all wet on that one.

    This again pertains to the PropGCC program that I would like to convert too PropBasic. There are three critical parts to the PropGCC program, 1. use of the ADC; 2. use of a com link; 3. TASKing, in this case turning on/off of specific device as a separate activity. I guess I could add a fourth item, access and usage of the WX WiFi module. Yes, The WiFi module has also been working with out a fault.

    The Activity Board that I have been using has been running, without a fault, for more than a year now, but I would like to switch over to a FLiP module configuration, with the appropriate components. The Activity Board should be used more like an experimentation device.

    ' uart1.pbas
    ' July 19, 2018
    ' 
    ' 
    DEVICE P8X32A, XTAL1, PLL16X ' Mandatory
    FREQ 80_000_000
    
    BAUD CON "T115200"
    SOut PIN 30
    SIn PIN 31
    
    inBuff VAR LONG
    
    SendChar SUB 1
    SendStr SUB 1
    ReadStr SUB 1
    write SUB 1
    
    PROGRAM Start ' Mandatory
    
    ' Main UI loop
    Start:
      SendStr "A\r"
      write "Does this work?\n"
      
      DO
        write "\n> "
        SERIN SIn,BAUD,inBuff
        IF inBuff = 0 THEN EXIT
        write inBuff
      LOOP
    
    END
    'Use: SendChar "A"
    SUB SendChar
      SEROUT SOut, BAUD, __PARAM1
    ENDSUB
    
    'USE: SendStr "String", can also embed a CR - SendStr "string\n"
    SUB SendStr
      __PARAM2 = __PARAM1
      DO
        RDBYTE __PARAM2,__PARAM1
        INC __PARAM2
        IF __PARAM1 = 0 THEN EXIT
        SendChar __PARAM1
      LOOP
    ENDSUB
    
    SUB write
      printStr VAR LONG(40)
      printStr = __PARAM1
      SendStr printStr
    ENDSUB
    
    'SUB ReadStr  
    '  SERIN SIn,BAUD,__PARAM1
    'ENDSUB
    
  • And yet another point of confusion, for me at least, the "file" component. Now there are three components, "include", "load", and "file". The PDF docs have some very very terse explanations as to how these should be used, in a full functional manner.

    For the "file" component - "Loads a binary data file." A brief explanation "file contains the text HELLO". So, do I covert the text "HELLO" to binary and place it in a txt file? Just curious, what is the binary form of HELLO.


    Ray
  • Rsadeika wrote: »
    And yet another point of confusion, for me at least, the "file" component. Now there are three components, "include", "load", and "file". The PDF docs have some very very terse explanations as to how these should be used, in a full functional manner.

    For the "file" component - "Loads a binary data file." A brief explanation "file contains the text HELLO". So, do I covert the text "HELLO" to binary and place it in a txt file? Just curious, what is the binary form of HELLO.


    Ray

    A text string is usually placed in a binary file as an array of the 8 bit ascii codes for the desired characters, usually followed by a null byte (hex 00, binary 00000000) as the end of string indicator. IOW no conversion is usually needed.
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • Over the past couple of days I have been re-evaluating PropBasic. For the new forum members, Propbasic has been around for at least eight years, so it is not a new item. For my purposes and the way I program, PropBasic does not fill my needs. That said, I am not implying that it is a bad language, in fact it is a good language, which just does not fill my needs at the moment.

    The biggest sore point is the lack of drivers and some instruction as to how the drivers would be implemented within a SUB/FUNC/TASK. Having said that I have not really explored a specific tool called spin2c.

    If I remember correctly, with spin2c, you can have a spin program converted to PASM. So theoretically you could convert a spin program that uses a specific component to PASM, and then use the PASM code, using asm … endasm within a SUB/FUNC/TASK to get the driver aspect that is needed. Then you would really have to know something about PASM, in order to figure out how to use the specific parts of the PASM code. Sounds very tedious, but that is better, I guess, than waiting for some drivers to magically appear on the forum, for PropBasic anyway.

    I will probably have look into this, just to see how tedious and involved that approach would be.

    Ray
  • MicksterMickster Posts: 1,195
    edited July 21 Vote Up0Vote Down
    Thus far, I haven't needed any drivers because I write what I need. Admittedly, I haven't attempted any SPI stuff yet but I do with other micro-controllers and in every case, I need to reference the data-sheet of the device that I need to talk to.

    Something I keep meaning to look at; how big of a deal would it be to make existing PASM objects work with PropBasic, using the asm directive?
    PropBASIC ROCKS!
Sign In or Register to comment.