128bit Shiftout? how?

[gtvmarty]

Hi All,

I need to send a 128bit word to control some external equipment.

the equipment requires the 128bit word clocked into it, then a seperate pin is pulsed to 'store' that word, and repeated forever (as the 128bit word changes).

Looking thru the shiftout command, i see it is limited to 8bit (or 16 bit words) that it will send out.

If i shiftout my 128bit word as 16x (8bit)bytes (=128 bits in total) will that do anything weird to my 128bit word? such as adding pauses or delays etc?
(or i could send 8x (16bit words) too).

Of course there may be a better way to achieve this? anyone?

thanx in advance,
Marty.

[Chris Barron]

Hi All,

I need to send a 128bit word to control some external equipment.

the equipment requires the 128bit word clocked into it, then a seperate pin is pulsed to 'store' that word, and repeated forever (as the 128bit word changes).

Looking thru the shiftout command, i see it is limited to 8bit (or 16 bit words) that it will send out.

If i shiftout my 128bit word as 16x (8bit)bytes (=128 bits in total) will that do anything weird to my 128bit word? such as adding pauses or delays etc?
(or i could send 8x (16bit words) too).

Of course there may be a better way to achieve this? anyone?

thanx in advance,
Marty.


It shouldn't matter at all if you break it down into 16 bytes, you are using an 8-bit device anyway presumably so there isn't any other major option.

There's a few ways, if you can use assembler then that will produce the shortest execution time for one loop, but might be unecessary.
If you're using picbasic only, why not save your 16 bytes as an array...and rotate through them

In pseudo-pseudocode


shift_reg var byte[16] ' the 16 bytes independently accesible via the array construct

loop_cnt var byte ' overall loop counter


for loop_cnt = 0 to 15

shiftout shift_reg[loop_cnt]

next

toggle pulse I/O pin
....do something else here or loop back to the shiftout for-next loop

Because you are using a shiftout I've assumed the device you are sending to will accept the synchronous condition, in other words it will work at whatever speed you happen to shift your data out at, and not load it's contol registers until after you have pulsed the I/O line and in this case the controlled device will not perceive any transmission speed errors even if you have varying duration wait periods between the sending of each byte.

If the controlled device needs you to send a continuous stream within a fixed time period between the start and end of the transmission, with no gaps, then you may need to look to using a idfferent approach where you either write consecutive shiftout commands, or use and abuse some of the pic's communictions peripherals to do the sending for you, and while it is sending yoiu reload the buffer register behind the peripheral so that it can keep pumping out a continuous bitstream.

Without knowing the communications protocol on the controlled device its not possible to say for sure which method is best suited for it. Does the controlled device have a datasheet, the clues are usually to be found there