How can we use SDA or SCL lines for I2C Addresses? - embedded

TMP102 chip( http://www.ti.com/lit/ds/symlink/tmp102.pdf ) can have multiple I2c slave addresses. It has an address pin called ADD0(Section 5) which can be used to select multiple addresses(Section 7.3.4). The logic level at that pin can be used to select a particular TMP102 slave device. According to table 4, 4 addresses are possible. I do understand that connecting the pin to high or low voltage will produce two different addresses. But the table mentions that we can use SDA and SCL pins for two different addresses. I am not sure how this works. Can anyone explain how can this be used and how can we use multiple TMP102 devices based on SDA and SCL pins.

The logic level at that pin can be used to select a particular TMP102 slave device
That is not the purpose of ADD0 - it is a configuration pin, not a select pin. It is not used to select the device; I2C addresses are part of the data stream on SDA, there is no "select" pin as there is on SPI for example.
Rather, ADD0 is used to define the address of each device to one of four defined in Table 4. Those addresses being one of 0x48, 0x49, 0x4A or 0x4B depending on connection of ADD0 to GND, V+, SDA or SDL respectively. Like so:
How the device determines the address is not revealed in the datasheet and you don't really need to know, but given:
Public domain image by Marcin Floryan from https://en.wikipedia.org/wiki/I%C2%B2C
at the start condition at the falling edge of SDA the following occurs:
ADDR ADD0 SDA SCL
0x48 0 v 1
0x49 1 v 1
0x4A v v 1
0x4B 1 v 1
Then on the next falling edge SCL
ADDR ADD0 SDA SCL
0x48 0 0 v
0x49 1 0 v
0x4A 0 0 v
0x4B v 0 v
So it is possible with suitable sequential logic to latch the address by the end of the S phase and before B1 which is sufficient because the address match does not occur until B7, and all devices on the bus must listen for the address.

You connect ADD0 to SDA/SCL to get those other addresses. The table shows the address you get based on what ADD0 is connected to.

Related

SPIDRV API port pin definition

I Need to communicate my EFM32LG with a dac80004 USING SPI.
When i define USART in SPI mode i need to define the pins and ports as follwoing:
Port A pin 2: chip select sync_not (active low)
Port E pin 10: MOSI (SDIN)
Port E pin 11: MISO (serial interface digital out)
Port E pin 12: SCLK
Port A pin 1: clear DAC pin
From the API shown in the link bellow,I have only _USART_ROUTE_LOCATION_LOC0 .
How do i Put set my actual locations Using the API of SPIDRV?
Thanks.\
https://docs.silabs.com/mcu/latest/efm32lg/group-SPIDRV#gaec2cac185e42ded3da0d3e2d5cd56226
The values listed there are the defaults, they're not the only option.
If you look at the EFM32LG datasheet, page 352 there are other locations where you can set up the USART0 SPI pins.
Location 0 is fine for MOSI, MISO and CLK, but the CS would need to be PE13 if you want it driver controlled.
Alternatively, you could alter spidrvCsControlAuto to spidrvCsControlApplication and control the CS manually as a GPIO.

How to send a packet to all switches using ryu controller?

I need to measure link delay in Ryu controller. I want to send a packet-out message for all switches by the controller and calculate the time between the sent packet-out message and received the packet-in message. I am a beginner in Ryu and don't know how to send a packet with specific EtherType such as 0x8fc to all switches. I have obtained the MAC of all switches and build a packet. how I can send a packet with specific EtherType to all switches? I don't know what is the db parameter for every switch?
def send_packet(self, dp, port, pkt):
ofproto = dp.ofproto
parser = dp.ofproto_parser
pkt.serialize()
data = pkt.data
action = [parser.OFPActionOutput(port=port)]
out = parser.OFPPacketOut(
datapath=dp, buffer_id=ofproto.OFP_NO_BUFFER,
in_port=ofproto.OFPP_CONTROLLER,
actions=action, data=data)
dp.send_msg(out)
def create_packet(self):
i=l=0
for l in range(1,len(self.adjacency)+1):
#print("\n")
for i in self.adjacency[l]:
ethertype = 0x8fc
dst = self.macaddr(i)
src = self.macaddr(l)
e = ethernet.ethernet(dst, src, ethertype)
p = packet.Packet()
p.add_protocol(e)
p.add_protocol(time.time())
p.serialize()
port=self.adjacency[l][i]
send_packet(self, dp **??????** , port, p):
DP is the abbreviation for DataPathID that is kind of Uniq ID for an OpenFlow switch in your network.
According to the OpenFlow specification:
“The datapath_id field uniquely identifies a datapath. The lower 48
bits are intended for the switch MAC address, while the top 16 bits
are up to the implementer. An example use of the top 16 bits would be
a VLAN ID to distinguish multiple virtual switch instances on a single
physical switch.”
If you're using Mininet and for example, you run linear topology:
mn --controller remote --topo linear,3
Your topology will be:
s1 -- s2 -- s3
| | |
h1 h2 h3
DataPathID's will be:
s1: 0x0000000000000001
s2: 0x0000000000000002
s3: 0x0000000000000003
Pay attention that in other testbeds this numbers may be different but they're alway 16 digit hex.

how to connect LVDS signals coming from test equipment to fpga virtex 5 when the design has only input signal Din ?

I would provide din+ to A1 and din- to A2, on pin connector on PM2 module, connecting to FPGA, but I have only 1 input port "din" in top level vhdl design module connected to AG7 pin on FPGA. How to go about connection in UCF file ?
PM2 Pin - A1, A2
FPGA pin -AG7, AG6
FPGA bank VCCO - 2.5v, 2.5v
Pin Function - LVDS pair 100 ohm differential impedance; can also be used as single-ended
You have to manually instantiate the differential input buffer. For Xilinx it will be IBUFDS in the Unisim library. Either modify your port to have two pins for din and add the buffer in the existing design or write a simple wrapper that converts the diff. pairs to single-ended and pass that into the current port.

interfacing ht12d decoder to PIC microcontroller?

this is my first question here.
i have ht12d ic connected to pic16f84a.. VT pin connected to Rb0/int pin of pic.. and the 4 data lines are connected to 4 pins of PortB.. also am having a digital sensor also connected to rb0/int pin.. whenever there is interrupt either from the decoder ic or the sensor i ve managed to deal with these two sources of interrupts.. the problem is ht12d pins remains latched to last signal and don't return to default state.. in fact am using the status of these 4 pins to differentiate between the two interrupts.. for example :
proto:
if portb.b1 is 1 then its command 1;
if portb.b2 is 1 then its command2;
if portb.b3 is 1 then its command3;
if portb.b4 is 1 then its command4;
if they are all 0, then it's sensor interrupt ;
is there any way to reset ht12d data pins to default state after each valid transmission..

A20 OLinuXino-Micro 4GB from Olimex - understanding GPIOs

i am using a A20 OLinuXino Micro 4GB from Olimex with Debian on SD Card.
I want to use the GPIOs and have some short question about the configuration of the GPIOs. The GPIO-1 connector on the board has pins numbered from 1 to 39. In the manual I have entries like that:
Pin # | Signal name | Processor pin
23 | PG9 | C19
...
39 | LRADC1 | AB22
In the fex file, I find this:
[gpio_para]
gpio_used = 1
gpio_num = 64
...
gpio_pin_10 = port:PG09<0><default><default><default>
How is defined that the processor pin C19 is routed to port PG9?
And port means exactly what?
How is defined that the port PG9 is routed to pin23 of the connector?
Can the gpio_pin_10 designation be chosen arbitrarily?
At the end I would like to use the LRADC1, to sample a signal, but the fex file doesn't have any LRADC1 entry. Why is that?
Maybe somebody could answer may questions in 2 or 3 sentences so it makes sense to the rest of what I read. Thanks!
Please take a look at A20-OLinuXino-MICRO schematics. You can find wiring:
PG09 - C19
PG10 - D18
PG11 - C18
(...)
In mentioned schematics is also section GPIO EXTENSION in which you can find which A20 SoC pin is assigned to which GPIO:
PG09 - 23 GPIO-1
PG10 - 25 GPIO-1
According to Wikipedia:
A GPIO port is a group of GPIO pins (typically 8 GPIO pins) arranged in a group and controlled as a group.
Mapping between physical pin and pin exposed through fex file to operating system is arbitrary. Of course to get correct results you have to assign GPIO ping not. I don't think that fex compiler check anything other then syntax.
In case LRADC0 (again schematics) it us used for buttons (vol +/-, menu, search, ...) and LRADC1 is exposed through GPIO-1 pin 39.