Need help for i2c communication with FDC2214

[ressas]

Hello to everyone. Fdc2112 integration was corrupted. So I had a break. I made a new experiment with a new integrated.
I have not made any changes to the above code.
The code worked properly. Thank you to everyone who helped. Under this heading we have run both FDC2214 and FDC2112 integrations. We can close the title here.
However, if you want to continue; let me ask you a question
As output in FDC2214 IC; We were getting 32-bit data like "15505207, 15639900, 15257648, 15034281". The last 3 digits were constantly changing.
In FDC2112 IC (in the code above), we get values between "0-255".
I couldn't get a result by changing the variable types.
Datasheet also writes that I can make a reading of 12 bits. How can I do that?

[ressas]

Let me also state that in order not to waste time.
Combining the variables "Dummy" and "Reading" with the make32 command only grows the number. However, sensitivity does not change.

[Ttelmah]

Of course it won't.
On the high accuracy chip there is an extra word to read.
On the low accuracy chip there isn't. However the data sheet implies
that this value should be read or there may be issues. Hence it is read into
'dummy', to ensure this doesn't cause a problem, but the value is useless.

[ressas]

Thank you Ttelmah.
Can you tell me from which page of datasheet you learned this information?

[ressas]

Because datasheet also writes that this integrated is 12 bits. Therefore, I should read between 0-4096 and not between 0-255.

[Ttelmah]

The data sheet is the note:

[ressas]

The value I normally get was this;

[Ttelmah]

All this means is that you are really reading a value of 208. You have now
multiplied this by 16 so it displays as 3340, but now if a larger signal
comes in, the top bits of this will be lost.
This is great if your signal is never going to go over 255, but if it does
data will be lost. So you have restricted the maximum signal the system can
now handle. Implies there was nothing wrong with the maths or display,
it was just your signal was too small....

The unit is displaying the whole 12bit value fine. Hence 4095 in the unused
channel. It's just that the actual signal you have only gives a reading of
208.

[ressas]

What you say yes is correct. However, I did not directly multiply the data by 16. If this were the case, the change that occurred when the object approached would be 16 units. However, it changes one by one.
Secondly, it will never exceed 255. Because its idle value is 255. The value decreases as the object approaches.
What I do not understand; if I see 4095 in one channel, I should see a value close to that value from the other channel. But after the "offset" operation, I see values like 3000. I was hoping to get similar values without using "offset"

Thanks for helping me with my search Ttelmah.

[Ttelmah]

Yes. The advantage of the shift, is you actually access the extra 4 bits of the
ADC. The '12bit' chip has a 16bit ADC. It just only ever outputs 12bits
of this. However the point was the the reason you are needing this is the
signal is only covering about 1/5th the input range, and you therefore
need to be very careful if you are not going to over range this input.
The 4095 from the second channel is almost certainly a sign that
it is simply going 'full scale', which implies this channel is not seeing a
signal. You need to look carefully at how this is actually wired/configured.
You 'as standard' get the 28bit value.65536. With the shift applied, you
instead get the 28bit value over 4096.