Download PropBASIC here... 00.01.14 July 27, 2011

[Bean]

Because of the cog startup time, I think the best way to handle spin code would be to leave the spin interpreter running and use it was a dispatcher with hub variables.

Basically the spin code would wait for a "spinID" variable to get set to a value that indicates what spin routine you want to call.

The spin code would run that routine and return any values in some kind of "spinData" variables.

I'll try to mock up something in the next couple days to demonstrate what I mean.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PropBASIC home page www.propbasic.com
·

[TonyWaite]

Comment to Mike Huselton:

Hi Mike,

I check this forum several times daily with the hope of seeing exactly a reponse such as yours!

I've been researching all the variations of 'calling Spin from PASM' within the Forum to run with Cluso's advice; and am convinced that even to _understand_ the problem takes further thought.

Regards and encouragement,

T o n y

[TonyWaite]

Comment to Bean:

This sounds promising. Phil Pilgrim has posted code previously on calling Spin from PASM - using a 'dispatch' methodology and example; but it is beyond my comprehension unfortunately.

Regards,

T o n y

[skynugget]

* hug Bean and JonnyMac *

Post Edited (skynugget) : 12/29/2009 10:06:34 PM GMT

[Mike Huselton]

Bean,

I hadn't considered startup time for this process. So, obviously, a monitor process already running would neatly solve several problems.

Now, to consider the nature of that dispatcher task: Spin or Pasm or PropBasic?
PropBasic would work for educational purposes and can be optionally included as the first thing to be processed in all 7 possible tasks.
I will need to reread the documents and do some testing before going too far along this path.

Optimization can come later. Time to do some 'spermentin'...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH

Post Edited (Mike Huselton) : 12/28/2009 11:35:19 PM GMT

[Bean]

Just a note to let everyone know that a new version of the PropBASIC compiler has been posted in the first post.

Mike, The dispatcher will almost certainly have to be written in spin.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PropBASIC home page www.propbasic.com
·

[JonnyMac]

An updated version of the (work-in-progress) manual has been posted as well -- see my post on page #1 of thread.

[Bean]

Here is a demo program showing how to interface spin objects into PropBASIC using a spin dispatcher.


If you try this demo, make sure it's NOT in the same directory as the keyboard demo PropBASIC code. The PropBASIC keyboard demo creates a "keyboard.spin" file that is NOT the one we want to this demo.


You can see that I used an ASM...ENDASM block to insert the object and dispatcher code. Even though it's not PASM code, the ASM...ENDASM commands don't care they just put whatever is between them into the output file.

' Put in code to run spin dispatcher
ASM
OBJ
  Key: "Keyboard"
 
PUB SpinStart
  CogInit(1, @__Init, @__DATASTART) ' Start PropBASIC program
  Repeat
    case spinCmd
      spinKeyStart:
        Key.Start(spinP1, spinP2)
        spinCmd := 0
                
      spinKeyGetKey:
        spinP1 := Key.GetKey
        spinCmd := 0
  
ENDASM

If you have any questions about how this works, please let me know.


Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PropBASIC home page www.propbasic.com


Post Edited (Bean (Hitt Consulting)) : 12/30/2009 6:41:25 PM GMT

[TonyWaite]

Hi all,
Just to report SUCCESS using Bean's method to call a Spin object from PropBASIC!
I spent an hour trying to use the example given, before giving up and writing some _really_ simple code.
The joy finally on hearing a 400Hz tone generated by Spin called from the Obex by PropBASIC!
Many thanks,

T o n y

[TonyWaite]

Here's the code that I used. It may be crude, but it works!
Regards, T o n y

DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
ASM
OBJ
soundmachine: "Profbrd_tonegen" 'this is one of Rayman's sound drivers, renamed "Profbrd_tonegen" in my files
PUB SpinStart
CogInit(1, @__Init, @__DATASTART)
soundmachine.tonegen(400,500,3) 'sends frequency/duration/attenuation to the tonegen subroutine
ENDASM
PROGRAM Start
Start:
END

[Geekgirl]

Being new to the propeller, I'm hoping you guys with much greater knowledge can help.

I can't get "GOSUB" to work, but I can't find anything about declared SUB / FUNC which the documentation says replaces it.

If I use goto to get to the subroutine, and another goto (instead of return) at the end of the subroutine with a label at the place it should have "returned to" it works.

The error is "Undefined ?_RET symbol".


The other issue I can't seem to work around is "Origin Exceeds" errors.

If some one could explain what they mean, it might get me on the right track.

I keep getting the Origin Exceeds errors·once I have reached a fairly small number of code lines (about 200). If I rem (comment)·some out, I can use others, so it seems to be based on the amount of code, not some particular code.


Interestingly, the errors show up onscreen a minute or two after compiling (which shows no errors) and attempting to download to RAM, which just sort of·flashes for a second·the "downloading window", but doesn't download anything.

[Bean]

The Origin exceeds fit limit means that you have too much code. The PASM code that PropBASIC generates must fit within the COG. So only 496 instructions are allowed.

Some PropBASIC commands generate alot of PASM code so you need to put them into a subroutine.

If you look at the template.pbas you will see that near the top of the program you declare the subroutines along with how many parameters they need.

Plot SUB 2

Means you will have a subroutine named "Plot" that takes 2 parameters.

Near the bottom of the template you will see where you put the actual subroutine code.

