Thanks, it'll save having to set up all pointers to buffers at the start of the PropBASIC program, it's not a problem, just that it'd make the top file tidier, and more inviting to newbies
Also, is there any reason doing a FILE command puts the actual filename in before the binary also? ( or in the list file at least ) not checked the actual eeprom file for it.
1. Where can I find a Beginner's Guide?
2. Can PropBasic start an assembly object in another cog?
3. Can PropBasic start a Spin object in another cog?
4. Does PropBasic execute faster than spin?
5. Can Spin start a PropBasic object in another cog?
6. Why can't we use the Propeller Tool IDE for PropBasic instead of BST?
1. First post in this thread there are 2 pdfs. The "PropBASIC Syntax Guide" might be the most useful according to your question
2. Yes. PropBasic is compiled into PASM, so you can insert PASM snippets into your PropBasic code, like with SX/B
3. Not certain, but there was (as I recall) some talk of that earlier in this very long thread. The first few pages I believe.
4. Yes. PropBasic is compiled to PASM before being downloaded to the device, so there is no delay that would usually occur with the SPIN interpreter. You are basically comparing PASM to SPIN. ALSO, in the compiler stage, the PASM code is available for you to fine-tune - with all the original PropBasic code next to it in comments to help you find stuff. Again, much like the SX/B compiler =- and very cool!
5. I believe that PropBasic does upload with a small SPIN header, which acts as the loader/starter for the compiled program. So it is being done under the surface already- so I suspect you could do the same.
speculation: I would have thought it likely that if SPIN could start PASM in another cog, then it could start some PropBasic code which has been compiled into PASM! So can SPIN do it ?
6. PropBASIC is a relative newcomer to the Propeller stable. The Parallax tool was long released before, and I suspect it would take some significant resources and open some cans of worms if Parallax were to add another language (or two, or more...). It might also be a waste of resources as the BST tool exists and works perfectly. In fact, BST will compile SPIN, PASM and PropBASIC, on Windows,MAC and LINUX, so maybe the question should be reversed "Why should we use the Propeller Tool IDE for PropBasic instead of BST?"
On page 25 of this fine long thread, JonnyMac kindly posted a couple of libs (delays.lib & serial.lib).
If you download and try to use these in BST a strange failure occurs: "Unable to locate top file delays.lib" (that's if you compile the actual lib).. If you compile your main .pbas file you get "ERROR, UNKNOWN COMMAND"
The problem appears to be a NUL (0x00) at the end of the .lib files, perhaps due to the recent forum conversion. Once I removed that the files work fine!
Thought I should mention - could be a cause of frustration elsewhere !
I downloaded the latest code - propBASIC is really evolving into something very clever. Some random thoughts in no particular order;
1) STR is a blank page in the instruction manual. I am not sure if it has been written yet, nor whether other string functions exist like MID and RIGHT. If not, I was thinking of a generic way of writing functions. For example, if I write newstring=LEFT(oldstring,4) then LEFT might be an internal function to BASIC, but it might also be a library routine, or a subroutine that you cut and paste at the bottom of the program. How does the syntax work with functions and subroutines - eg is it possible to put the variables in brackets and pass them to the function (in this case it would be a function as it returns one variable). Looking at the syntax guide, I think one would write newstring=LEFT oldstring,4 so I think the syntax is slightly different, ie no brackets.
2) Strings are complicated so I appreciate that any code for strings might be hard to write. I have been thinking about how SBASIC and C use strings, and I think the simplest way to consider them is to use the C method of considering them to be null terminated arrays. Any string passed to and from an internal function (like STR) would be passed by location. Strings passed through functions you might write would need to be defined globally. SBASIC has a simple way of doing this
var mystring=string
and you can have variants on that, eg
dim mystring=string
dim mystring as string
and
var mystring=string:40
This latter example allows one to either use the default length of 80, or if memory is tight and the string will always be short, define something shorter.
Thoughts regarding strings would be most appreciated.
3) Adding in code from the OBEX. From time to time I look at my propeller with its 512k memory chip and ponder about BIG SPIN. And now, BIG BASIC. Using MP/M gives me 8 BASIC programs running in parallel with 48k of memory for each program, and maybe there is a way of replicating something similar in PropBASIC? ie, allocate external ram to each instance of BASIC and cycle between them so they appear to be running in parallel? So the idea is to replicate something that is already working but without the underlying operating system of MP/M.
Big Spin seems a daunting prospect, mainly (from my point of view) because it is not possible to view the entire source code of the interpreter. LMM can be used to gain more pasm code space, so if LMM can be used, maybe there is a solution where PropBASIC can be compiled to LMM code when external memory is available?
I've also pondered a Spin to Basic converter - such a program could open up the entire Obex to prop basic and I think there might be enough PropBasic commands to do this. Such a program could be run in any language you like.
For me, the idea is to work towards an 'ideal' language, which could be Basic or Spin or C or all three (Catalina probably is the most advanced in this respect) that can do the following;
a) the ability to work within the constraints of the propeller memory, or use external memory, and for this to be fairly transparent to the user (eg "Dim MyArray(40000) As Integer" produces an error when no external memory is available, but compiles when it is available).
b) The ability to use all obex code - either as-is, or translated to a different language.
c) Inline assembly
d) Inline LMM assembly - so you can write a 50k pasm program without having to think too much about the complexities of LMM
e) The ability to write a 1000 line program without worrying about running out of memory
f) A way to exploit the parallel nature of the propeller so it is possible to run multiple big, high level programs at the same time. With behind the scenes handling of memory and two programs accessing an SD card at the same time etc.
I'm trying to get started with 'bst' on the iMac. But cannot find the program called PropBASICIDE. It doesn't appear to be any of the downloaded files!
I'm trying to get started with 'bst' on the iMac. But cannot find the program called PropBASICIDE. It doesn't appear to be any of the downloaded files!
I'm trying to get started with 'bst' on the iMac. But cannot find the program called PropBASICIDE. It doesn't appear to be any of the downloaded files!
I did get something to come up, but seems something is missing, Here;s a portion of the screen. (Using Grab, I couldn't get the 'bst' app to remain on top.) Does this look right for OS X.
I'm trying to get started with 'bst' on the iMac. But cannot find the program called PropBASICIDE. It doesn't appear to be any of the downloaded files!
Apologies for those duplicate posts. Sometimes this new forum app leaves one LOST and it seems not until later does the duplicates appear. I don't know why the app allows such to happen.
1) You download BST from the website given as a link in the BST threat. You can also check the link on the Propeller Downloads page.
2) Double click the ZIP package downloaded to unpack it
3) Drag the resulting executable to your Applications folder.
4) Double click it to execute
5) In the Preferences, you can configure where BST searches for library files.
6) There's a dialog you get when you try to download or open a serial terminal window that allows you to select a serial port from a list of those available. On the Mac, they're all USB serial adapters.
Well, Mike, I can get through to step 4. I could not find any Library files, so did not know what to do for this step.
Step 6 is strange. It doesn't know of any ports. If I select Terminal, it cannot find any port to use. No ports are listed where I should choose a port to Test. Just get No Propeller Found type message.
The attachment shows what is displayed; is this right for OSX? Something seems missing. I used Grab for this pic, otherwise it would also be showing the bst menu bar. Might I have to shut down and turn on again?
1) You download BST from the website given as a link in the BST threat. You can also check the link on the Propeller Downloads page.
2) Double click the ZIP package downloaded to unpack it
3) Drag the resulting executable to your Applications folder.
4) Double click it to execute
5) In the Preferences, you can configure where BST searches for library files.
6) There's a dialog you get when you try to download or open a serial terminal window that allows you to select a serial port from a list of those available. On the Mac, they're all USB serial adapters.
Well, Mike, I can get through to step 4. I could not find any Library files, so did not know what to do for this step.
Step 6 is strange. It doesn't know of any ports. If I select Terminal, it cannot find any port to use. No ports are listed where I should choose a port to Test. Just get No Propeller Found type message.
The attachment shows what is displayed; is this right for OSX? Something seems missing. I used Grab for this pic, otherwise it would also be showing the bst menu bar. Might I have to shut down and turn on again?
Harley
'
Hang in there, If it was easy, We wouldn't have the forums!:idea:
I am working on a driver for the ENC28J60. I wondering what would be the best way to go about writing a library. When I was working in SPIN and wanted to call an ASM function I made I followed several examples of an ASM loop that checks for a flag that my SPIN code would set and then execute. Would I follow a similar procedure? Have a bunch of subroutines that tell the cog that runs the driver what to do. Harrison Pham wrote an excellent driver and maybe I can reuse some of his ASM code.
If the driver executes in a seperate cog, then yes follow the same type of handshake.
If the driver executes in the same cog (native or LMM) then there is no need for handshake, just use variables (VAR).
Reading RC receiver signals Serial Terminal issue.
I have been pulling my hair out on this little problem. I managed to put this little code together from other examples. It works but, I can't figure out how to keep the data in the serial terminal from moving across the ST screen? I have tried different combinations of the CR CLREOL CLS ect... no luck. Not sure if this is a BST or PropBasic issue but thought I would start here.
' File: RC_Reciver.pbas
' Purpose: Read PWM signal from an RC receiver.
' I am using a PEKit with the output from the reciver connected to PIN 15.
' Power for receiver is of the 5v reg on PEKit.
' I also have a 1k resistor between the RX signal and PIN15
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
Baud CON "T115200" 'baud rate to communicate with PC
' Parallax Serial Terminal (PST) Constants
HOME CON 1 'Debug instructions to numbers?
BKSP CON 8
TAB CON 9
LF CON 10
CLREOL CON 11
CLRDN CON 12
CR CON 13
CLS CON 16
Pulse PIN 15 INPUT 'pin 15 connected to RC Receiver
TX PIN 30 HIGH 'send data back to PC
value VAR LONG
Message DATA " ms"
valueStr DATA "1234", CR, 0
PROGRAM START
Start:
PAUSE 3000 'wait for reciver to bind
Main:
DO
PAUSE 10
PULSIN Pulse, 1, value 'measure pulse
valueStr = STR value, 5, 5 'convert value to ASCII
SEROUT TX, Baud, Message
Loop
END
If the driver executes in a seperate cog, then yes follow the same type of handshake.
If the driver executes in the same cog (native or LMM) then there is no need for handshake, just use variables (VAR).
Bean
Thank you. It will be running in a seperate cog. I am quite impressed by how straight forward it has been to port my project. Great work.
Just curious, will PropBASIC be supporting the C3, and/or GG 32MB memory module? I think I saw some mention of XMM for PropBASIC, but I have not seen anything further on that.
Ray,
PropBasic fully supports LMM (running code from the HUB) allowing 32K of code space.
No support for XMM (running code from external memory) is planned.
As far as the C3 or the GG, I'm sure someone will come up with a library to support them.
One thing I quickly learned is that __paramx is not a good place to hold value. I often call subroutines from subroutines and that will sometimes overwrite values stored there. So as soon as I call a subroutine or function with parameters I immediately set it to a variable. I make each variable unique so to prevent overwriting but it means alot variables. I have plenty of space now to do this but it is ugly and it is easy to make mistakes.
Might there be a better way to do this? Any help would be greatly appreciated.
Comments
Thanks, it'll save having to set up all pointers to buffers at the start of the PropBASIC program, it's not a problem, just that it'd make the top file tidier, and more inviting to newbies
Also, is there any reason doing a FILE command puts the actual filename in before the binary also? ( or in the list file at least ) not checked the actual eeprom file for it.
Cheers,
Baggers.
I would like to learn more about PropBasic.
My questions.
1. Where can I find a Beginner's Guide?
2. Can PropBasic start an assembly object in another cog?
3. Can PropBasic start a Spin object in another cog?
4. Does PropBasic execute faster than spin?
5. Can Spin start a PropBasic object in another cog?
6. Why can't we use the Propeller Tool IDE for PropBasic instead of BST?
2. Yes. PropBasic is compiled into PASM, so you can insert PASM snippets into your PropBasic code, like with SX/B
3. Not certain, but there was (as I recall) some talk of that earlier in this very long thread. The first few pages I believe.
4. Yes. PropBasic is compiled to PASM before being downloaded to the device, so there is no delay that would usually occur with the SPIN interpreter. You are basically comparing PASM to SPIN. ALSO, in the compiler stage, the PASM code is available for you to fine-tune - with all the original PropBasic code next to it in comments to help you find stuff. Again, much like the SX/B compiler =- and very cool!
5. I believe that PropBasic does upload with a small SPIN header, which acts as the loader/starter for the compiled program. So it is being done under the surface already- so I suspect you could do the same.
speculation: I would have thought it likely that if SPIN could start PASM in another cog, then it could start some PropBasic code which has been compiled into PASM! So can SPIN do it ?
6. PropBASIC is a relative newcomer to the Propeller stable. The Parallax tool was long released before, and I suspect it would take some significant resources and open some cans of worms if Parallax were to add another language (or two, or more...). It might also be a waste of resources as the BST tool exists and works perfectly. In fact, BST will compile SPIN, PASM and PropBASIC, on Windows,MAC and LINUX, so maybe the question should be reversed "Why should we use the Propeller Tool IDE for PropBasic instead of BST?"
Hope some of this helps.
If you download and try to use these in BST a strange failure occurs: "Unable to locate top file delays.lib" (that's if you compile the actual lib).. If you compile your main .pbas file you get "ERROR, UNKNOWN COMMAND"
The problem appears to be a NUL (0x00) at the end of the .lib files, perhaps due to the recent forum conversion. Once I removed that the files work fine!
Thought I should mention - could be a cause of frustration elsewhere !
1) STR is a blank page in the instruction manual. I am not sure if it has been written yet, nor whether other string functions exist like MID and RIGHT. If not, I was thinking of a generic way of writing functions. For example, if I write newstring=LEFT(oldstring,4) then LEFT might be an internal function to BASIC, but it might also be a library routine, or a subroutine that you cut and paste at the bottom of the program. How does the syntax work with functions and subroutines - eg is it possible to put the variables in brackets and pass them to the function (in this case it would be a function as it returns one variable). Looking at the syntax guide, I think one would write newstring=LEFT oldstring,4 so I think the syntax is slightly different, ie no brackets.
2) Strings are complicated so I appreciate that any code for strings might be hard to write. I have been thinking about how SBASIC and C use strings, and I think the simplest way to consider them is to use the C method of considering them to be null terminated arrays. Any string passed to and from an internal function (like STR) would be passed by location. Strings passed through functions you might write would need to be defined globally. SBASIC has a simple way of doing this
var mystring=string
and you can have variants on that, eg
dim mystring=string
dim mystring as string
and
var mystring=string:40
This latter example allows one to either use the default length of 80, or if memory is tight and the string will always be short, define something shorter.
Thoughts regarding strings would be most appreciated.
3) Adding in code from the OBEX. From time to time I look at my propeller with its 512k memory chip and ponder about BIG SPIN. And now, BIG BASIC. Using MP/M gives me 8 BASIC programs running in parallel with 48k of memory for each program, and maybe there is a way of replicating something similar in PropBASIC? ie, allocate external ram to each instance of BASIC and cycle between them so they appear to be running in parallel? So the idea is to replicate something that is already working but without the underlying operating system of MP/M.
Big Spin seems a daunting prospect, mainly (from my point of view) because it is not possible to view the entire source code of the interpreter. LMM can be used to gain more pasm code space, so if LMM can be used, maybe there is a solution where PropBASIC can be compiled to LMM code when external memory is available?
I've also pondered a Spin to Basic converter - such a program could open up the entire Obex to prop basic and I think there might be enough PropBasic commands to do this. Such a program could be run in any language you like.
For me, the idea is to work towards an 'ideal' language, which could be Basic or Spin or C or all three (Catalina probably is the most advanced in this respect) that can do the following;
a) the ability to work within the constraints of the propeller memory, or use external memory, and for this to be fairly transparent to the user (eg "Dim MyArray(40000) As Integer" produces an error when no external memory is available, but compiles when it is available).
b) The ability to use all obex code - either as-is, or translated to a different language.
c) Inline assembly
d) Inline LMM assembly - so you can write a 50k pasm program without having to think too much about the complexities of LMM
e) The ability to write a 1000 line program without worrying about running out of memory
f) A way to exploit the parallel nature of the propeller so it is possible to run multiple big, high level programs at the same time. With behind the scenes handling of memory and two programs accessing an SD card at the same time etc.
Thoughts and feedback would be most appreciated.
Que? Why not?
The STR command is documented on page 33 of "propbasic.pdf" available on the first post in this thread.
Bean
I answered it in Yours other thread.
PropellerBasic ---> USE BST as IDE.
I did get something to come up, but seems something is missing, Here;s a portion of the screen. (Using Grab, I couldn't get the 'bst' app to remain on top.) Does this look right for OS X.
Like what is the basic setup to get going in bst with an OS X machine? Does the terminal use the USB cable?
2) Double click the ZIP package downloaded to unpack it
3) Drag the resulting executable to your Applications folder.
4) Double click it to execute
5) In the Preferences, you can configure where BST searches for library files.
6) There's a dialog you get when you try to download or open a serial terminal window that allows you to select a serial port from a list of those available. On the Mac, they're all USB serial adapters.
Step 6 is strange. It doesn't know of any ports. If I select Terminal, it cannot find any port to use. No ports are listed where I should choose a port to Test. Just get No Propeller Found type message.
The attachment shows what is displayed; is this right for OSX? Something seems missing. I used Grab for this pic, otherwise it would also be showing the bst menu bar. Might I have to shut down and turn on again?
According to my interpretation of the PropBASIC_Manual.pdf (page 16), the above code should be valid. It will compile for HUB, but not for VAR (cog)
Harley
'
Hang in there, If it was easy, We wouldn't have the forums!:idea:
As with the previous feedback in this thread, not sure if this has already been thrashed out; but here goes anyhow...!
Let's say I have this declared in cog 1
... and this declared in cog 2 (in a lib or task I have loaded)
OK, I understand this might be intended 5% of the time, but should the compiler throw a warning just in case (when a PIN is declared twice) ?
Might be useful for 'some' users who enthusiastically import libs and don't check for conflicts carefully enough ..
If the driver executes in the same cog (native or LMM) then there is no need for handshake, just use variables (VAR).
Bean
Reading RC receiver signals Serial Terminal issue.
I have been pulling my hair out on this little problem. I managed to put this little code together from other examples. It works but, I can't figure out how to keep the data in the serial terminal from moving across the ST screen? I have tried different combinations of the CR CLREOL CLS ect... no luck. Not sure if this is a BST or PropBasic issue but thought I would start here.
' File: RC_Reciver.pbas ' Purpose: Read PWM signal from an RC receiver. ' I am using a PEKit with the output from the reciver connected to PIN 15. ' Power for receiver is of the 5v reg on PEKit. ' I also have a 1k resistor between the RX signal and PIN15 DEVICE P8X32A, XTAL1, PLL16X FREQ 80_000_000 Baud CON "T115200" 'baud rate to communicate with PC ' Parallax Serial Terminal (PST) Constants HOME CON 1 'Debug instructions to numbers? BKSP CON 8 TAB CON 9 LF CON 10 CLREOL CON 11 CLRDN CON 12 CR CON 13 CLS CON 16 Pulse PIN 15 INPUT 'pin 15 connected to RC Receiver TX PIN 30 HIGH 'send data back to PC value VAR LONG Message DATA " ms" valueStr DATA "1234", CR, 0 PROGRAM START Start: PAUSE 3000 'wait for reciver to bind Main: DO PAUSE 10 PULSIN Pulse, 1, value 'measure pulse valueStr = STR value, 5, 5 'convert value to ASCII SEROUT TX, Baud, Message Loop ENDI am using Ubuntu 10.04 LTS
Thanks
Ron
You are converting to a 5 digit string, but you only left 4 digits in the DATA for it. So the "CR" in the data is getting overwritten.
Bean
By the way thanks for PropBASIC I really appreciate it.
-Ron
Bean
Thank you. It will be running in a seperate cog. I am quite impressed by how straight forward it has been to port my project. Great work.
Ray
PropBasic fully supports LMM (running code from the HUB) allowing 32K of code space.
No support for XMM (running code from external memory) is planned.
As far as the C3 or the GG, I'm sure someone will come up with a library to support them.
Bean
A simple example:
x CON 5
y CON x + 2
z CON y + 2
In my SPIN program this was useful for picking out data from a TCP/IP packet.
PropBASIC returns an invalid parameter when I try to compile.
Edit: I just hard coded them as they shouldn't change from the documentation.
Might there be a better way to do this? Any help would be greatly appreciated.