Thanks Bean!
I'd been mistakenly updating from the www.PropBASIC website, thinking it the primary source.
Now I know better.
With the new version your demo file sounds like a car alarm as opposed to a monster
hunting in the deep sometime in the future. I wondered about your musical tastes that you
would choose such a rumbling, uneasy soundbite!
It also explains some of the strange performance while I was playing with it ...
T o n y
Reading this thread was like one of those books you just can't put down! The work Bean and JonnyMac are doing is beyond belief. I know it will pay off for Parallax and I sincerely hope it pays off for them, as well.
To all forum members: · If you have some code you'd like to see converted (from PBASIC or SX/B specifically) just post it in this thread and I'll have a go at it. · I just ask that you have the propeller hardware to try the PropBASIC code on to see if it works.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
@Bean, I noticed you cover NTSC, but, will you be creating any demo programs for VGA? To bad PropBasic does not have a .lib provision, could be a way of saving some time, instead of re-inserting all of the code all of the time.
@Ray
There is the LOAD command within PropBASIC, which I believe would enable some of the functionality
of the dot-LIB that you suggest ...
@Bean
... except that I haven't yet fathomed out how to get it to work!
Is there any chance of a working example of PropBASIC script that uses LOAD to call your tonegenerator.pbas code?
T o n y
TonyWaite said...
@Bean
... except that I haven't yet fathomed out how to get it to work!
Is there any chance of a working example of PropBASIC script that uses LOAD to call your tonegenerator.pbas code?
T o n y
Tony, · The only "trick" is that you need two files. One for the definitions at the beginning of the program. And another for the actual code at the end of the program.
· Here I have put the instructions into one file named "ToneGen.hdr" for the header. And "ToneGen.cod" for the code. You can use whatever extension works best for you.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
Peter Verkaik had a good suggestion when doing this in SX/B so that code in the files could be syntax highlighted (I do this with EditPlus). You could name the files to be loaded:
TONEGEN_DEFS.PBAS
TONEGEN_CODE.PBAS
This is what I'm doing with a LCD project that I'm working through now.
I was looking through the DEMO code, and something very essential is missing. Where is the SIRCS propBASIC version? I would like to see how propBASIC deals with the asm code, and the timing that would be necessary?
New Year's resolution and note to self: check this thread daily!
A lot has happened in the last few weeks. Very excitiing.
I've got a few questions and they lead on to some other questions.
Firstly, great to see the beginnings of strings on the 4th Jan. Looking at that code, I see there is something in a data statement and then there is output of an inline string. Mbasic from 30 years ago had
A$="Hello"
PRINT A$
where A$ never was declared, could be of any length and strings were denoted with $.
Basic moved on from that and copied what I think was a very positive aspect of C when it required the variable to be declared before it could be used. Variants on
Dim A as String
A="Hello"
Print A
The Dim told the compiler to reserve some space for A and then any references to A in the program would point the compiler to that memory location. If you want to make sure there is enough room for big strings, some variants of basic reserved 32 bytes. Or a number of bytes specified by the programmer.
So that leads to a question; is memory 'precious'? Which leads to another question - if prop basic is being compiled to pasm and then run as pasm, does that mean a program has to fit into a cog?
There is some code there from last week which shows something even more cunning - string manipulation subroutines that are written in prop basic itself. I think this shows the program has now evolved into something very useful. If you can do one string subroutine that works one byte at a time, you can add some others like left() and mid(), and do those as basic subroutines rather than as part of the language.
I've got some assembly string handling I'd like to try converting to prop basic subroutines. I think I'm almost there understanding where string data is stored, but I'm not sure if it is in one dimensional named arrays or whether it is in data statements where the data ends up being changed.
There is an article in Nuts and Volts Jan 2010 by JonnyMac about that very same thing. (Assembly).
Remember, PBasic is still in Beta and timing might be a moving target. ·
Rsadeika said...
I was looking through the DEMO code, and something very essential is missing. Where is the SIRCS propBASIC version? I would like to see how propBASIC deals with the asm code, and the timing that would be necessary?
Rsadeika said...
I was looking through the DEMO code, and something very essential is missing. Where is the SIRCS propBASIC version? I would like to see how propBASIC deals with the asm code, and the timing that would be necessary?
Ray
Remember, PropBASIC is just a couple months old (still in early beta) and just because you want SIRCS for it does not make it "essential" (I say this because my SIRCS RX object in Obex has only been downloaded 65 times). The WIP docs show how PropBASIC handles ASM, using the same ASM..ENDASM block from SX/B. Put your SIRCS decoder in a TASK so that it can run on its own and communicate between the task and the main cog using hub variables.
My January column (posted online) shows how to receive and transmit SIRCS codes with the Propeller (my code is in PASM). This wouldn't be very difficult to move to PropBASIC, and would be a really good experience for you to code yourself.
Post Edited (JonnyMac) : 1/12/2010 12:55:48 AM GMT
As far as strings go...They are typically stored in HUB ram, because in COG ram they require 1 LONG per character and COG ram is precious.
You can store strings in DATA lines. Or you can pass a string to a subroutine. So you could in fact use:
PRINT "Hello there"
If you made a subroutine named PRINT with 1 parameter. That parameter being a location in HUB ram·(using RDBYTE to get each character).
As far as working on variable strings, that is not something that typically gets done on a microcontroller very often. It can be done, but it takes alot of space.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
I don't know how many member's have a BOE-BOT and a Propeller Proto board...But if you do you can make a decent robot.
Here is some code I wrote for a Prop-BOT with a Ping.
' PropBOT (BOE-BOT with Propeller Protoboard)
'
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
' Define CONs
LeftStop CON 1524 ' 1520 TO 1528 (You may need to adjust these values for your servos)
RightStop CON 1530 ' 1526 TO 1533
' Define PINs
LeftServo PIN 0 LOW ' Left servo controlled by pin 0
RightServo PIN 1 LOW ' Right servo controlled by pin 1
PingPin PIN 2 LOW ' Ping controlled by PIN 2 through a 1K resistor
' Define HUB variables
LeftSpeed HUB LONG = 0 ' Left servo current speed
RightSpeed HUB LONG = 0 ' Right servo current speed
LeftGoal HUB LONG = 0 ' Left servo speed wanted
RightGoal HUB LONG = 0 ' Right servo speed wanted
' Define DATA (DATA, WDATA, LDATA)
' none
' Define TASKs
MoveServos TASK
' Define variables (LONGs only)
temp VAR LONG
dist VAR LONG
' Define Subroutines
ServoDir SUB 2 ' Left (-200 to +200), Right(-200 to +200) -200=full backwards; 0 = stop; +200=full forwards
PingDist FUNC 0 ' Returns inches
' Start of main code
PROGRAM Start
Start:
COGSTART MoveServos
DO
' Move forward until something is < 20 inches away
ServoDir 200, 200
DO
PAUSE 10
dist = PingDist
LOOP UNTIL dist < 20
' Backup a little bit
ServoDir -200, -200
PAUSE 1000
DO
' Turn slightly right
ServoDir 200, -200
PAUSE 200
' Stop turning
ServoDir 0, 0
PAUSE 500
' Measure distance
dist = PingDist
LOOP UNTIL dist > 20 ' Keep turning until distance is > 20
LOOP
END
' Subroutine Code
SUB ServoDir ' Left, Right
WRLONG LeftGoal, __param1, __param2
ENDSUB
FUNC PingDist ' Returns inches
ReStart:
PULSOUT PingPin, 5 ' Trigger PING
PAUSEUS 5 ' Needs to stay low for a little while
PULSIN PingPin, 1, __param1
__param1 = __param1 * 1_000 ' Convert to inches
__param1 = __param1 / 73_746
RETURN __param1
ENDFUNC
' ----------------------------------------------------------------------------
' Task Code (Runs simultaniously in a seperate cog)
TASK MoveServos
speed VAR LONG
goal VAR LONG
DO
RDLONG LeftSpeed, speed ' Get left servo speed
RDLONG LeftGoal, goal ' Get left servo goal
goal = goal - speed ' goal = delta
goal = goal MAX 10 ' keep delta(goal) with in +/- 10uSec
goal = goal MIN -10
speed = speed + goal ' Adjust speed by delta (goal)
WRLONG LeftSpeed, speed ' Save new left servo speed
speed = LeftStop + speed ' Add left servo stopping value to speed
PULSOUT LeftServo, speed ' Send pulse to left servo
PAUSE 10 ' Pause 10, so servos don't move at the same time
RDLONG RightSpeed, speed ' Get right servo speed
RDLONG RightGoal, goal ' Get right servo goal
goal = goal - speed ' goal = delta
goal = goal MAX 10 ' keep delta(goal) within +/- 10uSec
goal = goal MIN -10
speed = speed + goal ' Adjust speed by delta(goal)
WRLONG RightSpeed, speed ' Save new right servo speed
speed = RightStop - speed ' Add right servo stopping value to speed
PULSOUT RightServo, speed ' Send pulse to right servo
PAUSE 10 ' Pause 10, so servos don't move at the same time
LOOP
ENDTASK
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
I've got 512k of external ram to play with and I'm pondering some propbasic routines to use it.
Code was originally written in spin but it was just a bit slow, so it was ported to pasm. But I understand that propbasic gets compiled to pasm? So if I write a line of propbasic code to make a pin go high, that gets converted to a tiny bit of pasm code, right?
Another instruction for example, the <<. I can see how that would be converted to pasm, maybe only one pasm instruction.
Or - even simpler, I see that inline assembly code is possible. So maybe one could take some existing external ram assembly code and drop it into a propbasic subroutine?
I still don't quite understand the code limitations. Is a prop basic program limited to 2k? Or are you using overlays or some other technique to fit more code in?
Also I still don't understand local and global variables. Are variables declared locally in subroutines or are they all global? They all look global in that latest code example, but is that because they always are, or because that particular code example doesn't have local variables?
Gee. I lobbied very hard for a version of BASIC for the Propeller. However, until I saw Bean's simple·servo code above, I really never understood what the Propeller could do for ME.
Obviously, it would pretty much eliminate my use of multiple Stamps and/or SXs. I don't know if I can come up with any more excuses for not buying into the Prop world.
Hub variables can be Longs, words, or bytes.
Hub variables are accessible to all tasks.
Task variables are local. They are longs because thet reside in cog ram.
Each Task runs in its own Cog. That's 16k for starters
Yes its compiled to PASM, no interpreter required
Not optimized PASM code,·but it·looks very fast.
I have been looking at the issue of xram also. Whilst only 7 tasks can be active at any one time. It would be interesting to know if more than 7 tasks could be declared so that the main program can stop a task and start another task. I can see a way to use xmem using one cog to overlay tasks into·hub ram.· Maybe Bean will shed some light on this. I did ask the question a while ago but it was over looked.
Ron
Post Edited (Ron Sutcliffe) : 1/12/2010 2:48:39 AM GMT
Each task (the main code is a task too) runs in it's own cog. That is 496 instructions per COG (or TASK).
There are no local variables for subroutines. All COG variables are global. There are __paramx variables that hold values that are passed to a subroutine, but the __paramx variables can also be used like a regular variable in the subroutine. Just be careful if you nest subroutines.
The compiler is single pass. So it compiles very fast, and the generated code (while not optimized for size) runs very fast.
Also as you pointed out, since the compiler generates straight PASM code, in-line PASM is very easy to use (if you know PASM).
Future versions of the compiler will hopefully be able to generate LMM (Large memory model) code. This will be by TASK. So the main code can be LMM and other TASKs in the same program can be straight PASM (video drivers etc).
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
Can we declare mode than 7 tasks at compile time even if they are not all started at the same time. They could be started and stopped to a max of 7 plus main ?
Can we declare mode than 7 tasks at compile time even if they are not all started at the same time. They could be started and stopped to a max of 7 plus main ?
Ron
Oh, sure you can have as many as will fit into the 32K EEPROM (In Theory).
They can be started and stopped at will.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
Thanks Ron/Bean. Essentially it appears to be basic designed to work best with prop architecture.
So - 2k cogs and a hub. Ok, racing ahead with brainstorming evrything, I get to the same point Ron is at:
" It would be interesting to know if more than 7 tasks could be declared so that the main program can stop a task and start another task. I can see a way to use xmem using one cog to overlay tasks into hub ram."
How could this work? Well, lets say a compiler takes a chunk of code and compiles it so it fits in a cog. It becomes a self contained binary - just a list of bytes. You could load any number of those binary files into external ram, or external sd card, and as long as they had a name, it should be possible to call them as if they were subroutines.
A trivial example - a cog 'binary' for adding two numbers. Grab it from sd/external ram, put it in a cog, pass the variables, run it, get the answer, stop the cog. If the main program could do that, it makes the program easily expandable to many megabytes in size.
The compiler would need to flag that the code fits, which I think is easy with the FIT command.
All you need then is a common place to transfer data to and from cogs. You may not need much - maybe 10 longs or whatever, and when you call one of these cog subroutines, you pass 10 longs and when it finishes then it returns those 10 longs. Those longs could sit at the top of hub ram and I think reading them assembles to a few lines of assembly. I guess that is an issue - some sort of standardised I/O to cogs. I think this has been pondered before.
The 'main' program is a list of calls to subroutines such that the 'main' is a short piece of code that easily fits in hub.
Next challenge to think about - is there enough propbasic code already written to do the above in propbasic itself without any changes to the compiler? I might sleep on that one, but my gut feeling is that it may well be possible.
I don't want Hijack this thread, but I·am doing this. Two Props, Prop1 uses 2 cogs for SDcard·driver,·1cog Xram, 1cog SDcard port,·1cog xram port. Coded Spin and PASM.··(5 cogs)
Prop 2 uses·Beans PropBasic·serial I/O(using messages)·to access Prop1 via the two ports. I just need to set up a dummy file area in HUB·from which I can down a file from xmem or sdcard and then get main to load a task from that area.· Pretty crude·but just wanted to see how useful Probasic might be, and I am impressed·with how easy it is to use.·Beans previous SX compiler experience shows.
The boards I'm using have sd card and external ram, and with the hardware and building blocks of the software all working, I'm starting to think about other things besides CP/M.
One of the things I see as a problem with spin (maybe there is a way round this) is you write a whole lot of code and some of that code sits in hub and is transferred to the cog and run in the cog, but it also ends up sitting in the hub forever and taking up room.
Further, let's say you transferred some code to a cog (call it a cog subroutine), if that freed up n bytes in hub, it would be very useful to know where exactly those n bytes were so you could then reuse that space. As I see it, the location of those bytes changes each time you edit the main program.
So where you say "I just need to set up a dummy file area in HUB from which I can down a file from xmem or sdcard and then get main to load a task from that area." it looks like you are working on the same thing, a dummy file area for cog code.
This could instantly save a whole lot of hub space in a program, as say you had 7 cogs running with 7 bits of 2k cog code, well you could replace that with one dummy file area and feed those 7 cog programs through that dummy area one at a time.
So - do you have that working yet?
Is there a way in propbasic of (say) reserving an area of memory? (maybe even in spin). Reserve 2k and put a pointer at the beginning and reference that pointer.
I don't think you even need external memory for this - sd card ought to be enough and even if it is a bit slower it could prove the concept of pulling in subroutines and running them as needed. There are schematics out there for standard SD connections to the standard prop boards so anyone could join in the fun!
@drac
All I was suggesting was to run the stock standard SDcard software availble from the OBEX on one Prop and communicate with it via a dedicated port on a Prop running Probasic. (yes done that bit) I was thinking that if by creating a dummy file area in Hub, where a file can be downloaded from the SD card. It maybe possible to get some sort of crude task swapping going. ATM I am just interested in what PropBasic can do and trying a few things for myself.
@Bean
@JonnyMac
Thanks for the advice re. calling in PropBASIC code.
@Ron
I can see why you're tempted with the dual-Prop approach, one running the Spin modules and
the other PropBASIC. But I'm confident that as the PropBASIC community takes off we'll soon
develop techniques to get around the Spin/PropBASIC interworking issues and make them
relatively transparent; as well, PropBASIC code will be contributed to give us the equivalent of
a PropBASIC Obex.
Guys,
I don't mind you brainstorming here at all. Anything to bump this post [noparse];)[/noparse]
This discussion is all very interesting, but PropBASIC is designed for the BS2 user. So things need to be simple (not that BS2 users are simple) and easy to understand.
The compiler just generates straight PASM, so anything you can do in PASM you should be able to do in PropBASIC. The "trick" is that the compiler is single pass, so things need to be put in a certain order so the compiler "knows" about stuff.
That is not to say that you guys might be able to get PropBASIC to "sit-up-and-beg", and that would be great. But it's not the focus right now. The focus right now is to try to arm twist forum members into writing code with PropBASIC so we can discover any bugs (Oh, and they are in there. I know).
P.S. To reserve space, just declare a HUB variable as an array.
MyCode HUB LONG(512)
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
Sorry Bean, I keep forgetting that this is a beta testing exercise. I have to dampen my enthusiasm for propBASIC, keep reminding myself to keep it simple, and straight forward. I will try to keep the suggestions to a minimum, and then after it gets released ...
Comments
Download version 00.00.58 that I just posted.
That will leave _Freq alone so you don't have to declare it.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134·
I'd been mistakenly updating from the www.PropBASIC website, thinking it the primary source.
Now I know better.
With the new version your demo file sounds like a car alarm as opposed to a monster
hunting in the deep sometime in the future. I wondered about your musical tastes that you
would choose such a rumbling, uneasy soundbite!
It also explains some of the strange performance while I was playing with it ...
T o n y
Sorry about that. I haven't been updating the website.
I just did now, but this post will always have the latest version first.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134·
Reading this thread was like one of those books you just can't put down! The work Bean and JonnyMac are doing is beyond belief. I know it will pay off for Parallax and I sincerely hope it pays off for them, as well.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Could you change the date in the title? It would be cruel to make us wait 11 months for the next installment
Jim
· Sorry about that. I'll get that fixed.
To all forum members:
· If you have some code you'd like to see converted (from PBASIC or SX/B specifically) just post it in this thread and I'll have a go at it.
· I just ask that you have the propeller hardware to try the PropBASIC code on to see if it works.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134·
Ray
There is the LOAD command within PropBASIC, which I believe would enable some of the functionality
of the dot-LIB that you suggest ...
@Bean
... except that I haven't yet fathomed out how to get it to work!
Is there any chance of a working example of PropBASIC script that uses LOAD to call your tonegenerator.pbas code?
T o n y
· The only "trick" is that you need two files. One for the definitions at the beginning of the program. And another for the actual code at the end of the program.
· Here I have put the instructions into one file named "ToneGen.hdr" for the header. And "ToneGen.cod" for the code. You can use whatever extension works best for you.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
TONEGEN_DEFS.PBAS
TONEGEN_CODE.PBAS
This is what I'm doing with a LCD project that I'm working through now.
Ray
A lot has happened in the last few weeks. Very excitiing.
I've got a few questions and they lead on to some other questions.
Firstly, great to see the beginnings of strings on the 4th Jan. Looking at that code, I see there is something in a data statement and then there is output of an inline string. Mbasic from 30 years ago had
A$="Hello"
PRINT A$
where A$ never was declared, could be of any length and strings were denoted with $.
Basic moved on from that and copied what I think was a very positive aspect of C when it required the variable to be declared before it could be used. Variants on
Dim A as String
A="Hello"
Print A
The Dim told the compiler to reserve some space for A and then any references to A in the program would point the compiler to that memory location. If you want to make sure there is enough room for big strings, some variants of basic reserved 32 bytes. Or a number of bytes specified by the programmer.
So that leads to a question; is memory 'precious'? Which leads to another question - if prop basic is being compiled to pasm and then run as pasm, does that mean a program has to fit into a cog?
There is some code there from last week which shows something even more cunning - string manipulation subroutines that are written in prop basic itself. I think this shows the program has now evolved into something very useful. If you can do one string subroutine that works one byte at a time, you can add some others like left() and mid(), and do those as basic subroutines rather than as part of the language.
I've got some assembly string handling I'd like to try converting to prop basic subroutines. I think I'm almost there understanding where string data is stored, but I'm not sure if it is in one dimensional named arrays or whether it is in data statements where the data ends up being changed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Remember, PBasic is still in Beta and timing might be a moving target.
· Post Edited (hover1) : 1/12/2010 1:08:48 AM GMT
Remember, PropBASIC is just a couple months old (still in early beta) and just because you want SIRCS for it does not make it "essential" (I say this because my SIRCS RX object in Obex has only been downloaded 65 times). The WIP docs show how PropBASIC handles ASM, using the same ASM..ENDASM block from SX/B. Put your SIRCS decoder in a TASK so that it can run on its own and communicate between the task and the main cog using hub variables.
My January column (posted online) shows how to receive and transmit SIRCS codes with the Propeller (my code is in PASM). This wouldn't be very difficult to move to PropBASIC, and would be a really good experience for you to code yourself.
Post Edited (JonnyMac) : 1/12/2010 12:55:48 AM GMT
You can store strings in DATA lines. Or you can pass a string to a subroutine. So you could in fact use:
If you made a subroutine named PRINT with 1 parameter. That parameter being a location in HUB ram·(using RDBYTE to get each character).
As far as working on variable strings, that is not something that typically gets done on a microcontroller very often. It can be done, but it takes alot of space.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
Post Edited (Bean (Hitt Consulting)) : 1/12/2010 12:52:19 AM GMT
Here is some code I wrote for a Prop-BOT with a Ping.
' PropBOT (BOE-BOT with Propeller Protoboard) ' DEVICE P8X32A, XTAL1, PLL16X FREQ 80_000_000 ' Define CONs LeftStop CON 1524 ' 1520 TO 1528 (You may need to adjust these values for your servos) RightStop CON 1530 ' 1526 TO 1533 ' Define PINs LeftServo PIN 0 LOW ' Left servo controlled by pin 0 RightServo PIN 1 LOW ' Right servo controlled by pin 1 PingPin PIN 2 LOW ' Ping controlled by PIN 2 through a 1K resistor ' Define HUB variables LeftSpeed HUB LONG = 0 ' Left servo current speed RightSpeed HUB LONG = 0 ' Right servo current speed LeftGoal HUB LONG = 0 ' Left servo speed wanted RightGoal HUB LONG = 0 ' Right servo speed wanted ' Define DATA (DATA, WDATA, LDATA) ' none ' Define TASKs MoveServos TASK ' Define variables (LONGs only) temp VAR LONG dist VAR LONG ' Define Subroutines ServoDir SUB 2 ' Left (-200 to +200), Right(-200 to +200) -200=full backwards; 0 = stop; +200=full forwards PingDist FUNC 0 ' Returns inches ' Start of main code PROGRAM Start Start: COGSTART MoveServos DO ' Move forward until something is < 20 inches away ServoDir 200, 200 DO PAUSE 10 dist = PingDist LOOP UNTIL dist < 20 ' Backup a little bit ServoDir -200, -200 PAUSE 1000 DO ' Turn slightly right ServoDir 200, -200 PAUSE 200 ' Stop turning ServoDir 0, 0 PAUSE 500 ' Measure distance dist = PingDist LOOP UNTIL dist > 20 ' Keep turning until distance is > 20 LOOP END ' Subroutine Code SUB ServoDir ' Left, Right WRLONG LeftGoal, __param1, __param2 ENDSUB FUNC PingDist ' Returns inches ReStart: PULSOUT PingPin, 5 ' Trigger PING PAUSEUS 5 ' Needs to stay low for a little while PULSIN PingPin, 1, __param1 __param1 = __param1 * 1_000 ' Convert to inches __param1 = __param1 / 73_746 RETURN __param1 ENDFUNC ' ---------------------------------------------------------------------------- ' Task Code (Runs simultaniously in a seperate cog) TASK MoveServos speed VAR LONG goal VAR LONG DO RDLONG LeftSpeed, speed ' Get left servo speed RDLONG LeftGoal, goal ' Get left servo goal goal = goal - speed ' goal = delta goal = goal MAX 10 ' keep delta(goal) with in +/- 10uSec goal = goal MIN -10 speed = speed + goal ' Adjust speed by delta (goal) WRLONG LeftSpeed, speed ' Save new left servo speed speed = LeftStop + speed ' Add left servo stopping value to speed PULSOUT LeftServo, speed ' Send pulse to left servo PAUSE 10 ' Pause 10, so servos don't move at the same time RDLONG RightSpeed, speed ' Get right servo speed RDLONG RightGoal, goal ' Get right servo goal goal = goal - speed ' goal = delta goal = goal MAX 10 ' keep delta(goal) within +/- 10uSec goal = goal MIN -10 speed = speed + goal ' Adjust speed by delta(goal) WRLONG RightSpeed, speed ' Save new right servo speed speed = RightStop - speed ' Add right servo stopping value to speed PULSOUT RightServo, speed ' Send pulse to right servo PAUSE 10 ' Pause 10, so servos don't move at the same time LOOP ENDTASKBean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
Post Edited (Bean (Hitt Consulting)) : 1/12/2010 1:20:16 AM GMT
I've got 512k of external ram to play with and I'm pondering some propbasic routines to use it.
Code was originally written in spin but it was just a bit slow, so it was ported to pasm. But I understand that propbasic gets compiled to pasm? So if I write a line of propbasic code to make a pin go high, that gets converted to a tiny bit of pasm code, right?
Another instruction for example, the <<. I can see how that would be converted to pasm, maybe only one pasm instruction.
Or - even simpler, I see that inline assembly code is possible. So maybe one could take some existing external ram assembly code and drop it into a propbasic subroutine?
I still don't quite understand the code limitations. Is a prop basic program limited to 2k? Or are you using overlays or some other technique to fit more code in?
Also I still don't understand local and global variables. Are variables declared locally in subroutines or are they all global? They all look global in that latest code example, but is that because they always are, or because that particular code example doesn't have local variables?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 1/12/2010 1:22:28 AM GMT
Gee. I lobbied very hard for a version of BASIC for the Propeller. However, until I saw Bean's simple·servo code above, I really never understood what the Propeller could do for ME.
Obviously, it would pretty much eliminate my use of multiple Stamps and/or SXs. I don't know if I can come up with any more excuses for not buying into the Prop world.
--Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You are what you write.
Reading the manual.
Hub variables can be Longs, words, or bytes.
Hub variables are accessible to all tasks.
Task variables are local. They are longs because thet reside in cog ram.
Each Task runs in its own Cog. That's 16k for starters
Yes its compiled to PASM, no interpreter required
Not optimized PASM code,·but it·looks very fast.
I have been looking at the issue of xram also. Whilst only 7 tasks can be active at any one time. It would be interesting to know if more than 7 tasks could be declared so that the main program can stop a task and start another task. I can see a way to use xmem using one cog to overlay tasks into·hub ram.· Maybe Bean will shed some light on this. I did ask the question a while ago but it was over looked.
Ron
Post Edited (Ron Sutcliffe) : 1/12/2010 2:48:39 AM GMT
There are no local variables for subroutines. All COG variables are global. There are __paramx variables that hold values that are passed to a subroutine, but the __paramx variables can also be used like a regular variable in the subroutine. Just be careful if you nest subroutines.
The compiler is single pass. So it compiles very fast, and the generated code (while not optimized for size) runs very fast.
Also as you pointed out, since the compiler generates straight PASM code, in-line PASM is very easy to use (if you know PASM).
Future versions of the compiler will hopefully be able to generate LMM (Large memory model) code. This will be by TASK. So the main code can be LMM and other TASKs in the same program can be straight PASM (video drivers etc).
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134·
Thanks, yes forgot to mention __params.
Can we declare mode than 7 tasks at compile time even if they are not all started at the same time. They could be started and stopped to a max of 7 plus main ?
Ron
They can be started and stopped at will.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
Post Edited (Bean (Hitt Consulting)) : 1/12/2010 3:35:40 AM GMT
Thanks for clearing that up.
I do hope others take the time to look at what you have done.
Ron
So - 2k cogs and a hub. Ok, racing ahead with brainstorming evrything, I get to the same point Ron is at:
" It would be interesting to know if more than 7 tasks could be declared so that the main program can stop a task and start another task. I can see a way to use xmem using one cog to overlay tasks into hub ram."
How could this work? Well, lets say a compiler takes a chunk of code and compiles it so it fits in a cog. It becomes a self contained binary - just a list of bytes. You could load any number of those binary files into external ram, or external sd card, and as long as they had a name, it should be possible to call them as if they were subroutines.
A trivial example - a cog 'binary' for adding two numbers. Grab it from sd/external ram, put it in a cog, pass the variables, run it, get the answer, stop the cog. If the main program could do that, it makes the program easily expandable to many megabytes in size.
The compiler would need to flag that the code fits, which I think is easy with the FIT command.
All you need then is a common place to transfer data to and from cogs. You may not need much - maybe 10 longs or whatever, and when you call one of these cog subroutines, you pass 10 longs and when it finishes then it returns those 10 longs. Those longs could sit at the top of hub ram and I think reading them assembles to a few lines of assembly. I guess that is an issue - some sort of standardised I/O to cogs. I think this has been pondered before.
The 'main' program is a list of calls to subroutines such that the 'main' is a short piece of code that easily fits in hub.
Next challenge to think about - is there enough propbasic code already written to do the above in propbasic itself without any changes to the compiler? I might sleep on that one, but my gut feeling is that it may well be possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I don't want Hijack this thread, but I·am doing this. Two Props, Prop1 uses 2 cogs for SDcard·driver,·1cog Xram, 1cog SDcard port,·1cog xram port. Coded Spin and PASM.··(5 cogs)
Prop 2 uses·Beans PropBasic·serial I/O(using messages)·to access Prop1 via the two ports. I just need to set up a dummy file area in HUB·from which I can down a file from xmem or sdcard and then get main to load a task from that area.· Pretty crude·but just wanted to see how useful Probasic might be, and I am impressed·with how easy it is to use.·Beans previous SX compiler experience shows.
Ron
The boards I'm using have sd card and external ram, and with the hardware and building blocks of the software all working, I'm starting to think about other things besides CP/M.
One of the things I see as a problem with spin (maybe there is a way round this) is you write a whole lot of code and some of that code sits in hub and is transferred to the cog and run in the cog, but it also ends up sitting in the hub forever and taking up room.
Further, let's say you transferred some code to a cog (call it a cog subroutine), if that freed up n bytes in hub, it would be very useful to know where exactly those n bytes were so you could then reuse that space. As I see it, the location of those bytes changes each time you edit the main program.
So where you say "I just need to set up a dummy file area in HUB from which I can down a file from xmem or sdcard and then get main to load a task from that area." it looks like you are working on the same thing, a dummy file area for cog code.
This could instantly save a whole lot of hub space in a program, as say you had 7 cogs running with 7 bits of 2k cog code, well you could replace that with one dummy file area and feed those 7 cog programs through that dummy area one at a time.
So - do you have that working yet?
Is there a way in propbasic of (say) reserving an area of memory? (maybe even in spin). Reserve 2k and put a pointer at the beginning and reference that pointer.
I don't think you even need external memory for this - sd card ought to be enough and even if it is a bit slower it could prove the concept of pulling in subroutines and running them as needed. There are schematics out there for standard SD connections to the standard prop boards so anyone could join in the fun!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
All I was suggesting was to run the stock standard SDcard software availble from the OBEX on one Prop and communicate with it via a dedicated port on a Prop running Probasic. (yes done that bit) I was thinking that if by creating a dummy file area in Hub, where a file can be downloaded from the SD card. It maybe possible to get some sort of crude task swapping going. ATM I am just interested in what PropBasic can do and trying a few things for myself.
Ron
@JonnyMac
Thanks for the advice re. calling in PropBASIC code.
@Ron
I can see why you're tempted with the dual-Prop approach, one running the Spin modules and
the other PropBASIC. But I'm confident that as the PropBASIC community takes off we'll soon
develop techniques to get around the Spin/PropBASIC interworking issues and make them
relatively transparent; as well, PropBASIC code will be contributed to give us the equivalent of
a PropBASIC Obex.
T o n y
I don't mind you brainstorming here at all. Anything to bump this post [noparse];)[/noparse]
This discussion is all very interesting, but PropBASIC is designed for the BS2 user. So things need to be simple (not that BS2 users are simple) and easy to understand.
The compiler just generates straight PASM, so anything you can do in PASM you should be able to do in PropBASIC. The "trick" is that the compiler is single pass, so things need to be put in a certain order so the compiler "knows" about stuff.
That is not to say that you guys might be able to get PropBASIC to "sit-up-and-beg", and that would be great. But it's not the focus right now. The focus right now is to try to arm twist forum members into writing code with PropBASIC so we can discover any bugs (Oh, and they are in there. I know).
P.S. To reserve space, just declare a HUB variable as an array.
MyCode HUB LONG(512)
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134·
Ray