Hi Bean,
Nice job on using the @@@ operator and writing "register" values to hub when they're changed. Yes, "load" will call propbasic without the "/vp" option- hopefully later today. I'll also check up on strings. Good job with the array.
Hanno
Hi Bean,
Sharing strings works well- try this out:
CON
_clkmode = xtal1 + pll16x
_clkfreq = 80_000_000
OBJ 'include 2 ViewPort objects:
vp : "Conduit" 'transfers data to/from PC
VAR
long a,s[5],b 'vars shared with ViewPort
PUB main
vp.config(string("var:a,s(string=20),b"))
'channel "s" is a string length 20 bytes
vp.share(@a,@b) 'share from a..b
b:=10
repeat
repeat a from 0 to b
case a // 3
0:bytemove(@s,@one,7)
1:bytemove(@s,@two,10)
2:bytemove(@s,@three,10)
waitcnt(cnt+clkfreq/2)
dat
one byte "hi one",0
two byte "hello two",0
three byte "bye three",0
You do need to allocate the same number of bytes to the string as you configure with the "vp.config" line. In my case I allocated 5 longs=20 bytes. You also need to copy null terminated strings into the string buffer you're sharing with VP- in my case I use "bytemove"...
Hanno
Hi,
ViewPort v4.64 is here: http://hannoware.com/viewport/viewport464.exe
+when compiling .pbas files, working directory is set to directory of source pbas file
+load button on "code" view loads spin code without connecting; compiles pbas code without "/vp" option and doesn't connect
+run menu has new entries to load to ram/eeprom with viewport support and connect
+channel editor does better job of configuring strings
Enjoy!
Hanno
Hanno,
Ok, I get it. The strings MUST be within the vp.share() range and CANNOT be used as a vp.array().
I'll work on this and post something later today.
Thanks for all your work on supporting PropBasic.
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
PROGRAM Start
temp VAR LONG
temp2 VAR LONG
Hub1 HUB LONG(100)
Hub2 HUB LONG(100)
Mess HUB String(20)
watch temp
watch Hub1
watch Hub2
watch Mess
Start:
DO
Mess = "Forward"
FOR temp = 0 to 99
WRLONG Hub1(temp), temp
temp2 = temp & 15
WRLONG Hub2(temp), temp2
PAUSE 10
NEXT
Mess = "Backward"
FOR temp = 99 TO 0 STEP -1
WRLONG Hub2(temp), temp
temp2 = temp & 15
WRLONG Hub1(temp), temp2
PAUSE 10
NEXT
LOOP
END
Still todo:
Only LET and FOR...NEXT update watch values (need to modify all other commands that update variables)
Allow to watch IO pins (at least with MonitorINA)
I'd like to take a moment to say how impressed I am at how close and quickly Bean and Hanno are working to extend the functionality of propbasic and viewport so that the two will work together! This type of cooperation is rare and refreshing to see.
While I have to admit to not currently using either propbasic or viewport currently. They're both on my list of things to get and learn how to use over the next month or so though. A big part of why I'm interested in both is the level of cooperation between Bean and Hanno!
As one of the ViewPort LAS beta testers, your comments are right on. Hanno is one of 'our' good guys to work with. And there are many others, as you will discover. The Propeller has attracted a large number of co-operative fellows, and gals, who work together quite well. That makes this one great forum.
Oops, found a minor bug. The IO view shows 1 extra bit for a PIN variable.
If you define "LEDs PIN 16..23" then "WATCH LEDs" the lsa view will show pins 16 through 24 (should be 23).
I have fixed it already, but I'll wait to post a new version to see if there are any other fixes needed.
As one of the ViewPort LAS beta testers, your comments are right on. Hanno is one of 'our' good guys to work with. And there are many others, as you will discover. The Propeller has attracted a large number of co-operative fellows, and gals, who work together quite well. That makes this one great forum.
I have noticed that this forum is full of very helpful people! I only got the prop education kit to learn about what the propeller can and can't do as well as learn how to work with it. While it's taking some time to get used to and at times I struggle with the different paradigm of use then the microcontrollers (68hc11, 68hc12 and 68hc16) that I've used in the past. The people on the forum have been very patient with my struggles. So far I really like the propeller and can see using it for various projects for years to come.
Wow Bean- this is looking great!
I love how this is coming along. All the speed of PropBasic, simple BASIC syntax, and no complex configuration strings- it just works!
Great job demoing how to share strings, arrays, IO state, and variables.
I really like how you supported the individual bits for IO monitoring.
What determines the order of the watched items? I was surprised that hub2 showed up before hub1 in the spin code.
I like how easy it is to watch the arrays plotted in real time. I still need to work on plotting the contents of the array across the graph's width.
Now that pbasic variable values are in ViewPort you can access them easily from other applications (labview, .net, python,...) using DDE. For example, type one of these into an Open Office Calc cell:
What determines the order of the watched items? I was surprised that hub2 showed up before hub1 in the spin code.
I'll have to fix that. I had everything in one string, and arrays HAD to come first. So I added them to the beginning of the string (putting them in reverse order). But now arrays are in a seperate string, so I should be able to make the order correct.
Have you seen Tubular's use of ViewPort streaming color video?
Hanno
Yeah, that looks really good. I want to support video so I guess that is the recommended driver ?
Sometime in the future I'd like to change PropBasic so that it doesn't use arrays in COG ram (they require self-modifying code). And support arrays in HUB ram. Right now arrays in HUB ram can only be accessed using RDxxxx and WRxxxx.
This version fixes the order of arrays.
Enhanced WATCH and UNWATCH:
- Can specify multiple names (seperated by a comma)
- Can specify NO parameters meaning ALL variables
- Can specify a viewport modifier with WATCH (see example)
' Program to show speed difference when a variable is WATCHed (450 mSec) and UNWATCHed (150 mSec)
' Also shows WATCH modifiers
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
PROGRAM Start
temp VAR LONG
time1 VAR LONG
time2 VAR LONG
watch temp "base=16",time1 "unit= mSec",time2 "unit= mSec"
Start:
time1=cnt
FOR temp=1 to 1_000_000
NEXT
time1=cnt - time1
time1 = time1 / 80_000 ' Convert to milliSeconds
unwatch temp
time2=cnt
FOR temp=1 to 1_000_000
NEXT
time2=cnt - time2
time2 = time2 / 80_000 ' Convert to milliseconds
END
OOPS !!! Found a major bug in the multiply routine. I think I have it fixed now...
If you have a previous version...Please update to this version.
Also implemented Viewport Video support.
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
vidBuffer HUB BYTE(19200)
PROGRAM Start
Plot SUB 3 ' X, Y, Color(0-63)
x VAR LONG
y VAR LONG
temp VAR LONG
color VAR LONG
WATCH temp,y,x
Start:
VPVideo vidBuffer
DO
FOR temp=0 to 255
FOR y=0 to 119
FOR x=0 to 159
color = x ^ y ' Make a pretty pattern
color = color ^ temp ' Make a pretty pattern
Plot x, y, color
NEXT
NEXT
PAUSE 500
NEXT
LOOP
END
SUB Plot ' X, Y, Color
__param2 = __param2 * 160
__param1 = __param1 + __param2
WRBYTE vidBuffer(__param1), __param3
ENDSUB
Okay, another update. I added the VPWait that waits for Viewport to update. You can also give an optional value that will add a delay before the next update (to give your program time to update).
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
vidBuffer HUB BYTE(19200)
PROGRAM Start
Plot SUB 3 ' X, Y, Color(0-63)
x VAR LONG
y VAR LONG
color VAR LONG
temp VAR LONG
WATCH temp
Start:
VPVideo vidBuffer
DO
FOR temp=0 to 255
FOR y=0 to 119
FOR x=0 to 159
color = x ^ y
color = color + temp
Plot x, y, color
NEXT
NEXT
VPWait
NEXT
LOOP
END
SUB Plot ' X, Y, Color
__param2 = __param2 * 160
__param1 = __param1 + __param2
__param3 = __param3 shl 2
WRBYTE vidBuffer(__param1), __param3
ENDSUB
Bean,
It's hard to keep up with you! Awesome job getting video to work- I love how simple your graphics program is. Very easy to understand.
ViewPort has a slew of interesting features that could one day make it to PropBasic: fuzzy logic, terminal IO, up/downloading of large files, etc. However, I think changing variables from VP should be next. It's very useful when you're tweaking programs, calibrating sensors/actuators, using the Prop as a device with a VP GUI front end, etc...
Your generated code should "rdlong" from a pointer into hub before "editable" variables are used. Spin variables can be monitored and changed just by "vp.share"ing them. For PropBasic it may make sense to use ViewPort's "control channel"- so that "editable" variables can only be edited- not watched. They just need to be allocated right after the last "watched" variable- and named in the "var" config string.
Hanno
Okay, I have implemented edit-able variable. But I had to "cheat". Variables are read at way too many places in the compiler to change the code without ALOT of work.
So I made a command "UPDATE varname" that will read a variable value from viewport. One good thing is that a variable's value can only change at one point, instead of anywhere (which might cause problems).
Here is a demo program
' For PropBasice 1.22 in Viewport
'
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
PROGRAM Start
temp VAR LONG
limit VAR LONG
WATCH temp,limit "min=50,max=500"
Start:
limit = 100
VPConfig "dso:view=temp,timescale=10ms,trigger=temp>25"
VPConfig "edit:limit(mode=dial,default=100)"
DO
UPDATE limit
FOR temp=0 TO limit
VPWait
NEXT
LOOP
END
Kevin,
I just tried it and I forgot to make VPWait compatible with LMM. So I fixed that.
WATCH seems to work fine now with LMM both in the main code and in the TASK.
Bean,
Awesome getting "editable" variables to work. I'm fine with your "update" command- may make it less confusing for novice programmers. I didn't even know you had a LMM version/option- how does that work? I now have ViewPort running on OSX and Linux- how does PropBasic fit there? What language is PropBasic written in?
Hanno
Hanno,
To make program LMM simply add "LMM" to the PROGRAM command.
PROGRAM Start LMM
Each TASK (tasks run in other cogs) can be either native (default) or LMM by adding LMM to the "TASK taskname" line (not the "taskname TASK" that is declared at the top of the program).
PropBasic is written in Delphi 7. Can also be compiled with Lazarus (I think that is what BradC used for BST). I can provide you with the source if you need/want it to integrate PropBasic with Viewport.
@Bean
I think there is a bug in the newer version of PropBasic concerning strings:
The following code used to work fine (I don't remember what the PropBasic version was):
' ----------------------------------------------------------------------
' File...... FloatTest.pbas
' Author.... fgvissel 02.10.2011
' ======================================================================
' ----- Device Settings ------------------------------------------------
DEVICE P8X32A, XTAL1, PLL16X
XIN 6_250_000
' ----- Conditional Compilation Symbols --------------------------------
' ----- Constants ------------------------------------------------------
LCD_baud CON "T115200"
' ----- IO Pins --------------------------------------------------------
LCD_tx Pin 1 High 'idle State High
LCD_rx Pin 2 Input
' ----- Shared (HUB) Variables (Byte, Word, Long) ----------------------
' ----- User Data (DATA, WDATA, LDATA, FILE) ---------------------------
' ----- TASK Definitions -----------------------------------------------
' ----- Local Variables (LONG only) ------------------------------------
' ----- SUB and FUNC Definitions ---------------------------------------
LCD_Print SUB 1
sout SUB 1
' ======================================================================
PROGRAM Start
Start:
' setup code
Main:
LCD_Print "AAAAA"
do 'FOREVER
loop
END
' ----- SUB and FUNC Code ----------------------------------------------
SUB LCD_Print
LCD_DC1 CON $11
LCD_ACK CON $06
LCD_i VAR LONG
LCD_bcc VAR LONG
LCD_length VAR LONG
LCD_char VAR LONG
LCD_stradr VAR LONG
LCD_result VAR LONG
sout LCD_DC1
LCD_bcc = LCD_DC1
LCD_length = LEN __STRING(__param1)
sout LCD_length
LCD_bcc = LCD_bcc + LCD_length
LCD_length = LCD_length - 1
for LCD_i = 0 to LCD_length
LCD_stradr = __param1 + LCD_i
RDBYTE LCD_stradr, LCD_char
sout LCD_char
LCD_bcc = LCD_bcc + LCD_char
next
sout LCD_bcc
serin LCD_rx,LCD_Baud, LCD_result
ENDSUB
SUB sout
serout LCD_tx, LCD_Baud, __param1
ENDSUB
' ----- TASK Code ------------------------------------------------------
' ----------------------------------------------------------------------
but now the output is $11,$02,$F5,$FC,$04.
I think the string pointer must be wrong, because the protokoll frame is allright.
Cheers, Fried
What I do for subroutines that call other subroutines is to use the high __paramx variables.
Something like:
SUB LCD_Print
LCD_DC1 CON $11
LCD_ACK CON $06
LCD_i VAR LONG
LCD_bcc VAR LONG
LCD_length VAR LONG
LCD_char VAR LONG
LCD_stradr VAR LONG
LCD_result VAR LONG
__param2 = __param1 ' Save __param1
sout LCD_DC1
LCD_bcc = LCD_DC1
LCD_length = LEN __STRING(__param2) ' NOTE __param2
sout LCD_length
LCD_bcc = LCD_bcc + LCD_length
LCD_length = LCD_length - 1
for LCD_i = 0 to LCD_length
LCD_stradr = __param2 + LCD_i ' NOTE __param2
RDBYTE LCD_stradr, LCD_char
sout LCD_char
LCD_bcc = LCD_bcc + LCD_char
next
sout LCD_bcc
serin LCD_rx,LCD_Baud, LCD_result
ENDSUB
Thanks Bean, good idea!
Another point I have with strings:
"AB" is a string and will be compiled as such (inline string). But "A" compiles as a single character.
So in a SUB len __string(__param1) will of course not work.
Perhaps "A" should be compiled as $41,$00 (string) and 'A' as $41 ?
Another point on my personal wishlist for PropBasic would be a CASE statement like in spin or C.
BRANCH and On .. GOTO are not quite the same.
Fried
Comments
Nice job on using the @@@ operator and writing "register" values to hub when they're changed. Yes, "load" will call propbasic without the "/vp" option- hopefully later today. I'll also check up on strings. Good job with the array.
Hanno
Here is a demo program and the generated .spin file. You'll see the Viewport configuration is now at the very end of the .spin file.
Bean
Sharing strings works well- try this out:
You do need to allocate the same number of bytes to the string as you configure with the "vp.config" line. In my case I allocated 5 longs=20 bytes. You also need to copy null terminated strings into the string buffer you're sharing with VP- in my case I use "bytemove"...
Hanno
ViewPort v4.64 is here:
http://hannoware.com/viewport/viewport464.exe
+when compiling .pbas files, working directory is set to directory of source pbas file
+load button on "code" view loads spin code without connecting; compiles pbas code without "/vp" option and doesn't connect
+run menu has new entries to load to ram/eeprom with viewport support and connect
+channel editor does better job of configuring strings
Enjoy!
Hanno
Ok, I get it. The strings MUST be within the vp.share() range and CANNOT be used as a vp.array().
I'll work on this and post something later today.
Thanks for all your work on supporting PropBasic.
Bean
Here is the compiler, and a demo program.
Still todo:
Only LET and FOR...NEXT update watch values (need to modify all other commands that update variables)
Allow to watch IO pins (at least with MonitorINA)
Bean
While I have to admit to not currently using either propbasic or viewport currently. They're both on my list of things to get and learn how to use over the next month or so though. A big part of why I'm interested in both is the level of cooperation between Bean and Hanno!
This version implements IO watching.
By default a variable "IO" shows all the pin states.
If you WATCH a pin variable as in: Then IO will show the pin variable states. You may watch more than on PIN variable also.
Typically you will use the "lsa" to view the IO pin states.
This uses the rather slow "MonitorINA" method that does not require an additional cog. I'll try to work in the fast IO logger later.
P.S. I also fixed all commands the modify variables to update the WATCH values.
Bean
As one of the ViewPort LAS beta testers, your comments are right on. Hanno is one of 'our' good guys to work with. And there are many others, as you will discover. The Propeller has attracted a large number of co-operative fellows, and gals, who work together quite well. That makes this one great forum.
If you define "LEDs PIN 16..23" then "WATCH LEDs" the lsa view will show pins 16 through 24 (should be 23).
I have fixed it already, but I'll wait to post a new version to see if there are any other fixes needed.
Bean
I have noticed that this forum is full of very helpful people! I only got the prop education kit to learn about what the propeller can and can't do as well as learn how to work with it. While it's taking some time to get used to and at times I struggle with the different paradigm of use then the microcontrollers (68hc11, 68hc12 and 68hc16) that I've used in the past. The people on the forum have been very patient with my struggles. So far I really like the propeller and can see using it for various projects for years to come.
I love how this is coming along. All the speed of PropBasic, simple BASIC syntax, and no complex configuration strings- it just works!
Great job demoing how to share strings, arrays, IO state, and variables.
I really like how you supported the individual bits for IO monitoring.
What determines the order of the watched items? I was surprised that hub2 showed up before hub1 in the spin code.
I like how easy it is to watch the arrays plotted in real time. I still need to work on plotting the contents of the array across the graph's width.
Now that pbasic variable values are in ViewPort you can access them easily from other applications (labview, .net, python,...) using DDE. For example, type one of these into an Open Office Calc cell:
Have you seen Tubular's use of ViewPort streaming color video?
See here:
http://forums.parallax.com/showthread.php?134793-Browser-s-Math-Puzzle/page2
Thanks Harley and 4x5n for your support- I'm having a blast!
Hanno
I'll have to fix that. I had everything in one string, and arrays HAD to come first. So I added them to the beginning of the string (putting them in reverse order). But now arrays are in a seperate string, so I should be able to make the order correct.
Yeah, that looks really good. I want to support video so I guess that is the recommended driver ?
Sometime in the future I'd like to change PropBasic so that it doesn't use arrays in COG ram (they require self-modifying code). And support arrays in HUB ram. Right now arrays in HUB ram can only be accessed using RDxxxx and WRxxxx.
Bean
Enhanced WATCH and UNWATCH:
- Can specify multiple names (seperated by a comma)
- Can specify NO parameters meaning ALL variables
- Can specify a viewport modifier with WATCH (see example)
Bean
If you have a previous version...Please update to this version.
Also implemented Viewport Video support.
Bean
It's hard to keep up with you! Awesome job getting video to work- I love how simple your graphics program is. Very easy to understand.
ViewPort has a slew of interesting features that could one day make it to PropBasic: fuzzy logic, terminal IO, up/downloading of large files, etc. However, I think changing variables from VP should be next. It's very useful when you're tweaking programs, calibrating sensors/actuators, using the Prop as a device with a VP GUI front end, etc...
Your generated code should "rdlong" from a pointer into hub before "editable" variables are used. Spin variables can be monitored and changed just by "vp.share"ing them. For PropBasic it may make sense to use ViewPort's "control channel"- so that "editable" variables can only be edited- not watched. They just need to be allocated right after the last "watched" variable- and named in the "var" config string.
Hanno
Yes, Editable variables will be really useful (like Thomas the tank engine).
I'll explore that next.
Bean
So I made a command "UPDATE varname" that will read a variable value from viewport. One good thing is that a variable's value can only change at one point, instead of anywhere (which might cause problems).
Here is a demo program
Bean
I think I found a bug in your compiler (V1.22)
When I try to add a Task to your example above, it gave me a "Wrong number of arguments (1 instead of 2)" error.
the code generated for the task is...
Oops sorry about that.
See if this fixes it.
Bean
Thanks, that works now.
How about LMM /w Viewport, is that supported yet?
It seem to partially work for me (the code seem to run but the watch does not work)
Thanks,
Kevin
I just tried it and I forgot to make VPWait compatible with LMM. So I fixed that.
WATCH seems to work fine now with LMM both in the main code and in the TASK.
Bean
Awesome getting "editable" variables to work. I'm fine with your "update" command- may make it less confusing for novice programmers. I didn't even know you had a LMM version/option- how does that work? I now have ViewPort running on OSX and Linux- how does PropBasic fit there? What language is PropBasic written in?
Hanno
To make program LMM simply add "LMM" to the PROGRAM command.
Each TASK (tasks run in other cogs) can be either native (default) or LMM by adding LMM to the "TASK taskname" line (not the "taskname TASK" that is declared at the top of the program).
PropBasic is written in Delphi 7. Can also be compiled with Lazarus (I think that is what BradC used for BST). I can provide you with the source if you need/want it to integrate PropBasic with Viewport.
Bean
I think there is a bug in the newer version of PropBasic concerning strings:
The following code used to work fine (I don't remember what the PropBasic version was):
but now the output is $11,$02,$F5,$FC,$04.
I think the string pointer must be wrong, because the protokoll frame is allright.
Cheers, Fried
You can't use __param1 inside the loop.
As soon as you call "sout" the variable __param1 get set to the parameter of the "sout" subroutine.
Bean
sorry about that, Fried
Something like:
Bean
Another point I have with strings:
"AB" is a string and will be compiled as such (inline string). But "A" compiles as a single character.
So in a SUB len __string(__param1) will of course not work.
Perhaps "A" should be compiled as $41,$00 (string) and 'A' as $41 ?
Another point on my personal wishlist for PropBasic would be a CASE statement like in spin or C.
BRANCH and On .. GOTO are not quite the same.
Fried