Ray,
The Quickstart touch pads the absolute worse thing to use to try to learn a new language.
Those things are very unreliable and very sensitive to temperature/humidity/sun spots/emotional state/ect.
I would say learn by writing code for everything else, then try to tackle the touchpads last.
Ray,
The Quickstart touch pads the absolute worse thing to use to try to learn a new language.
Those things are very unreliable and very sensitive to temperature/humidity/sun spots/emotional state/ect.
I would say learn by writing code for everything else, then try to tackle the touchpads last.
Bean
On that note; it would be cool to have a PropBASIC development/learning community thread where we agree on a common platform. I still use the demo board.
I would say learn by writing code for everything else, then try to tackle the touchpads last.
For everything else, I was just plain lucky to get somebody to help me out with a driver for the touch pads. It is not like there is a large crowd ready to jump in, for doing drivers, let alone having some useful drivers available for looking at the existing code. Not sure which way to go on this one.
On that note; it would be cool to have a PropBASIC development/learning community thread where we agree on a common platform.
What would be your suggestion for the "common platform"? I started with the Hackable Badge, but that had no momentum. It seems like the QuickStart board is turning out to be the same. I guess maybe the Activity board, then move up to the Activity WX? The Demo board is long gone, so that is out of the question.
Maybe we should all just sit back and wait for an IDE for PropBASIC, that is current, to show up, and then see who is still around working with PropBASIC, and go from there. Not sure what else can be done to keep PropBASIC alive.
Maybe we should all just sit back and wait for an IDE for PropBASIC, that is current, to show up, and then see who is still around working with PropBASIC, and go from there. Not sure what else can be done to keep PropBASIC alive.
Ray
I must admit that I didn't put much thought in to the common platform thing but if I had a QS, I would've been able to play along.
I ain't sitting back waiting for an IDE. I already recommended ViewPort because it works for me and the built-in scope, logic analyzer, etc., etc. are extremely useful in my case. I provided a download link but you decided not to entertain it. You haven't even bothered to let us know if the charging delay proposals from earlier today made any difference. Starting to wonder what the motive is here; to suggest that PropBASIC is not ready for prime time?
So I switched gears a bit, and I thought I would try serial I/O, first things first:
SERIN
Serial input. Prefix baud value "T" for true mode, "N" for inverted mode.
If SERIN times-out var is not changed. If label is not specified execution continues with the next line of code.
If "var" is a string, characters are stored until a carrage return is received, timeout is only in effect until the first
character is received.
SERIN pin, baud, var {, timeoutms{, label}}
"If SERIN times-out var is not changed.", can anybody tell me what that means?
I am trying to get an idea as to how to work with serial IO, in the program below I am setting up to have serin respond to an inVar = "test", but I get an error at compile. When I change it to inVar = "t", then it compiles without an error, but does not do what I want. I thought 'inVar VAR LONG(5)' is supposed to make inVar a string, but I guess it is doing something else, not sure what though.
I guess I will have to restrain myself from making any contrary comments, I do not want this thread to get into to the weeds.
Ray
' test1.pbas
' Feb 11, 2016
'
'
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
RX_BAUD CON "T115200"
RX_PIN CON 31
TX_BAUD CON "T115200"
TX_PIN CON 30
inVar VAR LONG(5)
PROGRAM Start
Start:
DO
SERIN RX_PIN, RX_BAUD, inVar
IF inVar = "t" THEN ' Want this to work with "test"
SEROUT TX_PIN, TX_BAUD, "Got it!"
ENDIF
LOOP
END
' SUBs FUNCs TASKS
'
If you set the variable to 256 then use SERIN with a timeout, if it times out the variables will still contain 256 (which is impossible to receive as a valid byte).
SERIN receives a single byte. You need to put SERIN in a subroutine and call it for each character you want to received.
Strings are stored in HUB memory.
tempStr HUB STRING(10)
VAR LONG(5) creates an array in the COG memory. This is not recommended, it is much better to create arrays in HUB memory and use RDLONG and WRLONG to access the elements.
I am not sure why I keep getting an 'error - invalid parameter' for 'inBuff' in IF inBuff = "test" THEN.
It seems that I am saving the contents of RX_STR to a HUB string, and the comparison, inBuff = "test", should work, but no I get an error. I guess I need a good explanation.
I am finding this HUB vs COG variable stuff to be very confusing in terms of how to use it correctly in a line of code. The below program is probably a decent example, if you store something in a HUB variable how do you use that HUB variable in your program.
Ray
' test1.pbas
' Feb 11, 2016
'
'
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
RX_BAUD CON "T115200"
RX_PIN CON 31
TX_BAUD CON "T115200"
TX_PIN CON 30
inBuff HUB STRING(32)
'inTemp VAR LONG (32)
'inTemp VAR LONG
RX_STR SUB 1,2
RX_BYTE FUNC 0
TX_STR SUB 1,2
TX_BYTE SUB 1
PROGRAM Start
Start:
DO
RX_STR inBuff
IF inBuff = "test" THEN
TX_STR "Got it!"
ENDIF
LOOP
END
' SUBs FUNCs TASKS
'
''''''''''''''''''''
SUB RX_STR
rsChar VAR __param1
rsAddr VAR __param3
rsCount VAR __param4
rsAddr = __param1
IF __paramcnt = 1 THEN
rsCount = 32
ELSE
rsCount = __param2 MIN 0
rsCount = rsCount MAX 32
ENDIF
DO WHILE rsCount > 0
rsChar = RX_BYTE
IF rsChar <> 8 THEN
IF rsChar <> 13 THEN
WRBYTE rsAddr, rsChar
INC rsAddr
DEC rsCount
ELSE
rsChar = 0
rsCount = 0
ENDIF
ELSE
IF rsCount < 32 THEN
DEC rsAddr
WRBYTE rsAddr, 0
INC rsCount
ENDIF
ENDIF
LOOP
WRBYTE rsAddr, 0
ENDSUB
''''''''''''''''''''
''''''''''''''''''''
FUNC RX_BYTE
SERIN RX_PIN, RX_BAUD, __param1
RETURN __param1
ENDFUNC
''''''''''''''''''''
''''''''''''''''''''
' Use: TX_BYTE char
' - sub for SEROUT
'
SUB TX_BYTE
SEROUT TX_PIN, TX_BAUD, __param1
ENDSUB
''''''''''''''''''''
''''''''''''''''''''
' Use: TX_STR string
' - Transmits a string
' - Uses TX_BYTE
SUB TX_STR
tsPntr VAR __param3
tsChar VAR __param4
tsPntr = __param1
DO
RDBYTE tsPntr, tsChar
IF __paramcnt = 1 THEN
IF tsChar = 0 THEN EXIT
ELSE
IF tsChar = __param2 THEN EXIT
ENDIF
TX_BYTE tsChar
INC tsPntr
LOOP
ENDSUB
''''''''''''''''''''
PropBASIC cannot compare strings. Only single characters.
For a 4 character or less string, you can put the byte values into a long and compare it that way.
For more than 4 characters, you'll need to make a function to do it.
Comments
The Quickstart touch pads the absolute worse thing to use to try to learn a new language.
Those things are very unreliable and very sensitive to temperature/humidity/sun spots/emotional state/ect.
I would say learn by writing code for everything else, then try to tackle the touchpads last.
Bean
On that note; it would be cool to have a PropBASIC development/learning community thread where we agree on a common platform. I still use the demo board.
What would be your suggestion for the "common platform"? I started with the Hackable Badge, but that had no momentum. It seems like the QuickStart board is turning out to be the same. I guess maybe the Activity board, then move up to the Activity WX? The Demo board is long gone, so that is out of the question.
Maybe we should all just sit back and wait for an IDE for PropBASIC, that is current, to show up, and then see who is still around working with PropBASIC, and go from there. Not sure what else can be done to keep PropBASIC alive.
Ray
I must admit that I didn't put much thought in to the common platform thing but if I had a QS, I would've been able to play along.
I ain't sitting back waiting for an IDE. I already recommended ViewPort because it works for me and the built-in scope, logic analyzer, etc., etc. are extremely useful in my case. I provided a download link but you decided not to entertain it. You haven't even bothered to let us know if the charging delay proposals from earlier today made any difference. Starting to wonder what the motive is here; to suggest that PropBASIC is not ready for prime time?
I strongly disagree.
I am trying to get an idea as to how to work with serial IO, in the program below I am setting up to have serin respond to an inVar = "test", but I get an error at compile. When I change it to inVar = "t", then it compiles without an error, but does not do what I want. I thought 'inVar VAR LONG(5)' is supposed to make inVar a string, but I guess it is doing something else, not sure what though.
I guess I will have to restrain myself from making any contrary comments, I do not want this thread to get into to the weeds.
Ray
SERIN receives a single byte. You need to put SERIN in a subroutine and call it for each character you want to received.
Strings are stored in HUB memory.
tempStr HUB STRING(10)
VAR LONG(5) creates an array in the COG memory. This is not recommended, it is much better to create arrays in HUB memory and use RDLONG and WRLONG to access the elements.
Bean
It seems that I am saving the contents of RX_STR to a HUB string, and the comparison, inBuff = "test", should work, but no I get an error. I guess I need a good explanation.
I am finding this HUB vs COG variable stuff to be very confusing in terms of how to use it correctly in a line of code. The below program is probably a decent example, if you store something in a HUB variable how do you use that HUB variable in your program.
Ray
For a 4 character or less string, you can put the byte values into a long and compare it that way.
For more than 4 characters, you'll need to make a function to do it.
Bean