![]() |
i2c output
So the I2C class has a Write() routine, however its asking for a register address and a piece of data... so what if you just want to write a byte(or a sequence of bytes) to the device? Is it possible to do this?
|
Re: i2c output
I2C is a multi-drop buss. It is designed to support multiple I2C devices all daisy-chained together. Thus most devices require an address byte to precede the data. And the address usually includes a bit to tell whether you are writing to the device or wanting to read from it. Remember there is a single bi-directional data line.
So unless you designed a custom I2C peripheral you need the address anyway. HTH |
Re: i2c output
Right, I knew that part. But it seems to me that the Write() function is referring to a different address. The problem is that the constructor of the class takes an address, which is transmitted along with the data (or at least, something is being done with it each time). Unless its referring to a different type of address...
I suppose I'll find out tonight when I play with it. :) |
Re: i2c output
Usually the address is sent every time and one bit in the address is changed to indicate whether it is a red or write operation (just after the address which is always written of course). So sounds like you need a class instance for every device you intend to talk to.
HTH |
Re: i2c output
Quote:
Internally, they may (and usually do) have multiple registers. These registers are numerically indexed -- 0, 1, ... N. If the I2c device you want to access only has 1 user accessible register, then use register address (register number) 0. Additionally, for I2C devices that do have multiple internal registers, you can read or write multiple consecutive registers by specifying the first register number and supplying multiple bytes of data. |
Re: i2c output
Before getting too deep into I2C, you should read this:
http://forums.usfirst.org/showthread.php?t=11227 We asked for clarification on the rules, GDC says no ethernet, serial, or I2C. Just a heads up. -Jeff Erickson, FRC 41 |
Re: i2c output
Quote:
FIRST and the GDC said nothing about restricting access to I2C until now! they even mention it as a good bus for connecting sensors in the FRC Suggestions PDF that has just been uploaded. I can find no mention of restricting I2C in the rules up to this point. They have only mentioned CAN bus restrictions. Why would FIRST suggest it as a good way to connect sensors if it is going to be banned from use?!! http://www.usfirst.org/uploadedFiles...%20Rev%20A.pdf (FIRST & GDC if you are reading this, Please don't restrict the I2C bus......) Edit: dang <R67> seems to prohibit I2C. But, that just pisses me off that they recommend it as a good way to hook up sensors, but at the same time prohibit it! |
Re: i2c output
The rules also seem to prohibit the use of the Axis camera. There doesn't seem to be a specific exception in the rules for the Axis camera, and since the camera is, by definition, a sensor, and <R67> prohibits hooking sensors to the Ethernet port, using the camera is a violation of <R67>. I would guess that they will make a rule change to allow the specific exception of allowing the camera to be connected to the Ethernet port, but nothing else.
|
Re: i2c output
If you need I2C then use the i/o lines of the sidecar and write the I2C software yourself. Thats valid within R67. There are a lot of examples around showing what to do, depending on the sensor you can take short cuts and not do all of I2C.
|
Re: i2c output
Quote:
I would love to hear the explanation from FIRST why you can't use I2C on the Sidecar. Quite frankly- unless someone can point to a specific rule against this I would ignore the forum post. Forum posts are not rules. The rules are in PDF form in the 2009 FRC Manual. Team updates make modifications to the rules. Forum posts only provide clarification for you to use during design or to provide to robot inspectors to certify your robot is in compliance to a rule. |
Re: i2c output
Quote:
As far as why - who knows. Leveling the field? Maybe the back end software isn't there yet? Keeping things simple for inspectors? Regardless, you should be able to mimic the I2C (or serial, for that matter) interface using digital I/O and some low-level code. It would be a lot of work, but it can be done. EDIT: You can also look out for specialized hardware to convert between I2C and an easier-to-implement protocol like RS-232. You can then connect your sensor to that custom circuit and write some simple serial port code for your digital inputs. I believe that this would still be legal. |
Re: i2c output
Quote:
Quote:
<R66> Inputs to custom circuits can be connected only to the following sources: A. Power Distribution Board protected 12Vdc outputs B. Speed controller outputs, C. Relay module outputs, D. Analog Breakout outputs, E. Digital Sidecar PWM, relay or digital outputs, F. Other custom circuits, or G. Switches, potentiometers, accelerometers, sensors, and other additional permitted electronics. <R67> All outputs from sensors, custom circuits and additional electronics shall connect to only the following: A. Other custom circuits, or B. Input/output ports on the Digital Sidecar, or C. Input/output ports on the Analog Breakout. If it's not on the list, it's off limits. That's why I said that the rules prohibit using the camera. I do see a contradiction though. I think the I2C is described under <R67> B. Input/output ports on the Digital Sidecar. So under that interpretation, outputs from sensors, custom circuits and additional electronics CAN be connected to the I2C. If you consider the I2C to be a digital output <R66> allows you to use it for output as well. Someone really should ask for clarification in the Q&A. It seems to be a contradiction. |
Re: i2c output
<R66> and <R67> would indicate that the digital sidecar's I2C hardware has always been off limits this season (at leas that's my interpretation).
|
Re: i2c output
Quote:
|
Re: i2c output
I'm expecting a rules update on this one on Friday.
The problem with the way the rules are written is that while the I2C pins are technically digital IO, they are both an input and output for the hardware connected to it (like an I2C sensor). Therefore, I2C is permissable under <R67B> but not under <R66E>. However, under <R66G> the digital side car is an "approved electronic device" which would seem to allow it. That's why we asked the question. As for a work around, it appears that I2C is interfaced through the FPGA, which makes sense since you need to asynchronously push data into registers to get it to work. On the old PIC18 based RC, tapping the right combination of pins on the relay outputs gave you access to I2C. So, I agree it seems kind of odd to not give us access to it this year. Bitbanging the GPIO ports for I2C could prove problematic. However, have a look at WPILib\ChipObject\tSPI.h, which implements SPI. That allows channel selection. So, building around that may yet provide a serial interface bus that is within the rules. But, it also makes any notion of using LEGO NXT sensors (that's what the phone jack looking thing on the DSC is) impossible. -Jeff Erickson, FRC 41 |
| All times are GMT -5. The time now is 14:01. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi