I admit that I have another problem. I use WAITCNT but have learned, that WAITCNT waits for the given system counter value to EXACTLY MATCH the param.
This leads to problems if your code is such that you MAY arrive at the WAITCNT a few clock cycles "to late" because then the program is blocked 2^32 cycles (until ctr reaches your value again after an overflow)
I did therefore try this:
Led PIN 27 HIGH
delta VAR LONG
target VAR LONG
RDLONG 0, delta ' read system frequency
delta = delta >> 2 ' divide by 4
target = cnt + delta ' sync with system counter
DO
target = cnt + delta ' this is of course not helpful if using WAITCNT :-)
TOGGLE LED ' toggle led on P16
'WAITCNT target, delta ' wait 1/4s (synchronized) - this does work as intended
DO WHILE cnt < target ' this does not work but halt the cog forever. Why ?
LOOP
LOOP
END
The above code works as expected if using WAITCNT but not if I try to wait by using an empty loop until cnt becomes greater than target. Why ?
Wolfgang,
Because "cnt" is signed. So it counts up to it's maximum positive value, then the next clock it becomes it's maximum negative value counts to zero, then start up the positive number again.
You could just use PAUSE 250
or you could do
DO
__param1 = cnt - target
LOOP UNTIL __param1 > 0
Dear all,
sorry for the next question. BUT it also includes an offer..
The question first: I read in an 74lv165 ( shift register) with the prop and did try "SHIFTIN' for this purpose. This is very slow, around 60kBits/sec. Why is this so ?
In the manual, there is a parameter "speed" mentioned for the SHIFTIN and SHIFTOUT commands, but it is not explained what format it is . Bits per second ? Hertz ? Kbits per second ? uSec pulse-duration ?
Right now, I read the register "by hand" - set CLK pin high, read data pin, set clk pin low ... This is way faster than SHIFTIN. Which makes "shiftin" somewhat useless...
And now the Offer:
I learned that Propbasic, albeit beeing version 00.01... is already very usable and very powerful. Unfortunately, the manual is obviously behind the code. Some commands are not explained and often, the really interesting details are not explained or mentioned ( e.g. the whole String handling stuff, the fact that COGSTOP does not accept literal numbers and lots of other small but good-to-know things)
I would offer to extend the manual with those details. Everytime I find out some confusing (for me) thing , I will write it down in the manual.
Maybe this leads to sort of "propbasic for dummies" but in my opinion that is better than an non-complete manual.
Dont get me wrong, I do really appreciate all the effort gone into ProbBasic, BST and the manual. But for beginners (like me) it is really very time-consuming to crawl all the details via searches in this forum.
Anyhow, if you are interested in this offer, let me know. I will write down my findings anyhow, but it would be nice for the community if they would be used to extend the manual.
Wolfgang,
Your comments are very welcome.
I would appreciate your help with a manual for PropBasic.
I suggest we start a blog here so we can communicate without cluttering up the forums.
Let me know and I'll start a blog if you are interested.
P.S. The speed value is a multipiler. So a value of 2 would be twice as fast.
Allows some escape sequences inside strings \r = return; \n = Enter; \\ = backslash; \" = embedded quote; \123 = char(123); \xEA = char($EA)
If you have ANY strings with a backslash in them, you will need to change it to a double backslash.
Added CLKSET mode,freq
Allows more nested loops (raised limit from 127 to 1024)
If a pingroup starts at pin zero, the pasm code no longer contains "shl xxx,#0"
HIGH,LOW,TOGGLE,INPUT,OUTPUT,REVERSE if pin # is a constant < 9 then do shift as literal
I'm a complete newbie to the Prop, and to PropBasic. I have used Basic, though it's probably been 20 years ago, and I'm not familiar with the Stamp or SX/B dialects. I'm extremely impressed by the compiler and the BST environment, however, and it looks perfect for the project I have in mind. I've used C to program the PIC line, though I wouldn't call myself a particularly experienced programmer (I write code only when I have to) and my problem could easily be operator stupidity.
I have BST and PropBasic up and running and am working through the demos. Most have worked fine, but when I tried Serial_to_NTSC.pbas I ran into a problem. I get compile errors, and couldn't quite work through them.
In line 44 I got an "unknown command" error, referring to "TV_SendChar". Looking at TV.lib I found that the command is really TV_Char, and changing the call to that name cleared the error.
In lines 95 and 112 I got "Invalid parameter" errors complaining about two references to "vidmem". Again looking at TV.lib, it appears the array is actually TV_VidMem, and making that change cleared those errors.
Finally, I got similar "invalid parameter" errors in lines 90 and 122 complaining about "Font". The character array in hub RAM in TV.lib is really TV_Font, so I expected when I changed the array reference in Serial_to_NTSC those errors would clear as well, but they didn't. In both cases it's a call to GetAddr, in one case to the base address of the array (i.e. no index specified), and in the other case it's also a call to GetAddr, but offset into the array with the parameter Font(__param1). I think I understand what's supposed to be happening, but I'm a bit confused by the fact that I can't clear the invalid parameter error. Since I never got the code to compile, I really don't know if my "fixes" really fixed anything. Based on what I think the code is doing, I believe they are OK. You know what they say about assumptions, however.
Incidentally, the other demo programs that call TV.lib work fine. I think I have the current versions of everything, downloaded from the link at the beginning of this very long thread.
Any guidance for the rookie would be appreciated. And thanks for the incredible effort and generosity to make the tools available!
Jones,
Yeah sorry about that.
PropBasic is a work in progress and as things get changed sometimes the old demos need some changes too.
You have the right idea...Look at the library file and make the changes needed.
I've been trying to name library files as "xxx_lib.pbas" so you can double-click on them and BST will open.
I just (think) I figured out that the call to "TV_SendChar" that I "corrected" to TV_Char, actually refers to the SendChar subroutine in the source file. That still clears the invalid command error, but I'm still scratching my head over the Font array reference. Maybe I need to scratch harder...
I think the problem with Font is it should be TV_Font also the TV_Font data in TV.lib is incorrectly located in the $CODE section. Move the DATA section starting with
' Define DATA (DATA, WDATA, LDATA) and ending with
DATA $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF ' Block
up above the ' Define Subroutines section.
the line '{$IFUSED TV_Char} should be just above
SUB TV_Char ' character value
Thanks, indeed it did. I hadn't figured out how the compiler directives worked in the .lib file, and assumed (there's that word again) that because the other demos using TV.lib worked that it was OK. So it appears that the font table was being created correctly in hub RAM since the other demos had access to the fonts, it was just that when the source file referred to the TV_Font array the compiler couldn't find it in the .lib file because it was not where it was supposed to be. None of the other demos referred to the font table directly but called functions that could find it so they were OK.
Thanks again for the help. I don't think I would've found that problem no matter how long I stared at it.
I'm finding that the program still doesn't work right, but at least it compiles! For now I think I'll leave it at that and maybe revisit it when I know more.
I have entered into the Spinneret Contest and was thinking about doing the top object file in PropBasic. I have this one question for you. Can, I call variables that are done in Spin so they can be used in the PropBasic program, which is ASM code? The variables I am calling are all "LONG" and were created by an ladder logic program called PICoPLC.
You can read/write spin variables my passing their address to PropBasic.
Here is a simple example:
DEVICE P8X32A,XTAL1,PLL16X
FREQ 80_000_000
ASM
' Spin code goes here
VAR
LONG myVar
PUB Main
myVarAddr := @myVar ' Tell PropBasic "myVar"'s address
myvar := 0
CogInit(1, @__Init, @__DATASTART) ' Start PropBasic code in COG 1
REPEAT
waitcnt(cnt+8000000) ' Wait 100mSec
myVar+=1
' End of spin code
ENDASM
PROGRAM Start
myVarAddr HUB LONG
ascii HUB STRING(20)
temp VAR LONG
Start:
RDLONG myVarAddr, temp ' temp=address of "myVar"
DO
RDLONG temp,__param1 ' get value of "myVar"
' Convert value to ascii and output to PST
ascii = STR __param1, 10, 3
ascii = ascii + 13
SEROUT 30, T115200, ascii
LOOP
END
I found a problem with Propbasic SHIFTIN modes which use the rev instruction: rev is done for the same number of Bits as shifted in, but it should actually be for 32 minus the number of Bits shifted in. I attach screen snips to illustrate. I tested with versions 1.04 and 1.08.
Good guess. So, is this the only way to move variables from spin file (non ASM) into PropBasic program? My goal was to make my spin file an Task, because my spin file (non ASM) runs in it's own cog with Start and Stop methods. Below is what I am kind of talking about.
{ This is auto-generated code from PICoPLC. Do not edit this file! Go
back to the ladder diagram source for changes in the logic, and compile }
CON
_CLKFREQ = 4000000 'Hz
_CLKMODE = XTAL1 + PLL16X
CycleTime = 100 '1/sec
var
BYTE I_mcr
var
BYTE I_rung_top
con
U_Yclock = 1
var
WORD U_Tpulse
var
BYTE I_parOut_0000
var
BYTE I_parThis_0000
var
BYTE I_oneShot_0000
var
WORD U_Cshift
var
WORD I_scratch2
var
WORD U_buttons
con
U_Xdata = 0
VAR
LONG stack[100]
LONG cog
PUB Start
cog := cognew(PlcCycle, @stack) +1
PUB Stop
if (cog)
cogstop(cog~ - 1)
cog~
PRI PlcCycle | timing
DIRA := $00000002
DIRB := $00000000
timing := cnt + clkfreq / CycleTime
repeat
I_mcr~~
{ start rung 2 }
I_rung_top := I_mcr
{ start series [ }
{ Negated contact }
if (OUTA[U_Yclock])
I_rung_top~
{ TON element }
if (I_rung_top)
if (U_Tpulse < 9)
U_Tpulse++
I_rung_top~
else
U_Tpulse := 0
{ start parallel [ }
I_parOut_0000~
I_parThis_0000 := I_rung_top
{ Normal coil }
OUTA[U_Yclock] := I_parThis_0000
if (I_parThis_0000)
I_parOut_0000~~
I_parThis_0000 := I_rung_top
{ CTC element }
if (I_parThis_0000)
ifnot (I_oneShot_0000)
U_Cshift++
if (U_Cshift < 9)
else
U_Cshift := 0
I_oneShot_0000 := I_parThis_0000
if (I_parThis_0000)
I_parOut_0000~~
I_rung_top := I_parOut_0000
{ ] finish parallel }
{ ] finish series }
{ start rung 3 }
I_rung_top := I_mcr
{ start series [ }
I_scratch2 := 0
{ EQU element }
if (U_Cshift == I_scratch2)
else
I_rung_top~
{ MOVE element }
if (I_rung_top)
U_buttons := 0
{ ] finish series }
{ start rung 4 }
I_rung_top := I_mcr
{ start series [ }
I_scratch2 := 1
{ EQU element }
if (U_Cshift == I_scratch2)
else
I_rung_top~
{ Contact }
ifnot (INA[U_Xdata])
I_rung_top~
{ MOVE element }
if (I_rung_top)
U_buttons := 1
{ ] finish series }
{ start rung 5 }
I_rung_top := I_mcr
{ start series [ }
I_scratch2 := 2
{ EQU element }
if (U_Cshift == I_scratch2)
else
I_rung_top~
{ Contact }
ifnot (INA[U_Xdata])
I_rung_top~
{ MOVE element }
if (I_rung_top)
U_buttons := 2
{ ] finish series }
{ start rung 6 }
I_rung_top := I_mcr
{ start series [ }
I_scratch2 := 3
{ EQU element }
if (U_Cshift == I_scratch2)
else
I_rung_top~
{ Contact }
ifnot (INA[U_Xdata])
I_rung_top~
{ MOVE element }
if (I_rung_top)
U_buttons := 4
{ ] finish series }
{ start rung 7 }
I_rung_top := I_mcr
{ start series [ }
I_scratch2 := 4
{ EQU element }
if (U_Cshift == I_scratch2)
else
I_rung_top~
{ Contact }
ifnot (INA[U_Xdata])
I_rung_top~
{ MOVE element }
if (I_rung_top)
U_buttons := 16
{ ] finish series }
{ start rung 8 }
I_rung_top := I_mcr
{ start series [ }
I_scratch2 := 5
{ EQU element }
if (U_Cshift == I_scratch2)
else
I_rung_top~
{ Contact }
ifnot (INA[U_Xdata])
I_rung_top~
{ MOVE element }
if (I_rung_top)
U_buttons := 32
{ ] finish series }
{ start rung 9 }
I_rung_top := I_mcr
{ start series [ }
I_scratch2 := 6
{ EQU element }
if (U_Cshift == I_scratch2)
else
I_rung_top~
{ Contact }
ifnot (INA[U_Xdata])
I_rung_top~
{ MOVE element }
if (I_rung_top)
U_buttons := 64
{ ] finish series }
{ start rung 10 }
I_rung_top := I_mcr
{ start series [ }
I_scratch2 := 7
{ EQU element }
if (U_Cshift == I_scratch2)
else
I_rung_top~
{ Contact }
ifnot (INA[U_Xdata])
I_rung_top~
{ MOVE element }
if (I_rung_top)
U_buttons := 128
{ ] finish series }
{ start rung 11 }
I_rung_top := I_mcr
{ start series [ }
I_scratch2 := 8
{ EQU element }
if (U_Cshift == I_scratch2)
else
I_rung_top~
{ Contact }
ifnot (INA[U_Xdata])
I_rung_top~
{ MOVE element }
if (I_rung_top)
U_buttons := 256
{ ] finish series }
waitcnt(timing)
timing += clkfreq / CycleTime
Andre, Yes you are right. I will correct that in the next release.
Bean
Hi Bean,
Cool, thanks. In the mean time the work-around is fortunately very simple.
Just one other thing: Is there a way around Propellent's problem with Propbasic LMM? Especially in version 00.01.08 which uses @@@? BST and BSTC work perfectly fine, though.
I am afraid I have discovered another bug in Ver. 00.01.08: When using variables for the SDA and SCL Pins, the I2C_Start routine uses the SDA variable for SCL (__temp2) as well, instead of using the SCL variable.
I am systematically re-writing all my PBASIC code in PropBasic, so I have a suspicion that you will hear from me often.
I am also creating Libraries for often-used code and right now I am trying to create a library for SHIFTIN and SHIFTOUT routines using Variables for the Data and Clock Pins, but it does not work because the Data Pin Variable is also used for the Clock Pin. Is this a bug or have you perhaps not yet enabled this functionality?
I am really sorry for doing this to you, but I have found another problem. When using command "ON var GOSUB label1, label2 [, label3, [, etc]]", BST generates the following error: "Compiler crashed with run time error: 217 : Unhandled Exception". Propellent generates the following error: "Line (nnn) Undefined Symbol. mov dira, __InitDirA"
These commands work fine,though:
ON var = value1, value2, value3 GOSUB label1, label2, label3
ON var GOTO label1, label2 [, label3, [, etc]]
ON var = value1, value2, value3 GOTO label1, label2, label3
Andre,
Okay, you are now the OFFICAL PropBasic tester...
Yeah, I had a variable that was never initialized in there, it worked in the development environment because it was set to zero, but was a random value in the real-world.
I fixed it, but I'm still waiting to hear from BradC... Hopefully the fix will be in the next release.
Firstly I must say that I am absolutely thrilled by the fact that it is possible to alias VAR arrays! Thanks!
Aliasing a HUB variable or array generates a syntax error, though.
As for pre-initializing arrays, I found that this works: "myVar HUB LONG(4) = 0".
But this generates a syntax error: "myVar VAR LONG(4) = 0". Admittedly, the Syntax Guide Ver. 00.01.04 does not specifically state that it is possible to pre-initilize a VAR array.
Should this stop the code currently running in cog0, then start the new task code in cog0 (ie. restart the new cog/task over itself)
OR - should this not work like that ?
Comments
I admit that I have another problem. I use WAITCNT but have learned, that WAITCNT waits for the given system counter value to EXACTLY MATCH the param.
This leads to problems if your code is such that you MAY arrive at the WAITCNT a few clock cycles "to late" because then the program is blocked 2^32 cycles (until ctr reaches your value again after an overflow)
I did therefore try this:
Led PIN 27 HIGH delta VAR LONG target VAR LONG RDLONG 0, delta ' read system frequency delta = delta >> 2 ' divide by 4 target = cnt + delta ' sync with system counter DO target = cnt + delta ' this is of course not helpful if using WAITCNT :-) TOGGLE LED ' toggle led on P16 'WAITCNT target, delta ' wait 1/4s (synchronized) - this does work as intended DO WHILE cnt < target ' this does not work but halt the cog forever. Why ? LOOP LOOP ENDThe above code works as expected if using WAITCNT but not if I try to wait by using an empty loop until cnt becomes greater than target. Why ?
Because "cnt" is signed. So it counts up to it's maximum positive value, then the next clock it becomes it's maximum negative value counts to zero, then start up the positive number again.
You could just use PAUSE 250
or you could do
DO __param1 = cnt - target LOOP UNTIL __param1 > 0Bean
sorry for the next question. BUT it also includes an offer..
The question first: I read in an 74lv165 ( shift register) with the prop and did try "SHIFTIN' for this purpose. This is very slow, around 60kBits/sec. Why is this so ?
In the manual, there is a parameter "speed" mentioned for the SHIFTIN and SHIFTOUT commands, but it is not explained what format it is . Bits per second ? Hertz ? Kbits per second ? uSec pulse-duration ?
Right now, I read the register "by hand" - set CLK pin high, read data pin, set clk pin low ... This is way faster than SHIFTIN. Which makes "shiftin" somewhat useless...
And now the Offer:
I learned that Propbasic, albeit beeing version 00.01... is already very usable and very powerful. Unfortunately, the manual is obviously behind the code. Some commands are not explained and often, the really interesting details are not explained or mentioned ( e.g. the whole String handling stuff, the fact that COGSTOP does not accept literal numbers and lots of other small but good-to-know things)
I would offer to extend the manual with those details. Everytime I find out some confusing (for me) thing , I will write it down in the manual.
Maybe this leads to sort of "propbasic for dummies" but in my opinion that is better than an non-complete manual.
Dont get me wrong, I do really appreciate all the effort gone into ProbBasic, BST and the manual. But for beginners (like me) it is really very time-consuming to crawl all the details via searches in this forum.
Anyhow, if you are interested in this offer, let me know. I will write down my findings anyhow, but it would be nice for the community if they would be used to extend the manual.
With best regards,
Wolfgang
Your comments are very welcome.
I would appreciate your help with a manual for PropBasic.
I suggest we start a blog here so we can communicate without cluttering up the forums.
Let me know and I'll start a blog if you are interested.
P.S. The speed value is a multipiler. So a value of 2 would be twice as fast.
Bean
Changes are:
Allows some escape sequences inside strings \r = return; \n = Enter; \\ = backslash; \" = embedded quote; \123 = char(123); \xEA = char($EA)
If you have ANY strings with a backslash in them, you will need to change it to a double backslash.
Added CLKSET mode,freq
Allows more nested loops (raised limit from 127 to 1024)
If a pingroup starts at pin zero, the pasm code no longer contains "shl xxx,#0"
HIGH,LOW,TOGGLE,INPUT,OUTPUT,REVERSE if pin # is a constant < 9 then do shift as literal
Allow I2C pins to be variables
Changed LMM to use @@@ this makes jumps faster
Bean
I have BST and PropBasic up and running and am working through the demos. Most have worked fine, but when I tried Serial_to_NTSC.pbas I ran into a problem. I get compile errors, and couldn't quite work through them.
In line 44 I got an "unknown command" error, referring to "TV_SendChar". Looking at TV.lib I found that the command is really TV_Char, and changing the call to that name cleared the error.
In lines 95 and 112 I got "Invalid parameter" errors complaining about two references to "vidmem". Again looking at TV.lib, it appears the array is actually TV_VidMem, and making that change cleared those errors.
Finally, I got similar "invalid parameter" errors in lines 90 and 122 complaining about "Font". The character array in hub RAM in TV.lib is really TV_Font, so I expected when I changed the array reference in Serial_to_NTSC those errors would clear as well, but they didn't. In both cases it's a call to GetAddr, in one case to the base address of the array (i.e. no index specified), and in the other case it's also a call to GetAddr, but offset into the array with the parameter Font(__param1). I think I understand what's supposed to be happening, but I'm a bit confused by the fact that I can't clear the invalid parameter error. Since I never got the code to compile, I really don't know if my "fixes" really fixed anything. Based on what I think the code is doing, I believe they are OK. You know what they say about assumptions, however.
Incidentally, the other demo programs that call TV.lib work fine. I think I have the current versions of everything, downloaded from the link at the beginning of this very long thread.
Any guidance for the rookie would be appreciated. And thanks for the incredible effort and generosity to make the tools available!
Bob
Yeah sorry about that.
PropBasic is a work in progress and as things get changed sometimes the old demos need some changes too.
You have the right idea...Look at the library file and make the changes needed.
I've been trying to name library files as "xxx_lib.pbas" so you can double-click on them and BST will open.
Bean
Bob
I think the problem with Font is it should be TV_Font also the TV_Font data in TV.lib is incorrectly located in the $CODE section. Move the DATA section starting with
' Define DATA (DATA, WDATA, LDATA) and ending with
DATA $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF ' Block
up above the ' Define Subroutines section.
the line '{$IFUSED TV_Char} should be just above
SUB TV_Char ' character value
This will clear the errors on lines 90 and 122.
regards
Gerry
Thanks, indeed it did. I hadn't figured out how the compiler directives worked in the .lib file, and assumed (there's that word again) that because the other demos using TV.lib worked that it was OK. So it appears that the font table was being created correctly in hub RAM since the other demos had access to the fonts, it was just that when the source file referred to the TV_Font array the compiler couldn't find it in the .lib file because it was not where it was supposed to be. None of the other demos referred to the font table directly but called functions that could find it so they were OK.
Thanks again for the help. I don't think I would've found that problem no matter how long I stared at it.
I'm finding that the program still doesn't work right, but at least it compiles! For now I think I'll leave it at that and maybe revisit it when I know more.
Cheers
Bob
I have entered into the Spinneret Contest and was thinking about doing the top object file in PropBasic. I have this one question for you. Can, I call variables that are done in Spin so they can be used in the PropBasic program, which is ASM code? The variables I am calling are all "LONG" and were created by an ladder logic program called PICoPLC.
You can read/write spin variables my passing their address to PropBasic.
Here is a simple example:
DEVICE P8X32A,XTAL1,PLL16X FREQ 80_000_000 ASM ' Spin code goes here VAR LONG myVar PUB Main myVarAddr := @myVar ' Tell PropBasic "myVar"'s address myvar := 0 CogInit(1, @__Init, @__DATASTART) ' Start PropBasic code in COG 1 REPEAT waitcnt(cnt+8000000) ' Wait 100mSec myVar+=1 ' End of spin code ENDASM PROGRAM Start myVarAddr HUB LONG ascii HUB STRING(20) temp VAR LONG Start: RDLONG myVarAddr, temp ' temp=address of "myVar" DO RDLONG temp,__param1 ' get value of "myVar" ' Convert value to ascii and output to PST ascii = STR __param1, 10, 3 ascii = ascii + 13 SEROUT 30, T115200, ascii LOOP ENDBean
I found a problem with Propbasic SHIFTIN modes which use the rev instruction: rev is done for the same number of Bits as shifted in, but it should actually be for 32 minus the number of Bits shifted in. I attach screen snips to illustrate. I tested with versions 1.04 and 1.08.
Regards
Andre Nieuwoudt
Bean
Good guess
{ This is auto-generated code from PICoPLC. Do not edit this file! Go back to the ladder diagram source for changes in the logic, and compile } CON _CLKFREQ = 4000000 'Hz _CLKMODE = XTAL1 + PLL16X CycleTime = 100 '1/sec var BYTE I_mcr var BYTE I_rung_top con U_Yclock = 1 var WORD U_Tpulse var BYTE I_parOut_0000 var BYTE I_parThis_0000 var BYTE I_oneShot_0000 var WORD U_Cshift var WORD I_scratch2 var WORD U_buttons con U_Xdata = 0 VAR LONG stack[100] LONG cog PUB Start cog := cognew(PlcCycle, @stack) +1 PUB Stop if (cog) cogstop(cog~ - 1) cog~ PRI PlcCycle | timing DIRA := $00000002 DIRB := $00000000 timing := cnt + clkfreq / CycleTime repeat I_mcr~~ { start rung 2 } I_rung_top := I_mcr { start series [ } { Negated contact } if (OUTA[U_Yclock]) I_rung_top~ { TON element } if (I_rung_top) if (U_Tpulse < 9) U_Tpulse++ I_rung_top~ else U_Tpulse := 0 { start parallel [ } I_parOut_0000~ I_parThis_0000 := I_rung_top { Normal coil } OUTA[U_Yclock] := I_parThis_0000 if (I_parThis_0000) I_parOut_0000~~ I_parThis_0000 := I_rung_top { CTC element } if (I_parThis_0000) ifnot (I_oneShot_0000) U_Cshift++ if (U_Cshift < 9) else U_Cshift := 0 I_oneShot_0000 := I_parThis_0000 if (I_parThis_0000) I_parOut_0000~~ I_rung_top := I_parOut_0000 { ] finish parallel } { ] finish series } { start rung 3 } I_rung_top := I_mcr { start series [ } I_scratch2 := 0 { EQU element } if (U_Cshift == I_scratch2) else I_rung_top~ { MOVE element } if (I_rung_top) U_buttons := 0 { ] finish series } { start rung 4 } I_rung_top := I_mcr { start series [ } I_scratch2 := 1 { EQU element } if (U_Cshift == I_scratch2) else I_rung_top~ { Contact } ifnot (INA[U_Xdata]) I_rung_top~ { MOVE element } if (I_rung_top) U_buttons := 1 { ] finish series } { start rung 5 } I_rung_top := I_mcr { start series [ } I_scratch2 := 2 { EQU element } if (U_Cshift == I_scratch2) else I_rung_top~ { Contact } ifnot (INA[U_Xdata]) I_rung_top~ { MOVE element } if (I_rung_top) U_buttons := 2 { ] finish series } { start rung 6 } I_rung_top := I_mcr { start series [ } I_scratch2 := 3 { EQU element } if (U_Cshift == I_scratch2) else I_rung_top~ { Contact } ifnot (INA[U_Xdata]) I_rung_top~ { MOVE element } if (I_rung_top) U_buttons := 4 { ] finish series } { start rung 7 } I_rung_top := I_mcr { start series [ } I_scratch2 := 4 { EQU element } if (U_Cshift == I_scratch2) else I_rung_top~ { Contact } ifnot (INA[U_Xdata]) I_rung_top~ { MOVE element } if (I_rung_top) U_buttons := 16 { ] finish series } { start rung 8 } I_rung_top := I_mcr { start series [ } I_scratch2 := 5 { EQU element } if (U_Cshift == I_scratch2) else I_rung_top~ { Contact } ifnot (INA[U_Xdata]) I_rung_top~ { MOVE element } if (I_rung_top) U_buttons := 32 { ] finish series } { start rung 9 } I_rung_top := I_mcr { start series [ } I_scratch2 := 6 { EQU element } if (U_Cshift == I_scratch2) else I_rung_top~ { Contact } ifnot (INA[U_Xdata]) I_rung_top~ { MOVE element } if (I_rung_top) U_buttons := 64 { ] finish series } { start rung 10 } I_rung_top := I_mcr { start series [ } I_scratch2 := 7 { EQU element } if (U_Cshift == I_scratch2) else I_rung_top~ { Contact } ifnot (INA[U_Xdata]) I_rung_top~ { MOVE element } if (I_rung_top) U_buttons := 128 { ] finish series } { start rung 11 } I_rung_top := I_mcr { start series [ } I_scratch2 := 8 { EQU element } if (U_Cshift == I_scratch2) else I_rung_top~ { Contact } ifnot (INA[U_Xdata]) I_rung_top~ { MOVE element } if (I_rung_top) U_buttons := 256 { ] finish series } waitcnt(timing) timing += clkfreq / CycleTime.Hi Bean,
Cool, thanks. In the mean time the work-around is fortunately very simple.
Just one other thing: Is there a way around Propellent's problem with Propbasic LMM? Especially in version 00.01.08 which uses @@@? BST and BSTC work perfectly fine, though.
Andre
I am afraid I have discovered another bug in Ver. 00.01.08: When using variables for the SDA and SCL Pins, the I2C_Start routine uses the SDA variable for SCL (__temp2) as well, instead of using the SCL variable.
Example Code:
SUB I2C_START
__param1 = 29
__param2 = 28
I2CSTART __param1, __param2
ENDSUB
produces the following result:
I2C_START 'SUB I2C_START
mov __param1,#29 ' __param1 = 29
mov __param2,#28 ' __param2 = 28
mov __temp1,#1 ' I2CSTART __param1, __param2
shl __temp1,__param1
mov __temp2,#1
shl __temp2,__param1
The line "shl __temp2,__param1" should be "shl __temp2,__param2".
It is only the I2C_START routine which has the problem, the other I2C routines are OK.
Regards
Andre Nieuwoudt
Yeah, I had caught that one already. But BradC hasn't responded to my update yet.
Thanks anyway. It's good to know that someone is paying attention
Bean
I am systematically re-writing all my PBASIC code in PropBasic, so I have a suspicion that you will hear from me often.
I am also creating Libraries for often-used code and right now I am trying to create a library for SHIFTIN and SHIFTOUT routines using Variables for the Data and Clock Pins, but it does not work because the Data Pin Variable is also used for the Clock Pin. Is this a bug or have you perhaps not yet enabled this functionality?
Samples for SHIFTOUT and SHIFTIN:
Shift_Out 'SUB Shift_Out
mov __temp1,#1 ' SHIFTOUT __param1, __param2, LSBFIRST, __param3\8 ' DataIO, Clock,
shl __temp1,__param1
or dira,__temp1
mov __temp2,#1
shl __temp2,__param1
or dira,__temp2
mov __temp3,__param3
Shift_In 'FUNC Shift_In
mov __temp1,#1 ' SHIFTIN __param1, __param2, LSBPRE, __param3\8 ' DataIO, Clock,
shl __temp1,__param1
andn dira,__temp1
mov __temp2,#1
shl __temp2,__param1
In both cases "shl __temp2,__param1" should be "shl __temp2,__param2".
Regards
Andre
PS. SERIN and SEROUT work correctly when using a Variable for the Serial Pin.
I will fix that one too.
Bean
Cool, thanks. I promise I won't find another bug for at least a week (hee-hee). But, jesting aside, PropBasic is GREAT !!!
I am really sorry for doing this to you, but I have found another problem. When using command "ON var GOSUB label1, label2 [, label3, [, etc]]", BST generates the following error: "Compiler crashed with run time error: 217 : Unhandled Exception". Propellent generates the following error: "Line (nnn) Undefined Symbol. mov dira, __InitDirA"
These commands work fine,though:
ON var = value1, value2, value3 GOSUB label1, label2, label3
ON var GOTO label1, label2 [, label3, [, etc]]
ON var = value1, value2, value3 GOTO label1, label2, label3
Regards
Andre
Okay, you are now the OFFICAL PropBasic tester...
Yeah, I had a variable that was never initialized in there, it worked in the development environment because it was set to zero, but was a random value in the real-world.
I fixed it, but I'm still waiting to hear from BradC... Hopefully the fix will be in the next release.
Thanks again for your finds...
Bean
Firstly I must say that I am absolutely thrilled by the fact that it is possible to alias VAR arrays! Thanks!
Aliasing a HUB variable or array generates a syntax error, though.
As for pre-initializing arrays, I found that this works: "myVar HUB LONG(4) = 0".
But this generates a syntax error: "myVar VAR LONG(4) = 0". Admittedly, the Syntax Guide Ver. 00.01.04 does not specifically state that it is possible to pre-initilize a VAR array.
Am I being too optimistic here?
Regards
Andre
throws...
If I call this command from cogid 0
Should this stop the code currently running in cog0, then start the new task code in cog0 (ie. restart the new cog/task over itself)
OR - should this not work like that ?
Thanks, Max.
Concerning "COGINIT MyTask, 0". Yes that should work like you said. It will start the task in the same cog as the main code.
Bean
OK, I will cross that one off the list of possible showstoppers. BIG thanks !