Here's a very simple example of using Load. This little program Task_example.pbas loads Simple_task.pbas. It's a brain-dead little program where the task increments a count and sends it to hub ram, and also sets a flag byte to tell main that a new count is ready. Main watches for the flag byte to change, resets it and writes the count out to the terminal. I set main to LMM for no reason other than to show that an LMM program can load a task. Note that while the hub variables are listed in the task file, they are commented out since they're already declared in main.
I've always used BST and I'm still using the last version of PropBasic that BST could use, so I haven't tested this with a newer version, but it compiles with BST and runs on an Activity Board. Hope this helps.
' ----------------------------------------------------------------------
' Device Settings
' ----------------------------------------------------------------------
DEVICE P8X32A, XTAL1, PLL16X
XIN 5_000_000
' ----------------------------------------------------------------------
' Constants
' ----------------------------------------------------------------------
YES CON 1
NO CON 0
Baud CON "T19200"
' ----------------------------------------------------------------------
' Libraries
' ----------------------------------------------------------------------
LOAD "Simple_task.pbas"
' ----------------------------------------------------------------------
' I/O Pins
' ----------------------------------------------------------------------
TX PIN 30 HIGH
RX PIN 31 INPUT
' ----------------------------------------------------------------------
' Shared (hub) Variables (Byte, Word, Long)
' ----------------------------------------------------------------------
hub_count HUB LONG = 0
newcount HUB BYTE = 0
outstring HUB BYTE(10)
' ----------------------------------------------------------------------
' Cog Variables (Long only)
' ----------------------------------------------------------------------
temp VAR LONG = 0
' ----------------------------------------------------------------------
' SUB/FUNC Definitions
' ----------------------------------------------------------------------
SendChar SUB 1 'sends a single ASCII char
SendStr SUB 1 'sends a string
' ======================================================================
PROGRAM Main LMM
' ======================================================================
Main:
do
rdbyte newcount, temp
loop while temp <> YES
rdlong hub_count, temp
outstring = STR temp, 4
SendStr outstring
wrbyte newcount, NO
goto main
END
' ----------------------------------------------------------------------
' SUB/FUNC Code
' ----------------------------------------------------------------------
SUB SendChar
SEROUT TX, Baud, __param1
ENDSUB
' ----------------------------------------------------------------------
SUB SendStr
__param2 = __param1 ' SendChar uses __param1
DO
RDBYTE __param2, __param3
IF __param3 = 0 THEN EXIT
SendChar __param3
INC __param2
LOOP
SendChar 13
ENDSUB
' ----------------------------------------------------------------------
Thanks jones, for the nice example for using the LOAD command. The problem that I was bumping into is trying to LOAD a *_lib.pbas that contained the SUBs.
Today I will probably spend some time and try to figure out why my program was presenting with a lot of errors when it was compiled with bstc or Propeller IDE. This would be a nice feature if it could be used in a manner in which you could create libs for component drivers that would have the most usage flexibility.
A case in point, Jon McPhalen wrote an article describing charlieplexing and its uses. He also used the Activity board in his description, so, now there is two possibilities, which would include the Hackable Badge. I was trying to come with a solution, using PropBasic, where you could have a lib that would contain the charlieplexing code, and be flexible enough to be used, in an easy manner, to work with the Badge or the Activity board or any other scenario. Of course it would have a minimal fuss attribute to it.
The other feature that PropBasic has is the use of LMM, still not sure how that could be used with the LOAD command, and be able to maybe have the SUBs declared LMM. Having to get into the lib file and adding LMM to the SUBs, and then removing LMM when you do not want use it, seems to be very cumbersome. You might as well not use a lib file, and just add the code to the main program task. I guess I would like see some ideas for achieving something like this.
I keep in the back of my mind that there are components that appear in more than one Propeller board, for instance IR. It would be nice to create a driver lib that could be used for the Badge, QuickStart+HIB board, and some components placed on the Activity board. The list could be expanded to include the Propeller RPi HAT also.
I am not sure if this is a coincidence or what, but the below program compiles with no errors using bstc or Propeller IDE.
Notice that I placed the LOAD command after the 'PROGRAM Start' and not before. When LOAD command is placed before the 'PROGRAM Start' then I get get errors.
I tried the Bled1 SUB, using ON...GOSUB, it creates errors, I get the feeling that this command does not like the __param1 value, I think that is what is causing the problem. If indeed that is the case, then my concept of a PropBasic switch command, using this setup, will not suffice for what I need.
Ray
' test_subs.pbas
' Jan 28,2016
'
'
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
' Pin defs, using the QuickStart board
Cled16 PIN 16 OUTPUT
Cled17 PIN 17 OUTPUT
Cled18 PIN 18 OUTPUT
PROGRAM Start
' When the LOAD is placed here, bstc and Propeller IDE
' compile with no errors, program runs as expected.
LOAD "/home/ray/propbasic/subs_lib_test.pbas"
Start:
' led,on/off
CledCtrl 0,0,1
CledC1 0,0
Pause 2000
CledOff
END
' SUBs FUNCs TASKS
'
subs_lib_test.pbas
' subs_lib_test.pbas
CledOff SUB
CledOn SUB
CledCtrl SUB 3
CledC1 SUB 2
Bled1 SUB 1
'SUB Bled1
' If __param1 = 0 Then
' ON __param1 GOSUB CledOn
' EndIf
'ENDSUB
SUB CledCtrl
if __param2 = 1 Then
low Cled16
goto Stop
elseif __param1 = 0 Then ' High
high Cled16
if __param3 = 1 then
pause 3000
low Cled16
endif
endif
Stop:
ENDSUB
SUB CledC1
If __param1 = 1 Then
Low Cled18
Goto Stop1
ElseIf __param2 = 0 Then
High Cled18
pause 3000
Low Cled18
EndIf
Stop1:
ENDSUB
SUB CledOn
high Cled17
ENDSUB
SUB CledOff
low Cled16
low Cled17
low Cled18
ENDSUB
Ray, I'm at a loss as to what this is supposed to do ?
The LED callout would be associated with a number, for this SUB test, maybe 0 was a poor choice. __param1 would be dealing with numbers, maybe 1 - 6, then the gosub would start up the correct associated SUB that the __param1 had, I guess sort of like a switch command. I was trying create something where you could reduce the amount of IF ELSEIF commands.
Ray - Regarding LMM, maybe Bean wants to comment, but I don't think there's any need to make subroutines LMM. Whatever program or task they are part of will determine that. IOW, if you make main LMM, all of the subs and functions associated with main will also be run LMM. Similarly, if you load a task as part of a library, and you make that task run LMM, all of the subs and functions subordinate to the task will also run LMM. I haven't had to use LMM with a task, but running main LMM and the other cogs running cog code works fine.
I think Bean is asking the same thing I did previously. If you use ON - GOSUB, there's no reason for the IF statement, ON - GOSUB will test __param1 and branch accordingly. So your code would be something like:
SUB Bled1
ON __param1 GOSUB CledOn, sub1, sub2, sub3, sub4, sub5
ENDSUB
Be careful, however, because ON - GOSUB should jump to the first sub in the list when __param1 = 0, not 1, so your numbers would be 0-5, not 1-6.
Thanks guys, sometimes I am a little slow on seeing the correct usage of a command, as Bob showed me delicately.
The usual method is to make the main program LMM (to allow more code), and then make the tasks native for speed.
OK, I guess I have to bring this up again, is PropBasic at an impasse? It sounds like Bean is not going to rewrite PropBasic, and openspin is not going to add support for @@@. IMO if you cannot use the LMM feature of PropBasic, what would be the point of having it be part of Propeller IDE?
The program below works as expected, compiles with no errors. Now I have to work out the kinks for the RGB code.
The RGB code is going to be a little trickier, I need a SUB command with three elements, R or L, Red Green or Blue, on or off. Using the ON...GOTO is very handy, but it will get messy when I use it within those IF statements, I think.
I have been thinking about how to approach dealing with the OLED driver, I looked in the OBEX, and there is an object for working with the uOLED screen. It is the same code that is used for the Badge.
I guess I could pull out the PASM part and use it in PropBasic, but how would you associate a SUB command with the appropriate part of the assembly program? I would imagine that the OLED driver would be running in its own TASK, so then how would a SUB in the main program get access to any of the PASM code? Any ideas about this?
Ray
' Base_badge.pbas
' Jan 27, 2016
'
' Turn on LED
' to give visual that the Badge is on.
'
' Layout of Hackable Badge LEDs
'
' led led
' 5 |O| (P17)| O |(P27) |O| 0
' 4 |O| (P16)| L |(P26) |O| 1
' 3 |O| (P15)| E |(P25) |O| 2
' | D |
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
' charlieplexed LEDs configuration
' for the Parallax Hackable Badge
CPin0 PIN 6 OUTPUT
CPin1 PIN 7 OUTPUT
CPin2 PIN 8 OUTPUT
''''''''''''''''''''
PROGRAM Start
''''''''''''''''''''
LOAD "/home/ray/propbasic/CPled_lib.pbas"
' Start up code
Start:
' led,state = 0-on, 1-off
CPled 3,0 ' Turn on LED
Main:
END
' SUBs FUNCs TASKS
'
' CPled_lib.pbas
' Jan 27, 2016
'
'
' charlieplexing strategy - read Jon McPhalan article for complete info.
' Blue LEDs
'
' B5 B4 B3 B2 B1 B0 Layout
' --- --- --- --- --- --- --------------------
' P8 Z Z H L H L B5 B0
' P7 L H L Z Z H B4 B1
' P6 H L Z H L Z B3 B2
'
'
'
'SUBs
CPled SUB 2
Pled0 SUB
Pled1 SUB
Pled2 SUB
Pled3 SUB
Pled4 SUB
Pled5 SUB
''''''''''''''''''''
' Usage CPled led, state
' led = 0 - 5
' state = 0-on, 1-off
''''''''''''''''''''
SUB CPled
' __param1 = led
' __param2 = state, 0 = on, 1 = off
IF __param2 = 1 THEN ' state is off
INPUT CPin0 ' Turn off LED
INPUT CPin1
INPUT CPin2
GOTO CPledStop
ENDIF
ON __param1 GOSUB Pled0,Pled1,Pled2,Pled3,Pled4,Pled5
CPledStop:
ENDSUB
SUB Pled0
INPUT CPin0 'Pin 6
HIGH CPin1 'Pin 7
LOW CPin2 'Pin 8
ENDSUB
SUB Pled1
LOW CPin0
INPUT CPin1
HIGH CPin2
ENDSUB
SUB Pled2
HIGH CPin0
INPUT CPin1
LOW CPin2
ENDSUB
SUB Pled3
INPUT CPin0
LOW CPin1
HIGH CPin2
ENDSUB
SUB Pled4
LOW CPin0
HIGH CPin1
INPUT CPin2
ENDSUB
SUB Pled5
HIGH CPin0
LOW CPin1
INPUT CPin2
ENDSUB
... and openspin is not going to add support for @@@. IMO if you cannot use the LMM feature of PropBasic, what would be the point of having it be part of Propeller IDE?
Any links for that ?
If @@@ is supported in old tool flows that Parallax wish to retire, then any new replacements will need to offer a similar operation, otherwise they simply are not replacements.
Any links for that ?
If @@@ is supported in old tool flows that Parallax wish to retire, then any new replacements will need to offer a similar operation, otherwise they simply are not replacements.
Their are no Parallax tools that use the '@@@', this is something that Brads Spin Tool (bst) came up with. Any links, there was a post in the P2 forum, that dealt with that, and I got the impression, from the post, that openspin was not going to add that functionality. So, again, is PropBasic at an impasse?
I got the CPrgb SUB and lib working, if only to have the Red, Green, and Blue colors to work. Now I want to see what can be done with the touch pads.
The below attempt is using the QuickStart board, and the P16 LED lights up, but not when I touch the pad. Not sure if I am using the INPUT command correctly, although the program compiles without errors.
I think I will need a lot of help with this one, not sure how to implement PropBasic to be able to use the touch pads.
Ray
' tch_pads.pbas
' Jan 30, 2016
'
' Use of touch pads, using the QuicStart board, then the Badge.
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
T_pad7 PIN 7 INPUT
LED16 PIN 16 OUTPUT
PROGRAM Start
Start:
DO
INPUT T_pad7
IF T_pad7 > 0 THEN
HIGH LED16
ELSE
PAUSE 500
ENDIF
LOOP
END
' SUBs FUNCs TASKS
'
INPUT sets a pin as an input, which you did when you defined the pin, so the INPUT T_pad7 before the IF is redundant. I think it should work since nothing is changed, it just isn't necessary. You don't need INPUT to read the pin, the test in the IF statement is sufficient. If you are switching the T_pad7 pin mode, that's when you'd use INPUT or OUTPUT in the body of your code.
I've not used a QuickStart nor touch pads, so I don't know how to set those up.
[edit] I just looked at the Quickstart doc and the touch pad driver and it looks like you will either need to use INPUT and OUTPUT to switch pin mode or write directly to registers the way the PASM code does. I wonder if you could use the PASM code as inline ASM? I haven't tried that, but there is the ASM..ENDASM command. Sorry, I'm obviously not going to be much help with the touch pads.
At the risk of looking like an idiot (very possible), here's a stab at reading one pin, though I haven't tried this since I don't have a Quickstart board. This is what a non-PASM programmer *thinks* he sees in the PASM driver. The driver also loops to test the pin 32 times, only returning true if all tests were true. Obviously this is just one test.
WaitTime is some number of ms longer than the decay time when touched, but shorter than the decay time when not touched. WaitTime is in clock cycles.
'set pin to output, get the current cnt and add the delay
output T_pin
temp = WaitTime + cnt
'charge the pin capacitance
high T_pin
'switch to high impedance input
input T_pin
'wait the delay time and test to see if the capacitance has been discharged
waitcnt temp
if T_pin <> 1 then
result = TRUE
else
result = FALSE
endif
Bob, I think I got your logic right, but no joy. At least the program compiles and runs without any errors. Still missing the magic for making this work.
Ray
' tch_pads.pbas
' Jan 30, 2016
'
' Use of touch pads, using the QuicStart board, then the Badge.
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
T_pad7 PIN 7 INPUT
LED16 PIN 16 OUTPUT
Ttime VAR LONG
PROGRAM Start
Start:
DO
OUTPUT T_pad7 ' Set pin to output
Ttime = Ttime + cnt ' Capture cnt ?
HIGH T_pad7 ' Charge pin
INPUT T_pad7 ' Switch pin capacitance
PAUSE Ttime ' Wait the delay time
IF T_pad7 <> 1 THEN ' If touched
HIGH LED16 ' On when pad is touched
ELSE
LOW LED16 ' Otherwise keep it low
ENDIF
LOOP
END
' SUBs FUNCs TASKS
'
Lets try this a different way, below is the official Parallax driver for the QuickStart touch buttons, Bean, is there a way to tie the below driver to a PropBasic program?
Since the object has a way of getting the state of the buttons, how could you use the results in a PropBasic program? If this could be done, then the people that are creating the PASM driver programs could possibly leave hooks for PropBasic usage. Just a thought, if there is that much difficulty in creating fresh PropBasic driver code, then what chance would one even have at coming up with some code to access the uOLED?
Ray
CON
BUTTON_PINS = $FF ' The QuickStart's touch buttons are on the eight LSBs
SAMPLES = 32 ' Require 32 high redings to return true
VAR
long Results
PUB Start(Rate)
Results := Rate
cognew(@Entry, @Results) ' Launch a new cog to read samples
PUB State | Accumulator
Accumulator := Results ' Sample multiple times and return true
repeat constant(SAMPLES - 1) ' if every sample was highw
Accumulator &= Results
return Accumulator
DAT
org
Entry
rdlong WaitTime, par
mov outa, #BUTTON_PINS ' set TestPins high, but keep as inputs
mov Wait, cnt ' preset the counter
add Wait, WaitTime
Loop
or dira, #BUTTON_PINS ' set TestPins as outputs (high)
andn dira, #BUTTON_PINS ' set TestPins as inputs (floating)
mov Reading, #BUTTON_PINS ' create a mask of applicable pins
waitcnt Wait, WaitTime ' wait for the voltage to decay
andn Reading, ina ' clear decayed pins from the mask
wrlong Reading, par ' write the result to RAM
jmp #Loop
Reading res 1
WaitTime res 1
Wait res 1
The program below is my start, the program compiles without any errors and bstc likes it. Now what would I have to do next to get it to react to a touch?
In other words, how do you get PropBasic to use the PASM code? Any ideas out there?
Ray
' TTest.pbas
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
BUTTON_PINS CON $FF
SAMPLES CON 32
T_Buttons TASK
PROGRAM Start
Start:
COGSTART T_Buttons
TASK T_Buttons
ASM
org
Entry
rdlong WaitTime, par
mov outa, #BUTTON_PINS ' set TestPins high, but keep as inputs
mov Wait, cnt ' preset the counter
add Wait, WaitTime
Loop
or dira, #BUTTON_PINS ' set TestPins as outputs (high)
andn dira, #BUTTON_PINS ' set TestPins as inputs (floating)
mov Reading, #BUTTON_PINS ' create a mask of applicable pins
waitcnt Wait, WaitTime ' wait for the voltage to decay
andn Reading, ina ' clear decayed pins from the mask
wrlong Reading, par ' write the result to RAM
jmp #Loop
Reading res 1
WaitTime res 1
Wait res 1
ENDASM
ENDTASK
It's going to pause for a really long time. You grab the cnt value, but pass that to PAUSE instead of waitcnt. Pause waits for some number of milliseconds, but cnt is in clock cycles, which are only about 12 nanoseconds at 80 MHz and cnt is usually a big number. Either pass a value in milliseconds to pause, or use waitcnt.
The Quickstart docs suggest a 1 millisecond delay, but you might need to experiment. You want the delay long enough that touching the pad can discharge the pin capacitance, but not so long that it can bleed off without a touch. The simplest change would be to just change your PAUSE to PAUSE 1.
Note the PASM driver also tests the touchpad 32 times, presumably to reduce the chance of a spurious response, but without a board to play with I'm guessing. In fact I'm guessing about a lot of this, but the idea's pretty simple so I don't think I'm too far off. Anyone who has played with the touch pads is welcome to jump in here!
Bob, I think I got your logic right, but no joy. At least the program compiles and runs without any errors. Still missing the magic for making this work.
Ray
' tch_pads.pbas
' Jan 30, 2016
'
' Use of touch pads, using the QuicStart board, then the Badge.
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
T_pad7 PIN 7 INPUT
LED16 PIN 16 OUTPUT
Ttime VAR LONG
PROGRAM Start
Start:
DO
OUTPUT T_pad7 ' Set pin to output
Ttime = Ttime + cnt ' Capture cnt ?
HIGH T_pad7 ' Charge pin
INPUT T_pad7 ' Switch pin capacitance
PAUSE Ttime ' Wait the delay time
IF T_pad7 <> 1 THEN ' If touched
HIGH LED16 ' On when pad is touched
ELSE
LOW LED16 ' Otherwise keep it low
ENDIF
LOOP
END
' SUBs FUNCs TASKS
'
Sometimes when I look at PASM code, it looks like gibberish to me. :-)
Thanks Bob for setting me straight on some of the command usage, but I think I am done with this thread. I will leave it up to Bean or someone else to promote the further usage of PropBasic. Maybe in about a year from now, if and when PropBasic gets added to Propeller IDE, I will see what PropBasic looks like then, but I have my doubts about anything getting better. Just my personal thoughts at the moment.
Hi
I've been using PropBasic for a while now, and so far it has done everyting I asked of it. Sometimes the compiling to asm mnemonics passes but the compiling to machine code fails- ie Bst reports errors, and not PropBasic, but a bit of research shows my error. Often I run out of memory and have to find a workround.
You started out talking about charlieplexing which got my attention because recently I got an LOL (lots of leds card with 126 leds (14 by 9)) card running with twelve prop pins and thirty lines of code, (not including lookup tables) without problems and I was thinking perhaps I could help you, but I couldn't understand why you needed a SUB for every led, and only seemed to require one led to be on at a time. In my approach I used a table with a long for each led, (a word for the mask and a word for the bit pattern), then used them to set the pin directions and pin values. With this I could make it 'appear' that all leds were functioning together and show a numerical counter using a 4 by 5 or 7 by 8 font, and the classical bouncing ball routine.
I've not used LMM! so cant comment- you seemed to jump in the deep end and started with that.
Its not perfect, but its the work of one man for no reward who has given it freely to those that are more familiar with Basic and cant be bothered to learn yet another language. Its also good to be able to look at the asm produced; Ive learned a lot more about asm and some of its wierd (to me I hasten to add), yet powerful instructions and even modified the finished code to suit my particular purposes.
So dont be too quick to give up on it- when it gets some well deserved support from Parrallax on the Prop2 I'm sure it will prove to be very powerful and flexible, and more will come to appreciate the time and effort Bean has put into this wonderful tool.
Ray, I think you're giving up too soon, and blaming PropBasic for things that are really misunderstandings. I designed a GPS-based video timing overlay board and wrote everything in PropBasic. It uses most of the hub ram, has a large LMM main program and runs cog code in the other seven cogs with lots of bit twiddling, coordination between cogs and even a video OSD driver in PropBasic that was based on Bean's examples. One of the issues we all deal with is that information is scattered among several sources and it takes a little looking to find things. Bean's docs are terse, but I've found no errors, and Jon McPhalen's PropBasic Syntax Guide provides additional info. Jon also wrote a number of his Spin Zone columns for Nuts & Volts on PropBasic, which provide not only tested examples but lots of detailed explanations. Now that I think of them, he has some examples of using inline assembler which I clearly need to re-read. The info is all out there somewhere, so don't give up on it. I haven't even used the recent versions, just sticking to BST with an old version of PropBasic. I have had a few issues, but I've always found a work-around.
I just faked a touchpad on an Activity Board with a couple of wires, one to ground and the other to P7 through a 100k resistor like the Quickstart. I copied your last PropBasic code to BST and made the change I recommended regarding PAUSE. I had to put the LED on P15 since that board doesn't have P16 on a header, but other than that it was your code. It compiled on BST and ran fine, with the "touchpad" working exactly as it's supposed to. Try this code, Ray (LED moved back to P16).
' tch_pads.pbas
' Jan 30, 2016
'
' Use of touch pads, using the QuicStart board, then the Badge.
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
T_pad7 PIN 7 INPUT
LED16 PIN 16 OUTPUT
PROGRAM Start
Start:
DO
OUTPUT T_pad7 ' Set pin to output
HIGH T_pad7 ' Charge pin
INPUT T_pad7 ' Switch pin capacitance
PAUSE 1 ' Wait the delay time
IF T_pad7 <> 1 THEN ' If touched
HIGH LED16 ' On when pad is touched
ELSE
LOW LED16 ' Otherwise keep it low
ENDIF
LOOP
END
OK guys, I was not really blaming PropBasic, just getting a little frustrated at the terseness of the documentation.
Bob, I can confirm that the touch pad on the QuickStart works as expected, when I touch the P7 pad the P16 LED lights up and stays lit until you remove your finger. Not sure how you came up with that magic number though. Now to see how I can package it so it works with all the pads and associated requested function. I also have to see how to turn this into a lib so it can be used with the Badge, and any other device that Parallax sells.
Which magic number? The delay time was suggested in the Quickstart docs, if that's what you're referring to. It's not that mysterious, it's just enough time for the small capacitance of the pin plus pcb pad to discharge through a 100k resistor and your finger, but not so much that it can bleed off through leakage paths.
FWIW, using PAUSE values anywhere from about 700 microseconds (using PAUSEUS) up to about 50 milliseconds worked OK. It started to get flaky below 500 us and the response was obviously slowing down a bit at 50 ms, but it still worked OK. You might even want to bump the delay up a bit, to maybe a few ms.
A number of years ago, since Parallax were not going to add any features to PropTool, two forumistas decided to write their own propeller compilers. They were Michael Park (homespun and sphinx) and Brad Campbell (bst).
The most requested features were compile time variables (#define, #ifdef, and variants), plus @@@. There was another to reserve a block of space at $0010 hub.
Brad and Michael implemented #define slightly differently. IIRC one passes the #define to child objects whereas the other does not. Both implemented @@@ and IIRC only Brad implemented the reserve $0010 space.
Both spent a lot of time implementing the compilers to be precise object code compatible compilers. Neither had access to Chip's PropTool source (I believe despite requests).
Brad implemented a group of programs that made up a PropTool development like IDE. He also made the integrated terminal function better than PropTool. It was also platform independent, since Brad was a Linux guy at heart.
Mark just wrote the compiler (only Windows I think). He then went on to produce a Propeller based compiler and a minimal OS. He called this Sphinx. (BTW I currently have LEX and LINK working under my OS, but CODEGEN is incomplete).
Ross Higson produce Catalina C for the Propeller at a time when Parallax was not interested in C. He used Michael's homespun for the compiler, and Michael provide Ross with the source to make a few required compiler changes for Catalina.
Both compilers can produce (incompatible) compiler listings - an under used feature IMHO.
BTW @@@ cannot be worked around. If you need it, you need it!
Bean's docs are terse, but I've found no errors, and Jon McPhalen's PropBasic Syntax Guide provides additional info. Jon also wrote a number of his Spin Zone columns for Nuts & Volts on PropBasic, which provide not only tested examples but lots of detailed explanations. Now that I think of them, he has some examples of using inline assembler which I clearly need to re-read. The info is all out there somewhere.
I have had a few issues, but I've always found a work-around.
Ditto.
I use Viewport for PropBasic. The latest version of VP has issues so I use the previous version.
So, here is my rendition of using a touch pad, this is set up for the QuickStart board. I guess the key is the Chk_pad SUB which would be the basis for the touch pad access. I need some input on this, is their a better or more efficient way of doing this?
Since this would go into a lib, that could be used for the QuickStart or the Badge, the code has to be portable.
I just noticed, with the QuickStart board, with the below program running, every once in a while LED16 and LED23 would turn on/off, not sure what would be causing that, it is a random event. I also noticed that when I run my finger across the back side of the board over the expansion bus via's, that also lites up the LEDs. But my concern is more for the random event of LED16 and LED23 going on and off with this program.
I put the program in a DO...LOOP, on the Badge the key operation would be the checking of a pad touch and then responding. The response could be to some menu selection on the oled, or just starting some function like an IR operation, or just about anything.
Ray
' tch_pads1.pbas
' Jan 30, 2016
'
' Use of touch pads, using the QuicStart board, then the Badge.
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
T_pad7 PIN 7 INPUT
T_pad6 PIN 6 INPUT
T_pad5 PIN 5 INPUT
T_pad4 PIN 4 INPUT
T_pad3 PIN 3 INPUT
T_pad2 PIN 2 INPUT
T_pad1 PIN 1 INPUT
T_pad0 PIN 0 INPUT
LED16 PIN 16 OUTPUT
LED23 PIN 23 OUTPUT
Chk_Pad SUB 1
temp1 VAR long
'''''''''''''''''''
PROGRAM Start
'''''''''''''''''''
Start:
DO
Chk_pad T_pad7
IF T_pad7 <> 1 THEN
HIGH LED16
ELSE
LOW LED16
ENDIF
Chk_pad T_pad0
IF T_pad0 <> 1 THEN
HIGH LED23
ELSE
LOW LED23
ENDIF
LOOP
END
'''''''''''''''''''
''''''''''''''''''''''''''
' Check the touch pad for a touch.
' Chk_pad pad_number
' Chk_pad T_pad7
SUB Chk_pad
OUTPUT __param1 ' Set pin to output
HIGH __param1 ' Charge pin
INPUT __param1 ' Switch pin capacitance
PAUSE 100 ' Wait the delay time
ENDSUB
'''''''''''''''''''
Comments
I've always used BST and I'm still using the last version of PropBasic that BST could use, so I haven't tested this with a newer version, but it compiles with BST and runs on an Activity Board. Hope this helps.
' ---------------------------------------------------------------------- ' Device Settings ' ---------------------------------------------------------------------- DEVICE P8X32A, XTAL1, PLL16X XIN 5_000_000 ' ---------------------------------------------------------------------- ' Constants ' ---------------------------------------------------------------------- YES CON 1 NO CON 0 Baud CON "T19200" ' ---------------------------------------------------------------------- ' Libraries ' ---------------------------------------------------------------------- LOAD "Simple_task.pbas" ' ---------------------------------------------------------------------- ' I/O Pins ' ---------------------------------------------------------------------- TX PIN 30 HIGH RX PIN 31 INPUT ' ---------------------------------------------------------------------- ' Shared (hub) Variables (Byte, Word, Long) ' ---------------------------------------------------------------------- hub_count HUB LONG = 0 newcount HUB BYTE = 0 outstring HUB BYTE(10) ' ---------------------------------------------------------------------- ' Cog Variables (Long only) ' ---------------------------------------------------------------------- temp VAR LONG = 0 ' ---------------------------------------------------------------------- ' SUB/FUNC Definitions ' ---------------------------------------------------------------------- SendChar SUB 1 'sends a single ASCII char SendStr SUB 1 'sends a string ' ====================================================================== PROGRAM Main LMM ' ====================================================================== Main: do rdbyte newcount, temp loop while temp <> YES rdlong hub_count, temp outstring = STR temp, 4 SendStr outstring wrbyte newcount, NO goto main END ' ---------------------------------------------------------------------- ' SUB/FUNC Code ' ---------------------------------------------------------------------- SUB SendChar SEROUT TX, Baud, __param1 ENDSUB ' ---------------------------------------------------------------------- SUB SendStr __param2 = __param1 ' SendChar uses __param1 DO RDBYTE __param2, __param3 IF __param3 = 0 THEN EXIT SendChar __param3 INC __param2 LOOP SendChar 13 ENDSUB ' ----------------------------------------------------------------------' ---------------------------------------------------------------------- ' Shared (hub) Variables (Byte, Word, Long) ' ---------------------------------------------------------------------- 'declared in main 'hub_count HUB LONG = 0 'newcount HUB BYTE = 0 ' ---------------------------------------------------------------------- ' TASK Definitions ' ---------------------------------------------------------------------- Simple TASK AUTO ' ---------------------------------------------------------------------- ' {$CODE} ' ---------------------------------------------------------------------- ' ====================================================================== '{$TASKS} TASK ' ====================================================================== TASK Simple ' ---------------------------------------------------------------------- ' TASK Pins ' ---------------------------------------------------------------------- ' ---------------------------------------------------------------------- ' TASK Cog Variables (Long only) ' ---------------------------------------------------------------------- temp VAR LONG = 0 ' ---------------------------------------------------------------------- ' *** TASK CODE *** ' ---------------------------------------------------------------------- Start: do inc temp wrlong hub_count, temp wrbyte newcount, YES pause 1000 loop END ENDTASKToday I will probably spend some time and try to figure out why my program was presenting with a lot of errors when it was compiled with bstc or Propeller IDE. This would be a nice feature if it could be used in a manner in which you could create libs for component drivers that would have the most usage flexibility.
A case in point, Jon McPhalen wrote an article describing charlieplexing and its uses. He also used the Activity board in his description, so, now there is two possibilities, which would include the Hackable Badge. I was trying to come with a solution, using PropBasic, where you could have a lib that would contain the charlieplexing code, and be flexible enough to be used, in an easy manner, to work with the Badge or the Activity board or any other scenario. Of course it would have a minimal fuss attribute to it.
The other feature that PropBasic has is the use of LMM, still not sure how that could be used with the LOAD command, and be able to maybe have the SUBs declared LMM. Having to get into the lib file and adding LMM to the SUBs, and then removing LMM when you do not want use it, seems to be very cumbersome. You might as well not use a lib file, and just add the code to the main program task. I guess I would like see some ideas for achieving something like this.
I keep in the back of my mind that there are components that appear in more than one Propeller board, for instance IR. It would be nice to create a driver lib that could be used for the Badge, QuickStart+HIB board, and some components placed on the Activity board. The list could be expanded to include the Propeller RPi HAT also.
This is just a couple things on my mind...
Ray
Notice that I placed the LOAD command after the 'PROGRAM Start' and not before. When LOAD command is placed before the 'PROGRAM Start' then I get get errors.
I tried the Bled1 SUB, using ON...GOSUB, it creates errors, I get the feeling that this command does not like the __param1 value, I think that is what is causing the problem. If indeed that is the case, then my concept of a PropBasic switch command, using this setup, will not suffice for what I need.
Ray
subs_lib_test.pbas
If you know __param1 is zero, then what is the point of the ON __param1 GOSUB CLedOn line ?
Bean
Ray
I think Bean is asking the same thing I did previously. If you use ON - GOSUB, there's no reason for the IF statement, ON - GOSUB will test __param1 and branch accordingly. So your code would be something like:
SUB Bled1 ON __param1 GOSUB CledOn, sub1, sub2, sub3, sub4, sub5 ENDSUBBe careful, however, because ON - GOSUB should jump to the first sub in the list when __param1 = 0, not 1, so your numbers would be 0-5, not 1-6.
-Bob
The usual method is to make the main program LMM (to allow more code), and then make the tasks native for speed.
Bean
OK, I guess I have to bring this up again, is PropBasic at an impasse? It sounds like Bean is not going to rewrite PropBasic, and openspin is not going to add support for @@@. IMO if you cannot use the LMM feature of PropBasic, what would be the point of having it be part of Propeller IDE?
Ray
The RGB code is going to be a little trickier, I need a SUB command with three elements, R or L, Red Green or Blue, on or off. Using the ON...GOTO is very handy, but it will get messy when I use it within those IF statements, I think.
I have been thinking about how to approach dealing with the OLED driver, I looked in the OBEX, and there is an object for working with the uOLED screen. It is the same code that is used for the Badge.
I guess I could pull out the PASM part and use it in PropBasic, but how would you associate a SUB command with the appropriate part of the assembly program? I would imagine that the OLED driver would be running in its own TASK, so then how would a SUB in the main program get access to any of the PASM code? Any ideas about this?
Ray
I think that is a typo, but something similar could be useful.
What does ON,,GOSUB do for out of range ?
ie this is safe for all values of param
If __param1 < 5 Then ON __param1 GOSUB CledOn... Else GOSUB Sub_vGE5 EndIfAny links for that ?
If @@@ is supported in old tool flows that Parallax wish to retire, then any new replacements will need to offer a similar operation, otherwise they simply are not replacements.
Ray
The below attempt is using the QuickStart board, and the P16 LED lights up, but not when I touch the pad. Not sure if I am using the INPUT command correctly, although the program compiles without errors.
I think I will need a lot of help with this one, not sure how to implement PropBasic to be able to use the touch pads.
Ray
I've not used a QuickStart nor touch pads, so I don't know how to set those up.
[edit] I just looked at the Quickstart doc and the touch pad driver and it looks like you will either need to use INPUT and OUTPUT to switch pin mode or write directly to registers the way the PASM code does. I wonder if you could use the PASM code as inline ASM? I haven't tried that, but there is the ASM..ENDASM command. Sorry, I'm obviously not going to be much help with the touch pads.
Bob
WaitTime is some number of ms longer than the decay time when touched, but shorter than the decay time when not touched. WaitTime is in clock cycles.
'set pin to output, get the current cnt and add the delay output T_pin temp = WaitTime + cnt 'charge the pin capacitance high T_pin 'switch to high impedance input input T_pin 'wait the delay time and test to see if the capacitance has been discharged waitcnt temp if T_pin <> 1 then result = TRUE else result = FALSE endifRay
Since the object has a way of getting the state of the buttons, how could you use the results in a PropBasic program? If this could be done, then the people that are creating the PASM driver programs could possibly leave hooks for PropBasic usage. Just a thought, if there is that much difficulty in creating fresh PropBasic driver code, then what chance would one even have at coming up with some code to access the uOLED?
Ray
CON BUTTON_PINS = $FF ' The QuickStart's touch buttons are on the eight LSBs SAMPLES = 32 ' Require 32 high redings to return true VAR long Results PUB Start(Rate) Results := Rate cognew(@Entry, @Results) ' Launch a new cog to read samples PUB State | Accumulator Accumulator := Results ' Sample multiple times and return true repeat constant(SAMPLES - 1) ' if every sample was highw Accumulator &= Results return Accumulator DAT org Entry rdlong WaitTime, par mov outa, #BUTTON_PINS ' set TestPins high, but keep as inputs mov Wait, cnt ' preset the counter add Wait, WaitTime Loop or dira, #BUTTON_PINS ' set TestPins as outputs (high) andn dira, #BUTTON_PINS ' set TestPins as inputs (floating) mov Reading, #BUTTON_PINS ' create a mask of applicable pins waitcnt Wait, WaitTime ' wait for the voltage to decay andn Reading, ina ' clear decayed pins from the mask wrlong Reading, par ' write the result to RAM jmp #Loop Reading res 1 WaitTime res 1 Wait res 1In other words, how do you get PropBasic to use the PASM code? Any ideas out there?
Ray
' TTest.pbas DEVICE P8X32A, XTAL1, PLL16X FREQ 80_000_000 BUTTON_PINS CON $FF SAMPLES CON 32 T_Buttons TASK PROGRAM Start Start: COGSTART T_Buttons TASK T_Buttons ASM org Entry rdlong WaitTime, par mov outa, #BUTTON_PINS ' set TestPins high, but keep as inputs mov Wait, cnt ' preset the counter add Wait, WaitTime Loop or dira, #BUTTON_PINS ' set TestPins as outputs (high) andn dira, #BUTTON_PINS ' set TestPins as inputs (floating) mov Reading, #BUTTON_PINS ' create a mask of applicable pins waitcnt Wait, WaitTime ' wait for the voltage to decay andn Reading, ina ' clear decayed pins from the mask wrlong Reading, par ' write the result to RAM jmp #Loop Reading res 1 WaitTime res 1 Wait res 1 ENDASM ENDTASKThe Quickstart docs suggest a 1 millisecond delay, but you might need to experiment. You want the delay long enough that touching the pad can discharge the pin capacitance, but not so long that it can bleed off without a touch. The simplest change would be to just change your PAUSE to PAUSE 1.
Note the PASM driver also tests the touchpad 32 times, presumably to reduce the chance of a spurious response, but without a board to play with I'm guessing. In fact I'm guessing about a lot of this, but the idea's pretty simple so I don't think I'm too far off. Anyone who has played with the touch pads is welcome to jump in here!
Thanks Bob for setting me straight on some of the command usage, but I think I am done with this thread. I will leave it up to Bean or someone else to promote the further usage of PropBasic. Maybe in about a year from now, if and when PropBasic gets added to Propeller IDE, I will see what PropBasic looks like then, but I have my doubts about anything getting better. Just my personal thoughts at the moment.
Ray
I've been using PropBasic for a while now, and so far it has done everyting I asked of it. Sometimes the compiling to asm mnemonics passes but the compiling to machine code fails- ie Bst reports errors, and not PropBasic, but a bit of research shows my error. Often I run out of memory and have to find a workround.
You started out talking about charlieplexing which got my attention because recently I got an LOL (lots of leds card with 126 leds (14 by 9)) card running with twelve prop pins and thirty lines of code, (not including lookup tables) without problems and I was thinking perhaps I could help you, but I couldn't understand why you needed a SUB for every led, and only seemed to require one led to be on at a time. In my approach I used a table with a long for each led, (a word for the mask and a word for the bit pattern), then used them to set the pin directions and pin values. With this I could make it 'appear' that all leds were functioning together and show a numerical counter using a 4 by 5 or 7 by 8 font, and the classical bouncing ball routine.
I've not used LMM! so cant comment- you seemed to jump in the deep end and started with that.
Its not perfect, but its the work of one man for no reward who has given it freely to those that are more familiar with Basic and cant be bothered to learn yet another language. Its also good to be able to look at the asm produced; Ive learned a lot more about asm and some of its wierd (to me I hasten to add), yet powerful instructions and even modified the finished code to suit my particular purposes.
So dont be too quick to give up on it- when it gets some well deserved support from Parrallax on the Prop2 I'm sure it will prove to be very powerful and flexible, and more will come to appreciate the time and effort Bean has put into this wonderful tool.
Dave
Bob, I can confirm that the touch pad on the QuickStart works as expected, when I touch the P7 pad the P16 LED lights up and stays lit until you remove your finger. Not sure how you came up with that magic number though. Now to see how I can package it so it works with all the pads and associated requested function. I also have to see how to turn this into a lib so it can be used with the Badge, and any other device that Parallax sells.
Ray
A number of years ago, since Parallax were not going to add any features to PropTool, two forumistas decided to write their own propeller compilers. They were Michael Park (homespun and sphinx) and Brad Campbell (bst).
The most requested features were compile time variables (#define, #ifdef, and variants), plus @@@. There was another to reserve a block of space at $0010 hub.
Brad and Michael implemented #define slightly differently. IIRC one passes the #define to child objects whereas the other does not. Both implemented @@@ and IIRC only Brad implemented the reserve $0010 space.
Both spent a lot of time implementing the compilers to be precise object code compatible compilers. Neither had access to Chip's PropTool source (I believe despite requests).
Brad implemented a group of programs that made up a PropTool development like IDE. He also made the integrated terminal function better than PropTool. It was also platform independent, since Brad was a Linux guy at heart.
Mark just wrote the compiler (only Windows I think). He then went on to produce a Propeller based compiler and a minimal OS. He called this Sphinx. (BTW I currently have LEX and LINK working under my OS, but CODEGEN is incomplete).
Ross Higson produce Catalina C for the Propeller at a time when Parallax was not interested in C. He used Michael's homespun for the compiler, and Michael provide Ross with the source to make a few required compiler changes for Catalina.
Both compilers can produce (incompatible) compiler listings - an under used feature IMHO.
BTW @@@ cannot be worked around. If you need it, you need it!
Ditto.
I use Viewport for PropBasic. The latest version of VP has issues so I use the previous version.
Since this would go into a lib, that could be used for the QuickStart or the Badge, the code has to be portable.
I just noticed, with the QuickStart board, with the below program running, every once in a while LED16 and LED23 would turn on/off, not sure what would be causing that, it is a random event. I also noticed that when I run my finger across the back side of the board over the expansion bus via's, that also lites up the LEDs. But my concern is more for the random event of LED16 and LED23 going on and off with this program.
I put the program in a DO...LOOP, on the Badge the key operation would be the checking of a pad touch and then responding. The response could be to some menu selection on the oled, or just starting some function like an IR operation, or just about anything.
Ray