Sending serial data to chip

Hello,

I am wanting to send serial data to an 8 bit serial to parallel converter IC in order to free up outputs on a Nano Every. My first thought is to manually implement this using a loop which (in principle) would look something like this:

    byte value = <some bit pattern>;
    byte length = <length of bit pattern>;
    byte mask = 1;

    for (byte i = 0; i < length; i++) {
      digitalWrite(<some output port>, value & mask);
      value = value >> 1;
      delayMicroseconds(100);
    }

I am not sure this is the best approach. For one thing, at this timing the digitalWrite() takes about 8% of the pulse width. I don't see how I can get around using delayMicroseconds() in order to keep things in sync as my loop can take 15ms each pass. I suppose I could measure the time for each write and calculate the delay time accordingly. Using too much longer of a delay time to try to mitigate the affect would begin to affect other processes in the loop. I suppose accessing the output register directly instead of digitalWrite() would take less time for the write. But I was hoping to keep things the most portable, but really, before heading down that road the question is, is outputting the data stream this way even the best approach?

I have considered whether I should use the serial data port and library, but I don't know if that would apply here or how to implement it, as the chip uses its own protocol for serial input which would not be what is normally used for serial communication.

Frankly I am pretty green in this realm and would benefit from some guidance.

Thank you kindly...

KevinJones:
...For one thing, at this timing the digitalWrite() takes about 8% of the pulse width. I don't see how I can get around using delayMicroseconds() in order to keep things in sync as my loop can take 15ms each pass. I suppose I could measure the time for each write and calculate the delay time accordingly. Using too much longer of a delay time to try to mitigate the affect would begin to affect other processes in the loop. I suppose accessing the output register directly instead of digitalWrite() would take less time for the write. But I was hoping to keep things the most portable, but really, before heading down that road the question is, is outputting the data stream this way even the best approach?

Ugh, I should have read the replies from my post yesterday first delayMicroseconds accuracy - Programming Questions - Arduino Forum (I had notifications turned off.) Even still,

"...but really, before heading down that road the question is, is outputting the data stream this way even the best approach?"

KevinJones:
I am wanting to send serial data to an 8 bit serial to parallel converter IC

First thing needed is a link to the datasheet for the IC so we can see what it requires.

...R

Robin2:
First thing needed is a link to the datasheet for the IC so we can see what it requires.

...R

Thanks for responding.

Page 3 has the timing sequence.

Maybe while you're looking at it, you can tell me how the thing tells the difference between the first frame and the second frame, since the start/stop patterns are the same, and addresses are the same. And for that matter, how it tells the beginning of the frame. The only thing I can guess is that the sender has to listen for Sout from the chip and start its stream then. (But then, it appears that the input stream triggers Sout?)

The serial data idle state is high. Each frame starts with a low start bit followed by a high bit. The duration of the low state determines the data rate for the following address and data bits.

I think that each frame shifts in 4 data bits, the output register is updated on every other frame. Eventually a delay between both frames will drop the already received frame. Find out yourself by watching Sout.

The datasheet is surprisingly sparse.

My guess is that the device expects 2 frames in every "message" and the address bits are used to make sure that two different messages are not confused. You should use a different set of address bits for each message.

My guess is that it detects the end of a frame by counting bits after the start bits.

It does not say so but it may be that it interprets a long idle period as the precursor to the first of a series of messages.

I think you are in for some experiments. :slight_smile:

Or a search for an easier-to-use chip :slight_smile:

...R

The address bits must be the same for both frames, else different devices are addressed.

Thanks for the feedback.

Robin2:
The datasheet is surprisingly sparse.

Indeed.

My guess is that it detects the end of a frame by counting bits after the start bits.

It does not say so but it may be that it interprets a long idle period as the precursor to the first of a series of messages.

I am guessing that is correct; seems like the only way. An idle state would have to be a high state on the input, since timing is determined between the falling edge of ST0 (low) and the rising edge of ST1 (high)

I think you are in for some experiments. :slight_smile:

Yup :slight_smile:

Or a search for an easier-to-use chip :slight_smile:

Not so easy, there are very few serial to binary converters out there AFAICT, and most of them are high voltage output. And this is the only device I've found that's not smt. AND, the datasheets I've looked at on these devices are even more cryptic that this one.

DrDiettrich:
The address bits must be the same for both frames, else different devices are addressed.

