Pasm vs. Spin

James Long · 2009-04-17 23:27

I have a question that I feel is pretty dumb, but I'm going to ask it any way.

Is there any operation of which Spin can do that Pasm can not.

We are not talking about length of code, so if the code wouldn't fit in the eeprom, that is ok.

I'm thinking about starting the exciting journey of Pasm, and wondering if there are any instructions (combinations) which do not convert.

I have been tinkering with the Propeller for a long time, and it is time to start learning Pasm. I think it will help me understand Spin operations a little better (or just totally confuse me. One or the other).

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer

Lil Brother SMT Assembly Services

Philldapill · 2009-04-17 23:31

Start new cogs? That's about the only thing I can think of...

You're right about PASM helping to understand spin better and write more efficient spin code. I've spent the last few days playing with PASM, and pulling my hair out. I've been taking a spin program and converting it to PASM, mainly for speed purposes. Wow, that's much faster. I've been makin an ADC object, and the spin code can pull about 4ksps, and my optimized PASM can pull almost 200ksps(the maximum for the ADC).

In the process, I've learned alot of new tricks that I can use in my spin code, such as shifting bits, binary OR's and AND's in spin. It simplifies code and, suprisingly, speeds up spin alot too.

Post Edited (Philldapill) : 4/17/2009 11:36:22 PM GMT

jazzed · 2009-04-17 23:55

You can start new COG in PASM·too. Spin is a higher level language (and all that comes with that concept) and can abstract away complexity of course. Spin can also produce more compact code than PASM ... in good hands, this would not matter though.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

MagIO2 · 2009-04-17 23:59

@philldapill
Of course a COG running PASM can start other COGs. What do you think the SPIN interpreter is? It's PASM code. So when SPIN can start new COGs PASM can do it as well. Easy thing is to start other PASM code.

@James
NO. The SPIN interpreter is written in PASM. So, everything that can be done in SPIN can also be done in PASM!

Mike Green · 2009-04-18 00:14

Some things that aren't the same:
1) There's no multiply or divide operation in PAsm. Spin does it using a subroutine and makes the operations available as a primitive operator. There are a few other less common things that are primitive operations in Spin done by subroutine in Pasm.
2) Pasm has the ANDN instruction which is very handy for doing I/O. Spin has separate AND (&) and NOT (!) operations.

Timothy D. Swieter · 2009-04-18 00:46

I think you might be getting the picture James with the above posts. One thing that may be highlighted is that there isn't always a one to one correlation of a SPIN command to an PASM command. SPIN being a higher level language takes care of some handling's automatically where in PASM you need to be verbose in what you want done and how to do it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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

James Long · 2009-04-18 06:35

I appreciate all the feedback. I figured the answer already, but I wanted to make sure.

My short time from Pasm research created some questions:

Because the increase in speed, how does a person insure they do not over speed a bus, like I2C? Do you just build in pauses, and reduce them until the chips freak out? Or does a person use an O-scope to check the bus? What do the members here do?
Does using Pasm, speed up every operation?
Can the "_" be used in Pasm?

I ask the second question, because of one item I'm using now, doesn't appear that Pasm would speed it up much, but my take on Pasm may be wrong.

If using lookdown in spin, the program is basically stepping through values to match another. In Pasm, it would be a simple loop (well simple in Pasm terms) with a loop counter in it. I know that is easier to type than do, but still the background operation is the same.

At this point, I wondering if it would be a "for instance" of an operation that would make little difference. Am I totally missing the point?

I have looked at Pasm, and after a few years of staring at Spin, it is less intimidating than at my first view of it. But I have yet to write any programs in it. I have looked at a few "starter programs" (tutorials) and Desilva's PDF. Mind you I haven't been through it all.

There are a few things (a bunch really) that do not make a huge amount of sense, but those will come with time.

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer

Lil Brother SMT Assembly Services

Timothy D. Swieter · 2009-04-18 06:43

James Long said...

Because the increase in speed, how does a person insure they do not over speed a bus, like I2C? Do you just build in pauses, and reduce them until the chips freak out? Or does a person use an O-scope to check the bus? What do the members here do?

Does using Pasm, speed up every operation?

To the first question, a lot of the code I have seen isn't geared to run at a set speed based on clock of the MCU. I am guilty of this too and I should start doing better in my own code. Some code just runs flat out and it is within limits of the operating device, however this is sloppy programming and I think a lot of objects may break with the Propeller II or may already break of someone runs on the code on a 40MHz Prop versus an 80MHz. clock. For instance, the I2C code runs flat out, but by I2C standards from what I understand there is a 100KHz and 400kHz operation, but the ICs out there, for the most part, don't care as long as it is getting its clock and not watching setup time of the signals. The Prop II will surely thrust this issue into light.

For the second question, sure why wouldn't it speed up the operation? For some though, the 'programming' and 'debugging' operation may be slower than in SPIN.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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

Mike Green · 2009-04-18 12:23

1) Where there's a specific speed involved (like I2C with its 100KHz or 400KHz clock), you build in specific pauses. In the I2C portion of the I2C/SPI PASM driver, there are WAITCNT instructions so the clock edges occur at approximately the right time. In the SPI part of the same driver, there are no WAITCNT instructions because the SD card can tolerate clocks at least up to 25MHz and the code is not tight enough to exceed that at 80MHz which is the highest in-spec clock speed for the Prop I.

2) If your code is using WAITCNTs or if your code is mostly using the cog counters, changing to PASM wouldn't necessarily speed things up because the timing is set by the system clock, not the program's execution time.

3) Yes, the "_" can be used in the PASM portion of a program

Write some simple programs in PASM and use GEAR to execute them so you can watch what happens when you execute them. Sometimes you can go crazy thinking about something new when just doing some of it makes things much clearer.

James Long · 2009-04-18 20:45

Mike Green said...
1) Where there's a specific speed involved (like I2C with its 100KHz or 400KHz clock), you build in specific pauses. In the I2C portion of the I2C/SPI PASM driver, there are WAITCNT instructions so the clock edges occur at approximately the right time. In the SPI part of the same driver, there are no WAITCNT instructions because the SD card can tolerate clocks at least up to 25MHz and the code is not tight enough to exceed that at 80MHz which is the highest in-spec clock speed for the Prop I.

2) If your code is using WAITCNTs or if your code is mostly using the cog counters, changing to PASM wouldn't necessarily speed things up because the timing is set by the system clock, not the program's execution time.

3) Yes, the "_" can be used in the PASM portion of a program

Write some simple programs in PASM and use GEAR to execute them so you can watch what happens when you execute them. Sometimes you can go crazy thinking about something new when just doing some of it makes things much clearer.

Mike,

So you are saying, you calculate pauses to place in your code to keep the speed in the range you want. I've noticed the I2C speed range, and still working to figure out how to use it.

I have been using your code to communicate with an SD card, and it works beautifully. Now if I can figure out the I2C part to communicate with a PCF8575 I'll be in the money. Then my only other task to deal with is making lookdown in Pasm.

I'm going to download GEAR again (I know I have had it in the past, but don't want to do a major search for it. I may have uninstalled it).

I appreciate all the help with learning Pasm. I'm planning to buy AndreL's (think I got that right) book on Pasm, and also go through the tutorials from the forum. There is a lot of information on Pasm here, and lot of great people.

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer

Lil Brother SMT Assembly Services

Mike Green · 2009-04-18 21:02

Reread the comments at the beginning of sdspiFemto.spin. I think the PCF8575 is very similar to the PCF9554. BoeBotBasic uses sdspiFemto (BB_i2cSpiInit and BB_i2cSpiLdr) to interface to a PCF9554 and there are some modifications to sdspiFemto and fsrwFemto (BB_massStorage) to support this to access an HM55B compass. The routines near the end are hm55bGet, hm55bPut, and hm55bValue.

The routines in BB_i2cSpiLdr are readExpander and writeExpander. There's a "pass through" interface for these in BB_massStorage because BB_massStorage uses BB_i2cSpiLdr. You'll see if you look at the code.

The PCF8575 requires a two byte read and two byte write. You could just make copies of readExpander and writeExpander and add a "2" at the end of the names, then change the byte count from 1 to 2 in the readExpander2 and writeExpander2 routines in BB_i2cSpiLdr. That way, you'll simply transfer 16 bit words instead of 8 bit bytes.

I think I posted a PASM lookup routine for 16 bit values in the PASM beginner's tutorial in one of the "sticky threads". Have a look for that message.

James Long · 2009-04-18 21:06

Mike Green said...
Reread the comments at the beginning of sdspiFemto.spin. I think the PCF8575 is very similar to the PCF9554. BoeBotBasic uses sdspiFemto (BB_i2cSpiInit and BB_i2cSpiLdr) to interface to a PCF9554 and there are some modifications to sdspiFemto and fsrwFemto (BB_massStorage) to support this to access an HM55B compass. The routines near the end are hm55bGet, hm55bPut, and hm55bValue.

The routines in BB_i2cSpiLdr are readExpander and writeExpander. There's a "pass through" interface for these in BB_massStorage because BB_massStorage uses BB_i2cSpiLdr. You'll see if you look at the code.

The PCF8575 requires a two byte read and two byte write. You could just make copies of readExpander and writeExpander and add a "2" at the end of the names, then change the byte count from 1 to 2 in the readExpander2 and writeExpander2 routines in BB_i2cSpiLdr. That way, you'll simply transfer 16 bit words instead of 8 bit bytes.

I think I posted a PASM lookup routine for 16 bit values in the PASM beginner's tutorial in one of the "sticky threads". Have a look for that message.

Mike,

Thanks, I'm sure I'll have more questions, but I'll try to make them more specific.

James

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer

Lil Brother SMT Assembly Services

James Long · 2009-04-19 00:37

Mike,

I have looked at the code, and it looks pretty straight forward. (BoeBotBasic) I do have a question. What is the default speed of the I2C. I'm having a hard time trying to find where it is set. I figure it is set in it's start up or init .

I've found it is difficult to go through others programs, but I'm getting better at it.

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer

Lil Brother SMT Assembly Services

localroger · 2009-04-19 01:57

@James -- I'm a bit late, but thought I should put in something philosophical that nobody has mentioned. The Spin interpreter is written in pasm. If it was not possible to do it in pasm, it would not be possible to do it in Spin. Just thought somebody should mention that.

ericball · 2009-04-19 02:11

There is one SPIN only command: CHIPVER.· I suspect the result is hardcoded into the encrypted ROM so isn't available to PASM.

I thought REBOOT was SPIN only, but there's a bit in the CLK register (set in PASM with CLKSET) to reboot the system.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: http://forums.parallax.com/showthread.php?p=800114

localroger · 2009-04-19 02:38

@ericball -- has anyone looked at the published source for the SPIN interpreter to see what it does when you ask for CHIPVER?

jazzed · 2009-04-19 02:50

Chip version is at hex FFFF

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230

Mike Green · 2009-04-19 04:02

The start method in either BB_i2cSpiInit or sdspiFemto computes the WAITCNT times for both 100KHz and 400KHz I2C clock speeds and stores them into the PASM code before COGNEW is called. The PASM driver code selects one set of constants or the other based on a bit in the control block used to start an operation.

James Long · 2009-04-19 07:06

Mike Green said...
The start method in either BB_i2cSpiInit or sdspiFemto computes the WAITCNT times for both 100KHz and 400KHz I2C clock speeds and stores them into the PASM code before COGNEW is called. The PASM driver code selects one set of constants or the other based on a bit in the control block used to start an operation.

Mike,

Yea, I see that. Now I'm just trying to figure out how to use the method. I made a second version with the following changes:

PUB writeExpander(addr,value) | t                      '' Write value to I/O Expander
    t := def#ioWrite1Cmd | def#ioLowSpeed
    return doOperation(t,addr,@value,1)

to this

PUB writeExpander(addr,value) | t                      '' Write value to I/O Expander
*   t := def#ioWrite1Cmd
*   return doOperation(t,addr,@value,2)

I have a small problem....and trying to work through it. Because I'm working with a breakout board I built, I'm using the pins backwards. My SCL is 5 and SDA is 6 so I'm looking to rewrite the asm a little to let me get around the problem.

I think I'm going to reverse the the order of the following (SCL and SDA)

 if_nc   mov     i2cClkHigh,i2cClkHigh4
                        mov     i2cTemp,i2cAddr
                        shr     i2cTemp,#18             ' Determine bit masks for
                        and     i2cTemp,#%11110         '  I/O pins for I2C bus
                        mov     i2cSCL,#1
                        shl     i2cSCL,i2cTemp
                        mov     i2cSDA,i2cSCL           ' SDA is next higher pin
                        shl     i2cSDA,#1
                        test    FirstCall,i2cSCL   wz   ' Is this our first call?
                        andn    FirstCall,i2cSCL        '  if so, do a reset
                if_nz   call    #i2cReset

to this

 if_nc   mov     i2cClkHigh,i2cClkHigh4
                        mov     i2cTemp,i2cAddr
                        shr     i2cTemp,#18             ' Determine bit masks for
                        and     i2cTemp,#%11110         '  I/O pins for I2C bus
 *                      mov     i2cSDA,#1
 *                      shl     i2cSDA,i2cTemp
 *                      mov     i2cSCL,i2cSDA           ' SCL is next higher pin
 *                      shl     i2cSCL,#1
                        test    FirstCall,i2cSCL   wz   ' Is this our first call?
                        andn    FirstCall,i2cSCL        '  if so, do a reset
                if_nz   call    #i2cReset

If I understand the commands correctly, I need to send the following to the method to get a output to turn on (PCF8575):

XXX.writeExpander (%0010_0000, %0000_0000_0000_0001)

This should turn on output 0 (or one if you count in standard terms). I'm only using the expanders for out. I do not need to read them at all.

I'm not sure if this will work or not.

I think I have tried all of this, but my results are not promising at the moment.

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer

Lil Brother SMT Assembly Services

Post Edited (James Long) : 4/19/2009 11:21:43 PM GMT

James Long · 2009-04-19 07:09

localroger said...
@James -- I'm a bit late, but thought I should put in something philosophical that nobody has mentioned. The Spin interpreter is written in pasm. If it was not possible to do it in pasm, it would not be possible to do it in Spin. Just thought somebody should mention that.

That was my original thought, but I figure it never hurts to ask.

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer

Lil Brother SMT Assembly Services

James Long · 2009-04-19 23:22

After looking at the code (for hours) I think my problem is with the command structure.

I'm not sure I'm initializing the system correctly, or missing something calling the command.

I'm really picking up on the Pasm pretty quickly, there are so many actions to this Object, it is pretty hard to follow.

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer

Lil Brother SMT Assembly Services

James Long · 2009-04-20 15:33

Mike, help I have a problem, and I'm really lost on it.

I finally got the I2C code somewhat working, but have a problem, and do not know where to look.

I went back and put everything back in it's original state. Then I changed the asm to put the SCL after the SDA. That was a no brainer after I studied it for a while (SHL to SHR).

I finally worked out the coding for the SCL address (actually found it in the Boe Bot Basic, and discovered that is what I needed).

I changed the count to 2(two) in the writeExpander method, but here is where the problem develops. If I keep the count as 2 I only get half of the PCF8575 outputs. They are the top 8 , but they come out on the bottom 8 on the I/O chip. They are reversed as well, but I found that problem, and I'm not sure how to fix that part.

If I bump the writeExpander up to 4 I do get other outputs but they are not working correctly. The outputs are not staying on long. If I wasn't paying attention, I probably wouldn't have noticed.

I'm not sure if I am aligned byte wise with the asm call, but have tried changing some length on the caller code. Nothing seems to work.

I really do not know where to look from here. Do you have any ideas?

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer

Lil Brother SMT Assembly Services

Mike Green · 2009-04-20 15:46

Post your code using the Attachment Manager.

James Long · 2009-04-20 16:12

Mike,

Please don't critique the mess, I'm still hacking at it (literally).

Here are the notes and locations of what I changed, that way you won't have to look hard to find any changes I did.

Under PCF8575 objects:

BB_Definitions lines 24 and 25

BB_i2cSpiLdr line 71

BB_i2cSpiInit lines 140 through 143

Sorry, I just edited line 143 from shl to shr. I forgot I put them back as original.

The main call that starts this lineage is in the top object file line 131 and 141

"lightout.main($XX,d1,@cuelist)"

If you can weed through that mess and find the problem, that would be great. I can't find it.

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer

Lil Brother SMT Assembly Services

Post Edited (James Long) : 4/20/2009 4:22:58 PM GMT

Mike Green · 2009-04-20 17:28

In BB_i2cSpiLdr, you've got

PUB readExpander(addr) : value | t                     '' Read value from I/O Expander
  t := def#ioRead1Cmd | def#ioLowSpeed
  if doOperation(t,addr,@value,1)                      '  (Return value zeroed on entry)
     return -1                                         '  Return -1 on an error

PUB writeExpander(addr,value) | t                      '' Write value to I/O Expander
  t := def#ioWrite1Cmd | def#ioLowSpeed
  return doOperation(t,addr,@value,3)

In writeExpander, the value should be 2, not 3. In readExpander, the value should be 2, not 1.

If I spot anything else, I'll post other messages

Mike Green · 2009-04-20 17:34

In BB_i2cSpiInit, may I suggest that instead of

                        mov     i2cSCL,#1
                        shl     i2cSCL,i2cTemp
                        mov     i2cSDA,i2cSCL           ' SDA is next higher pin
                        shr     i2cSDA,#1

you use the following instead

                        mov     i2cSDA,#1
                        shl     i2cSDA,i2cTemp
                        mov     i2cSCL,i2cSDA           ' SCL is next higher pin
                        shl     i2cSCL,#1

This way you still specify the pin pair, but SDA is the even numbered pin and SCL is the next higher odd numbered pin.

Mike Green · 2009-04-20 17:44

In your case, you've got an odd numbered SDA followed by the next higher even numbered pin for SCL so you'd need:

                        mov     i2cSCL,#1
                        shl     i2cSCL,i2cTemp
                        mov     i2cSDA,i2cSCL           ' SDA is next higher pin
                        shr     i2cSDA,#1

In this case, you'd supply the pin pair number of the SCL pin and the SDA pin would be the next lower.

You'd have ADDR = SCL << 18 where SCL = 6.

Please change BB_definitions back the way it was originally.

Note that the least significant byte is sent first and the most significant byte is sent second so bits 0-15 of the I/O expander should still correspond to bits 0-15 of the value passed to writeExpander.

James Long · 2009-04-20 18:15

Mike Green said...
In your case, you've got an odd numbered SDA followed by the next higher even numbered pin for SCL so you'd need:
                        mov     i2cSCL,#1
                        shl     i2cSCL,i2cTemp
                        mov     i2cSDA,i2cSCL           ' SDA is next higher pin
                        shr     i2cSDA,#1
In this case, you'd supply the pin pair number of the SCL pin and the SDA pin would be the next lower.

You'd have ADDR = SCL << 18 where SCL = 6.

Please change BB_definitions back the way it was originally.

Note that the least significant byte is sent first and the most significant byte is sent second so bits 0-15 of the I/O expander should still correspond to bits 0-15 of the value passed to writeExpander.

Mike so you want the BB_definitions to have the following:

General hardware dependent definitions

   maxPinPairs = 16                             ' Maximum number of possible I2C busses
  i2cBootSCL  = 28                             ' I2C Clock pin for boot EEPROM
  i2cBootSDA  = i2cBootSCL + 1                 ' I2C Data pin for boot EEPROM
  bootAddr    = i2cBootSCL << 18               ' File address for boot EEPROM

James

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer

Lil Brother SMT Assembly Services

Mike Green · 2009-04-20 18:57

Yes. It helps my sense of order. It's also one thing you don't have to remember to change back if you happen to try to use the object in some other program. Truthfully, it probably doesn't matter whether you change them back or not because "bootAddr" won't work with the modified cog driver anyway (because of how the I/O pin usage has changed).

James Long · 2009-04-20 19:02

Mike,

I made the following changes as you suggest,

I put the bb_definitions back original.

I used the shr asm command because, like a dummy, I put the pins backwards (and on an odd pin) on the breakout board.

I changed this in the PCF8575 driver object:

SCL = 6
ADDR = bootADDR + $40 << 8
bootADDR = SCL << 18

If I do not shift the SCL address in with the bootaddr, the chip never gets activated.

I think I'm going to need to modify the asm. I think it is doing two (2) write commands of 8 bits each. The PCF requires a 16 bit command (Address + 16). I think that is where the problem occurs.

I'm not positive that is the problem, but it seems to be. The first half (15-8) I/O barely blink (very rapid on and off) when turned on and off. The second half of the I/O (7-0) work as advertised (which makes no sense). I have tested with a spin Driver and it works fine until I switch over to asm.

I'm just guessing at this point.

James

BTW, I appreciate your help. I have learn more from Beau and you than anyone.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer

Lil Brother SMT Assembly Services

Mike Green · 2009-04-20 19:19

James,
I'm sorry I gave you wrong advice. The PCF9554 requires one address byte before the data while the PCF8575 only uses two data bytes. The following is corrected. The device select code is incorporated into the "addr" value. You can define "ADDR = (SCL << 18) + $40". Note that the device select code is in the least significant byte of the address for devices without an address byte.

PUB readExpander(addr) : value | t                     '' Read value from I/O Expander
  t := def#ioRead0Cmd | def#ioLowSpeed
  if doOperation(t,addr,@value,2)                      '  (Return value zeroed on entry)
     return -1                                         '  Return -1 on an error

PUB writeExpander(addr,value) | t                      '' Write value to I/O Expander
  t := def#ioWrite0Cmd | def#ioLowSpeed
  return doOperation(t,addr,@value,2)

Then you call it with "writeExpander(6<<18+$40,OUT)" or "writeExpander(ADDR,OUT)" with ADDR defined as above.

Post Edited (Mike Green) : 4/20/2009 7:26:52 PM GMT

Pasm vs. Spin

Comments