PropBasic and the Hackable Badge
Rsadeika
Posts: 3,837
in Propeller 1
Since it looks like there is some renewed interest in PropBasic, again, I downloaded PropBasic_1_42 for linux, and set up a somewhat cumbersome development system. This should be temporary until PropBasic shows up on the Propeller IDE for linux.
I use Geany as the editor and compiler, plus I run the generated Spin file on Propeller IDE; this is being done on my xubuntu set up. Although it is a little cumbersome, the end product seems to work, when run with Propeller IDE. So far so good.
My interest at the moment is the Hackable Badge, I would like to see if there could be another way of programming the Badge, aside from doing it in Spin or PropGCC. One thing of interest with PropBasic is that you can set up a program in LMM, which could allow for a fairly large Badge program, I think. Not even sure if this is the correct way of looking at the proper usage of PropBasic.
Now, that next big hurdle to overcome is, how do you set up drivers, in PropBasic, for the devices on the Badge. I am thinking, start with the charlieplexed LEDs, not even sure how to approach this using PropBasic. Maybe the buttons next, followed by the access to the oled, and then the IR. That should cover the main components, oh I forgot, another important item, setting up a datetime and access to the RC, just to name a few more items.
In the long run, I guess the experiment would be set up and find out if using PropBasic would be of any benefit, in using it to program the Badge. Since the PropBasic code being produced is PASM, even a large sized Badge program should run fairly quick, even if part of it is done in LMM. So, I am open to some discussion about this before I start coding, or going any further.
Ray
I use Geany as the editor and compiler, plus I run the generated Spin file on Propeller IDE; this is being done on my xubuntu set up. Although it is a little cumbersome, the end product seems to work, when run with Propeller IDE. So far so good.
My interest at the moment is the Hackable Badge, I would like to see if there could be another way of programming the Badge, aside from doing it in Spin or PropGCC. One thing of interest with PropBasic is that you can set up a program in LMM, which could allow for a fairly large Badge program, I think. Not even sure if this is the correct way of looking at the proper usage of PropBasic.
Now, that next big hurdle to overcome is, how do you set up drivers, in PropBasic, for the devices on the Badge. I am thinking, start with the charlieplexed LEDs, not even sure how to approach this using PropBasic. Maybe the buttons next, followed by the access to the oled, and then the IR. That should cover the main components, oh I forgot, another important item, setting up a datetime and access to the RC, just to name a few more items.
In the long run, I guess the experiment would be set up and find out if using PropBasic would be of any benefit, in using it to program the Badge. Since the PropBasic code being produced is PASM, even a large sized Badge program should run fairly quick, even if part of it is done in LMM. So, I am open to some discussion about this before I start coding, or going any further.
Ray
Comments
PropBasic 1
Propeller IDE 0
Ray
Propeller IDE
Build Manager
"Build failed!"
Propeller IDE
Ray
Build Manager
"Build failed!"
Propeller IDE
BSTC is the compiler I use.
Bean
I believe the "@@@" for openspin was discussed in another forum, and it looks like openspin will NOT be adding that feature. So, where does that leave PropBasic, locked into BST?
SimpleIDE is no longer a viable alternative for supporting PropBasic, and Propeller IDE might be questionable for supporting ProbBasic. Well what other options are available?
I guess, maybe Geany could be an option, if somebody comes up with a plugin for running PropBasic. Geany is available for Windows, Linux, and not so sure about the Apple stuff. With a plugin that would definitely make PropBasic easy to use.
We have had this discussion, about PropBasic at least three other times, and the outcome is always the same, a short flurry of activity and then PropBasic goes dormant. What would make the outcome different this time around?
Ray
I use Geany-
instructions for setting up and using bat files etc are around somewhere, discussed some time ago.
I have no colour coding, but that is not a problem for me.
Uses BSTC
Error reports can be confusing but a little head scratching sorts it out.
Dave
Here are the instructions for Geany as an editor, with instruction for building/loading prop
http://forums.parallax.com/discussion/118611/download-propbasic-here-00-01-14-last-version-for-bst/p27
Dave
I realize that bstc is a 32-bit program, but I would imagine that the program would not run to begin with if that was an issue. Anybody have a solution?
Ray
If anybody is playing along, be careful with the PropBasic manual, the latest that was pointed to for download, the documentation does not necessarily describe correctly how a command is supposed to work. For example, the way I set up the TASK, that is not exactly as the PropBasic manual describes it, unless of course there are multiple ways of doing it.
Ray
to run bstc. Probably has to be refined somewhat, but for a test run it should suffice.
Build->Set Build Commands
Bottom of window:
Execute commands
1 "Execute" | "%d/PropBasic.linux" %d/%e.pbas | /home/ray/propbasic
2 "run bstc" | "%d/bstc.linux" -d /dev/ttyUSB0 -p 0 %d/%e.spin | /home/ray/propbasic
Ray
With the temp Geany solution, if you want to do more, like have the program burned to EEPROM, '-p 1', you will have to make a manual change to the "run bstc" command. I guess this is a little better than working with a bash script. For your next challenge you will have to find and download bstc, happy searching.
Ray
Brad's Spin Tool can be found here:
http://www.fnarfbargle.com/bst.html
It's kind of silly to not have a way to get the absolute address of a label.
Bean
Every LED will need a three state command to turn it on, HIGH, LOW, INPUT, and I think a one state command to turn it off. The specific pin will have to be declared either HIGH, LOW or INPUT, I do not know how this could be done in a workable manner.
I guess you could try implementing something in PASM and then use ASM ... ENDASM, but even that is a little daunting at this stage. Anybody have any ideas?
Ray
You could have a Hub byte for the blue LEDs, with each bit representing one LED.
And either another 1 or 2 Hub bytes for the 2 RGB LEDs, again with 1 bit per color.
I made all the SUBs LMM, not sure what that does for me, but it does run, as expected. I also ran the below program with Propeller IDE, that also ran as expected. This time, using LMM, did not produce an error, when run with Propeller IDE. Not sure what is going on, maybe when you run a TASK in LMM, that produces an error when run in Propeller IDE.
I am hoping that one of the PropBasic experts will give me some hints in how to trim the fat, if there is any fat to be trimmed.
Now I will give the Badge RGB LEDs a try, I think that will be somewhat harder than the plain LEDs. At some point I guess I will have to create lib file that will contain all the code for operating the Hackable Badge.
Ray
Yes. Does not sound like a hard feature to add to OpenSpin ?
I am not sure what PropBasic command I would use to get, for instance, a yellow RGB, to show up. It seems the charlieplexing the RGBs for the other colors, needs a fourth state, which I do not understand. Any ideas out there?
Ray
Provided you have a loop flashing both colors on and off fast enough (I'd aim faster than 50-60Hz), your eye should see the colors as mixed.
When I created the SUBs I was keeping in mind the fact that I did not want to lock in the SUBs functionality to the Badge. Trying to make it as easy as possible to be able to apply it too some other charlieplexed scenario.
I really took notice of how terse the latest documentation is, and I am also wondering if the docs are really describing the latest PropBasic release. I think that when some new people look at the PropBasic docs, they are wondering if they should really get involved with working with PropBasic, but that is just my opinion.
Ray
I also ran it with Propeller IDE which also comes up with errors, since I do not really know PASM at all, somebody proficient in that area will have to make some comments.
I tried to attach some file(s), not sure what is there.
Ray
The culprit, I use Stop: in the SUBs, I guess PropBasic says it's OK, but bstc thinks otherwise. I am not sure what the work around is, use Stop1:, Stop2:, and so on?
Ray
The main code and all of it's SUBs and FUNCs are one task.
Bean
While were on the subject of PropBasic details, I was trying to use the branch command within an if statement, and the compiler kept coming up with an error, not enough variables. In fact I had setup the branch just like what you show in the docs. The reason I ask is because I wanted to set up something like a switch command.
Ray
Defined TASKs can have SUB and FUNCs too. But they need to be fully declared within the TASK..ENDTASK body.
Can you submit a small program that uses BRANCH in an IF that shows the problem. To be honest I've not used BRANCH hardly ever.
P.S. Of course HUB variables are global for all tasks.
Bean
Edit oops made a mistake- was going to suggest using the EXIT command (rather then GOTO) but it seems that does not work in 'IF' commands ...
Edit again
It seems to me the goto and exit are uneccesary anyway in this case
Dave
Well that makes life a little harder, now if I have to keep control of multiple same labels, how many variations on the word stop are their, amongst the SUBs, and with in TASKS.
Ray
Ray
That is, if the test is true, call the sub. You've already tested the variable, so any test by branch is redundant.
I don't know if branch will allow the use of a subroutine, I would think if you're selecting between subs the better choice would be On.... GOSUB. But when you've already tested, even that is redundant.
-Bob
In the docs "IF var cond value THEN label", this format did not work, the bstc compiler came up with an error, something along the lines of needs a unique name. I changed back to the format I have below, and now it works without any errors. Again some detailed examples might be in order.
Ray
Since that might be a place for something like a switch statement, based on my reading of the documentation, I think you could use: