One little, two little, three littleendians

Duane Degn

I'm trying to shift out one byte of data in PASM.

I'd like to read the data in with a rdlong but I'm not sure where the MSBit of the byte is.

Is it bit 31 or bit 7? I had thought it would be bit 31 but now I'm not so sure.

I doubt bits are arranged differently in cog RAM than hub RAM.

I know the LSByte is located first but all the bit shifts seem to treat it as if it's located last (I think).

I'm hoping someone is in the mood to enlighten me.

Thanks.

Phil Pilgrim (PhiPi)

First of all, if you read a byte with a rdlong the byte address will have its last two bits truncated before the transfer. If the byte happens to be long-aligned, its MSB will be bit 7 of the long, and bits 8-31 will contain the three bytes that follow. If the byte is not long-aligned in the hub, its MSB could be read into bit 15, 23, or 31, depending on the misalignment.

Why not use rdbyte? Then the MSB will always end up in bit 7, and bits 8-31 will be zero.

-Phil

Duane Degn

Okay, I'm pretty sure the MSBit of one byte in a long is 7.

The Propeller must switch these around for bit shifting purposes.

I don't think I'm the first person to have problems with littleendian longs.

After learning a little of Spin's byte code, I can see where it can be useful though.

I'm still hoping someone can explain how this all works, but I think I can get back to programming now.

Thanks.

Duane

jazzed

You need to send a byte MSB first on a serial stream a bit at a time?
If so, you can use PASM ROR data,#8 (or SHL data,#24) to put bit 7 on bit 31.
Positioning the bit lets you to set the carry with an ROL or SHL (with WC).
With the carry set, you can use MUXC outa, pinmask.

' code fragment to shift "data" MSB first from HUB byte at "hubptr".
' assumes "len" is 8. output pin is defined in "pinmask" as 1 << pin number.
' there are faster ways to do this with counters, etc... but this is easy
' waitcnt could be used to pace the bit times.

  rdbyte data, hubptr
  ror data,#8
  mov len, #8
:loop
  shl data,#1 wc
  muxc outa, pinmask
  djnz len, #:loop

Hope that helps.
--Steve

Duane Degn

Phil, I hadn't seen your post when I posted my last message.

Thanks, I mainly want to use rdlong because I'm hoping to switch to shifting out a long at a time instead of just a byte in a SPI object I'm working on. Another reason is because that's the way it is done in SPI_Asm and I was kind of hoping to change as few things as possible.

I think I will change the variable to a byte and use rdbyte instead.

I'm still confused about using bytes inside of a cog. Beau sticks them in right in the middle of everything too (in SPI_Asm). That's just wrong. Cogs are for longs not bytes doesn't he know this?

I have noticed whenever someone uses bytes within a cog they are in groups of four. I think Beau uses some weird (since I don't understand it) shifting to access these bytes within the cog.

I hope I can get my head to stop spinning (or pasming in this case (ducking the shoe thrown at me)). I was making progress on my nRF24L01+ object and I want to think clearly enough to finish it.

(I just broke a personal promise to myself of never using a spin pun.)

Duane Degn

Steve,

That's just what I've decided to do.

It's always fun when I realize I understand the code posted in the forums.

I hadn't thought to use ror #8. I suppose that has the advantage over shl #24 in not losing the information in the top bits (if there were any information there).

Off to program (really this time).

Duane Degn

Just a quick thank you to those who helped. I've got my object working.

I'm use Steve's ror trick (it's nice since I can also use when it comes time to shift out a long).

I'm also using the shift left to write the c flag I had just barely learned from jhh before Steve showed it to me.