Spin, PASM, and a table in there too

Timothy D. Swieter · 2009-03-12 10:44

I am working on a driver. The driver code is located in its own file - it is an object. There are SPIN routines at the top to start/stop the PASM driver that runs in its own cog. The driver is structured like the LM9033A driver: http://obex.parallax.com/objects/389/. So that means there are also SPIN routines that send commands to the PASM driver portion. Now, in addition to the DAT section having a PASM code, there is also a table. The table however is only accessed by the SPIN commands, that is there PASM routine does not access the table at all. That means there is no need to load the table into the COG when the PASM routine is launched.

What is the best way to include this table in the file? Should there be a DAT section with the table, then another DAT section with an ORG and the start of the program? I read that when a PASM code is launched it starts at the ORG and always loads the next 496 longs. That would mean it loads part of the table into the COG, which isn't really needed, if the table was after the ASM code. Am I right?

Thank you for the help,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com

Erik Friesen · 2009-03-12 12:17

You are right. I found that out when I added a font table to my lcd driver. If I put it all in the section prior to the assembly portion, it loads into hub ram.

Cluso99 · 2009-03-12 12:35

Yes, the coginit/cognew routine will load 496 longs, no matter how long the asm code is. There is no way to only load the required length, so you will end up with whatever follows you code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)

My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Baggers · 2009-03-12 12:41

Tim, yes when you start a cog it loads the 496 longs, the fact that the table is after it or before it, since it's not needed by the PASM code, it doesn't really matter where it's placed, as whatever is after the PASM part will get loaded into the cog also.
If however you're wanting to save memory, ( if you already have SD code in there, you could just have an empty file with with the PASM in, and load the binary into a buffer and start the cog that way. )
have the proggy for the pasm object like this

PUB main
' there's no actual routine here
DAT
    org 0
PASMCODE
'    mov   dira,blah etc. eg, put your code here

then compile that file, and save the binary,
the code will start $18 bytes into the binary, so when you load the file into a buffer, skip the first $18 bytes, or do cognew(@buffer+$18,parameter)

hope this helps.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

Timothy D. Swieter · 2009-03-12 14:24

Thanks guys for the quick confirmation and thank you Baggers for that tip! I like that idea, but right now I don't have much an SD. I suppose I could possible load from memory above 32K since I am using a 64K EEPROM if the rest of the program pushes the memory limits.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com

Baggers · 2009-03-12 14:43

Yeah, there ya go, you can put the COG binaries in the top 32KB, thus saving space, and only read from there to a single 2K buffer when you need to fire them up. [noparse]:D[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

TreeLab · 2009-03-12 16:57

Is there a consensus on how to have the run-time app stuff values into the cog variables prior to launching the cog? For example, by having the first PASM instructions jmp past a block of registers, and the top-level SPIN code could manipulate this block just by knowing offsets from the buffer start (ie treat it like an array) Or does everyone just do it the way they see fit?

Cheers!
Paul Rowntree

Timothy D. Swieter · 2009-03-15 09:23

Paul -

When I have variables or parameters to pass to an ASM routine on startup (like pin configuration or timing values) I first setup variables in SPIN. Those variables are populated before launching the ASM cog. When the ASM cog is launched, it is passed the first variables address. Then in the ASSM routine, using Par. I learned to do it this way by studying code done by others. It makes sense to me, you can see an example of how I did this in the LCD LM9033A driver in the object exchange.

Now - I had a though. If there is a data table or buffer that changes often in HUB RAM, but the ASM code needs to know about it, would it be faster to design the ASM code such that it could be started and stopped each time when the table/buffer needs to be updated? In other words, is it faster to load the COG with 496 longs then to go through a loop to load the table of say 100 or 200 longs (assuming a short ASM program that can handle starting/stopping)?

I can probably study the data sheet to determine this.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com

kevin101 · 2009-03-15 20:39

Timothy-

For short asm programs, i use the starting and stopping method to send data to a Nokia LCD that i ripped out of a cellphone.

pub refresh(pixels)|cog

reps:=pixels-1      'sets reps in the asm program, tells how many bytes to send
display[noparse][[/noparse]pixels]:=0       'makes sure that the stop byte is zero so the spin program will not stop the asm cog immediately
cog:=cognew(@prog,@display)      'launches asm cog with new reps value and at the display buffer
repeat until display[noparse][[/noparse]pixels]     'repeat until all the data is sent and the program is finished
cogstop(cog)    'stop cog (duh)


dat

org 0
prog
       'do program stuff to send number of bytes based on reps
        '...

       'finished major part of program, now tell spin cog that you are finished

        mov origin,par      'move par to origin
        add origin,reps    'add reps to origin, this is how many bytes were sent to the display + origin
        add origin,#1     'origin + 1 is the byte after all the data to be sent to the display. the spin program-
        'will look here to tell when this cog is finished

        wrbyte reps,origin      'writes to the hub ram to tell the spin program it is finished
jump    jmp #jump     'do nothing until stopped by the spin program

reps long 0     ' spin program will load the reps value here

The Nokia LCD has a cool feature where you can write to a specific section of the display that you can set. Because the entire screen is not refreshed, the amount of pixels sent changes depending on how big of an area is needed to be refreshed. The asm program reads the image buffer, sends the data to the LCD, and then writes a non zero number to the byte after the last pixel
sent. The spin cog waits until it reads a non zero value at this location. When this condition is met, the spin program stops the asm cog and move on to other things. The jump loop at the end of the asm program is just to keep that cog idle until it is stopped. With this part of this program in asm, I get a full screen refresh of about 40 hz, which is faster than the LCD can handle. In complete spin, I got a refresh rate of about .125 hz. PASM is my new friend!!!

TreeLab · 2009-03-18 01:54

Timothy;
Yes, I understand and use the initial stuffing of PASM values from spin in normal code; what I was referring to was the use of independently compiled cog codes (this is what launched this thread), such that the top-level spin does not know the addresses within the cogcode to be used as variable spaces.

I was wondering what the best way to stuff data into these systems. sorry about the imprecision ...
Cheers!
Paul Rowntree

Timothy D. Swieter · 2009-03-18 02:32

No prob Paul, I am sorry I misunderstood. I am not sure I have an answer for your question though. Maybe others can chime up. If I think through this I might have an idea, but I got a couple distractions first.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com

Spin, PASM, and a table in there too

Comments