A little help with shifting out Arrays?

[SteveB]

Ryan,
I’m curious about the actual results you get with your example:

myArray VAR BYTE[3]

SHIFTOUT PORTB.0, PORTB.1, 1, [myArray\24]

Why? Because PBP is not aware of, and never tracks, the array size. In fact, it isn’t an array in the same sense that other languages use arrays (like VBA or .Net). PBP only knows that MyArray[0] is a byte at address $XX. It then ‘skips’ the number of addresses you specify in your array declaration before allocating another variable to a memory location. When you use brackets, it is really only offsetting [y] from $XX. Take this example:

myArray VAR WORD[4]

myArray[5] = 123

This is a perfectly valid expression, but will result in a lot of grief. What PBP will do is insert 123 into the two byte “WORD” located at a 5 WORD offset (10 bytes) from the memory location of myArray[0]. More than likely, that address will be allocated to another variable, so that variable will be corrupted, and your program will go off into a ditch pretty quick.

So back to your problem. When you use that shift out with myArray assigned, it really only understands that myArray is a Byte. Thus, I suspect it is trying to shift out 24 bits of data, but doing so in byte sized chunks. In doing this, it’s starting with the Address of myArray[0], just as Henrick states, and moving to the next address until 24 bits are sent.

But, I could be off track here, so I’m interested in what it’s outputting.

[HenrikOlsson]

Steve,
Ha, you're right, it even says that in the manual. However, and I guess I could try this, but are you (and the manual) saying that when using "\bits" it always shifts out LSB first? The manual really isn't clear as it just says it's the low order bits regardless of the MODE but it doesn't really say if it completely disregards the MODE and does LSB first even if told to do MSB.

I guess, based on Ryans post, that it does shift them out in the correct order, ie \24 on a long will start at the MSB of the third byte and go "down" to the LSB of the first byte.

As for Ryans array example I'd expect the output to be 00000001 01111111 11111111. The first bit going out is the MSB of myArray[0] and the last bit going out is the LSB of myArray[2].

/Henrik.

[Ryan7777]

I'll maybe try both ways and break out my logic analyzer. I get confused with the MSB/LSB stuff though. I guess the analyzer captures on the screen the first bit it sees on the left hand side of the screen and goes from there. So we'll see. I just have to think about what numbers to use to get a result I can fit my little brain around. high voltage modulators and vacuum tubes at work to microcontrollers and digital circuits at home. Maybe I should take up wood working as a hobby instead!

[SteveB]

Henrik,
What "low order bits" means in this case is that "\X" will always shift out the x lowest bits. So myByte\4 or myWord\4 or myLong\4 would all just output the 4 lowest bits. Now that the correct bits have been determined, it will shift them out based on the mode. So you can think of "\X" as "Shift out the lowest X bits of the variable"

This is why I'm curious about the actual output of the the shift statement used, which could be understood as, "Shift out the lowest 24 bits in the byte called myArray". As you can see, it doesn't make a lot of sense, but it's going to try to do something, and I am wondering what that something is.

[SteveB]

myArray VAR BYTE[3]

myArray[0] = 1
myArray[1] = 127
myArray[2] = 255

SHIFTOUT PORTB.0, PORTB.1, 1, [myArray\24]

Prediction:
The above code will shift out the following:
00000000 00000000 00000001

With myArray[0] = 127:
00000000 00000000 01111111

With myArray[0] = 255:
00000000 00000000 11111111

The values in myArray[1] and myArray[2] have no effect on the outcome.

[Ryan7777]

Sorry for not getting back to this. I've had my logic analyzer tied up for something else and haven't been able to get back to that project let alone this one due to some things beyond my control. I will however report back when I do get to it. I hate starting a question and not getting to the answer.

Best Regards,

Ryan

[SteveB]

I haven't had a chance to test it either. But my prediction is based on looking at the asm code produced. Although I noticed that I compiled it using PBPLong.

Using the non-long PBP, the results will be a little different, but likely still have 0000000000 00000001 as part of the result, since the internal temporary variable PBP uses is a 2-byte word, and it clears the top byte before entering the shift-out routine, then shifts out 24 bytes.

Bottom line, to do what you want, either of the following will work:
- Use 3 seperate BTYE variables
- 1 BYTE and 1 WORD variable
- 1 LONG variable

There may be some other, more creative way to work out the problem, but these are striaght foward and simple. The code may not look as 'tight', but it will work the way you expect/desire.

SB