Shop OBEX P1 Docs P2 Docs Learn Events
Do you use PropBASIC and do you need Libraries? — Parallax Forums

Do you use PropBASIC and do you need Libraries?

ColeyColey Posts: 1,108
edited 2011-02-02 19:00 in Propeller 1
I'm interested in guaging how many people use PropBASIC on a regular basis and what interest there is in converting many of the OBEX SPIN libraries.

In this thread you will see Baggers and myself working on libraries for TV drivers, the next logical step would be to convert some other libraries like Full Duplex Serial.

Thanks,

Coley

EDIT: The voting options are at the very top of this thread page, please vote if you can, thanks.

Comments

  • Cluso99Cluso99 Posts: 18,066
    edited 2010-09-01 01:30
    I think it would be a great idea for at least some of the more relevant objects. I thought FDX may have been done already. As soon as I get time I will convert my 1-pin TV & Keyboard if you like - this will make me look at PropBasic.

    I saw a reference that it was going to beome part of the PropTool which will be of great benefit to new prop users. IMHO Basic is much simpler than C or Spin for the beginner. Of course, they each have their place.

    Has anyone thought about what to do with the OBEX regarding PropBasic objects? Does it require a seperate section???
  • Heater.Heater. Posts: 21,230
    edited 2010-09-01 01:40
    Coley,

    I don't use PropBASIC and have no idea what it takes to convert existing Spin device drivers for use with it.

    However I do use C, as in Zog, which could probably make use of many existing objects.

    My approach so far is to:
    1) Take an Spin object and throw away the Spin part by compiling with BSTC with -Ox -c options.
    2) Create a C wrapper that provides the equivalent of the Spin interface methods and uses the binary blob produced by step 1).

    This works easily for objects that have the guts of their functioning in PASM with a thin Spin interface. FullDuplexSerial, float32, VMCog for example.

    FDX did need some small mods to remove some dependency on Spin statements that were tweaking vars in DAT prior to loading the COG. This will be true of all objects that don't have a clean PAR and "mailbox" interface.

    Anyway the point of all this is that I'm wondering if we can share some effort here and end up with PASM driver blobs that can be used with PropBASIC, C, LMM or whatever other language/systems pops up.
  • ColeyColey Posts: 1,108
    edited 2010-09-01 01:43
    Cluso99 wrote: »
    I think it would be a great idea for at least some of the more relevant objects. I thought FDX may have been done already. As soon as I get time I will convert my 1-pin TV & Keyboard if you like - this will make me look at PropBasic.

    I saw a reference that it was going to beome part of the PropTool which will be of great benefit to new prop users. IMHO Basic is much simpler than C or Spin for the beginner. Of course, they each have their place.

    Has anyone thought about what to do with the OBEX regarding PropBasic objects? Does it require a seperate section???

    Ray, thanks, your one pin driver would be a great addition.

    BASIC is ideal for getting more people interested in Propeller, even better if they have ready made libraries to use....

    The OBEX now includes a section for PropBASIC code, options are now Spin, ASM, C or BASIC.

    Regards,

    Coley
  • TonyWaiteTonyWaite Posts: 219
    edited 2010-09-01 01:44
    I'm not sure how to participate in the poll, but just to say that I use PropBasic and am thrilled that some of the libraries are being ported!

    Thank you,

    T o n y
  • ColeyColey Posts: 1,108
    edited 2010-09-01 01:59
    Heater. wrote: »
    Anyway the point of all this is that I'm wondering if we can share some effort here and end up with PASM driver blobs that can be used with PropBASIC, C, LMM or whatever other language/systems pops up.

    Heater, I guess that sharing ideas would be beneficial for all of us so let's go for it.
    As far as converting the existing OBEX files we re-code the Spin elements into PropBASIC and incorporate any PASM structure directly into the code. Effectively what you are left with a PASM module which could be called from C or any other language for that matter (with the right mechanism of course)

    Regards,

    Coley
  • ColeyColey Posts: 1,108
    edited 2010-09-01 02:00
    TonyWaite wrote: »
    I'm not sure how to participate in the poll, but just to say that I use PropBasic and am thrilled that some of the libraries are being ported!

    Thank you,

    T o n y

    T o n y,

    Look at the top of this post and you will find the voting buttons.

    Regards,

    Coley
  • Heater.Heater. Posts: 21,230
    edited 2010-09-01 02:18
    Coley,

    Problem is that Zog is a byte code interpreter, calling PASM library functions is not directly possible.

    What I'm aiming for is objects whose PASM parts are loaded from binary blobs. All set up is done via PAR parameters and all interaction with the running PASM done through a memory "mailbox".

    Because of the binary blobs there is no "linkage" between C and the PASM in the conventional sense. i.e. One cannot use C code to set up any DAT vars prior to loading the COG as is done in may objects.

    With the simple minded way I have done this so far it means an object can only have one PASM part that can be extracted nicely with BSTC.

    Do you have a simple example of a PropBASIC object I could look at?
  • TonyWaiteTonyWaite Posts: 219
    edited 2010-09-01 03:31
    Hint for people wanting to take part in the vote:

    The voting buttons only appear if you are 'logged in'!

    Regards,

    T o n y
  • Invent-O-DocInvent-O-Doc Posts: 768
    edited 2010-09-01 07:44
    We need to get things so that we can use ANY SPIN/PASM object in the OBEX with ANY language. The need for duplicative libraries impairs development on this platform.
  • Heater.Heater. Posts: 21,230
    edited 2010-09-01 08:49
    Invent-O-Doc:
    We need to get things so that we can use ANY SPIN/PASM object in the OBEX with ANY language.

    Yep, for this reason Bill Henning and now myself always bring up the idea of "mailbox" based interfaces to PASM objects rather than relying on Spin interface methods.

    Have a look at Bill's VMCog for a good example.
  • ColeyColey Posts: 1,108
    edited 2010-09-01 10:59
    Heater. wrote: »
    Invent-O-Doc:



    Yep, for this reason Bill Henning and now myself always bring up the idea of "mailbox" based interfaces to PASM objects rather than relying on Spin interface methods.

    Have a look at Bill's VMCog for a good example.


    Heater, can you elaborate a little on how this would work please....

    Regards,

    Coley
  • Mike_GTNMike_GTN Posts: 106
    edited 2010-09-01 14:32
    Hi Coley,

    Was somewhat aware of the very hard work that Bean has put in on Propbasic. I thought had all matured when Parallax never jumped on this majorly as the next biggest resource for the new comer to the Propeller chip from the Basic Stamp or other competions compilers. I would certainly love to see more libraries to become available for this very important resource. On my holidays next week will make some free time to write some Propbasic code from the documents that exist now.

    Regards

    Mike.
  • ColeyColey Posts: 1,108
    edited 2010-09-01 14:53
    Hey Mike,

    Am real glad to see you are still around and Propping in every now and then :lol:

    Bean has done a great job so far on PropBASIC, it really is a great tool and when used with BST it's even better.

    We will be having a Prop Expo over here next year, hope you'll be able to make it.

    Regards,

    Coley
  • Invent-O-DocInvent-O-Doc Posts: 768
    edited 2010-09-01 16:09
    Would it be feasible to add functionality or commands so Propbasic could call SPIN methods and use SPIN/PASM objects??? I wonder what Bean thinks.
  • Capt. QuirkCapt. Quirk Posts: 872
    edited 2010-09-01 16:49
    Despite my experience with SXB, I am not planning on using Prop Basic until it works in windows7 as a fully functional IDE.
  • Kevin WoodKevin Wood Posts: 1,266
    edited 2010-09-01 18:21
    Capt. Quirk, just to let you know, PropBasic works with Brad's Spin Tool under Windows 7 x64.
  • Capt. QuirkCapt. Quirk Posts: 872
    edited 2010-09-01 19:39
    Kevin Wood wrote: »
    Capt. Quirk, just to let you know, PropBasic works with Brad's Spin Tool under Windows 7 x64.

    I have the same version of win7. I strongly supported Bean's first proposal for a Basic Stamp style language for the Propeller. I have read everything available printed by Brad & Bean, and tried all the preferences, and I still can't get color syntax to work for Prop Basic. It works fine for Spin though. I believe Brad has a couple versions of a syntax highlighter in the works, but until I can get a color syntax function to work for Prop Basic, it just looks like a bunch of noise on a piece of paper to me. (may sound strange, but that is an accurate description)

    I have set up a my Notepad++ to recognize Prop Basic and it's syntax, but then I need the use the command line or copy it into BST to debug it, and I don't want to.

    Sorry
  • Heater.Heater. Posts: 21,230
    edited 2010-09-01 23:23
    Coley, Re: mailbox interface to PASM objects.

    The issue here is how to provide a collection of devices, UARTS, I2C, video etc that are implemented in PASM running in COGS and can be used from ANY language or operating system on the Prop.

    Let's consider the humble UART:

    In a traditional micro-controller UARTs are provided in hardware. They have no language or operating system or other software dependencies. They can be used from any language, assembler, C, ADA, Pascal etc and any OS. The interface to the UARTs is simply through special function registers that exist in the controllers memory map or are accessed through input/output instructions. As long as your language has the capability to read/write to any specified location then it can make use of the UART. You can write a software driver for the UART.

    The "mailbox" approach to devices on the Prop is simply proposing to mimic that style of traditional hardware device interface.

    How would that look?

    1) We have no hardware UARTs on the Prop so we create them in PASM to run on COGs.

    2) Whatever language we use now has to at least be able to get the PASM UART driver started so it must:
    a) Be able to include or load the compiled driver PASM as a binary blob into HUB memory.
    b) Be able to start that UART blob in a COG with COGINIT/NEW
    c) Probably be able to set up an array of parameters for the UART, passed through PAR, that configure pins, baudrate,etc etc.

    3) When the UART driver is running all interaction with it should go through memory. There is no "linkage" of interface functions or variables within the UART device. This is the "mailbox" simply an area of memory known to both the application and the UART that is used to exchange commands, status and data.

    How does the PASM UART know where that "mailbox" memory is?

    The actual memory is "owned" by the application. Perhaps just an array of LONGs declared in Spin, or similar array of ints declared in C or whatever in BASIC. The address of that mailbox area is passed to the UART in the parameter list given to COGINT via PAR.

    As you see this mailbox approach can be applied to many devices besides UARTS.

    This approach does imply some restrictions on how the devices is written. For example FullDuplexSerial "pokes" some setup data into the PASMs DAT space prior to starting the COG. It can do this because the FDX Spin code has "linkage" to the PASM DAT space. It knows the name of those DAT items and can just write to them. This is not allowed if you want to use the compiled FDX PASM as an anonymous binary black box from C or BASIC.

    If you look in the ZOg project I have started on a little library of such objects. So far only FDX and VMCog. The approach is:

    1) If needed modify the object so that no Spin code is modifying the DAT section before load time. All parameters must go through PAR.
    2) Compile the object with BSTC with the option that emits the compiled PASM as a binary blob and throws away all the Spin.
    3) Write a C wrapper for the resulting binary blob that basically replaces the original Spin of FDX.

    Now I can link all that into my C programs and use FDX. My C code has no idea what is inside that FDX binary blob.

    That FDX binary blob is now usable form any language not just C under ZOG.
  • BradCBradC Posts: 2,601
    edited 2010-09-02 01:34
    I have the same version of win7. I strongly supported Bean's first proposal for a Basic Stamp style language for the Propeller. I have read everything available printed by Brad & Bean, and tried all the preferences, and I still can't get color syntax to work for Prop Basic. It works fine for Spin though. I believe Brad has a couple versions of a syntax highlighter in the works, but until I can get a color syntax function to work for Prop Basic, it just looks like a bunch of noise on a piece of paper to me. (may sound strange, but that is an accurate description)

    We all have priorities I'm afraid.
  • ColeyColey Posts: 1,108
    edited 2010-09-02 01:42
    Hey Brad, just do it when you can, the main point is it compiles! :smilewinkgrin:

    Excellent work BTW, since moving over to a Linux box I only use BST now, how did I manage without it before.......

    Regards,

    Coley
  • ColeyColey Posts: 1,108
    edited 2010-09-02 02:34
    @Heater,

    Thanks for the explanation, I understand what you mean now.

    I gues then we have a common goal here maybe the best thing to do is work with the TV driver Baggers has already adapted.

    I'll have a chat with him and see what the best way of doing this is.

    Regards,

    Coley
  • Heater.Heater. Posts: 21,230
    edited 2010-09-02 04:02
    Coley,

    I've never really looked into video drivers but I for sure would like to have a mailbox driven VT100 terminal available. 80 columns wide. VGA.

    So what is required there is to have a basic text video driver in COG.
    All of it's configuration, pins, clock frequency etc would have to come in through a PAR block.
    Presumably one gets text displayed by such a driver by "poking" chars into it's HUB video buffer. The address of that buffer would also go in via the PAR block.

    From there on all management of character output would be performed in C code, in my case, that is: wrapping at the end of lines, scrolling, VT100 escape sequences etc etc.
  • BradCBradC Posts: 2,601
    edited 2010-09-02 06:46
    Coley wrote: »
    Hey Brad, just do it when you can, the main point is it compiles!

    Yeah, sorry for getting grumpy. I just get a bit funny when people say they can't program without syntax highlighting or block indent indicators or BASIC.

    Programmers Program. The language and editor are irrelevant. It's just another tool in the box. There are an awful lot of people putting in No. 3 torx fasteners with 5 pound hammers.

    I guess the days of actually being a programmer are gone. <sigh>

    I'm going back in the box now.. I obviously need more time away..

    I'll be in the UK between the 17th of Sept and the 11th of Oct, and pretty much away from a network connection..
  • Capt. QuirkCapt. Quirk Posts: 872
    edited 2010-09-02 10:00
    I am not a programmer, I am a profesional mechanic, a hobbiest that enjoys programming in SXB. I am also the type of person that needs to highlight everything I read in text books and my notes. Otherwise text books are like watching a TV that has a lot of static in the picture.

    Now that I am back in school, I have found the teachers and students in math, science, and computers are just as disfunctional as I am. From ADD, SLD's to high functioning Autism, we all seem to find our niche with technology.

    Undoubtably, many others here are obviously more fortunate.

    Bill Mazzacane
  • Bill HenningBill Henning Posts: 6,445
    edited 2010-09-02 10:05
    Heater did a great job explaining it, however I thought I'd pipe in on mailboxes...

    Mailboxes as I use them have the following general structure:

    long mailbox[4]

    Why?

    1) That's how I designed them for Largos (which may someday be finished), because

    2) It's nice to have a known, fixed size, and even more important...

    3) Prop2 will be able to read/write four longs from the hub in one rdqlong/wrqlong (which I did not know when I initially settled on four longs)

    The "formal" Largos mailbox format is:

    mailbox[0] := command
    mailbox[1] := pointer1
    mailbox[2] := pointer2
    mailbox[3] := data/return value

    Due to efficiency/speed concerns, the only part that is absolutely hard wired and required is that the lowest nine bits of the first long be the command, as this way a 23 bit address (or other argument) can be passed to the command in the first long. Cogs must clear the command long after they are finished processing the command.

    If a cog needs more initialization data, use mailbox[1]/mailbox[2] to point at lists of pointers, or values, or whatever you need.

    My standard is that if the command fails, an error code should be placed on mailbox[3] -1 is the generic error code.

    For an example of how I use mailboxes, as heater suggests, take a look at my VMCOG code - which also shows how to reclaim the cog space used for initialization code for in-cog variables.

    p.s.

    My mailboxes are VERY similar to the one and two long randevouz locations used by Cluso99, David Hein etc - I use four longs because for a large majority of commands it is sufficient, and thus there is no need to de-reference a pointer embedded in a randevouz location.
    Coley wrote: »
    Heater, can you elaborate a little on how this would work please....

    Regards,

    Coley
  • Christof Eb.Christof Eb. Posts: 1,088
    edited 2010-09-09 00:35
    Hi alltogether,
    it is very nice, that there is more focus on PropBasic here! A SD-Card library would be very good!
    I understand, that it is good to have a language independant interface to the drivers.
    On the other side, PropBasic is so fast, that it is possible to write most drivers directly in PropBasic. As a matter of fact, this possibility seems to be the main strength of PropBasic: No need for PASM. Example drivers written in PropBasic would show this power and encourage others to PropBasic.
    Christof
  • kevin@cachia.comkevin@cachia.com Posts: 23
    edited 2011-02-02 14:21
    This sounds so awesome. I was thinking of how many of the OBEX objects I've found have parts I can use. But some of the code is over my head on the assembly parts. So I've just been writing what I needed from scratch, even if it's probably poorly implemented from a uC coding standard. I would love to see some more libraries or at least demos to use and understand the syntax better.

    I hope you guys decide to move forward and have a lot of success. I just jumped into microcontroller stuff a couple months ago, and really like PropBasic so much. It's so simple and fast, although it does have some limits for parsing. But nothing an extra line of code doesn't fix, and SPIN just wasn't cutting it for my on performance. I would love to see PropBasic develop and grow a lot more, it has so much potential.

    -Kevin
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2011-02-02 15:36
    One could always use more libraries!

    In fact, dare I say it, but iit is the lack of libraries that is hindering progress in Basic, Zog, C and probably other languages as well. Most code on the obex is only written in Spin.

    But translating libraries is hard. I've pondered sometimes whether it might be easier to write a "Spin to C" and a "Spin to Basic" translator, just to automate the process of creating libraries.

    One of the problems is that there is no standard. There are some great ideas on the previous page of this thread and maybe we could look at them some more?

    Mostly, the pasm part is going to translate as it is. But the spin part will be different for each object. For example:

    Object 1 receives one long and returns one long and uses no hub memory.
    Object2 receives 10 longs with data in them but uses its own cog memory. This implies the hub memory can be recycled.
    Object3 receives 10 longs with data in them and reuses this hub memory.
    Object4 receives one longs, returns no longs, but uses 20k of hub memory (ie a video driver).
    Object5 I haven't thought of yet but there will be at least one that does not fit into the above category.

    So whatever standard you adopt ought to be able to handle all of these. So if you have a mailbox system, you might need to also say how much hub ram you want reserved, and maybe a flag to say that this ram can be recycled (recycling is used for instance with high resolution vga drivers running in multiple cogs in parallel). As well as mailbox locations for data in and data out.

    Probably the mailbox format is more to do with commenting than with actual code, as all the cog knows is that it got passed one value with 'par' and then it reads one long from that location. Or an array of n bytes. Or an array with the addresses of other data.

    So from the driver code side, one needs to be really explicit about exactly which format one is using with lots of comments. I say this because I have spent some time in various object code and it is sometimes not easy to work out what is going on.

    And then there is the next problem - decoding spin. I find this hard because in order to translate an object to Basic and C, you need to be proficient in Spin, Basic and C.

    I have resorted at times to having to take a single line of spin code and put it inside a test program and throw all sorts of data at it to test out what it does. I'll give a little example which has had me stumped for days trying to translate to Basic and C:
      vcfg_ := $300000FF + (base_pin & %111000) << 6
    

    Firstly, this comes with no comments. But the bit that gets me is the order of precedence. (This is something that is being discussed on Bean's interpreter thread and it is a fascinating topic).

    Most people know BODMAS, and you can use that to decode some of the above line. But BODMAS does not contain "&" or "|" or >> or << or most of the other spin operators. Is it simply "left to right"? Is it "left to right and do the inside of brackets first". Is it "left to right and do brackets first and apply BODMAS if you find +-*/" Or, to put it another way, in the above example, if << were a multiply, you would do that first, even though it is at the end. Answer is yes, because it is BODMAS. But a bit shift to the left is a multiply. So this impies << is higher precedence than +. Which is the opposite to 'left to right' precedence.

    And when you think you understand that, along comes this line
      j := base_pin & %100000 == 0
    

    is == higher or lower precedence than &
    if == were multiply instead, would you do the multiply first?

    Answer is to memorise this simple table on page 251 of the manual *grin*
    Highest (0) Unary --, ++, ~, ~~, ?, @, @@ Inc/Decrement, Clear, Set, Random, Symbol/Object Address
    1 Unary +, -, ^^, ||, |<, >|, ! Positive, Negate, Square Root, Absolute, Decode, Encode, Bitwise NOT
    2 ->, <-, >>, <<, ~>, >< Rotate Right/Left, Shift Right/Left, Shift Arithmetic Right, Reverse
    3 & Bitwise AND
    4 |, ^ Bitwise OR, Bitwise XOR
    5 *, **, /, // Multiply-Low, Multiply-High, Divide, Modulus
    6 +, - Add, Subtract
    7 #>, <# Limit Minimum/Maximum
    8 <, >, <>, ==, =<, => Boolean: Less/Greater Than, Not Equal, Equal, Equal or Less/Greater
    9 Unary NOT Boolean NOT
    10 AND Boolean AND
    11 OR Boolean OR
    Lowest (12) =, : =, all other assignments Constant/Variable Assignment, assignment forms of Binary Operators
    

    And these are just simple examples, some code has multiple operators with multiple nested brackets.

    So one step in translating libraries is to unroll nested bracket code into individual instructions where you only have one instruction per line. That may also be necessary translating to other languages as not every maths operator might exist in other languages, so some operators might have to be translated to function calls.

    Writing libraries is a daunting task!

    And then there is new code being posted to the obex all the time, so how do you keep up?

    So I am wondering if it might be possible to automate some of the process? Maybe a Spin to Basic translator and an Spin to C translator.

    Even that is not so simple as there are many dialects of Basic and which one do you pick? (C is a bit easier as there is the C89 standard).

    Thoughts would be most appreciated.
  • $WMc%$WMc% Posts: 1,884
    edited 2011-02-02 19:00
    @ Coley
    '
    Man I can't believe I missed the start of this post back in Sept.
    '
    I would love to see more lib. files for PropBasic.
    '
    I use PropBasic for just about all of my propeller projects.I really like the shorter code and its speed over SPIN.
    '
    While Parallax doesn't seem to show much interest in PropBasic,(very disappointed) They did at least give us a PropBasic "ICON" to add pbas.lib code to in the OBEX.
    So I think PropBasic is starting to get some attention at Parallax.
    '
    @Dr_Acula
    '
    A PASM to PropBasic compiler would great.Double revers engineering/programing?
Sign In or Register to comment.