Is this allowed for i2c devices?

[hexafraction]

(BTW: Anybody got a source for short run boards like this?)

A good source is Oshpark: $5 per square inch of design, gets you three copies. This is two-layer with reasonable design rules. You won't be able to break out super-fine-pitch BGA with them of course, but the quality is good enough for relatively fine pitch SMD components, and of course more than good enough for through-hole. There's a good soldermask included as well (which is hard to get when milling your own PCBs). I plan to use them for most of my simpler sensor designs.

[4106Coach]

[QUOTE=mikets;27955]I think it may be a little overkill ...QUOTE]
Ha! This whole project screams overkill! But that's the summer fun!

Something like this https://www.sparkfun.com/products/12702 would clearly be a better choice if we are just making a few.

It was surprisingly not difficult to make a 4x10 pin header with all the 10 pins in a column shorted together with solder. But it looks like a mistake waiting to happen to short things out. This little board would be way better cleaner.

[dmssargent]

This is something worth looking at. The 6-device limit seems needless given that 127 addresses can be supported, the rules don't specify a limit on sensor count, and the connectors all share the same I2C bus anyway. If anything, the method should be cdim through hardware map -> i2cbus field (without any nonsense of creating separate i2c devices).

This doesn't seem to be as trivial as I thought, still it is doable. Since the extra effort for supporting what you are wanting is currently tied to the number of I2C devices supported; wrapping around one allows me to fix the other. Note that the version for Xtensible will be first (it has the backend code to make the wrapper simpler) then a stock version (I need to shim what Xtensible has and the wrapper needs)

[mikets]

Something like this https://www.sparkfun.com/products/12702 would clearly be a better choice if we are just making a few.

It was surprisingly not difficult to make a 4x10 pin header with all the 10 pins in a column shorted together with solder. But it looks like a mistake waiting to happen to short things out. This little board would be way better cleaner.

We tried similar boards like the sparkfun one you mentioned but that doesn't work well because like you said, to short adjacent .1-inch pitch holes with solder, the solder blob got so big that it is dangerously close to shorting unintended neighbors. We also tried to use a section of bare wires to solder the whole row of holes. That works much better but it still looks very unprofessional. So we found protoboards that actually have rows of holes already tied together. That makes the soldering job a lot easier and looks much nicer. And in effect, that is exactly what you want to achieve with custom layout boards, not to mention a lot cheaper too.

[dmssargent]

This doesn't seem to be as trivial as I thought, still it is doable. Since the extra effort for supporting what you are wanting is currently tied to the number of I2C devices supported; wrapping around one allows me to fix the other. Note that the version for Xtensible will be first (it has the backend code to make the wrapper simpler) then a stock version (I need to shim what Xtensible has and the wrapper needs)

Does anyone want the wrapper API to support more than 6 devices and/or more than one port callback? If so, I need to know if the device limit is 111(ModernRoboticsUsbDeviceInterfaceModule.MAX_NEW _I2C_ADDRESS - ModernRoboticsUsbDeviceInterfaceModule.MIN_NEW_I2C _ADDRESS) or 127? Also, when is "startupComplete()" called? Since if the call happens outside of OpMode code, I essentially need to rewrite a good portion of ftc_app SDK to make everything work (the Robot Service, Hardware Factory, main Activity, Modern Robotics*, etc.).

A single constant defines the number of allowed devices, ModernRoboticsUsbDeviceInterfaceModule.NUMBER_OF_P ORTS, which is 6. Since that constant gets inlined at compile-time, you have to rewrite a good chunk of the class hierarchy (as that constant gets passed to the super class). This much code rewriting may require to use the ftc_app Qualcomm license.

[FTC0417]

I wonder if the firmware in the CDIM is set up to be able to handle an arbitrary number of I2c devices, or only six. My suspicion is that it's the latter.

[FTC6081]

Note also that there are electrical concerns with adding too many i2c devices to a bus. The i2c spec requires total capacitance of less than 400 pF. (Though this app note says you can get away with more if you adjust termination resistance appropriately: http://www.i2c-bus.org/i2c-primer/te...s-capacitance/). Unfortunately, we don't have control over the pullup resistor(s) in our configuration.

Does anyone know what ICs are used in the various sensors, and what capacitance they have?

Ribbon cable, such as is used in the connections to the DIM, can add about 50 pF/meter. If you have too much capacitance in the system, the square edges of the signals get rounded over so much that communications becomes unreliable.

[GearTicks]

I wonder if the firmware in the CDIM is set up to be able to handle an arbitrary number of I2c devices, or only six. My suspicion is that it's the latter.

If you look at the last page of the MR spec sheet for the CDIM (at http://modernroboticsinc.com/Content...ation_v1_1.pdf), you can see that there is a set of registers corresponding to each of the 6 I2C slots, so the CDIM is designed to handle only six devices. If you wanted to use more, you would have to switch between I2C addresses on a single I2cDevice instance, much like switching between which registers are being read on an I2C device.

[4106Coach]

If you look at the last page of the MR spec sheet for the CDIM (at http://modernroboticsinc.com/Content...ation_v1_1.pdf), you can see that there is a set of registers corresponding to each of the 6 I2C slots, so the CDIM is designed to handle only six devices. If you wanted to use more, you would have to switch between I2C addresses on a single I2cDevice instance, much like switching between which registers are being read on an I2C device.

Hmmm. It seems this could be impossible to workaround to have more than 6. It does seem doable to switch addresses on the fly. Looking at the I2cDeviceSyncImpl class, the constructor seems to just assign the address to a register and the setI2cAddress seems wrap a simple change to that register with some semaphore logic. So it would seem trivial to make work ...

I'll post after Wednesday about that. We are doing an all-day completion to our summer-long FTC camp that day and should have a good chunk of time to play with it.

Thanks for the great idea to try.