Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   i2c output (http://www.chiefdelphi.com/forums/showthread.php?t=72085)

virtuald 14-01-2009 13:04

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?

wireties 14-01-2009 15:38

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

virtuald 14-01-2009 15:48

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. :)

wireties 15-01-2009 00:36

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

gvarndell 15-01-2009 07:23

Re: i2c output
 
Quote:

Originally Posted by virtuald (Post 800915)
Right, I knew that part. But it seems to me that the Write() function is referring to a different address.

I2C devices have a bus address -- the address to which the device itself responds for reads or writes.
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.

jee7s 15-01-2009 10:52

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

keen101 15-01-2009 11:56

Re: i2c output
 
Quote:

Originally Posted by jee7s (Post 801403)
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

What?! That is crap.

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!

martin417 15-01-2009 12:30

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.

timmmoore 15-01-2009 12:42

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.

MikeDubreuil 15-01-2009 13:09

Re: i2c output
 
Quote:

Originally Posted by jee7s (Post 801403)

That is absolutely insane! I can understand not using CAN. I was disappointed and mystified to hear teams couldn't use the cRIO's serial port. Now we can't use the I2C port on the Sidecar??? :confused:

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.

Jared Russell 15-01-2009 13:32

Re: i2c output
 
Quote:

Originally Posted by timmmoore (Post 801489)
Unfortuntely its in the offical Q/A http://forums.usfirst.org/showthread.php?t=11227

The Q&A still is not supposed to be the medium over which rules changes are made. If any rules changes have been made (I haven't read the relevant manual sections, so I'm not sure whether they were or if only clarifications were offered), they might appear in a team update.

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.

martin417 15-01-2009 13:38

Re: i2c output
 
Quote:

Originally Posted by MikeDubreuil (Post 801478)
I would love to hear the explanation from FIRST why you can't use I2C on the Sidecar.

My guess is that they want you to use the capability of the cRIO only, no extra processing. That makes you maximize the power of the cRIO (could be driven by NI)


Quote:

Originally Posted by MikeDubreuil (Post 801478)
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.

Specific rule(s)

<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.

Jared Russell 15-01-2009 13:39

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).

martin417 15-01-2009 13:45

Re: i2c output
 
Quote:

Originally Posted by Abwehr (Post 801508)
<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).

I don't think it's that clear-cut. It would be hard for the GDC to argue that I2C and/or SPI are not digital input/output ports on the sidecar.

jee7s 15-01-2009 13:59

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