I've ran into a trouble while reading serial data. I'm trying to read data, that is fed into the shift register via serial input. The register is TPCI6C596, and it's installed into a vehicle instrument cluster. But all i'm getting is some trash noizy signals that look far from what should have been fed into the register.
I wired Arduino Nano Every to SER_IN, SRCK and RCK in parralel to a register pins
Here's my code:
#define SCRK 2
#define LATCH 3
#define SERIN 4
#define BITS 8
bool data[BITS];
short i = 0;
int t = 0;
int x = BITS;
void setup() {
Serial.begin(9600);
pinMode(SERIN, INPUT_PULLDOWN);
attachInterrupt(digitalPinToInterrupt(SCRK), clock, RISING);
attachInterrupt(digitalPinToInterrupt(LATCH), latch, RISING);
}
void latch() {
for (int j = 0; j < x - 1; j++) {
Serial.print(data[j]);
}
Serial.println(data[x - 1]);
}
void clock() {
int in = digitalRead(SERIN);
if (i < BITS) {
data[i++] = in;
} else {
for (int j = 0; j < x - 1; j++) {
data[j] = data[j+1];
}
data[x - 1] = in;
}
}
Can you, please, help me to get it to work, or at least give me some pieces of advice on it?
P.S. It's my first post here, please, don't be too harsh on me
First, have you also connected a ground between the system you're intruding on, and your Arduino circuit?
By the way, this is the sort of reason we ask that you provide some form of schematic. If the information is provided in your post, we can more quickly zero in upon what may be the problem.
Yes, I did. That's basicaly all I did. 3 wires to D2, D3, D4 pins of arduino directly to pins of a register and ground pin to ground of register
Fast schematics here (but I omit that arduino is connected to usb to read serail, all drains have LED's connected, and all other pins on IC also connected somewhere)
Well, that deals with the most likely cause of a 'noise' issue. Second thought: is the data valid for sampling on the edge you've configured to sample it? Clocked data systems generally rely on a clock signal which causes data latching on one clock edge and updating the data on the other clock edge. If you're triggering on the wrong edge, you'll get nothing but noise. An oscilloscope would make short work of figuring this out. Another way is to use a transistor or logic device to invert the clock to your shift register.
I'm sorry I can't be more precise, I don't know the devices involved.
According to the datasheet, yes.
Quote: Data transfers through both the shift and • Low Power Consumption storage registers on the rising edge of the shift register clock (SRCK) and the register clock (RCK), respectively
UPD: I tried to measure time between clock interrupts, and I'ts ~20000 microseconds (measured with micros() function). If my math is right, the signal has ~50Hz clock. Can it be too much for arduino to read?
Short of in-person o'scope measurements, I'm stuck. Perhaps someone else can see something in your code, or setup, but I'm out of ideas.
How do you know that's not the data that's being transmitted, by the way?
I might be really dumb, because 50Hz is Arduino's own interrupt frequency, as I read on the web (still new to this). Maybe signal is more than 50Hz, but I have no oscillo to measure it
What do you mean by
that's not the data that's being transmitted
If you mean that I might be reading data instead of clock, that shouldn't be a case, beacuse it's gathered from SRCK pin of shift register, and that should be clock.
For the clarity, basically, right now I'm trying to make a shift register out of arduino
What you said is pretty clear. As I understood it, the data is being clocked into the shift register, and you are attempting to 'eavesdrop' with your Nano. When one eavesdrops, one receives whatever's being said. So if you're correct, you're sampling on the right transition, is it possible you received exactly what you should have received? How do you know the data is incorrect? Do you know how the data is encoded? Do you know what the data should be?
As for reading a data stream being clocked at 50 Hz, no, it's not impossible. A Nano can do that in it's sleep, without resorting to interrupts, if coded smartly. Note carefully the "if".
One thing you should keep in mind is that I have an instrument cluster on my desk, so I see which leds are lit. So I have some understanding on how the data should look like. And it shouldn't be noziy at all (leds are stable)
Yes, if it's being fed into the register, it should comply with datasheet, shouldn't it?
That's a big IF for me . I'm really new to programming this close to hardware, so if you have any examples of the top of your head on how to read data like that with Nano, I'd be gravely grateful
Because I need to know which leds are lit at any time
The serial output (SER OUT) is clocked out of the
device on the falling edge of SRCK to provide
additional hold time for cascaded applications. This
will provide improved performance for applications
where clock signals may be skewed, devices are not
located near one another, or the system must tolerate
electromagnetic interference.
Well, then I'll be reading data, that is no longer in the register, so not showing current state. The clock is constant though, so that might work, but it seems like i'm going to have same troubles as now
One thing you should keep in mind is we're not there in person, nor have we seen a complete schematic; if this is a single shift register, and that stream represents several bytes sampled continuously, instead of one write cycle, then yep, your data stream is either being sampled incorrectly, or possibly, the data is not being produced 'purely', but was considered good enough by the supplier to release the hardware. If you sample it correctly, you may find 'burst's of data with dead time in between. I.e. it's not being shifted out continuously. Which would tell you where your byte begins and ends. Though, there might be other signals you can monitor to determine when the stream begins and ends.
However, I think you're correct, it's your code. I'm out of time, there are others who can continue with you.
One edge behind..
looking at datasheet, maybe tap CLR instead of RCK..
CLR should tell you when to data is ready to read..
But yes @camsysca is correct, none of us are there and I don't have one of these to experiment with..
but, yes I think you may have better results..
first method, too me..
is the old cat in a box..
assumed alive an well..
till we look and the act of looking, kills the cat..
Do you have tools to measure the signal? E.g. a logic analyser or scope? It would be useful to know the frequency of the clock and to know if the TPCI6C596 is constantly updated or only when data changes.