the soldering of the white nylon connector with it's very thin wires is fragile.
Maybe it's just a bad connection in wiring and is the TOF10120 module ok.
Something I don't understand is why the I2C address finder worked and thus there was a communication!
But then again maybe it gave the wrong address.
Last edit: Haroen 2021-01-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
there's 5 pads on the back which maybe attach to flying leads. I'll buzz them first
I did not get the point Haroen made about the white lead as it's serial tx.
why does tof red supply go to nano Vin and not +5V ?
Don't know, I just did. There is a 5VReg 1117 in between!
Works on both!
But when I connect the red wire to 3V3 I get your printscreen error distances!
Stan, have you tried it before on 5Vin?
How to read serial from the other tof 2 wires if i2c not working.
I have not tried that yet in gcb. Worked in Picaxe code.
Evan,I could post device to you 2nd class letter post, if you are interested.
Send thru! :-)
Will you be using your Logic analyser, would like to join to see how you proceed...
Maybe Stan will then use his too,
Maybe Chris Roper could show his Sigrok Project Logic analyser.
why does tof red supply go to nano Vin and not +5V ?
Don't know, I just did. There is a 5VReg 1117 in between!
Works on both!
But when I connect the red wire to 3V3 I get your printscreen error distances!
Stan, have you tried it before on 5Vin?
vin is supply in to nano/uno.
It bypasses on board reg
so you could run vin from 3.3V but it will be below spec but logic levels will be 3,3V not 5V
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Stan: I did not get the point Haroen made about the white lead as it's serial tx.
Haroen: the soldering of the white nylon connector with it's very thin wires is fragile.
Correct Stan, white lead it's serial tx!
I said another thing about the "white nylon connector". Check the connections carefully.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These are somewhat misleading as they do not actually determine the pins used for I2C. The I2c library looks to see if the constant HI2C_Data is defined. If it is defined then Hardware I2C is used. The value is irrelevant. It could just as well be
#DefineHI2C_DataNanaNanaBooBoo
As far as I can tell .... "#Define HI2C_Clock" does nothing at all except use up space.
My guess is that they have been retained in the demos for "compatibility " . It might be that some very old PIC chips use these pin values but I have not found one yet . It should be sufficient to
simply use < #Define HI2C Data >
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Haroen: Both works but why?! Doesn't it matter in gcb?
William Roth: It should be sufficient to simply use < #Define HI2C Data >
Anobium: However, the two constants are used for documentation and should be retained.
I think it is essential to know for everyone using GCB that I2C works like that.
But I think Anobium is right that it should be rule that GCB style is to always document your connections like this!
Maybe put it in the GCB manual guide lines and on the Open Discussion Main page.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The registers, within the I2C init routine, sets values to config the IC2. The is also a script to calculate the register value to set the I2C frequency.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I cannot see the connections on the photo you posted. On most UNO boards SCL and SDA are brought out on AD4 and AD5 as well as on Pins 10 & 9 on the 10 Pin header(Right next to AREF). You seem to have them connected somewhere in the center of your board.
The UNO board does not supply Pullups for the I2C lines. So they need to be provided by the device or added by you. Your measurements indicate that there are no pullups fitted, which is likely not the case. My guess is that you are measuring the wrong pins/connections.
If you disconnect the device completely and measure the resistance between PIN6 and V+ and Between PIN5 and V+ ( On the TO device) ... you should get the resistance of the Pullups fitted on the device. Should be 10K or less. With your somewhat long leads the resistance should be less than 10K for reliable operations. A good value might be around 3.3K. So you could add additional 4K7 pullups in parallel to the ones already on the TO device to get to more appropriate value.
The discovery demo shows a Speed of 400. Not sure why 400 but I would reduce that to 100 for
Testing/Discovery.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I measured a resistance between PIN6(green) and V+ = 13M, way to high!
Why it works with mine I don't know but I will also do for good practise...
William Roth: Should be 10K or less. With your somewhat long leads the resistance should be less than 10K for reliable operations. A good value might be around 3.3K. So you could add additional 4K7 pullups in parallel to the ones already on the TO device to get to more appropriate value.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to the TO1020 Datasheet. Pin 6 is SCL and Pin 5 Is SDA. These lines both need to be pulled up since the microcontroller I2C lines can only sink current. The source current is supplied via the pullup resistor. It would seem based upon your measurement that the TO1020 has no pullup on the SCL line (Pin6) . Is the measurement on PIN 5 to V+ the same?
The value of the Pullup resistors generally depends upon the length of the wires and/or the parasitic capacitance on the PCB(s). Originally i2c was intended as a communication protocol between devices on a PCB where traces were relatively short. 10K Pullups were usually sufficient. Adding external leads requires increased source current (lower resistance Pullups) to overcome the added parasitic capacitance and therefore to produce a cleaner waveform.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would use the I2C Discovery program((s) in your demo folder - this the quickest way to test all the I2C devices,
Sensor connected
1 DATA to 5v rail=2Meg
2 CLOCK to 5v rail=2Meg
Sensor disconnected
3 DATA to 5v rail=11Meg
4 CLOCK to 5v rail=11Meg
Off the top of my head.... those R values are way way way of of whack.
2.2k is typically.. You cannot run I2C at any frequency with 11m0 Ohms. It would be snails pace clock frequency.
Can you check the circuit ? Check connections. Look for some resistor.
the soldering of the white nylon connector with it's very thin wires is fragile.
Maybe it's just a bad connection in wiring and is the TOF10120 module ok.
Something I don't understand is why the I2C address finder worked and thus there was a communication!
But then again maybe it gave the wrong address.
Last edit: Haroen 2021-01-23
https://sourceforge.net/p/gcbasic/discussion/579126/thread/1fe0a785f5/?limit=25&page=1
why does tof red supply go to nano Vin and not +5V ?
looking for i2c finders for 328 in demos and git hub always wrong pins for
scl/sda
~~~
#chip mega328p,16
#option explicit
#include "displaydevices.h"
"displaydevices.h" can not be found error and syntax errors relating to this.
;----- Define Hardware settings
' Define I2C settings
#define HI2C_BAUD_RATE 400
#define HI2C_DATA PORTC.5
#define HI2C_CLOCK PORTC.4
~~~
https://github.com/stanley74/Great-Cow-BASIC-Demonstration-Sources/blob/master/I2C_Solutions/I2C_Discovery/i2cHardwareDiscovery_to_Terminal_mega328p.gcb
I'm trying this one from github...getting terminal shown.
https://github.com/Anobium/Great-Cow-BASIC-Demonstration-Sources/blob/master/I2C_Solutions/I2C_Discovery/i2cHardwareDiscovery_to_Terminal_Alternative_Display_mega328p.gcb
Last edit: stan cartwright 2021-01-24
From that terminal display... you have no PullsUp.
Please adapt the demos to correct if they are incorrect.
Which is the correct i2c finder for 328 only please?
I tried with 3.8K pullups before and no difference/
Haroen said not needed
well plugged a ssd1306 i2c display in and it works with same 3.8kR pullups and i2c address finder says 78 which is the correct address.
How to read serial from the other tof 2 wires if i2c not working.
I just swapped it for a ssd1306 and that worked.
Evan,I could post device to you 2nd class letter post, if you are interested.
Last edit: stan cartwright 2021-01-24
Send thru!
:-)
there's 5 pads on the back which maybe attach to flying leads. I'll buzz them first
I did not get the point Haroen made about the white lead as it's serial tx.
Last edit: stan cartwright 2021-01-24
I tried but it won't work on the Arduino's and now I see that Stan did the same edit instead of #CHIP 16F18446, 32:
About the I2C in TOF10120 code I noticed the same:
And tried:
Both works but why?! Doesn't it matter in gcb?
Don't know, I just did. There is a 5VReg 1117 in between!
Works on both!
But when I connect the red wire to 3V3 I get your printscreen error distances!
Stan, have you tried it before on 5Vin?
I have not tried that yet in gcb. Worked in Picaxe code.
Will you be using your Logic analyser, would like to join to see how you proceed...
Maybe Stan will then use his too,
Maybe Chris Roper could show his Sigrok Project Logic analyser.
Connected to the Arduino UNO and working with Stan his connections:
Last edit: Haroen 2021-01-25
why does tof red supply go to nano Vin and not +5V ?
Don't know, I just did. There is a 5VReg 1117 in between!
Works on both!
But when I connect the red wire to 3V3 I get your printscreen error distances!
Stan, have you tried it before on 5Vin?
vin is supply in to nano/uno.
It bypasses on board reg
so you could run vin from 3.3V but it will be below spec but logic levels will be 3,3V not 5V
Correct Stan, white lead it's serial tx!
I said another thing about the "white nylon connector". Check the connections carefully.
These are somewhat misleading as they do not actually determine the pins used for I2C. The I2c library looks to see if the constant HI2C_Data is defined. If it is defined then Hardware I2C is used. The value is irrelevant. It could just as well be
As far as I can tell .... "#Define HI2C_Clock" does nothing at all except use up space.
My guess is that they have been retained in the demos for "compatibility " . It might be that some very old PIC chips use these pin values but I have not found one yet . It should be sufficient to
simply use < #Define HI2C Data >
Correct. The HI2C_DATA is the key test that Hardware I2C is to be used.
However, the two constants are used for documentation and should be retained.
I will say this again. If the demos are incorrect. Please correct in GitHub.
I think it is essential to know for everyone using GCB that I2C works like that.
But I think Anobium is right that it should be rule that GCB style is to always document your connections like this!
Maybe put it in the GCB manual guide lines and on the Open Discussion Main page.
Bill is correct.
I will be using both constants. :-)
So how are h i2c data and clk lines setup???
The registers, within the I2C init routine, sets values to config the IC2. The is also a script to calculate the register value to set the I2C frequency.
@Stan,
I cannot see the connections on the photo you posted. On most UNO boards SCL and SDA are brought out on AD4 and AD5 as well as on Pins 10 & 9 on the 10 Pin header(Right next to AREF). You seem to have them connected somewhere in the center of your board.
The UNO board does not supply Pullups for the I2C lines. So they need to be provided by the device or added by you. Your measurements indicate that there are no pullups fitted, which is likely not the case. My guess is that you are measuring the wrong pins/connections.
If you disconnect the device completely and measure the resistance between PIN6 and V+ and Between PIN5 and V+ ( On the TO device) ... you should get the resistance of the Pullups fitted on the device. Should be 10K or less. With your somewhat long leads the resistance should be less than 10K for reliable operations. A good value might be around 3.3K. So you could add additional 4K7 pullups in parallel to the ones already on the TO device to get to more appropriate value.
The discovery demo shows a Speed of 400. Not sure why 400 but I would reduce that to 100 for
Testing/Discovery.
@William - The uno used has extra pins for serial
I measured a resistance between PIN6(green) and V+ = 13M, way to high!
Why it works with mine I don't know but I will also do for good practise...
Re the example code. Sorted
I have posted a revised I2C Discovery program for the UNO.
Please review https://github.com/Anobium/Great-Cow-BASIC-Demonstration-Sources/blob/master/I2C_Solutions/I2C_Discovery/i2cHardwareDiscovery_to_Terminal_mega328p.gcb
I will delete all other MEGA328p programs from that folder.
Any changes needed ?
According to the TO1020 Datasheet. Pin 6 is SCL and Pin 5 Is SDA. These lines both need to be pulled up since the microcontroller I2C lines can only sink current. The source current is supplied via the pullup resistor. It would seem based upon your measurement that the TO1020 has no pullup on the SCL line (Pin6) . Is the measurement on PIN 5 to V+ the same?
The value of the Pullup resistors generally depends upon the length of the wires and/or the parasitic capacitance on the PCB(s). Originally i2c was intended as a communication protocol between devices on a PCB where traces were relatively short. 10K Pullups were usually sufficient. Adding external leads requires increased source current (lower resistance Pullups) to overcome the added parasitic capacitance and therefore to produce a cleaner waveform.