Correct. The chips can be programmed with an address on pins A0-A2, and you can use up to 8 devices to get 64 bits.

KevinJones:
Not so easy, there are very few serial to binary converters out there AFAICT, and most of them are high voltage output. And this is the only device I've found that's not smt. AND, the datasheets I've looked at on these devices are even more cryptic that this one.

Maybe I should be looking into implementing something like the MCP23017 (as was suggested to me in another thread.) But I'm expecting the SN74LV8153's in the mail today, and by now I'm very curious to see what I can do with it.

But I've ordered some MCP23017's anyway.

KevinJones:
The chips can be programmed with an address on pins A0-A2, and you can use up to 8 devices to get 64 bits.

I don't see why there would be any limitation on the number of devices.

I don't think it would be wise to send serial data to several devices over the same serial line - I can see nothing that would prevent the "wrong" chip from using the data.

As far as I can see the "address" bits are only used to match the two nibbles that amount to a single byte. I think "identification" would have been a better word than "address"

...R

Robin2:
I don't see why there would be any limitation on the number of devices.

I don't think it would be wise to send serial data to several devices over the same serial line - I can see nothing that would prevent the "wrong" chip from using the data.

As far as I can see the "address" bits are only used to match the two nibbles that amount to a single byte. I think "identification" would have been a better word than "address"

...R

The way I understand it, that is how it is designed, ie that all devices share the same serial line. From the datasheet:

Up to Eight Devices (64-Bit Parallel) Can Share the Same Bus by Using DifferentCombinations of A0, A1, A2

What prevents the "wrong" chip is that each device is programmed with an address (A0 - A2 pins on the devices). The address is sent in the bit stream which selects the proper chip. As there are 3 address bits, up to 8 devices can be configured this way and share the same serial line.

KevinJones:
What prevents the "wrong" chip is that each device is programmed with an address (A0 - A2 pins on the devices).

Sorry, I missed that piece completely.

But now I wonder how the device knows which of the two parts of a message is the first nibble and which is the second nibble. I had mistakenly thought that the address bits were intended to sort that out.

Apologies for any confusion by my earlier remarks.

...R

Robin2:
But now I wonder how the device knows which of the two parts of a message is the first nibble and which is the second nibble. I had mistakenly thought that the address bits were intended to sort that out.

Yes, that is exactly what I wondered. I'm playing with it now so I'll post my findings.

See datasheet and #4.

DrDiettrich:
See datasheet and #4.

I presume this is the #4 you are referring to

SOUT goes low when the data is received correctly and maintains a low level for one data-pulse period. Not tested, but specified by design.

I can see how that may be used to tell if the device has received 2 nibbles for the same address, but how does it ensure that the nibbles don't get mixed up.

I have seen nothing in the datasheet that defines the length of the interval (SP) between nibbles - I presume "SP" is shorthand for "space"

...R

The diagram suggests that SP (stop?) is as long as every other bit, see the internal sampling pulses.

He who wants to use that chip must love experiments, trial and error :wink:

I haven't exhausted this yet, but so far what I have seen, is if I transmit at least one[1] frame of HIGH pulses (10 clock cycles of HIGH), then send my 2 frames containing lower nibble and higher nibble, the device decodes it correctly.

I still need to do more exhaustive testing to be sure if this is reliable. I also want to find out that if I reset, and then send data immediately after reset is removed, if it will read the frames correctly.

[1] So far it appears like one will do it, but it's possible there may be ambiguity, I suspect that 2 full frames would initialize for sure though.

Edit: Well I have confirmed it takes at least 2 full frames.

DrDiettrich:
He who wants to use that chip must love experiments, trial and error :wink:

Yep, that's me :slight_smile:

Robin2:
I have seen nothing in the datasheet that defines the length of the interval (SP) between nibbles - I presume "SP" is shorthand for "space"

From the datasheet:

The serial data should be sent as 2START-3ADDRESS-4DATA-1STOP.

So I have concluded that the SP there is STOP, which has been proving itself in experimentation.

2START - ST0, ST1
3ADDRESS - A0, A1, A2
4DATA - D0, D1, D2, D3 (for first nibble)
1STOP - SP

Looking at the timing chart, I would say that the STOP (SP) between frames should be 1 clock cycle, but after the second frame it can be longer.

In asynchronous data transmission a stop bit assures a signal level distinct from the next start bit for a minimum time.