Hi Bean,
I was wondering why I didn't need the two .txt files with the BST version of PropBasic. And yes, PropBasic complains about not finding INVALID.TXT if you don't have that in the directory.
I've added this to VP:
- deletes corresponding spin file before propbasic compile
- if no spin file was generated, it shows a nice error message with whatever PropBasic outputs.
BST's version is only 115kb and doesn't need the .txt files- your v1.15 is 427kb and does need the files? Can I include ideally a ~115kb version which doesn't need other files in my installer?
Hanno
Skynugget,
For some reason the compiler doesn't like the like "nday = nday * 7" in the TASK CalendarMath ???
I'm not sure why, but the compiler hangs there for about a minute, then continues. It does generate the code for the line ???
It looks like ViewPort is timing out.
I almost missed that you already implemented "WATCH"!!!!
Hey- this is awesome!
Took me a couple tries:
- I just placed empty "invalid.txt" and "reserved.txt" files into my "PropBasic" directory
- I initially thought I needed to add the "ASM" section- but Bean does it for you!
So- you really do just need Bean's code:
DEVICE P8X32A, XTAL1, PLL16X
XIN 5_000_000
cntr VAR LONG
cntr2 VAR LONG
WATCH cntr
WATCH cntr2
PROGRAM Start
Start:
FOR cntr = 1 to 10
FOR cntr2 = 1 to 10
PAUSE 1
NEXT
NEXT
GOTO Start
END
and VP will show you the two variables changing- it Bean's even configured the variable names to show!
Great job Bean!
Hanno
Hanno, Bean,
this is an awesome development!
I have installed all the files on my German Win7 installation,
the standard dir for 32 bit programs is "c:\Programme (x86)\PropBasicNew\ProbBaisc.exe".
Viewport doesn't like that, c:\PropBasicNew\Propbasic.exe works fine.
I have another stupid question concerning the test program:
The vars VP_watch LONG 0[2] are in HUB RAM or not?
How are the cntr, cntr2 vars copied there?
Thanks, Fried
FriedV,
The compiler generates extra code to copy the variable to the VP_watch array whenever it is modified.
So for only LET (assignment) and FOR...NEXT generate the extra code, but I'll get around to the other commands.
Hanno,
I'll work on moving the .TXT files to internal data so you'll just need the .EXE.
With this version you need to add "/VP" to the PropBasic compiler options (under Edit->Program Preferences...). This tells the compiler right away that the program is being compile under viewport.
[edit] See later posts for latest version...
You can turn the watches on and off. When off the values are not updated (this generates less code and is quicker).
So you can use "WATCH varname" and "UNWATCH varname". Note that WATCH and UNWATCH are directives and don't actually generate any code, they just affect how code is generated after them.
Here is a small program to demonstrate (view in the "dso" tab).
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
Background TASK AUTO
PROGRAM Start
temp1 VAR LONG
Start:
WATCH temp1
DO
FOR temp1=0 to 10
PAUSE 10
NEXT
FOR temp1=9 to 1 step -1
PAUSE 10
NEXT
LOOP
END
TASK Background
temp2 VAR LONG
DO
WATCH temp2
FOR temp2=0 to 10
PAUSE 10
NEXT
UNWATCH temp2
FOR temp2=9 to 1 step -1
PAUSE 10
NEXT
LOOP
ENDTASK
Hi!
Marriage? I haven't even met the guy! But he looks quite handsome
Fried- make sure you spell the location of the path exactly right- I tested it in your specified directory and it works for me...
Sapieha- When you press "run", ViewPort first deletes the corresponding .spin file, then compiles the ".pbas" to ".spin" and leaves it in that directory. The file browser is also updated, so if you want you can click on that file and use it- to make changes in spin, or to do line by line debugging with breakpoints...
Bean- I've defaulted the option to "/VP /Q" for the next release- if people have downloaded VP v4.63 already they'll need to add the /VP option themselves.
How about a "watchio(1ms) " directive to include and configure the quicksample object to sample the IO pins at up to 20msps with one cog? It would need to add this:
OBJ 'include 2 ViewPort objects:
qs : "QuickSample" 'samples INA continuously in 1 cog- up to 20Msps
VAR
long frame[400] 'stores measurements of INA port
vp.config(string("lsa:view=io,timescale=TIMESCALE")) 'optional configuration to view "io" in the lsa view and set timescale to passed parameter
vp.register(qs.sampleINA(@frame,1)) 'sample INA into <frame> array with 1 cog- must be called before "vp.share". Can pass 4 to use 4 cogs for 80Msps
It's going good, but there is still alot of work yet to be done.
Support VPCONFIG "string" (done 1.16). Must be before the PROGRAM command.
Support modifying variables with "VPUPDATE varname" (Done 1.16).
Problem: Offsets get messed up if you define HUB variables (or DATA or STRINGS) between WATCHed variables. I'm not sure how to fix this just yet.
Support IO monitoring
Support Arrays
Support Video
I'm debating about making a subroutine that updates ALL of theWATCHed variables that will get called whenever ANY of the WATCHed variables are changed. This would make the code slower, but much smaller. And with only 496 instructions, I think size outweighs speed (PropBasic is super fast anyway). This subroutine could be called to manually update Viewport by calling VPREFRESH.
Bean, each statement only affects one variable right? So it would be very expensive to call a sub, loop through all vars to wrlong them, and return. Instead, how about keeping a pointer into HUB for each watched variable. Then, you just need to
wrlong watch_var_register,watch_var_hub_ptr
after each statement that changes a watched variable. That saves a ton of space and time!
Have you considered sharing all variables when "/vp" is used?
How about a suffix after the variable declaration that indicates that the variable should be an "editable" variable. Here's a sample program
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
PROGRAM Start
x VAR LONG 'will be written to hub after every instruction that changes it- and will automatically be "watched" by vp
y VAR LONG TEXTBOX 'vp will edit this variable with a textbox. before every instruction that uses this variable, it will be read from hub
Start:
DO
FOR x=0 to 10 'after this statement, x will be written to xptr, and y will be read from yptr
PAUSE y
NEXT
Bean,
Good idea to use "watch" to share all variables. VP can edit variables with: dial, scroll, text, slider, multi and switch.
I've updated the template used for "file>new"- the wizard asks you which variables you want to watch and VP generates the code to allocate and watch those vars.
I'd prefer to force users to keep their "watched" variables in one location. VP's Conduit does support sharing multiple areas of HUB- but that's really designed to share different arrays.
Have you seen VP's streaming of graphics? For example, tutorial #27? That example uses Kye's 1byte/pixel format- I support both 6bits RGB and 8bit grayscale- as well as my own 4bit/pixel formats for higher resolution. The streamed video is shown inside of VP and can be fed through OpenCV for computer vision analysis...
Hanno
Bean, each statement only affects one variable right? So it would be very expensive to call a sub, loop through all vars to wrlong them, and return. Instead, how about keeping a pointer into HUB for each watched variable. Then, you just need to
wrlong watch_var_register,watch_var_hub_ptr
after each statement that changes a watched variable. That saves a ton of space and time!
Hanno,
THANK YOU SO MUCH for this tidbit of knowledge. When I was first writing PropBasic I wanted to support the Parallax Propeller tool (which doesn't have @@@) so I calculated all hub offsets from PAR. But you just reminded me that I can just set a variable to the @@@ hub address and do it with only 1 instruction (instead of 2 or 3) and I don't have to worry about keeping track of offset either.
[in my best Yoda voice] Much work to be done there is...
FriedV,
No not yet. It's going to be tricky because Viewport requires all the WATCHed variables to be continuous in HUB memory (except arrays). Is that right Hanno ?
Maybe it will work as an array of 1 element ?
Yes, you don't have to calculate the offsets into hub at runtime- I would definitely use a pointer for each watched variable.
Lots of work there is- overcome it we shall.
Any way you can force the watched variables to be allocated next to hub vars? Then they would be contiguous.
As a last option- Conduit is capable of streaming multiple arrays- even "vp.share" just tells Conduit to share that memory section. So yes, it's possible for me to assign an array type to a second "vp.share"- but I haven't set up the rest of ViewPort for that- would mean quite a few somewhat risky changes...
See tutorial #0 for how to share a string- basically you're still sharing an array of longs, but VP treats it as a null terminated string- here's relevant configuration code:
vp.config(string("var:a,b,str(string=20),c"))
VP just supports array of longs. It also supports "files"- allowing up and downloading of unlimited length "arrays"- I'm using that to build an open protocol analyzer right now. See tutorials 24..26 for examples.
Hanno
Hanno,
Here is the latest version. Lots of changes in here..
I have a couple questions...
1) When there is a FILE "filename" in the spin file, Viewport tries to load the file from c:\program files\ instead of the directory that the spin file is in.
2) Is there any way you can have an option to just load the code without debugging with viewport ? In other words, It would be nice to use viewport to debug the code and then be able to just load the code without the viewport objects. I thought there were two options "RUN" and "DEBUG", but RUN still gives an error if the viewport object is not running. It would be nice if "RUN" called the compiler WITHOUT the "/vp" switch, and "DEBUG" would call the compiler WITH the "/vp" switch.
I'll make sure to set the "working directory" to the source's directory when calling PropBasic.
Yes, I've been meaning to add the ability to load code without ViewPort support- only thing stopping me is how to keep ViewPort simple for new users.
There are quite a few option when you want to "run" your program:
- load to eeprom or RAM?
- add ViewPort support to monitor/change variables and start the "connect" process?
- add traditional debugging support (breakpoints, line by line stepping) and start debugging?
Currently there are two buttons on the "code" view:
"Run"=Load with ViewPort support then connect
"Debug"=Load with Viewport and Debug support then start debugging
How about I add a third button so you can:
"Load"=Load program without ViewPort or Debug support
"Run"=Load with ViewPort support then connect
"Debug"=Load with Viewport and Debug support then start debugging
I think the "Run" menu should provide another means to "load" and "run"- with keyboard shortcut- as well as loading into eeprom.
-Load to RAM
-Load to EEPROM
-Load to RAM with ViewPort support then connect
-Load to EEPROM with ViewPort support then connect
I'm happy with the "Debug" menu, it let's you "start a debugging session" (load to ram with viewport and debug support) as well as letting you "pause", "step" code. If someone really wanted it, I could add an entry to "Load with Debug support into EEPROM"
People use ViewPort as a user interface for their projects- when they press "Run" they want code loaded to the Prop and ViewPort to provide the interface. For traditional breakpoint/line by line debugging they press "Debug". I would rather not merge those two concepts...
Hanno
Hanno,
What's new ? All HUB access is through COG variables set to @@@hub instead of offsets from "par".
"Load RAM" and "Load EEPROM" give an error if I remove the "/vp" switch. "Unable to load and connect PropBasic."
The "LOAD" button (and "Load RAM", "Load EEPROM" menu items too) should call the compiler WITHOUT the /vp switch.
"Run" and "Debug" should call the compier WITH the /vp switch.
This is just my way of thinking. I don't want to impose my will on you.
Fixed a couple bugs when you used multiple parameters with WRxxxx and RDxxxx for example: "RDBYTE datalabel, temp1, temp2, temp3" would increament the actual datalabel address.
I didn't up the rev so it is still rev 1.16 but is dated Sept 27, 2011.
Hanno,
I'm having trouble supporting strings.
I found that using str(string=20) doesn't work. By looking at the configuration dialog it appears that I need to use str(base=-1) but that only shows the first 4 characters. I tried using str(base=-1,string=20) but that only showed the first 4 characters too.
I know Message is defined as a byte array, but it IS long aligned.
I think the problem is that I need to use an ARRAY as a string. I can't put the strings in with the numeric "share" range.
Comments
I was wondering why I didn't need the two .txt files with the BST version of PropBasic. And yes, PropBasic complains about not finding INVALID.TXT if you don't have that in the directory.
I've added this to VP:
- deletes corresponding spin file before propbasic compile
- if no spin file was generated, it shows a nice error message with whatever PropBasic outputs.
BST's version is only 115kb and doesn't need the .txt files- your v1.15 is 427kb and does need the files? Can I include ideally a ~115kb version which doesn't need other files in my installer?
Hanno
For some reason the compiler doesn't like the like "nday = nday * 7" in the TASK CalendarMath ???
I'm not sure why, but the compiler hangs there for about a minute, then continues. It does generate the code for the line ???
It looks like ViewPort is timing out.
I'll investigate further.
Bean
Hey- this is awesome!
Took me a couple tries:
- I just placed empty "invalid.txt" and "reserved.txt" files into my "PropBasic" directory
- I initially thought I needed to add the "ASM" section- but Bean does it for you!
So- you really do just need Bean's code:
DEVICE P8X32A, XTAL1, PLL16X XIN 5_000_000 cntr VAR LONG cntr2 VAR LONG WATCH cntr WATCH cntr2 PROGRAM Start Start: FOR cntr = 1 to 10 FOR cntr2 = 1 to 10 PAUSE 1 NEXT NEXT GOTO Start ENDand VP will show you the two variables changing- it Bean's even configured the variable names to show!Great job Bean!
Hanno
I just posted the TXT files above.
Bean
i noticed a change in speed when i updated to .14 i think.
Can You have it that spin file always show after compiling NOT only if I have any error.
this is an awesome development!
I have installed all the files on my German Win7 installation,
the standard dir for 32 bit programs is "c:\Programme (x86)\PropBasicNew\ProbBaisc.exe".
Viewport doesn't like that, c:\PropBasicNew\Propbasic.exe works fine.
I have another stupid question concerning the test program:
The vars VP_watch LONG 0[2] are in HUB RAM or not?
How are the cntr, cntr2 vars copied there?
Thanks, Fried
The compiler generates extra code to copy the variable to the VP_watch array whenever it is modified.
So for only LET (assignment) and FOR...NEXT generate the extra code, but I'll get around to the other commands.
Hanno,
I'll work on moving the .TXT files to internal data so you'll just need the .EXE.
Bean
Here is a version of the compiler that fixes the "hang-up" problem you had.
Hanno,
This version also does NOT need the .TXT files.
[edit] See later posts for latest version...
Bean
I had to do some re-structuring.
With this version you need to add "/VP" to the PropBasic compiler options (under Edit->Program Preferences...). This tells the compiler right away that the program is being compile under viewport.
[edit] See later posts for latest version...
You can turn the watches on and off. When off the values are not updated (this generates less code and is quicker).
So you can use "WATCH varname" and "UNWATCH varname". Note that WATCH and UNWATCH are directives and don't actually generate any code, they just affect how code is generated after them.
Here is a small program to demonstrate (view in the "dso" tab).
DEVICE P8X32A, XTAL1, PLL16X FREQ 80_000_000 Background TASK AUTO PROGRAM Start temp1 VAR LONG Start: WATCH temp1 DO FOR temp1=0 to 10 PAUSE 10 NEXT FOR temp1=9 to 1 step -1 PAUSE 10 NEXT LOOP END TASK Background temp2 VAR LONG DO WATCH temp2 FOR temp2=0 to 10 PAUSE 10 NEXT UNWATCH temp2 FOR temp2=9 to 1 step -1 PAUSE 10 NEXT LOOP ENDTASKBean
Thanks Bean and Hanno for the very quick turnaround.
Jim
Marriage? I haven't even met the guy! But he looks quite handsome
Fried- make sure you spell the location of the path exactly right- I tested it in your specified directory and it works for me...
Sapieha- When you press "run", ViewPort first deletes the corresponding .spin file, then compiles the ".pbas" to ".spin" and leaves it in that directory. The file browser is also updated, so if you want you can click on that file and use it- to make changes in spin, or to do line by line debugging with breakpoints...
Bean- I've defaulted the option to "/VP /Q" for the next release- if people have downloaded VP v4.63 already they'll need to add the /VP option themselves.
How about a "watchio(1ms) " directive to include and configure the quicksample object to sample the IO pins at up to 20msps with one cog? It would need to add this:
OBJ 'include 2 ViewPort objects:
qs : "QuickSample" 'samples INA continuously in 1 cog- up to 20Msps
VAR
long frame[400] 'stores measurements of INA port
vp.config(string("lsa:view=io,timescale=TIMESCALE")) 'optional configuration to view "io" in the lsa view and set timescale to passed parameter
vp.register(qs.sampleINA(@frame,1)) 'sample INA into <frame> array with 1 cog- must be called before "vp.share". Can pass 4 to use 4 cogs for 80Msps
Hanno
It's going good, but there is still alot of work yet to be done.
Support VPCONFIG "string" (done 1.16). Must be before the PROGRAM command.
Support modifying variables with "VPUPDATE varname" (Done 1.16).
Problem: Offsets get messed up if you define HUB variables (or DATA or STRINGS) between WATCHed variables. I'm not sure how to fix this just yet.
Support IO monitoring
Support Arrays
Support Video
I'm debating about making a subroutine that updates ALL of theWATCHed variables that will get called whenever ANY of the WATCHed variables are changed. This would make the code slower, but much smaller. And with only 496 instructions, I think size outweighs speed (PropBasic is super fast anyway). This subroutine could be called to manually update Viewport by calling VPREFRESH.
Bean
wrlong watch_var_register,watch_var_hub_ptr
after each statement that changes a watched variable. That saves a ton of space and time!
Have you considered sharing all variables when "/vp" is used?
How about a suffix after the variable declaration that indicates that the variable should be an "editable" variable. Here's a sample program
DEVICE P8X32A, XTAL1, PLL16X FREQ 80_000_000 PROGRAM Start x VAR LONG 'will be written to hub after every instruction that changes it- and will automatically be "watched" by vp y VAR LONG TEXTBOX 'vp will edit this variable with a textbox. before every instruction that uses this variable, it will be read from hub Start: DO FOR x=0 to 10 'after this statement, x will be written to xptr, and y will be read from yptr PAUSE y NEXTI was going to use "WATCH" with no parameters to share all variables.
I like the format you suggested for the editable variables. I'll look into supporting that.
Bean
Good idea to use "watch" to share all variables. VP can edit variables with: dial, scroll, text, slider, multi and switch.
I've updated the template used for "file>new"- the wizard asks you which variables you want to watch and VP generates the code to allocate and watch those vars.
I'd prefer to force users to keep their "watched" variables in one location. VP's Conduit does support sharing multiple areas of HUB- but that's really designed to share different arrays.
Have you seen VP's streaming of graphics? For example, tutorial #27? That example uses Kye's 1byte/pixel format- I support both 6bits RGB and 8bit grayscale- as well as my own 4bit/pixel formats for higher resolution. The streamed video is shown inside of VP and can be fed through OpenCV for computer vision analysis...
Hanno
Hanno,
THANK YOU SO MUCH for this tidbit of knowledge. When I was first writing PropBasic I wanted to support the Parallax Propeller tool (which doesn't have @@@) so I calculated all hub offsets from PAR. But you just reminded me that I can just set a variable to the @@@ hub address and do it with only 1 instruction (instead of 2 or 3) and I don't have to worry about keeping track of offset either.
[in my best Yoda voice] Much work to be done there is...
Bean
WATCH does not support Hub vars, is that right?
Fried
No not yet. It's going to be tricky because Viewport requires all the WATCHed variables to be continuous in HUB memory (except arrays). Is that right Hanno ?
Maybe it will work as an array of 1 element ?
Bean
Hanno, Does viewport support arrays of bytes and words ? Or just longs ?
How can I WATCH text strings (stored in HUB ram) ?
Bean
Lots of work there is- overcome it we shall.
Any way you can force the watched variables to be allocated next to hub vars? Then they would be contiguous.
As a last option- Conduit is capable of streaming multiple arrays- even "vp.share" just tells Conduit to share that memory section. So yes, it's possible for me to assign an array type to a second "vp.share"- but I haven't set up the rest of ViewPort for that- would mean quite a few somewhat risky changes...
See tutorial #0 for how to share a string- basically you're still sharing an array of longs, but VP treats it as a null terminated string- here's relevant configuration code:
vp.config(string("var:a,b,str(string=20),c"))
VP just supports array of longs. It also supports "files"- allowing up and downloading of unlimited length "arrays"- I'm using that to build an open protocol analyzer right now. See tutorials 24..26 for examples.
Hanno
Here is the latest version. Lots of changes in here..
I have a couple questions...
1) When there is a FILE "filename" in the spin file, Viewport tries to load the file from c:\program files\ instead of the directory that the spin file is in.
2) Is there any way you can have an option to just load the code without debugging with viewport ? In other words, It would be nice to use viewport to debug the code and then be able to just load the code without the viewport objects. I thought there were two options "RUN" and "DEBUG", but RUN still gives an error if the viewport object is not running. It would be nice if "RUN" called the compiler WITHOUT the "/vp" switch, and "DEBUG" would call the compiler WITH the "/vp" switch.
[Edit] See later posts for latest version...
Bean
Good stuff- what's new?
I'll make sure to set the "working directory" to the source's directory when calling PropBasic.
Yes, I've been meaning to add the ability to load code without ViewPort support- only thing stopping me is how to keep ViewPort simple for new users.
There are quite a few option when you want to "run" your program:
- load to eeprom or RAM?
- add ViewPort support to monitor/change variables and start the "connect" process?
- add traditional debugging support (breakpoints, line by line stepping) and start debugging?
Currently there are two buttons on the "code" view:
"Run"=Load with ViewPort support then connect
"Debug"=Load with Viewport and Debug support then start debugging
How about I add a third button so you can:
"Load"=Load program without ViewPort or Debug support
"Run"=Load with ViewPort support then connect
"Debug"=Load with Viewport and Debug support then start debugging
I think the "Run" menu should provide another means to "load" and "run"- with keyboard shortcut- as well as loading into eeprom.
-Load to RAM
-Load to EEPROM
-Load to RAM with ViewPort support then connect
-Load to EEPROM with ViewPort support then connect
I'm happy with the "Debug" menu, it let's you "start a debugging session" (load to ram with viewport and debug support) as well as letting you "pause", "step" code. If someone really wanted it, I could add an entry to "Load with Debug support into EEPROM"
People use ViewPort as a user interface for their projects- when they press "Run" they want code loaded to the Prop and ViewPort to provide the interface. For traditional breakpoint/line by line debugging they press "Debug". I would rather not merge those two concepts...
Hanno
What's new ? All HUB access is through COG variables set to @@@hub instead of offsets from "par".
"Load RAM" and "Load EEPROM" give an error if I remove the "/vp" switch. "Unable to load and connect PropBasic."
The "LOAD" button (and "Load RAM", "Load EEPROM" menu items too) should call the compiler WITHOUT the /vp switch.
"Run" and "Debug" should call the compier WITH the /vp switch.
This is just my way of thinking. I don't want to impose my will on you.
Bean
I didn't up the rev so it is still rev 1.16 but is dated Sept 27, 2011.
Bean
I'm having trouble supporting strings.
I found that using str(string=20) doesn't work. By looking at the configuration dialog it appears that I need to use str(base=-1) but that only shows the first 4 characters. I tried using str(base=-1,string=20) but that only showed the first 4 characters too.
P.S. I got LONG arrays working fine.
Message BYTE "Hello There.",0[8] VP_Watch LONG 0[1] PUB vp_config vp.config(STRING("var:Message(base=-1),temp")) vp.array(@Message,20,5) vp.share(@VP_Watch,@VP_Watch+0)I know Message is defined as a byte array, but it IS long aligned.I think the problem is that I need to use an ARRAY as a string. I can't put the strings in with the numeric "share" range.
Bean