How about the pull-up resistors and line length? Is there a difference for the 6th in that respect. I2C can be critical to the R-value, where it is, and how long the line is.
Many thanks for your reply and again my thanks for your great work in providing the VL6180X OBEX software. As you mentioned, the setup for this tiny chip must of been a nightmare!
Each sensor board has its own integrated pull-up resistors, and I swapped the VL6180X sensor boards from the working cog1-cog5 setups with the cog6 setup and had the same result. Line lengths are also the same and quite short, and the results are not intermittent. I also wiggled all of the wires on the whole setup to see if there might be a wire current induced problem and there were no intermittent or erratic results. As I mentioned, your diagnostic that is in the i2cDriverX objects shows the same successful results for Cogs 1-6 ( ie, "High-Good", "Bus initialization Completed", "Bus Scan Completed"), EXCEPT that the diagnostic indicates that for the sensor in Cog6 that "0 Bus Slaves Found", whereas, for Cogs1-5 the diagnostic shows "1 Bus Slaves Found" even when I swap sensors in case the sensor in Cog6 was defective. This is the only difference that I have been able to determine. I don't know why the diagnostic for Cog 6 isn't recognizing the 6th sensor properly. Since all Cogs are independently running the identical software except for the hook-up pin designations, this really has me stumped!!!! I spend the last few weeks trying to track down the problem. Any ideas or suggested additional tests that I can run are sincerely appreciated! Best regards,
Thank you for your initial and subsequent suggestion. I am relatively new to electronics as well as the Propeller, so your shift register suggestion appears to be a bit above my current level. If there is some example how this may be implemented into this particular or similar application I would appreciate it, although since this is an odd application, I certainly understand if one is not readily available. As to your comment (below):
The RC time constant might be too long to be acceptable for the chip itself or you need more or less time on that 6th device. The shift register approach that I mentioned is a sure and certain way of initializing these chips though.
I don't understand if each Cog is independently running the identical software with identical independent sensors how one Cog may be running too fast or too slow for a different instance of the same hardware setup? I may be missing the whole point of your suggestion so please excuse me if it went over my head!
As far as I can see @robotics has taken the approach of starting 6 identical cog processes, each running the same type of code and driver objects, each driving it's own set of I2C pins, each driving it's own VL6180X. Strange then, that whatever instance of this chip does not respond to a I2C call on the 6th cog, but all other cogs do. Mystery.
If you do not start, say, cog 1 and 2, but go on to start cogs 3-6, does that make cog6 work? I am thinking this must have something to do with common resources, maybe stack usage, but I am not an expert.
Sorry, I was assuming you had implemented Erlend's idea of having all the devices on the same bus but it looks as if you are running separate buses for them so don't worry about shift registers.
Always best to not assume we know what you know, how you have it connected etc. Just lay it all out on the table for all to see and usually we spot the problem since it is not "hidden".
This applies to your code, just create a zipped archive from the Prop IDE and post it here. It may be you are trying to use more cogs than are available.
I noticed you have not changed the I2C driver code for each individual circuit. This may confuse the compiling and cause every call to the I2C object to use the same set of pins. This is discussed at the beginning of this thread.
The following part of the driver code is for that purpose:
ThisObjectInstance LONG 1 'Change to separate object loads for different physical buses
and you should set it to 1..6 according to which cog/circuit it belongs.
Erlend, Kwinn, and Peter: many thanks for all of your good points and questions.
Firstly, I attached a zip file wth the main control program, 6-i2cDriver objects, 6-Cog controllong objects. I hope this makes things easier to examine.
As a recap, by initiating sensors 1-6 of the VL6180x sensors, only sensors 1-5 would be activated. I set up a simple visual display of LEDs whereby if there is a distance measured of greater than 40mm, the associated LED would light up, otherwise, when you pass your hand over the sensor array, the LED's would successively turn off. Along the lines of Erlend's suggestion of trying different combinations of sensors, I reversed the order of activating the sensors FROM 1 to 6, TO 6 to 1. For this setup, again sensors 1-5 worked, and again the 6th sensor was not activated.
As Erlend suggested, I then activated sensors 2 to 6, with the result that the sensor 1 did not activate, and neither did sensor #6 (sensors 2,3, 4, and 5 did activate).
I then tried activating sensors 3 to 6, with the result that sensors 1-2 did not activate, and neither did sensor #6 (sensors 3, 4, and 5 did activate).
In regards to Kwinn and Peter's point that maybe the number of available Cogs was already used up. This had not occurred to me! I checked the Parallax Serial Terminal which was used to output numeric range data, and yes it does use 1 or more Cogs! So, I disabled this object and relied on the the Visual LED's display to verify if a sensor was operational. With the Parallax Serial Terminal disabled, the same results as outlined above were realized, in that sensor 6 did not operate, so it appears that the available number of Cogs is still in the safe zone for the 1-6 sensor trial. I now realize that perhaps if I had a sensor #7 and/or sensor #8 hooked up, then the Cog(s) used by the Parallax Serial Terminal would of caused a problem from a depleted number of available Cogs.
As I mentioned above, the only thing that I have been able to find that distinguishes sensor 6 from sensors 1-5 is Erlend's diagnostic which in the i2cDriver object which indicates that for sensor 6, that "0 slaves were detected" whereas, for each of sensors 1-5, "1 slaves were detected". As mentioned earlier, I swapped the #6 wiring, sensor, as well as pin assignments to no avail! A real puzzler!!!
Any insight as to why sensor 6 does not activate, while sensors 1-5 work fine is greaty appreciated!
So, as far as I can understand cog 6 has never been able to run sensor 6?
Have you tried to only alter the pin numbers (and connect the sensor to those other pins instead) to see if it works then?
An other approach is to run eg sensor 5 on cog 5, and then change one thing at the time toward becoming #6. First change I2C driver, then chip driver, then pin numbers, etc. until what you have is identical to your #6 setup. Somewhere along that road you should hit the error.
I appreciate your observation and suggestion. I actually wasn't too certain the effect of this line in the coding. I had thought that by specifying the following code ( with actual corresponding pin numbers) for in each i2cDriverX object that this would force the correct pins to activate:
LONG[@PINscl]:= 15 'Copy pin into DAT where it will survive
LONG[@PINsda]:= 16 'into later calls to this object
Nonetheless, I just changed the code in each of the i2cDriverX objects to the following respectively and there was no change in the operation of the Sensors/LED's:
ThisObjectInstance LONG 1 --- for i2cDriver1
ThisObjectInstance LONG 2 -- for i2cDriver2
ThisObjectInstance LONG 3 - etc
ThisObjectInstance LONG 4
ThisObjectInstance LONG 5
ThisObjectInstance LONG 6
I think our postings have crossed simultaneously! I did not specify particular Cogs in the coding, however, I believe that Cog 0 is used by the main control program on startup, whereby Cog 1 would be associated with Sensor 1, Cog 2 with Sensor 2, etc. as these objects are successively activated. Your recent post lists some good areas which to probe. I will work on these tonight and let you know where they lead. Thank you again for your thoughtful assistance.
You are using the objects in a different way than I anticipated, eg. by hardcoding the pin numbers in the I2C driver instead of passing them in the Init call. A bit confusing.
I suppose you have tried to force high the Reset signal (pin 26?)
Eureka! The six sensors now work fine with Erlend's code. The problem I was having was traced down to a faulty connector pin on my proto board! Very elusive as I wasn't sure if the problem was hardware and/or software. I want to thank everyone for their kind assistance and thoughtful suggestions. best regards,
I did a quick scan at DigiKey and noticed that they list many of the PCA9548A. I also noted that Adafruit carries a breakout board of the "TCA9548A I2C Multiplexer" at their link https://www.adafruit.com/products/2717
Do you know if your OBEX object is compatible with the "TCA"9548A in addition to the "PCA"9548A?
I've checked out the adafruit link. Yes, my object will work on this breakout board as this board is an extension of the pins from the IC and with the addition of bypass caps & pull-ups. Do download their pdf.
Comments
Erlend
Many thanks for your reply and again my thanks for your great work in providing the VL6180X OBEX software. As you mentioned, the setup for this tiny chip must of been a nightmare!
Each sensor board has its own integrated pull-up resistors, and I swapped the VL6180X sensor boards from the working cog1-cog5 setups with the cog6 setup and had the same result. Line lengths are also the same and quite short, and the results are not intermittent. I also wiggled all of the wires on the whole setup to see if there might be a wire current induced problem and there were no intermittent or erratic results. As I mentioned, your diagnostic that is in the i2cDriverX objects shows the same successful results for Cogs 1-6 ( ie, "High-Good", "Bus initialization Completed", "Bus Scan Completed"), EXCEPT that the diagnostic indicates that for the sensor in Cog6 that "0 Bus Slaves Found", whereas, for Cogs1-5 the diagnostic shows "1 Bus Slaves Found" even when I swap sensors in case the sensor in Cog6 was defective. This is the only difference that I have been able to determine. I don't know why the diagnostic for Cog 6 isn't recognizing the 6th sensor properly. Since all Cogs are independently running the identical software except for the hook-up pin designations, this really has me stumped!!!! I spend the last few weeks trying to track down the problem. Any ideas or suggested additional tests that I can run are sincerely appreciated! Best regards,
Thank you for your initial and subsequent suggestion. I am relatively new to electronics as well as the Propeller, so your shift register suggestion appears to be a bit above my current level. If there is some example how this may be implemented into this particular or similar application I would appreciate it, although since this is an odd application, I certainly understand if one is not readily available. As to your comment (below):
I don't understand if each Cog is independently running the identical software with identical independent sensors how one Cog may be running too fast or too slow for a different instance of the same hardware setup? I may be missing the whole point of your suggestion so please excuse me if it went over my head!
Again, I do appreciate your kind assistance.
Erlend
Yes, big mystery! Is there some additional diagnostic that you can suggest on Cog #6 that may shed some additional light?
regards,
Erlend
Always best to not assume we know what you know, how you have it connected etc. Just lay it all out on the table for all to see and usually we spot the problem since it is not "hidden".
This applies to your code, just create a zipped archive from the Prop IDE and post it here. It may be you are trying to use more cogs than are available.
The following part of the driver code is for that purpose: and you should set it to 1..6 according to which cog/circuit it belongs.
I still do not understand the symptoms, though.
Firstly, I attached a zip file wth the main control program, 6-i2cDriver objects, 6-Cog controllong objects. I hope this makes things easier to examine.
As a recap, by initiating sensors 1-6 of the VL6180x sensors, only sensors 1-5 would be activated. I set up a simple visual display of LEDs whereby if there is a distance measured of greater than 40mm, the associated LED would light up, otherwise, when you pass your hand over the sensor array, the LED's would successively turn off. Along the lines of Erlend's suggestion of trying different combinations of sensors, I reversed the order of activating the sensors FROM 1 to 6, TO 6 to 1. For this setup, again sensors 1-5 worked, and again the 6th sensor was not activated.
As Erlend suggested, I then activated sensors 2 to 6, with the result that the sensor 1 did not activate, and neither did sensor #6 (sensors 2,3, 4, and 5 did activate).
I then tried activating sensors 3 to 6, with the result that sensors 1-2 did not activate, and neither did sensor #6 (sensors 3, 4, and 5 did activate).
In regards to Kwinn and Peter's point that maybe the number of available Cogs was already used up. This had not occurred to me! I checked the Parallax Serial Terminal which was used to output numeric range data, and yes it does use 1 or more Cogs! So, I disabled this object and relied on the the Visual LED's display to verify if a sensor was operational. With the Parallax Serial Terminal disabled, the same results as outlined above were realized, in that sensor 6 did not operate, so it appears that the available number of Cogs is still in the safe zone for the 1-6 sensor trial. I now realize that perhaps if I had a sensor #7 and/or sensor #8 hooked up, then the Cog(s) used by the Parallax Serial Terminal would of caused a problem from a depleted number of available Cogs.
As I mentioned above, the only thing that I have been able to find that distinguishes sensor 6 from sensors 1-5 is Erlend's diagnostic which in the i2cDriver object which indicates that for sensor 6, that "0 slaves were detected" whereas, for each of sensors 1-5, "1 slaves were detected". As mentioned earlier, I swapped the #6 wiring, sensor, as well as pin assignments to no avail! A real puzzler!!!
Any insight as to why sensor 6 does not activate, while sensors 1-5 work fine is greaty appreciated!
regards,
Have you tried to only alter the pin numbers (and connect the sensor to those other pins instead) to see if it works then?
An other approach is to run eg sensor 5 on cog 5, and then change one thing at the time toward becoming #6. First change I2C driver, then chip driver, then pin numbers, etc. until what you have is identical to your #6 setup. Somewhere along that road you should hit the error.
Keep at it!
Erlend
I appreciate your observation and suggestion. I actually wasn't too certain the effect of this line in the coding. I had thought that by specifying the following code ( with actual corresponding pin numbers) for in each i2cDriverX object that this would force the correct pins to activate:
Nonetheless, I just changed the code in each of the i2cDriverX objects to the following respectively and there was no change in the operation of the Sensors/LED's:
regards,
I think our postings have crossed simultaneously! I did not specify particular Cogs in the coding, however, I believe that Cog 0 is used by the main control program on startup, whereby Cog 1 would be associated with Sensor 1, Cog 2 with Sensor 2, etc. as these objects are successively activated. Your recent post lists some good areas which to probe. I will work on these tonight and let you know where they lead. Thank you again for your thoughtful assistance.
I suppose you have tried to force high the Reset signal (pin 26?)
Erlend
I just went in the i2cDriver6 object and forced pin 26 high and it did not have any effect.
regards
obex.parallax.com/object/106
Do you know if your OBEX object is compatible with the "TCA"9548A in addition to the "PCA"9548A?
In advance, thank you.