I'm coding Sbasic and compiled Mbasic on a propeller right now. It works fine, but is a little lacking in speed. eg I want to capture data coming back from a remote wireless login to another propeller at 19200 baud, and compiled Mbasic on the zicog is struggling to keep up (it is jolly close though, about 95% of a "DIR" comes back intact). Not surprising in a way becuase it is emulating at maybe 1000 instructions per second.
Move over to propbasic and it could go *much* faster. And maybe with not much editing needed on the code.
Re BS2 users, there are other target markets too for people who want to program Basic on small microcontrollers. The key is making it simple, and prop basic is doing a fantastic job with some great potential (and to be unbiased, I'll say that for C programmers, Catalina is doing a similar job).
I'm excited about pushing the boundaries with the code already written. So re;
"MyCode HUB LONG(512)"
I'm working my way throught the manual on the first page of this thread. I found Mycode is an array (page 14). Cool, I can fill the array with 2k from an sd card. That will work.
I'm a bit confused about "tasks". Page 17 of the manual is "Tasks" but the page is blank. I think tasks are another name for cog code, is that right?
Let's say I have 2k (512 longs) of code that is now in Mycode array. How would I move that code to, say, the next available cog and then start the cog?
The "manual" that you are referring to, is the jonnymac document? That is a very preliminary document with a lot of stuff that has not been covered. As to 'task', think 'TASK' = cog, there is an example, in Bean's PropBASIC document, as to how to use it. This is the document that is in the propBASIC zip file. Basically, you define (name) the 'TASK', place your code within the task confines, and then start the task in your main portion of the program.
TASK is basically the same as a SPIN object. Except it is all in one source file.
You create a TASK header (this tells the compiler the task exists). Then you can use the do a "COGSTART taskname" to start the task. The actual TASK code comes at the end of the program.
Remember that since a TASK is code running in a different cog, you need to use HUB variables to communicate with it.
Take a look at the Prop-BOT code that I posted yesterday at 8:15pm (I put the code right in the post).
This uses a TASK to control the servo pulses. You set the HUB variable "goal", and the TASK will move the servo to the goal setting slowly. This avoids jerking the bot around and prevents power dips too.
Also look at the Serial_to_NTSC program in the demos folder.
This uses 3 cogs, one runs the main program, one receives serial data, and one generates a 64x24 character display. All written in PropBASIC in one source file.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
Yes, sorry, the JonnyMac document. I found the Bean document now in the page 1 zip. Reading it now...
TASK...ENDTASK Creates code that runs in a separate cog.
name TASK
TASK name
...
ENDTASK
* Task code runs in a separate cogs.
* VAR variables are not shared between cogs.
* SUBs and FUNCs are not shared between cogs.
* HUB variables, PINs and DATA are shared between cogs.
* Use COGSTART or COGINIT to start tasks.
I'm assuming that since this is a single pass compiler, that Task/Endtask gets converted to something like
org 0
start
... code
...data
fit or similar?
Let's take a very simple example. I want a little Task program that takes a variable and multiplies it by 2 and returns it
so my task might be (in token form)
rdlong
shl
wrlong
end
I suppose I could write that on the proptool, find out the bytes it compiled to on a real program, put them on a cog, write a program to read them off the cog, store those bytes and call that a cog subroutine. Propbasic is different as you seem to have more control over the process.
To flesh that out, rdlong needs to read from a known location in hub, and maybe that location should be up the top of hub memory somewhere. Ditto wrlong.
Maybe I'm jumping ahead here, but it would be so cool to have libraries of Task code, that you can drop into propbasic like objects from the obex, and you know that they work. Drop in a keyboard Task (would be very similar to the current object, except that it would return a flag and a byte to two fixed locations in upper hub ram). Drop in a VGA Task. An sd Task. Nothing different to the current way of doing things, except that these tasks may not take any hub memory. You pull them off an external ram or sd card, put them in the cog, run them, then discard them (or leave them running).
Some tasks would run once then end. Some would keep going and you throw variables at them and they return other variables then cycle through (like the external ram driver code from Cluso).
Maybe this is racing ahead too far? But I see so many possibilities! And I see this becoming simpler for the beginner.
Have you considered adding assignment operators such as += and *=? From the few samples I've seen, it appears that assignments are limited to the form
x = x op y
Assignment operators would let you write them
x op= y
which requires less typing, is conceptually clearer (imho), and gives people a nudge toward Spin or C-family languages.
I am using a demo board, I tried the program below, and it sort of works. The LED flashes, but I do not get anything displayed on the PST window, here I used 115200 baud. I tried the serout command all by itself, using 'T' mode, and that did not display anything on the PST window, here I used 9600 baud.
Ray
' ======================================================================
'
' File...... test1.pbas
' Purpose...
' Author....
' E-mail....
' Started...
' Updated...
'
' ======================================================================
' ----------------------------------------------------------------------
' Program Description
' ----------------------------------------------------------------------
'
' ----------------------------------------------------------------------
' Device Settings
' ----------------------------------------------------------------------
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
' ----------------------------------------------------------------------
' Constants
' ----------------------------------------------------------------------
Baud CON "T115200"
HOME CON 1
BKSP CON 8
TAB CON 9
LF CON 10
CLREOL CON 11
CLRDN CON 12
CR CON 13
CLS CON 16
' ----------------------------------------------------------------------
' I/O Pins
' ----------------------------------------------------------------------
TX PIN 30 HIGH
LED PIN 16 LOW
' ----------------------------------------------------------------------
' Shared (hub) Variables (Byte, Word, Long)
' ----------------------------------------------------------------------
alpha VAR Long
' ----------------------------------------------------------------------
' Shared (hub) Data (DATA, WDATA, LDATA, FILE)
' ----------------------------------------------------------------------
' ----------------------------------------------------------------------
' TASK Definitions
' ----------------------------------------------------------------------
' ----------------------------------------------------------------------
' Cog Variables (Long only)
' ----------------------------------------------------------------------
' ----------------------------------------------------------------------
' SUB/FUNC Definitions
' ----------------------------------------------------------------------
TX_BYTE SUB 2, 2 ' shell for SEROUT
DELAY_MS SUB 1, 1 ' shell for PAUSE
' ======================================================================
PROGRAM Start
' ======================================================================
Start:
' Main code goes here
DELAY_MS 10 ' TX idle for 10ms
TX_BYTE TX, CLS
Main:
DO
FOR alpha = "A" TO "Z"
TOGGLE LED
TX_BYTE TX, alpha
DELAY_MS 50
NEXT
TX_BYTE TX, CR
LOOP
END
' ----------------------------------------------------------------------
' SUB/FUNC Code
' ----------------------------------------------------------------------
SUB TX_BYTE
SEROUT __param1, Baud, __param2
ENDSUB
SUB DELAY_MS
PAUSE __param1
ENDSUB
' ----------------------------------------------------------------------
' TASK Code
' ----------------------------------------------------------------------
Me too. Keep in mind that you may be resetting the Propeller with PST and if you didn't download to EEPROM you will lose the program.
Hint: White space is your friend; be careful getting sloppy with your listings as "sloppy" serves as great camouflage for bugs (that may compile just fine).
What is there to setup? I got the right com port, and the correct baud rate, is there something else? I am using Windows 7 64 bit, I ran another Spin program that used the PST without any problems. So, I am not sure what else I should do differently. Running propBASIC in Windows 7 is getting to be a problem, Windows 7 keeps popping up a window that asks me if I want to continue to run the program, and it is a real pain when I do the 'Run' command. I think you might have to consider using another compiler, or it least make it behave with Windows 7.
I have run the Propeller IDE, and seems to behave with Windows 7, it even installed the 64 bit drivers with no problem. I have only had the new system for about a week now, so I have not tried everything out just yet.
Ray,
I use the compiler and PropBASICIDE with windows 7 64-bit.
You need to change the properties of the program so windows stops asking you if you want to run it. It has nothing to do with the compiler.
Yes, you need to choose the correct port and baud rate. All I can tell you is your code works fine on my Windows 7 64-bit system.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
@Rsadeika
It sounds like you are using COMPILE in the PropBasic IDE to create the Spin file and not compiling and loading the Spin file to EEprom. Use the EEPROM in the PropBasic IDE to compile and load the Prop in one step. There are other IDE's if you don't like what Bean has done, (I use Source Edit) but Beans IDE works fine with XP and windows 7.
The way I understand the propBASIC IDE is you have three choices - Compile, Run, and EEPROM. I use the 'Run' option which compiles, and loads it to RAM. As for the IDE itself, I was just making some observations as to how a new user might perceive the experience with propBASIC, when run for the first time. If this is being targeted at the Basic Stamp users, what is the tolerance level that is being used.
As for the program that I posted earlier, it was a direct copy of what is shown in the propBASIC manual, I left everything as is. Again, what will the Basic Stamp user be using as guide to learning the language? Remember, this is BETA testing!
@ Drac
Working code, to demonstate·using SD Card·or any other Spin/Pasm objects on Prop·1··with PinIn =·8 and PinOut·= 9
Prop·2 running the code below· where PinIn = 16 and PinOut = 18
If you want to use one cog for both Keyboard and SD comms you will need to use a flow control method.·I think its best to use two separate tasks
and turn the SD cog on when you need it.
@Tony
Why re-work·all the code in the·OBEX when a you·can use High Speed comms and an extra Prop.·FSRW is a hugh lump of code to port to PropBasic.
This is what I was refering to with Drac·in an earlier post. A·way in·which users·could load and execute·Pbasic files from SD
The screen below uses the code that I posted to handle the file server.
Obviously they will·not be able to save a·Pbasic file to SD but they could save data.
The trick·for me now is·to get the 2K(max) files from SD to the PropHub·ram and get PropBasic to load the file into a free·cog and run it.
The main program will have to reserve 496 longs in HUB ram for the sole purpose of holding· SD based Tasks. ·In other words tasks from SD would
always run within the Main Program (AKA in a·shell)· Its all vapourware at this stage, but its interesting.
Cheers
Ron
BTW the·original code was written using only one cog for SD and Keyboard·but I got few errors and thought that flow control would be messy so I butchered·it and used·two cogs. It will all go out the window when I get a shot·at the rest of the project.
Post Edited (Ron Sutcliffe) : 1/13/2010 1:24:26 PM GMT
Gut feeling here, but I think this might be the hidden key to breaking out of the 32k memory limit of the propeller.
You can fit some nifty routines in 2k. Simple, such as a single floating point math operation. Or complex, like an entire string manipulation library.
So, do these have a name? Would you use an 8.3 naming convention for these, and if so, what would be a suitable extension? .COG? .TSK?
And is there an easy way to create these binary files? Could it be as easy as writing some assembly in the prop tool, starting at org 0 with no spin at the beginning at all (is that allowed?), then compiling it to a binary?
Re the specific questions:
Loading a binary off the sd card.
Pulling apart the dracblade code I think it is something like:
OBJ
sd : "fsrwFemto" ' sd card driver
VAR
byte cogbuff[noparse][[/noparse]2048] 'buffer for a cog binary
PUB
sd.start(variable)
FindDriveBase(0, string("MYFILE.TSK")) ' find where the file is on the sd card so quicker to find next time
CheckSDCard ' init sd card
sd.readSDCard(drive_base[noparse][[/noparse]0], @cogbuff, 2048) ' get 2048 bytes from file in drive_base[noparse][[/noparse]0] and put in cogbuff array
Then the bit I'm not sure about; move the bytes from the cogbuff array into the cog itself, start the cog, run it, set a flag when it gets to the end.
You might only have one 'working' cog for this. Thinking of the dracblade, most of the cogs end up so useful for other things - fsrw, vga (x2?), keyboard, serial ports, ram
so maybe only one or two left over. But you can do so much with those if the way of loading them and talking to them ends up being only (say) one line of code, say a call to a subroutine with some parameters (filename.tsk, long1, long2 and returns long1,2 etc)
Well, I solved my problem with displaying the test1 program using PST. I have a propplug, and the demo board plugged in at the same time, which created a com3, com4 ports. Because propBASIC does not have a preferences, I assumed it was using com4, wrong choice, the choice should of been com3.
@ron, I just looked at your program, and I am assuming you have an SD card reader attached on pin 16. Are you using a serial communications setup, because the code does not look like spi to me, or am I wrong on that? If that is the case, have you tried writing to the SD card, and what kind of speed differences are you noticing compared to using spi code? You have a very interesting short program to learn from.
This is a test to see whether a program written in SX/B, will be compiled. The original SX/B program used 'byte' which I changed to 'long'. This program when compiled, has an error, in the 'sub GET_SIRCS' -
temp2 = GET_IR_PULSE
error 5 invalid parameter "GET_IR_PULSE"; ...
'
' Shared (hub) Variables (Byte, Word, Long)
'
cmdCode var long
devCode var long
temp1 var long
temp2 var long
temp3 var long
'
' Shared (hub) Data (DATA, WDATA, LDATA, FILE)
'
'
' TASK Definitions
'
'
' Cog Variables (Long only)
'
'
' SUB/FUNC Definitions
'
GET_IR_PULSE sub 1
GET_SIRCS sub
LedTEST sub
processKeys sub
' ======================================================================
PROGRAM Start
' ======================================================================
Start:
' Main code goes here
In SX/B, at one point, you were able to do a return within a 'SUB'. The attached file contains an update, changed the 'SUB' to a 'FUNC'. The next compile error is a little more difficult to resolve. The 'cmdCode.6 = 1' , and the 'devCode.4 = 1' , in the documentation I did not see any reference to being able to do this. I guess it probably needs some assembly code to handle this, but, I am not sure what the code would look like.
Rsadeika said...
In SX/B, at one point, you were able to do a return within a 'SUB'. The attached file contains an update, changed the 'SUB' to a 'FUNC'. The next compile error is a little more difficult to resolve. The 'cmdCode.6 = 1' , and the 'devCode.4 = 1' , in the documentation I did not see any reference to being able to do this. I guess it probably needs some assembly code to handle this, but, I am not sure what the code would look like.
Ray
There are a lot of things wrong with your program -- too many for me to fix in the time I have left today (off to class!). Since I wrote some of the SX/B code you're attempting to translate, I will do it tomorrow. I will write a demo that accepts SIRCS codes and lights LEDs on the Propeller Demo Baord.
Hints:
-- Use subroutines to work with values (passed as parameters), functions to do something and send a value back
-- minimize "global" variables to maximize code portability
* you can pass parameters to a subroutine
* you can pass parameters to a function, and get value(s) back
-- whenever possible, subroutines and functions should stand alone and not depend on others or global variables
Tip:
-- if a value is already in __param1, you don't need to use RETURN at the end of the function; for example
FUNC GET_IR_PULSE
PULSIN IR, 0, __param1
ENDFUNC
It's fine to use RETURN __param1 but it will just copy __param1 to __param1 and consume a precious instruction.
Note, too, that SX/B PULSIN worked in 10us units, PropBASIC PULSIN works in 1us units. To look for an SIRCS start pulse, then, you might do this:
FUNC GET_SIRCS
pWidth VAR Long
cmdCode VAR Long
DO
pWidth = GET_IR_PULSE
LOOP UNTIL pWidth > 2160 ' wait for valid start pulse
...
My sample code is based on the use of TWO props chips. The first Prop Chip is running Spin code which handles the SD card. The second Prop Chip is running PropBasic code and simply communicates with the first Prop chip via a serial port.
Your program
I don’t think you can expect code written for the SX compiler to compile on the PropBasic compiler. Whilst the code looks very similar the Prop chip is very different. I assume that Bean designed ProBasic this way so that SX users would find it easier to migrate to the Prop chip.
@Drac
Tasks do burn up cogs very quickly, on the other hand you can declare many Tasks, but of course you can only run 7 plus the main Task at any one time. Yes you may need vga, keyb in addition to the main Task running all the time but if you require access to SD you turn on that task, then turn it off when you have finished so that you can use the cog for another task like xmem for example etc. You can do that with any software, but it will feature more with PropBasic, because tasks will often be quite small, but very specific.
Anyway its was the first thing that I wrote after reading the manual, but it has given me some ideas.
Ron
Post Edited (Ron Sutcliffe) : 1/14/2010 11:30:39 AM GMT
Attached is a simple 12-bit SIRCS decoder program that runs on the demo board. If you press keys [noparse][[/noparse] 1 ] - [noparse][[/noparse] 8 ] on the remote a corresponding LED will light.
Note that PropBASIC -- despite similarities -- is not SX/B. In PropBASIC SUBs and FUNCs are declared the same way, with the min and max number of parameters if required. Since we only have one type of variable in a cog there is no need to define the number of returned values, simply place them in the RETURN statement at the end of the FUNC. Note that as of v0.65 you can return multiple parameters, for example:
...
RETURN xval, yval
ENDFUNC
In this case you call the function like this:
myVarX = FUNC_NAME
myVarY = __param2
You need to capture second and other parameters on your own.
This is how I think it could work, hope it makes sense. Sorry I was late responding to your post but a got a new toy from Clusso yesterday. [noparse]:)[/noparse]
ovlay TASK
ovlCode VAR LONG(300)
'First we need to get the name of the next ovlcode file from Hub. The file name could have been written to by any other running task, which requires
'the services of the ovlcode.
'Then we open the ovlcode file for read and download the ovlcode from SDcard into the space reserved in this cog (300 LONGS MAX)
'once the code is written into the cog, we close the SDcard port and jump to the Code we have just loaded into ovlCode code area.
'once the ovlcode has completed its task it jumps back to the handler( the first 180 longs say ) and waits for the
'file name of the ovlcode file name to change in Hub. Then then the process starts again.
'NOTE that the ovlcode is called by other tasks requiring the service. It is not determined at compile time.
ENDTASK
@Bean, true PIN is there to be used [noparse]:)[/noparse]
Comments
I'm coding Sbasic and compiled Mbasic on a propeller right now. It works fine, but is a little lacking in speed. eg I want to capture data coming back from a remote wireless login to another propeller at 19200 baud, and compiled Mbasic on the zicog is struggling to keep up (it is jolly close though, about 95% of a "DIR" comes back intact). Not surprising in a way becuase it is emulating at maybe 1000 instructions per second.
Move over to propbasic and it could go *much* faster. And maybe with not much editing needed on the code.
Re BS2 users, there are other target markets too for people who want to program Basic on small microcontrollers. The key is making it simple, and prop basic is doing a fantastic job with some great potential (and to be unbiased, I'll say that for C programmers, Catalina is doing a similar job).
I'm excited about pushing the boundaries with the code already written. So re;
"MyCode HUB LONG(512)"
I'm working my way throught the manual on the first page of this thread. I found Mycode is an array (page 14). Cool, I can fill the array with 2k from an sd card. That will work.
I'm a bit confused about "tasks". Page 17 of the manual is "Tasks" but the page is blank. I think tasks are another name for cog code, is that right?
Let's say I have 2k (512 longs) of code that is now in Mycode array. How would I move that code to, say, the next available cog and then start the cog?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Ray
Post Edited (Rsadeika) : 1/12/2010 1:31:12 PM GMT
You create a TASK header (this tells the compiler the task exists). Then you can use the do a "COGSTART taskname" to start the task. The actual TASK code comes at the end of the program.
Remember that since a TASK is code running in a different cog, you need to use HUB variables to communicate with it.
Take a look at the Prop-BOT code that I posted yesterday at 8:15pm (I put the code right in the post).
This uses a TASK to control the servo pulses. You set the HUB variable "goal", and the TASK will move the servo to the goal setting slowly. This avoids jerking the bot around and prevents power dips too.
Also look at the Serial_to_NTSC program in the demos folder.
This uses 3 cogs, one runs the main program, one receives serial data, and one generates a 64x24 character display. All written in PropBASIC in one source file.
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 1:29:57 PM GMT
I'm assuming that since this is a single pass compiler, that Task/Endtask gets converted to something like
org 0
start
... code
...data
fit or similar?
Let's take a very simple example. I want a little Task program that takes a variable and multiplies it by 2 and returns it
so my task might be (in token form)
rdlong
shl
wrlong
end
I suppose I could write that on the proptool, find out the bytes it compiled to on a real program, put them on a cog, write a program to read them off the cog, store those bytes and call that a cog subroutine. Propbasic is different as you seem to have more control over the process.
To flesh that out, rdlong needs to read from a known location in hub, and maybe that location should be up the top of hub memory somewhere. Ditto wrlong.
Maybe I'm jumping ahead here, but it would be so cool to have libraries of Task code, that you can drop into propbasic like objects from the obex, and you know that they work. Drop in a keyboard Task (would be very similar to the current object, except that it would return a flag and a byte to two fixed locations in upper hub ram). Drop in a VGA Task. An sd Task. Nothing different to the current way of doing things, except that these tasks may not take any hub memory. You pull them off an external ram or sd card, put them in the cog, run them, then discard them (or leave them running).
Some tasks would run once then end. Some would keep going and you throw variables at them and they return other variables then cycle through (like the external ram driver code from Cluso).
Maybe this is racing ahead too far? But I see so many possibilities! And I see this becoming simpler for the beginner.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
But for just a demonstration program here is how I would write it:
DEVICE P8X32A, XTAL1, PLL16X FREQ 80_000_000 temp VAR LONG value HUB LONG flag HUB LONG Mult2 TASK PROGRAM Start Start: WRLONG value, 1000 WRLONG flag, 0 COGSTART Mult2 DO RDLONG flag, temp LOOP UNTIL temp <> 0 RDLONG value, temp ' Temp now equals 2000 END TASK Mult2 temp VAR LONG RDLONG value, temp temp = temp * 2 WRLONG value, temp WRLONG flag, 1 COGID temp COGSTOP temp ENDTASKBean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134·
x = x op y
Assignment operators would let you write them
x op= y
which requires less typing, is conceptually clearer (imho), and gives people a nudge toward Spin or C-family languages.
The Propbasic manual shows command as
SHIFTOUT datapin, clockpin, mode, value[noparse]/noparse]\[/size][/font][/size][/font][font=CourierNew][size=2][font=CourierNew][size=2]bits[/size][/font][/size][/font][font=CourierNew][size=2][font=CourierNew][size=2
Placing a comma between value and [noparse][[/noparse]\bits] compiles ok and generates spin code.
Is this correct and can bits be any value ?
Regards
Gerry
That is a bug, I'll get that corrected. I'll post 00.00.63 ASAP.
The bits can be from 1 to 32.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134·
Ray
' ====================================================================== ' ' File...... test1.pbas ' Purpose... ' Author.... ' E-mail.... ' Started... ' Updated... ' ' ====================================================================== ' ---------------------------------------------------------------------- ' Program Description ' ---------------------------------------------------------------------- ' ' ---------------------------------------------------------------------- ' Device Settings ' ---------------------------------------------------------------------- DEVICE P8X32A, XTAL1, PLL16X FREQ 80_000_000 ' ---------------------------------------------------------------------- ' Constants ' ---------------------------------------------------------------------- Baud CON "T115200" HOME CON 1 BKSP CON 8 TAB CON 9 LF CON 10 CLREOL CON 11 CLRDN CON 12 CR CON 13 CLS CON 16 ' ---------------------------------------------------------------------- ' I/O Pins ' ---------------------------------------------------------------------- TX PIN 30 HIGH LED PIN 16 LOW ' ---------------------------------------------------------------------- ' Shared (hub) Variables (Byte, Word, Long) ' ---------------------------------------------------------------------- alpha VAR Long ' ---------------------------------------------------------------------- ' Shared (hub) Data (DATA, WDATA, LDATA, FILE) ' ---------------------------------------------------------------------- ' ---------------------------------------------------------------------- ' TASK Definitions ' ---------------------------------------------------------------------- ' ---------------------------------------------------------------------- ' Cog Variables (Long only) ' ---------------------------------------------------------------------- ' ---------------------------------------------------------------------- ' SUB/FUNC Definitions ' ---------------------------------------------------------------------- TX_BYTE SUB 2, 2 ' shell for SEROUT DELAY_MS SUB 1, 1 ' shell for PAUSE ' ====================================================================== PROGRAM Start ' ====================================================================== Start: ' Main code goes here DELAY_MS 10 ' TX idle for 10ms TX_BYTE TX, CLS Main: DO FOR alpha = "A" TO "Z" TOGGLE LED TX_BYTE TX, alpha DELAY_MS 50 NEXT TX_BYTE TX, CR LOOP END ' ---------------------------------------------------------------------- ' SUB/FUNC Code ' ---------------------------------------------------------------------- SUB TX_BYTE SEROUT __param1, Baud, __param2 ENDSUB SUB DELAY_MS PAUSE __param1 ENDSUB ' ---------------------------------------------------------------------- ' TASK Code ' ----------------------------------------------------------------------I think your PST is not setup right.
If anyone is keeping score, the program above uses all of 57 longs.
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 9:48:40 PM GMT
Hint: White space is your friend; be careful getting sloppy with your listings as "sloppy" serves as great camouflage for bugs (that may compile just fine).
I have run the Propeller IDE, and seems to behave with Windows 7, it even installed the 64 bit drivers with no problem. I have only had the new system for about a week now, so I have not tried everything out just yet.
Ray
I use the compiler and PropBASICIDE with windows 7 64-bit.
You need to change the properties of the program so windows stops asking you if you want to run it. It has nothing to do with the compiler.
Yes, you need to choose the correct port and baud rate. All I can tell you is your code works fine on my Windows 7 64-bit system.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134·
It sounds like you are using COMPILE in the PropBasic IDE to create the Spin file and not compiling and loading the Spin file to EEprom. Use the EEPROM in the PropBasic IDE to compile and load the Prop in one step. There are other IDE's if you don't like what Bean has done, (I use Source Edit) but Beans IDE works fine with XP and windows 7.
Ron
As for the program that I posted earlier, it was a direct copy of what is shown in the propBASIC manual, I left everything as is. Again, what will the Basic Stamp user be using as guide to learning the language? Remember, this is BETA testing!
Ray
Ron
Working code, to demonstate·using SD Card·or any other Spin/Pasm objects on Prop·1··with PinIn =·8 and PinOut·= 9
Prop·2 running the code below· where PinIn = 16 and PinOut = 18
If you want to use one cog for both Keyboard and SD comms you will need to use a flow control method.·I think its best to use two separate tasks
and turn the SD cog on when you need it.
@Tony
Why re-work·all the code in the·OBEX when a you·can use High Speed comms and an extra Prop.·FSRW is a hugh lump of code to port to PropBasic.
Ron
Nice program. It looks like you have a good handle on PropBASIC.
My only suggestion would be to use PIN to define "keyin" and "sdin".
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134·
This is what I was refering to with Drac·in an earlier post. A·way in·which users·could load and execute·Pbasic files from SD
The screen below uses the code that I posted to handle the file server.
Obviously they will·not be able to save a·Pbasic file to SD but they could save data.
The trick·for me now is·to get the 2K(max) files from SD to the PropHub·ram and get PropBasic to load the file into a free·cog and run it.
The main program will have to reserve 496 longs in HUB ram for the sole purpose of holding· SD based Tasks. ·In other words tasks from SD would
always run within the Main Program (AKA in a·shell)· Its all vapourware at this stage, but its interesting.
Cheers
Ron
BTW the·original code was written using only one cog for SD and Keyboard·but I got few errors and thought that flow control would be messy so I butchered·it and used·two cogs. It will all go out the window when I get a shot·at the rest of the project.
Post Edited (Ron Sutcliffe) : 1/13/2010 1:24:26 PM GMT
Gut feeling here, but I think this might be the hidden key to breaking out of the 32k memory limit of the propeller.
You can fit some nifty routines in 2k. Simple, such as a single floating point math operation. Or complex, like an entire string manipulation library.
So, do these have a name? Would you use an 8.3 naming convention for these, and if so, what would be a suitable extension? .COG? .TSK?
And is there an easy way to create these binary files? Could it be as easy as writing some assembly in the prop tool, starting at org 0 with no spin at the beginning at all (is that allowed?), then compiling it to a binary?
Re the specific questions:
Loading a binary off the sd card.
Pulling apart the dracblade code I think it is something like:
OBJ
sd : "fsrwFemto" ' sd card driver
VAR
byte cogbuff[noparse][[/noparse]2048] 'buffer for a cog binary
PUB
sd.start(variable)
FindDriveBase(0, string("MYFILE.TSK")) ' find where the file is on the sd card so quicker to find next time
CheckSDCard ' init sd card
sd.readSDCard(drive_base[noparse][[/noparse]0], @cogbuff, 2048) ' get 2048 bytes from file in drive_base[noparse][[/noparse]0] and put in cogbuff array
Then the bit I'm not sure about; move the bytes from the cogbuff array into the cog itself, start the cog, run it, set a flag when it gets to the end.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 1/13/2010 1:35:46 PM GMT
You might only have one 'working' cog for this. Thinking of the dracblade, most of the cogs end up so useful for other things - fsrw, vga (x2?), keyboard, serial ports, ram
so maybe only one or two left over. But you can do so much with those if the way of loading them and talking to them ends up being only (say) one line of code, say a call to a subroutine with some parameters (filename.tsk, long1, long2 and returns long1,2 etc)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
@ron, I just looked at your program, and I am assuming you have an SD card reader attached on pin 16. Are you using a serial communications setup, because the code does not look like spi to me, or am I wrong on that? If that is the case, have you tried writing to the SD card, and what kind of speed differences are you noticing compared to using spi code? You have a very interesting short program to learn from.
Ray
temp2 = GET_IR_PULSE
error 5 invalid parameter "GET_IR_PULSE"; ...
Not sure how to change this so it would work.
Ray
[noparse][[/noparse]code]
' ======================================================================
'
' File...... test2.pbas
' Purpose...
' Author....
' E-mail....
' Started...
' Updated...
'
' ======================================================================
'
' Program Description
'
'
'
' Device Settings
'
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
'
' Constants
'
'
' I/O Pins
'
Led1 pin 7 output
IRpin pin 0 input
'
' Shared (hub) Variables (Byte, Word, Long)
'
cmdCode var long
devCode var long
temp1 var long
temp2 var long
temp3 var long
'
' Shared (hub) Data (DATA, WDATA, LDATA, FILE)
'
'
' TASK Definitions
'
'
' Cog Variables (Long only)
'
'
' SUB/FUNC Definitions
'
GET_IR_PULSE sub 1
GET_SIRCS sub
LedTEST sub
processKeys sub
' ======================================================================
PROGRAM Start
' ======================================================================
Start:
' Main code goes here
Main:
do
GET_SIRCS
processKeys
'LedTEST
loop
END
'
' SUB/FUNC Code
'
sub GET_IR_PULSE
pulsin IRpin, 0, temp1
return temp1
endsub
sub GET_SIRCS
do
temp2 = GET_IR_PULSE
loop until temp2 > 216
cmdCode = 0
for temp3 = 0 to 6
cmdCode = cmdCode >> 1
temp2 = GET_IR_PULSE
if temp2 > 108 then
cmdCode.6 = 1
endif
next
devCode = 0
for temp3 = 0 to 4
devCode = devCode >> 1
temp2 = GET_IR_PULSE
if temp2 > 108 then
devCode.4 = 1
endif
next
endsub
sub LedTEST
high Led1
pause 1000
low Led1
endsub
sub processKeys
if cmdCode = 21 then Led1
cmdCode = 0
endsub
'
' TASK Code
'
Regards
Gerry
Ray
There are a lot of things wrong with your program -- too many for me to fix in the time I have left today (off to class!). Since I wrote some of the SX/B code you're attempting to translate, I will do it tomorrow. I will write a demo that accepts SIRCS codes and lights LEDs on the Propeller Demo Baord.
Hints:
-- Use subroutines to work with values (passed as parameters), functions to do something and send a value back
-- minimize "global" variables to maximize code portability
* you can pass parameters to a subroutine
* you can pass parameters to a function, and get value(s) back
-- whenever possible, subroutines and functions should stand alone and not depend on others or global variables
Tip:
-- if a value is already in __param1, you don't need to use RETURN at the end of the function; for example
It's fine to use RETURN __param1 but it will just copy __param1 to __param1 and consume a precious instruction.
Note, too, that SX/B PULSIN worked in 10us units, PropBASIC PULSIN works in 1us units. To look for an SIRCS start pulse, then, you might do this:
FUNC GET_SIRCS pWidth VAR Long cmdCode VAR Long DO pWidth = GET_IR_PULSE LOOP UNTIL pWidth > 2160 ' wait for valid start pulse ...My sample code is based on the use of TWO props chips. The first Prop Chip is running Spin code which handles the SD card. The second Prop Chip is running PropBasic code and simply communicates with the first Prop chip via a serial port.
Your program
I don’t think you can expect code written for the SX compiler to compile on the PropBasic compiler. Whilst the code looks very similar the Prop chip is very different. I assume that Bean designed ProBasic this way so that SX users would find it easier to migrate to the Prop chip.
@Drac
Tasks do burn up cogs very quickly, on the other hand you can declare many Tasks, but of course you can only run 7 plus the main Task at any one time. Yes you may need vga, keyb in addition to the main Task running all the time but if you require access to SD you turn on that task, then turn it off when you have finished so that you can use the cog for another task like xmem for example etc. You can do that with any software, but it will feature more with PropBasic, because tasks will often be quite small, but very specific.
Anyway its was the first thing that I wrote after reading the manual, but it has given me some ideas.
Ron
Post Edited (Ron Sutcliffe) : 1/14/2010 11:30:39 AM GMT
Note that PropBASIC -- despite similarities -- is not SX/B. In PropBASIC SUBs and FUNCs are declared the same way, with the min and max number of parameters if required. Since we only have one type of variable in a cog there is no need to define the number of returned values, simply place them in the RETURN statement at the end of the FUNC. Note that as of v0.65 you can return multiple parameters, for example:
In this case you call the function like this:
You need to capture second and other parameters on your own.
Post Edited (JonnyMac) : 1/14/2010 2:51:39 PM GMT
This is how I think it could work, hope it makes sense. Sorry I was late responding to your post but a got a new toy from Clusso yesterday. [noparse]:)[/noparse]
ovlay TASK
ovlCode VAR LONG(300)
'First we need to get the name of the next ovlcode file from Hub. The file name could have been written to by any other running task, which requires
'the services of the ovlcode.
'Then we open the ovlcode file for read and download the ovlcode from SDcard into the space reserved in this cog (300 LONGS MAX)
'once the code is written into the cog, we close the SDcard port and jump to the Code we have just loaded into ovlCode code area.
'once the ovlcode has completed its task it jumps back to the handler( the first 180 longs say ) and waits for the
'file name of the ovlcode file name to change in Hub. Then then the process starts again.
'NOTE that the ovlcode is called by other tasks requiring the service. It is not determined at compile time.
ENDTASK
@Bean, true PIN is there to be used [noparse]:)[/noparse]
Ron