SUB Plot 
  ' Parameters are in __PARAM1 and __PARAM2 
ENDSUB

If you could post your code we could help you much more.

Another more complecated thing to do is to break the program into multiple TASKs. Each TASK runs in it's own COG, so each TASK can have 496 PASM instructions.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Try BASIC on the Propeller.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

Post Edited (Bean (Hitt Consulting)) : 12/31/2009 5:17:57 PM GMT

[JonnyMac]

@Geekgirl: If you post your .pbas source Bean and/or I can fix it up for you -- that should help get you going as we continue to work on the docs.

One of the code space killers we frequently run into is PAUSE -- it's used a lot and generates several lines of code; one way to save space in your program is to create a subroutine that serves as shell for PAUSE. Start by defining the subroutine -- here's how I do it:

DELAY_MS        SUB     1, 1                    ' shell for PAUSE

Now you have to write the code for the definition; this one is easy:

' Use: DELAY_MS duration
' -- shell for PAUSE

SUB DELAY_MS
  PAUSE __param1
  ENDSUB

As you learn about PropBASIC you'll find that parameters are passed in the __paramX (1 - 5) variables. With 32-bit numbers we only need one value, and this can be dropped right into PAUSE as I've done in the DELAY_MS subroutine.

In your program you'll now substitute DELAY_MS for PAUSE (except in the body of the subroutine -- we need that one for the compiler). I had a look and PAUSE generates six lines of code. Using DELAY_MS uses only two lines -- that's a nice savings every time we need a delay, which can be frequent in many programs.

Of course, this is a very simple example but is shows the code-savings power of SUBs and FUNCs. I've attached a little working demo that uses DELAY_MS so you can see exactly how it works.

Post Edited (JonnyMac) : 12/31/2009 6:15:10 PM GMT

[Geekgirl]

Bean (Hitt Consulting) said...
The Origin exceeds fit limit means that you have too much code. The PASM code that PropBASIC generates must fit within the COG. So only 496 instructions are allowed.

Some PropBASIC commands generate alot of PASM code so you need to put them into a subroutine.

If you look at the template.pbas you will see that near the top of the program you declare the subroutines along with how many parameters they need.

Plot SUB 2

Means you will have a subroutine named "Plot" that takes 2 parameters.

Near the bottom of the template you will see where you put the actual subroutine code.

SUB Plot 
  ' Parameters are in __PARAM1 and __PARAM2 
ENDSUB

If you could post your code we could help you much more.

Another more complecated thing to do is to break the program into multiple TASKs. Each TASK runs in it's own COG, so each TASK can have 496 PASM instructions.

Bean.

I am working from the template, and saw the place to declare subs, but have no idea how it's done or what a parameter is or how you know how many the sub would have.

I put the sub code in the lower area specified for that.

Here's the program code that works. Apparently that's all the instructions cog0 can hold.

Thanks in advance,

Darlene

[JonnyMac]

@Darlene,

As I expected, lots of PAUSE usage (see my post above). Another way to save code is to declare pins as outputs and then write a value (0 for off, 1 for on) to the pin. I'll touch up you code and repost.

[Bean]

Here is one way to make it smaller.

I make the LEDs pin groups, this makes it easier to assign colors to them.

I didn't convert all of your code, but you should be able to get the idea.

Bean.


P.S. I screwed up the color names. I have posted the correct version.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Try BASIC on the Propeller.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

Post Edited (Bean (Hitt Consulting)) : 12/31/2009 7:03:57 PM GMT

[Geekgirl]

JonnyMac said...
@Darlene,

As I expected, lots of PAUSE usage (see my post above). Another way to save code is to declare pins as outputs and then write a value (0 for off, 1 for on) to the pin. I'll touch up you code and repost.

I changed all the PAUSEs to DELAY_MS, and set some times (T1, T2 ... ) as constants to use with it, and it works OK. It saved enough space that I didn't have to comment out anything.


I see what you mean about the pins thing, it's not as easy to visualize that yet as it is to think in·the way I've been doing it with the stamp, which is what the first code I posted based from.


Sometimes this stuff makes me feel like such a moron for a a while, and then the light bulb starts to flicker.


Thanks for all the help.


Darlene·

[Shawn Lowe]

Darlene-
DONT fell stupid or foolish! PropBasic is almost exactly like SX/B, and I've been studying JonnyMac's and others code for a YEAR now and still learn new things everyday! Take your time, keep your mind open and play! It'll get easier!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Shawn Lowe


When all else fails.....procrastinate!

[Geekgirl]

Bean (Hitt Consulting) said...
Here is one way to make it smaller.

I make the LEDs pin groups, this makes it easier to assign colors to them.

I didn't convert all of your code, but you should be able to get the idea.

Bean.
·

P.S. I screwed up the color names. I have posted the correct version.

WOW, Thanks....·

It took me a while to see how the colors worked, but then I saw how you broke the pins into groups of three and the color constants when seen as 3bit·binary, my light bulb is starting to flicker.


Darlene

[JonnyMac]

Here's a version of Terry's program that lets you store the lighting sequences in a DATA table (does not use program space as tables are stored in the Hub) -- this will let you define sequences using Terry's color scheme, which is FAR EASIER than the high-low mash-up strategy you started with. You simply call the PLAY subroutine with the sequence you want to use and the step timing.