Okay, The masses have spoken. I'll keep working on the current version.
I have added support for the Viewport Terminal window.
You need viewport 4.6.7 or later, PropBasic version 1.27 or later, and the VPterminal_lib.pbas file.
PropBasic 1.27 or later and the VPterminal_lib.pbas file are on the first post in this thread.
Here is a demo program:
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
' For Viewport 4.6.7
' For PropBasic 1.27
LOAD "VPterminal_lib.pbas"
name HUB STRING(30)
temp VAR LONG
watch temp
PROGRAM Start
Start:
VPConfig "start:terminal::terminal:1"
VP_Str "Hello from PropBasic\r"
VP_NewLine
FOR temp = -10 to 10
VP_Dec temp
VP_Char " "
NEXT
VP_NewLine
VP_Str "Enter your name:"
temp = VP_StrIn name
VP_Str "Hello there "
VP_Str name
VP_NewLine
VP_Str "Your name has "
VP_Dec temp, 2
VP_Str " characters.\r"
VP_Str "Press a key...\r"
DO
temp = VP_CharIn
VP_Str " = "
VP_Dec temp
VP_Newline
LOOP
END
Very nice Bean! I'll check this out later today. It would be nice if library files could live in the "viewport/lib" directory. Does your compiler support different directories yet?
Hanno
Okay, The masses have spoken. I'll keep working on the current version.
I have added support for the Viewport Terminal window.
You need viewport 4.6.7 or later, PropBasic version 1.27 or later, and the VPterminal_lib.pbas file.
PropBasic 1.27 or later and the VPterminal_lib.pbas file are on the first post in this thread.
Here is a demo program:
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
' For Viewport 4.6.7
' For PropBasic 1.27
LOAD "VPterminal_lib.pbas"
name HUB STRING(30)
temp VAR LONG
watch temp
PROGRAM Start
Start:
VPConfig "start:terminal::terminal:1"
VP_Str "Hello from PropBasic\r"
VP_NewLine
FOR temp = -10 to 10
VP_Dec temp
VP_Char " "
NEXT
VP_NewLine
VP_Str "Enter your name:"
temp = VP_StrIn name
VP_Str "Hello there "
VP_Str name
VP_NewLine
VP_Str "Your name has "
VP_Dec temp, 2
VP_Str " characters.\r"
VP_Str "Press a key...\r"
DO
temp = VP_CharIn
VP_Str " = "
VP_Dec temp
VP_Newline
LOOP
END
This version let's you print your code with colored background, indent guides, line numbers, headers and footers
Thanks Fried for all the feedback.
Hanno
Thanks for hearing our pleas, Bean. On the subject of support, I bought Hanno's standard version of Viewport, but you keep slaving away for nothing but our thanks. Do you have a website, or someplace you could put a "donate" button?
Thanks for hearing our pleas, Bean. On the subject of support, I bought Hanno's standard version of Viewport, but you keep slaving away for nothing but our thanks. Do you have a website, or someplace you could put a "donate" button?
-Bob
Bob,
No. That is really not necessary. Your (collective) thanks is enough for me.
If you make a profit with PropBasic and it would make you feel better, you can send me a donation via paypal to bean @ pa . net (remove spaces).
Downloaded and purchased ViewPort v4.6.7 (I look forward to a version for OSx). Downloaded and installed the Propbasic v1.27 and VPterminal_lib.pbas. Did a copy and paste for the demo code for the ViewPort Terminal Window. Compile fails with "Expected "(eol), got 8" on the following line in TermTest.spin:
This appears to be coming from Line 28 of VPterminal_lib.pbas and is an error being thrown by PropBasic?? Am I missing something? File is attached.
It also appears that block comments using "{" "}" are no longer allowed and throw errors. Is this intentional? The latest document I have is for PropBasic 1.04. Is there something newer?
To reinforce the previous comments, I am using PropBasic for specialized audio processing with a pipeline of 5 COGs and speed is very important to me so I would hate to lose it. I'd have to learn Propeller Assembly code. I appreciate the effort you have put into PropBasic Bean, and would be willing to help where I can (Testing, Documentation, Web Site help, etc) and look forward to the power and insight the PropBasic and ViewPort tools provides.
Hi Hanno! I installed the latest version (4.67) but the program stop loading, and the error messages "Project does not have -g compiler oprion set for debugging" and Project does not have -g link oprion set for debugging" appear. Clicking "OK" the program starts, but no way to have it working.
Hi Carlo,
Are you debugging a Catalina C file? Make sure your PropBasic files end with a .pbas extension.
If that's not the problem please post a screenshot and make sure to have ViewPort send the error log to me so I can see what's going on.
Hanno
Hi Hanno! I try to explain it better. I had ViewPort 4.6.3, it installed (and worked) perfectly. The problem arises when trying to install version 4.6.7,
I click on Viewport467 file, the installation starts, but,before installation is complete, the warning window (windowA.jpg) appears. I click OK, a new warning window appears (windowB.jpg). I click OK again, and the "problem" window (problem window.jpg) appears. If I click on restart or Exit buttons, the programs exits; if I click on "Try to continue", the program main window appears. This happens either with Catalina installed, and after uninstalling Catalina, and having PropBasic either in its directory, or copied in Viewport directory.
Can I continue using Viewport, or will I have to reinstall and use ver 4.6.3?
Hi Carlo,
Looks like you and Sapieha have hit a rare issue when upgrading to 4.67
Thanks for submitting the bug report, the screenshot, and letting me know you upgraded from 4.63. I should be able to reproduce and fix this asap.
Sapieha, it looks like you found a workaround to keep working with 4.67?
Hanno
When I press F8, a message windows pops up thus..
title: "Compile Error"
message: "PropBasic didn't generate a spin file because:"
That's it... no "because" shown
At the bottom of the main windows it shows, Status: "Failed to Compile code for PropBasic".
Sorry to post here Bean if that's rather a viewport issue, but I figured you and Hanno both watch this thread. Maybe I need to change some config options with this new VP version??
Needless to say it might also be my system and I would appreciate any suggestions...., although before the upgrade to 4.7.3 this morning all was fine. I have just re-downloaded the latest propbasic.exe from this thread. The same .pbas sources compile OK in bst... Also, I can press F7 in viewport and the prop is "found and reset" ok, which would suggest the com port is fine.
Anyhow, I will roll-back to the last stable VP for now, so no panic!
still get the same "Compile Error" mentioned above, but actually the .spin files are being created! They seem fine compared to what I would expect, so the "error" seems to be after the compile success.
Doh, my bad. I added a feature that let's you compile/run code without first saving it. To do this I create a temporary file of the text you're trying to compile and then compile that file. I didn't change one variable in the PropBasic module which caused ViewPort to look for the error log and resulting spin file in the wrong place. My regression test passed because the spin file already existed- I've fixed both issues and will upload a new version in a couple hours.
Hanno
Hi Bean... a very small thing and not really urgent, but if you misspell "DEVICE" and then try to compile from ViewPort, (indeed the same with XIN), does your PropBasic process lock-up and require an End Process from windows Task Manager to bring it under control ? You can misspell most other commands (ie. LOAD as TOAD is fine), and PropBasic handles that gracefully.
Maxwin,
Misspelling DEVICE causes a hang-up. I'll try to track down the problem.
My my very simple demo program is seems the FREQ command causes the problem, but there could be other commands that cause the hang-up too.
Without a valid device setting, many commands cannot work properly because the compiler doesn't know the hardware configuration.
I'll work on fixing FREQ, maybe I'll get lucky with the other commands...
that makes sense.. maybe a simple "text" INSTR type check for certain keywords before you try the real compile...
IF DEVICE or (XIN or FREQ) .. does not exist, return compiler error! Probably needs slightly more intelligence to check only start of lines, and even better at the start of the file... but anyhow maybe something like that.. Good luck !!
Yep, I found the problem. Without a DEVICE setting the PLL was set to zero (instead of 1). In the FREQ and XIN command there is a divide by PLL. This caused a divide-by-zero error and made the compiler abort.
I've been away from PropBasic for quite awhile, if anyone knows of any other issues let me know and I'll try to fix them in this update.
With this Viewport version of PropBasic, is it possible to output the compiled program to ..eeprom file format?
Am happy to work with the command line, perhaps if there exists an appropriate argument that might be passed to the compiler to control the output format?
Or even if there are some docs somewhere that might detail how to convert a bunch of .spin files to .eeprom format? I could create a little eepromBuilder program then!
Thanks for any help.
BTW,
1. Tried to load the .spin files into the Propeller tool (which would allow export to .eeprom), but some errors came. PropTool didn't like some @@@directives in the code.
2. Also tried to use bst, but that is running an older version of PropBasic- and I think the newer VP version contains some fixes my program relies on. At least the .eeprom file did not work as expected, whereas testing some simple "hello world" code did work.
Would still be nice to have that function in viewport though... along with the option to compile WITHOUT vp debugging (a shift F8 version of shift F3 I guess !!). I did already mention the idea at the hannoware forum, so it might all come together one day if Hanno has some spare moments.
Not sure if this is the thread to put this in, but here goes:
I've noticed that I get "Compile error: File not found" whenever I try to run newly created code - even if I save it first. I have to close ViewPort and re-open it to get the code to run.
I'm using ViewPort 4.7.7 and the latest PropBASIC.
I noticed something similar. My thinking was that Viewport does not "recognise" the code as PropBasic until it re-opens it- and then makes the language judgement based on the file extension. So it tried to compile as spin (perhaps?)
In older Viewport versions I noticed the same issue too, which would always occur if you started coding from a blank sheet (file/new), but did NOT happen if you started from a PropBasic template. Although the template function seems to be missing from the latest viewport version, I guess it worked ok in the older versions because viewport "opened" the template file as .pbas, and so could make the language judgement correctly.
So what I am guessing is that the logic to decide on the code lang is only done at file open time by viewport. Perhaps it needs to be smarter for "unknown" code (ie. newly created), and also make the decision once you make the first save, either by the file extension you use for saving, or by some keywords in the code.
Anyway... not such a big deal to close/re-open... Just wanted to support you- that you are not going crazy with it!
Hi!
I verified that there's something "funny" going on when you create a new .pbas file.
Workaround for now is to save the file, open it, and then compile it.
I removed the template functionality as you now no longer need to do anything special in order to use ViewPort.
So, this is a valid spin file that will let you view/edit 2 variables and analyze the IO states:
VAR LONG x,y 'vars in the first VAR section are automatically shared with viewport
PUB main
repeat
x+=y
This is a valid PropBasic file:
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
PROGRAM Start
temp1 VAR LONG
Start:
WATCH temp1
DO
FOR temp1=0 to 110
PAUSE 10
NEXT
LOOP
END
I've been enjoying using the Propeller and PropBasic for the last week and I think these 2 systems combined are amazing. I love the fact that you can have multiple tasks running on different COGs and the results are truly deterministic. Having been developing on the SX a while ago I see this environment as a breath of fresh air. Being able to create large programs and have them deployed to RAM quickly is a real bonus.
Since I'm a newbie, please forgive me if this has been covered before. I was curious on how to establish local variables for subroutines contained withing the COGs. I recall that in SX/B you could append a "l_" to the var.
Here is a typical example of 2 independent subroutines that need to have variables defined. Since having 6 variables defined (a,b,c,d,e,f,) is wasteful of COG ram, what would be the best practice here to have variable names that save on space but also have meaning within the routine ?
SubRoutine1 SUB
a VAR LONG
b VAR LONG
c VAR LONG
' Some code using these variables
ENDSUB
SubRoutine2 SUB
d VAR LONG
e VAR LONG
f VAR LONG
' Some code using these variables
ENDSUB
I know we could use something like declaring Temp1, Temp2, Temp3 etc outside the 2 routines and then using them within each routine. However, the generic names are meaningless within the context of each routine (I like to give the variable names accurate descriptions based on their role within each routine).
Comments
I have added support for the Viewport Terminal window.
You need viewport 4.6.7 or later, PropBasic version 1.27 or later, and the VPterminal_lib.pbas file.
PropBasic 1.27 or later and the VPterminal_lib.pbas file are on the first post in this thread.
Here is a demo program:
DEVICE P8X32A, XTAL1, PLL16X FREQ 80_000_000 ' For Viewport 4.6.7 ' For PropBasic 1.27 LOAD "VPterminal_lib.pbas" name HUB STRING(30) temp VAR LONG watch temp PROGRAM Start Start: VPConfig "start:terminal::terminal:1" VP_Str "Hello from PropBasic\r" VP_NewLine FOR temp = -10 to 10 VP_Dec temp VP_Char " " NEXT VP_NewLine VP_Str "Enter your name:" temp = VP_StrIn name VP_Str "Hello there " VP_Str name VP_NewLine VP_Str "Your name has " VP_Dec temp, 2 VP_Str " characters.\r" VP_Str "Press a key...\r" DO temp = VP_CharIn VP_Str " = " VP_Dec temp VP_Newline LOOP ENDBean
Hanno
You recommend Viewport "4.6.7" but on his site Hanno have only 4.6.6a
http://hannoware.com/viewport/beta.php
This version let's you print your code with colored background, indent guides, line numbers, headers and footers
Thanks Fried for all the feedback.
Hanno
-Bob
Bob,
No. That is really not necessary. Your (collective) thanks is enough for me.
If you make a profit with PropBasic and it would make you feel better, you can send me a donation via paypal to bean @ pa . net (remove spaces).
Bean
ERROR 8 INVALID PARAMETER "(" ; __ascii HUB STRING(12) ' Holds decimal string
This appears to be coming from Line 28 of VPterminal_lib.pbas and is an error being thrown by PropBasic?? Am I missing something? File is attached.
It also appears that block comments using "{" "}" are no longer allowed and throw errors. Is this intentional? The latest document I have is for PropBasic 1.04. Is there something newer?
To reinforce the previous comments, I am using PropBasic for specialized audio processing with a pipeline of 5 COGs and speed is very important to me so I would hate to lose it. I'd have to learn Propeller Assembly code.
Sonar
Do you have any suggestion?
Thanks so much
Carlo
Are you debugging a Catalina C file? Make sure your PropBasic files end with a .pbas extension.
If that's not the problem please post a screenshot and make sure to have ViewPort send the error log to me so I can see what's going on.
Hanno
I click on Viewport467 file, the installation starts, but,before installation is complete, the warning window (windowA.jpg) appears. I click OK, a new warning window appears (windowB.jpg). I click OK again, and the "problem" window (problem window.jpg) appears. If I click on restart or Exit buttons, the programs exits; if I click on "Try to continue", the program main window appears. This happens either with Catalina installed, and after uninstalling Catalina, and having PropBasic either in its directory, or copied in Viewport directory.
Can I continue using Viewport, or will I have to reinstall and use ver 4.6.3?
Yours sincerely and thanks!
Carlo
I think it is problem with link to last open files in previous version of Viewport that was installed before on his computer.
I had some start problems to -- but my last file was not one that used debugging.
Looks like you and Sapieha have hit a rare issue when upgrading to 4.67
Thanks for submitting the bug report, the screenshot, and letting me know you upgraded from 4.63. I should be able to reproduce and fix this asap.
Sapieha, it looks like you found a workaround to keep working with 4.67?
Hanno
When I press F8, a message windows pops up thus..
title: "Compile Error"
message: "PropBasic didn't generate a spin file because:"
That's it... no "because" shown
At the bottom of the main windows it shows, Status: "Failed to Compile code for PropBasic".
Sorry to post here Bean if that's rather a viewport issue, but I figured you and Hanno both watch this thread. Maybe I need to change some config options with this new VP version??
Needless to say it might also be my system and I would appreciate any suggestions...., although before the upgrade to 4.7.3 this morning all was fine. I have just re-downloaded the latest propbasic.exe from this thread. The same .pbas sources compile OK in bst... Also, I can press F7 in viewport and the prop is "found and reset" ok, which would suggest the com port is fine.
Anyhow, I will roll-back to the last stable VP for now, so no panic!
Best regards
still get the same "Compile Error" mentioned above, but actually the .spin files are being created! They seem fine compared to what I would expect, so the "error" seems to be after the compile success.
Have the command line args changed?
Hanno
Bean
Misspelling DEVICE causes a hang-up. I'll try to track down the problem.
My my very simple demo program is seems the FREQ command causes the problem, but there could be other commands that cause the hang-up too.
Without a valid device setting, many commands cannot work properly because the compiler doesn't know the hardware configuration.
I'll work on fixing FREQ, maybe I'll get lucky with the other commands...
Bean
IF DEVICE or (XIN or FREQ) .. does not exist, return compiler error! Probably needs slightly more intelligence to check only start of lines, and even better at the start of the file... but anyhow maybe something like that.. Good luck !!
I've been away from PropBasic for quite awhile, if anyone knows of any other issues let me know and I'll try to fix them in this update.
Bean
Am happy to work with the command line, perhaps if there exists an appropriate argument that might be passed to the compiler to control the output format?
Or even if there are some docs somewhere that might detail how to convert a bunch of .spin files to .eeprom format? I could create a little eepromBuilder program then!
Thanks for any help.
BTW,
1. Tried to load the .spin files into the Propeller tool (which would allow export to .eeprom), but some errors came. PropTool didn't like some @@@directives in the code.
2. Also tried to use bst, but that is running an older version of PropBasic- and I think the newer VP version contains some fixes my program relies on. At least the .eeprom file did not work as expected, whereas testing some simple "hello world" code did work.
http://forums.parallax.com/showthread.php?106401
Would still be nice to have that function in viewport though... along with the option to compile WITHOUT vp debugging (a shift F8 version of shift F3 I guess !!). I did already mention the idea at the hannoware forum, so it might all come together one day if Hanno has some spare moments.
COGSTOP not recognised by compiler "UNKNOWN COMMAND"... PropBasic 1.27
\ COGSTOP seems to work around the matter for now...
Okay, I see that. When COGSTOP is used with a constant.
Will be fixed in release 1.28
Bean
I've noticed that I get "Compile error: File not found" whenever I try to run newly created code - even if I save it first. I have to close ViewPort and re-open it to get the code to run.
I'm using ViewPort 4.7.7 and the latest PropBASIC.
In older Viewport versions I noticed the same issue too, which would always occur if you started coding from a blank sheet (file/new), but did NOT happen if you started from a PropBasic template. Although the template function seems to be missing from the latest viewport version, I guess it worked ok in the older versions because viewport "opened" the template file as .pbas, and so could make the language judgement correctly.
So what I am guessing is that the logic to decide on the code lang is only done at file open time by viewport. Perhaps it needs to be smarter for "unknown" code (ie. newly created), and also make the decision once you make the first save, either by the file extension you use for saving, or by some keywords in the code.
Anyway... not such a big deal to close/re-open... Just wanted to support you- that you are not going crazy with it!
I must admit I miss the template option, so I've left a note for Hanno about that. Hopefully we can have it back soon.
I think you're too late - I reckon I'm already crazy LOL
I verified that there's something "funny" going on when you create a new .pbas file.
Workaround for now is to save the file, open it, and then compile it.
I removed the template functionality as you now no longer need to do anything special in order to use ViewPort.
So, this is a valid spin file that will let you view/edit 2 variables and analyze the IO states:
VAR LONG x,y 'vars in the first VAR section are automatically shared with viewport
PUB main
repeat
x+=y
This is a valid PropBasic file:
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
PROGRAM Start
temp1 VAR LONG
Start:
WATCH temp1
DO
FOR temp1=0 to 110
PAUSE 10
NEXT
LOOP
END
I've been enjoying using the Propeller and PropBasic for the last week and I think these 2 systems combined are amazing. I love the fact that you can have multiple tasks running on different COGs and the results are truly deterministic. Having been developing on the SX a while ago I see this environment as a breath of fresh air. Being able to create large programs and have them deployed to RAM quickly is a real bonus.
Since I'm a newbie, please forgive me if this has been covered before. I was curious on how to establish local variables for subroutines contained withing the COGs. I recall that in SX/B you could append a "l_" to the var.
Here is a typical example of 2 independent subroutines that need to have variables defined. Since having 6 variables defined (a,b,c,d,e,f,) is wasteful of COG ram, what would be the best practice here to have variable names that save on space but also have meaning within the routine ?
SubRoutine1 SUB
a VAR LONG
b VAR LONG
c VAR LONG
' Some code using these variables
ENDSUB
SubRoutine2 SUB
d VAR LONG
e VAR LONG
f VAR LONG
' Some code using these variables
ENDSUB
I know we could use something like declaring Temp1, Temp2, Temp3 etc outside the 2 routines and then using them within each routine. However, the generic names are meaningless within the context of each routine (I like to give the variable names accurate descriptions based on their role within each routine).
Many thanks
Tony