Also, what is meant by dealing with binaries? You can download binary images through memory map in PropellerIDE (assuming that function works! haha).
Well, I guess what I was doing is what I thought would be the most intuitive, logical thing. Use Open on an exiting binary file, then either do a Run or Write, and have something happen. Sorry, I guess I missed an important fact in the PropellerIDE manual.
Incidentally, fastspin understands '@@@' (at least in some circumstances, e.g. when compiling to a binary) so it probably is usable as a backend for PropBASIC. The PropBASIC output is all PASM anyway, so in that case fastspin and openspin should produce the same results.
I downloaded the latest PropellerIDE, and I tried the memory map suggestion for dealing with binaries. When you have the PropellerIDE in a state with all the files closed, and you click on memory map icon or select it from the Menu, nothing happens.
It seems like the memory map thing was designed to work on an opened and saved .spin or .pbas file. I guess my question would be, if you went to the Tachyon site and downloaded an existing binary, how would you be able to run that with PropellerIDE?
I would still like to make a suggestion for having a preference mode for working with the in-built terminal window.
After looking at the PropellerIDE, latest version, I started to think about how PropC could be dealt with within PropellerIDE. I am thinking along the lines of once you New and Save a blinker.c file, and then hit Run or Write, the magic happens. But, if you need to add some existing C files to be compiled with your main program, not sure how that would be accomplished.
Line delays are used in Tachyon when loading new stuff.
The parser takes a little bit of time, so if you want to load a multiline program you add an end of line delay in the terminal.
It means the teminal sends a line, waits a little bit, sends the next line, waits a little bit, and so on.
Massimo
Also, what is meant by dealing with binaries? You can download binary images through memory map in PropellerIDE (assuming that function works! haha).
Well, I guess what I was doing is what I thought would be the most intuitive, logical thing. Use Open on an exiting binary file, then either do a Run or Write, and have something happen. Sorry, I guess I missed an important fact in the PropellerIDE manual.
Ray
Whenever I can finally introduce a generic View interface (hasn't happen yet), I've been considering the possibility of having memory map be just another file window with a binary extension, instead of a separate pop-up. I think that'd be a nice feature, and it would behave like that.
Incidentally, fastspin understands '@@@' (at least in some circumstances, e.g. when compiling to a binary) so it probably is usable as a backend for PropBASIC. The PropBASIC output is all PASM anyway, so in that case fastspin and openspin should produce the same results.
I downloaded the latest PropellerIDE, and I tried the memory map suggestion for dealing with binaries. When you have the PropellerIDE in a state with all the files closed, and you click on memory map icon or select it from the Menu, nothing happens.
It seems like the memory map thing was designed to work on an opened and saved .spin or .pbas file. I guess my question would be, if you went to the Tachyon site and downloaded an existing binary, how would you be able to run that with PropellerIDE?
I would still like to make a suggestion for having a preference mode for working with the in-built terminal window.
After looking at the PropellerIDE, latest version, I started to think about how PropC could be dealt with within PropellerIDE. I am thinking along the lines of once you New and Save a blinker.c file, and then hit Run or Write, the magic happens. But, if you need to add some existing C files to be compiled with your main program, not sure how that would be accomplished.
Ray
Not disabling memory map when all files are closed would be simple enough.
What sorts of preferences are you asking about? I suppose switching between DTR, RTS, and GPIO reset would be something for such a menu. And line delay. What else?
I've been contemplating how C could work in the context of PropellerIDE, and there seems to be two options.
1. Require libraries to have a .c and .h file of the same name; i.e. blahdriver.c and blahdriver.h. This would make C support project-less (just hit F10!) and much easier to implement. But would remove some freedom to do arbitrary file inclusion.
2. Implementing a whole project system that magically pops up for languages that want it, like C.
I'm more partial to #1. #2 is a giant junk of code that gives people the freedom to do more confusing things with their code. =P And #1 is much more near-term than #2. However, if people start doing #includes inside #ifdefs, it's going to get messy anyway.
I've been contemplating how C could work in the context of PropellerIDE, and there seems to be two options.
1. Require libraries to have a .c and .h file of the same name; i.e. blahdriver.c and blahdriver.h. This would make C support project-less (just hit F10!) and much easier to implement. But would remove some freedom to do arbitrary file inclusion.
2. Implementing a whole project system that magically pops up for languages that want it, like C.
I'm more partial to #1. #2 is a giant junk of code that gives people the freedom to do more confusing things with their code. =P And #1 is much more near-term than #2.
I'm not sure if you have this already, but a common way to manage all types of external languages/compilers, in Editor-IDEs is to allow a Batch Call Project.
This usually has some simple parameters like %FILENAME% %FILEPATH% etc that you can pass to an external command line, and auto-reopen of changed files then co-operates quite well with external builds.
Some editors capture the command output, and have a simple error parser expression that can extract the typical error tag of FileName (LineNo,ColumnNo) ErrMess with varying choices of /(, etc, or you can work with log-files.
I've been contemplating how C could work in the context of PropellerIDE, and there seems to be two options.
1. Require libraries to have a .c and .h file of the same name; i.e. blahdriver.c and blahdriver.h. This would make C support project-less (just hit F10!) and much easier to implement. But would remove some freedom to do arbitrary file inclusion.
2. Implementing a whole project system that magically pops up for languages that want it, like C.
I'm more partial to #1. #2 is a giant junk of code that gives people the freedom to do more confusing things with their code. =P And #1 is much more near-term than #2.
I'm not sure if you have this already, but a common way to manage all types of external languages/compilers, in Editor-IDEs is to allow a Batch Call Project.
This usually has some simple parameters like %FILENAME% %FILEPATH% etc that you can pass to an external command line, and auto-reopen of changed files then co-operates quite well with external builds.
Some editors capture the command output, and have a simple error parser expression that can extract the typical error tag of FileName (LineNo,ColumnNo) ErrMess with varying choices of /(, etc, or you can work with log-files.
PropellerIDE has a basic form of this, though it's not exposed to the user at present. Here are the compiler configs I currently have defined:
I had started out trying to implement the sort of %FILENAME% thing you mentioned, but ended up going with a simple extension change for now. The ExternalCompiler currently expects a single output from a single input, so that would take some rethinking. Basic success/error output parsing opens the file at the line where the error happened.
Perhaps there can be a means to add a custom compiler via the Preferences dialog at some point.
It's working well for me. I really wasn't aware of PropBASIC before this. Now, I'm running PropBASIC programs and wow they are fast. PropBAISC was just what I was looking for.
I'm working on code to provide I/O support to a 6502, and Spin was working but slow. I doubt I have the dedication to learn PASM just yet. PropBASIC fills the gap nicely and this IDE makes it easy. Thanks Brett, Bean, JohnnyMac and all the contributors. Amazing stuff.
I'll also note that there's a Spin to PASM translator spincvt that can do for Spin what PropBASIC does for BASIC, i.e. turn it into a fast PASM/LMM binary. There's a front end for this (fastspin) that has the same interface as openspin, so perhaps soon it will be supported in PropellerIDE as well.
I'll also note that there's a Spin to PASM translator spincvt that can do for Spin what PropBASIC does for BASIC, i.e. turn it into a fast PASM/LMM binary. There's a front end for this (fastspin) that has the same interface as openspin, so perhaps soon it will be supported in PropellerIDE as well.
I'll also note that there's a Spin to PASM translator spincvt that can do for Spin what PropBASIC does for BASIC, i.e. turn it into a fast PASM/LMM binary. There's a front end for this (fastspin) that has the same interface as openspin, so perhaps soon it will be supported in PropellerIDE as well.
Is it possible to generate COG code or only LMM?
It can generate both. In fact there are options for code in COG or HUB (the latter is LMM) and data in COG or HUB. The compiler hasn't really been tested with code in HUB and data in COG (that seems like an unlikely combination) so I don't know if that one works, but the other 3 combinations do work.
I tried it, I like it... So maybe a little more explination. Seems like calling spin objects kinda
takes away the speed advantage of pb... since the OBEX has been so helpful ,
Any chance of an object (sub) library for PropBasic? Just a few , maybe, ??
thank you for your support.
I tried it, I like it... So maybe a little more explination. Seems like calling spin objects kinda
takes away the speed advantage of pb... since the OBEX has been so helpful ,
Any chance of an object (sub) library for PropBasic? Just a few , maybe, ??
thank you for your support.
Bill
If you go to the OBEX and search for all, may take a minute, the objects with the green background with the star are some of the PropBasic libraries that Terry wrote.
Here is one of the RX/TX sample programs from the library:
DEVICE P8X32A, XTAL1, PLL16X
XIN 5_000_000
' ----------------------------------------------------------------------
' I/O Pins
' ----------------------------------------------------------------------
RX_PIN PIN 31 INPUT
TX_PIN PIN 30 INPUT
' ----------------------------------------------------------------------
' Constants
' ----------------------------------------------------------------------
Terminal_Baud CON 115200
' -- TX_Format Constants & Variables ---------------
HOME CON 1
GOTOXY CON 2
BKSP CON 8
TAB CON 9
LF CON 10
CLREOL CON 11
CLRDN CON 12
CR CON 13
GOTOX CON 14
GOTOY CON 15
CLS CON 16
' ----------------------------------------------------------------------
' Data
' ----------------------------------------------------------------------
' ----------------------------------------------------------------------
' Variables
' ----------------------------------------------------------------------
TX_BAUD VAR LONG
Temp VAR LONG
Temp2 VAR LONG
' ----------------------------------------------------------------------
' SUB & FUNC Definitions
' ----------------------------------------------------------------------
LOAD "D:\Propeller\Propeller Programs\Libraries\DELAYS_LIB.pbas" 'Adjust the path to point to the Library location
LOAD "D:\Propeller\Propeller Programs\Libraries\TX_RX_LIB.pbas" 'Adjust the path to point to the Library location
' ----------------------------------------------------------------------
' TASK Definitions
' ----------------------------------------------------------------------
' ======================================================================
PROGRAM START
' ======================================================================
START:
TX_BAUD = Terminal_Baud
PAUSE 5000
TX_BYTE CLS
Temp = 123_456_789
TX_STR "DEC "
TX_DEC Temp
TX_BYTE CR
TX_STR "DECX "
TX_DECX Temp, 12 ' Display 12 Digits padded with leading zeroes
TX_BYTE CR
TX_STR "DECX "
TX_DECX Temp, 3 ' Display 3 Digits. Leading digits are truncated
END
Here is the brief description of the extensions/modifications to the RX/TX library referenced above:
TX_RX Library
Because Jonny Mac’s 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.
I have also 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
Try out the library and see if it works for your needs and let us know how it goes...
Just a note for those of you using PropBasic on platforms not supported by bstc: fastspin (https://github.com/totalspectrum/spin2cpp/releases/) can be compiled on any Linux/Unix platform and the latest version (3.1.2) works as a replacement for bstc in PropellerIDE (just rename the fastspin binary to bstc and copy it in to the PropellerIDE installation directory, after backing up the original bstc of course).
fastspin differs from bstc and openspin because it turns Spin code into LMM binaries, which are larger and faster than normal Spin binaries. This won't make any difference for PropBasic, since the PropBasic compiler produces plain PASM code.
And of course fastspin is interesting in and of itself, so the rename fastspin to bstc trick can be useful on Windows too. Make a backup of bstc.exe, then copy fastspin.exe over top of bstc.exe and you'll be able to use PropellerIDE to compile your Spin code to PASM/LMM. For some programs the improvement is dramatic -- for example an SPI test benchmark is over 100x faster when compiled with fastspin than bstc or openspin. For most programs it'll be more like 4x - 10x faster. The cost is that fastspin code is much larger than regular Spin bytecode (probably 2x-4x larger, depending on the code).
I am experiencing a couple of problems with PropellerIDE while working in the Spin mode.
#1- When compiling the program the compile information window rolls by way to fast, so if you have an error, their is no way that you can view what the error is. Maybe PropellerIDE needs a separate stationary area, at the bottom of the main window, similar to the way SimpleIDE displays its compile status.
and I have Auto completion turned on, when I try to type in ser0.Start... it will not except the dot. If I have:
tlib : "tools.spin", then the dot works when you try something like tlib.high(12).
Probably the biggest concern at the moment is viewing the compile window information, I am now only guessing as to what the error could be, and this is just on a small program.
Had a play with PropellerIDE on OS X Yosemite. It's early days using it but I do quite like the look of it over the original bst. However I really needed the listing file generated as well - its a real show stopper for me without it and I use that a lot. So until the compiler options are properly exposed in the preferences dialog I came up with a simple intercept workaround which itself already seems to integrate rather nicely to the PropellerIDE build window output.
This is what I did...
1) In the PropellerIDE installation folder that contains the tools (mine was installed under /Applications/PropellerIDE.app/Contents/MacOS/), I just renamed bstc to bstc2
2) I then wrote and copied this simple bash script below as /Applications/PropellerIDE.app/Contents/MacOS/bstc, which generates the listing file in the same folder as the source fed into the compiler. To figure out the name of the listing file generated it assumes the source filename contained an extension removed by the compiler (i.e. source file name contained a period). You can also add other options in the EXTRAOPTS variable as required.
#!/bin/bash
# add the extra compiler options here
EXTRAOPTS=-l
# display the command being invoked
echo $0 $EXTRAOPTS $@
# detemine the name of the listing file
LISTFILE=`echo $1 | sed s/\.[a-zA-Z_0-9]*$/\.list/`
# delete the old listing file in case of error so we don't get stale output
rm -f $LISTFILE
# call the real compiler
$02 $EXTRAOPTS $@
# display the listing file only if it was produced otherwise exit with error
if [ -f $LISTFILE ] ; then cat $LISTFILE; else exit 1; fi
Now each time I do a build it will call the bash script and then output the listing file to the Build Manager output window where it can be viewed and easily scrolled around with cursor keys.
Enjoy.
ps. Also it would be rather nice to have the inbuilt terminal window support an optional mode where you can type in characters and not always need press the enter key or send button to transmit them to a Propeller in line oriented mode. I might like to look at the source code for that to see if there is a way to patch it, assuming I can manage to build it. I do have Xcode installed, not sure what other code or tools I may need to build the PropellerIDE tool from its source in GitHub, haven't really looked yet or started hacking around with it.
UPDATE: Through experiment I just found if you mouse click the PropellerIDE terminal window first, you can type characters directly in without using the line oriented mode - perfect!
UPDATE2: I also added the exit failure to the script when the listing file does not exist, this way the Build Manager build status better reflects success/failure of the build.
It seems the version of openspin that comes with propellerIDE is not the same as the 1 from GitHub, the -P preprocessor parameter has the opposite meaning see screen shot below, I discovered this when I was not able to compile code with propellerIDE that I know worked with openspin from GitHub https://github.com/parallaxinc/OpenSpin
Comments
Ray
It seems like the memory map thing was designed to work on an opened and saved .spin or .pbas file. I guess my question would be, if you went to the Tachyon site and downloaded an existing binary, how would you be able to run that with PropellerIDE?
I would still like to make a suggestion for having a preference mode for working with the in-built terminal window.
After looking at the PropellerIDE, latest version, I started to think about how PropC could be dealt with within PropellerIDE. I am thinking along the lines of once you New and Save a blinker.c file, and then hit Run or Write, the magic happens. But, if you need to add some existing C files to be compiled with your main program, not sure how that would be accomplished.
Ray
Ah, I see, that sounds simple enough. =P
Whenever I can finally introduce a generic View interface (hasn't happen yet), I've been considering the possibility of having memory map be just another file window with a binary extension, instead of a separate pop-up. I think that'd be a nice feature, and it would behave like that.
Cool, I'll have to check it out!
Not disabling memory map when all files are closed would be simple enough.
What sorts of preferences are you asking about? I suppose switching between DTR, RTS, and GPIO reset would be something for such a menu. And line delay. What else?
I've been contemplating how C could work in the context of PropellerIDE, and there seems to be two options.
1. Require libraries to have a .c and .h file of the same name; i.e. blahdriver.c and blahdriver.h. This would make C support project-less (just hit F10!) and much easier to implement. But would remove some freedom to do arbitrary file inclusion.
2. Implementing a whole project system that magically pops up for languages that want it, like C.
I'm more partial to #1. #2 is a giant junk of code that gives people the freedom to do more confusing things with their code. =P And #1 is much more near-term than #2. However, if people start doing #includes inside #ifdefs, it's going to get messy anyway.
But this is all far off in any case.
I'm not sure if you have this already, but a common way to manage all types of external languages/compilers, in Editor-IDEs is to allow a Batch Call Project.
This usually has some simple parameters like %FILENAME% %FILEPATH% etc that you can pass to an external command line, and auto-reopen of changed files then co-operates quite well with external builds.
Some editors capture the command output, and have a simple error parser expression that can extract the typical error tag of FileName (LineNo,ColumnNo) ErrMess with varying choices of /(, etc, or you can work with log-files.
PropellerIDE has a basic form of this, though it's not exposed to the user at present. Here are the compiler configs I currently have defined:
https://github.com/parallaxinc/PropellerIDE/tree/master/src/propelleride/config
These can then be added to a language using the "buildsteps" key in the language definition. PropBASIC is a good example (right at the top):
https://github.com/parallaxinc/PropellerIDE/blob/master/src/propelleride/languages/propbasic.json
I had started out trying to implement the sort of %FILENAME% thing you mentioned, but ended up going with a simple extension change for now. The ExternalCompiler currently expects a single output from a single input, so that would take some rethinking. Basic success/error output parsing opens the file at the line where the error happened.
Perhaps there can be a means to add a custom compiler via the Preferences dialog at some point.
I'm working on code to provide I/O support to a 6502, and Spin was working but slow. I doubt I have the dedication to learn PASM just yet. PropBASIC fills the gap nicely and this IDE makes it easy. Thanks Brett, Bean, JohnnyMac and all the contributors. Amazing stuff.
Is it possible to generate COG code or only LMM?
It can generate both. In fact there are options for code in COG or HUB (the latter is LMM) and data in COG or HUB. The compiler hasn't really been tested with code in HUB and data in COG (that seems like an unlikely combination) so I don't know if that one works, but the other 3 combinations do work.
takes away the speed advantage of pb... since the OBEX has been so helpful ,
Any chance of an object (sub) library for PropBasic? Just a few , maybe, ??
thank you for your support.
Bill
If you go to the OBEX and search for all, may take a minute, the objects with the green background with the star are some of the PropBasic libraries that Terry wrote.
Ray
How do I write strings and integers to PST when using PropBasic?
Thanks
Tom
forums.parallax.com/discussion/163372/propbasic-libraries
Here is one of the RX/TX sample programs from the library:
Here is the brief description of the extensions/modifications to the RX/TX library referenced above:
TX_RX Library
Because Jonny Mac’s 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.
I have also 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
Try out the library and see if it works for your needs and let us know how it goes...
fastspin differs from bstc and openspin because it turns Spin code into LMM binaries, which are larger and faster than normal Spin binaries. This won't make any difference for PropBasic, since the PropBasic compiler produces plain PASM code.
Eric
#1- When compiling the program the compile information window rolls by way to fast, so if you have an error, their is no way that you can view what the error is. Maybe PropellerIDE needs a separate stationary area, at the bottom of the main window, similar to the way SimpleIDE displays its compile status.
#2- When I have something like this: and I have Auto completion turned on, when I try to type in ser0.Start... it will not except the dot. If I have:
tlib : "tools.spin", then the dot works when you try something like tlib.high(12).
Probably the biggest concern at the moment is viewing the compile window information, I am now only guessing as to what the error could be, and this is just on a small program.
Ray
This is what I did...
1) In the PropellerIDE installation folder that contains the tools (mine was installed under /Applications/PropellerIDE.app/Contents/MacOS/), I just renamed bstc to bstc2
2) I then wrote and copied this simple bash script below as /Applications/PropellerIDE.app/Contents/MacOS/bstc, which generates the listing file in the same folder as the source fed into the compiler. To figure out the name of the listing file generated it assumes the source filename contained an extension removed by the compiler (i.e. source file name contained a period). You can also add other options in the EXTRAOPTS variable as required.
3) enable bash script to be executed
Now each time I do a build it will call the bash script and then output the listing file to the Build Manager output window where it can be viewed and easily scrolled around with cursor keys.
Enjoy.
ps. Also it would be rather nice to have the inbuilt terminal window support an optional mode where you can type in characters and not always need press the enter key or send button to transmit them to a Propeller in line oriented mode. I might like to look at the source code for that to see if there is a way to patch it, assuming I can manage to build it. I do have Xcode installed, not sure what other code or tools I may need to build the PropellerIDE tool from its source in GitHub, haven't really looked yet or started hacking around with it.
UPDATE: Through experiment I just found if you mouse click the PropellerIDE terminal window first, you can type characters directly in without using the line oriented mode - perfect!
UPDATE2: I also added the exit failure to the script when the listing file does not exist, this way the Build Manager build status better reflects success/failure of the build.