Has anyone else noticed that for the R6000, the I2C driver shifts the
device address left by one bit before using it? What's up with that?
Looking at the I2C sample program for the R6000, I2C_24LC16.C, it
defines the address of the device as 0xA2. The 'A' is the device
code,
and it's correct for the 24LC16. The '2' is the second device,
which
the sample doesn't mention. But if you left-shift that address, you get
an address of 0x44, which will never work. For the sample program to
work on the R6000, the address needs to be defined as 0x51.
Am I missing something, or is this as screwy as it seems?
Steve
I2C on R6000
Started by ●April 3, 2012
Reply by ●April 4, 20122012-04-04
Hi Steve,
I havent looked at the lib and the hardware manual in detail but the thing to remember is that the address is spassed in as an unsigned int not a char so the left shift produces a value of 0x0144. Th lib seems to shift left by 1 and puut the read/writ state into the lsb. This is probably related to how the hardware I2C registers need the data.
Regards,
Peter
--- In r..., "seecwriter" wrote:
>
> Has anyone else noticed that for the R6000, the I2C driver shifts the
> device address left by one bit before using it? What's up with that?
>
> Looking at the I2C sample program for the R6000, I2C_24LC16.C, it
> defines the address of the device as 0xA2. The 'A' is the device code,
> and it's correct for the 24LC16. The '2' is the second device, which
> the sample doesn't mention. But if you left-shift that address, you get
> an address of 0x44, which will never work. For the sample program to
> work on the R6000, the address needs to be defined as 0x51.
>
> Am I missing something, or is this as screwy as it seems?
>
> Steve
>
I havent looked at the lib and the hardware manual in detail but the thing to remember is that the address is spassed in as an unsigned int not a char so the left shift produces a value of 0x0144. Th lib seems to shift left by 1 and puut the read/writ state into the lsb. This is probably related to how the hardware I2C registers need the data.
Regards,
Peter
--- In r..., "seecwriter" wrote:
>
> Has anyone else noticed that for the R6000, the I2C driver shifts the
> device address left by one bit before using it? What's up with that?
>
> Looking at the I2C sample program for the R6000, I2C_24LC16.C, it
> defines the address of the device as 0xA2. The 'A' is the device code,
> and it's correct for the 24LC16. The '2' is the second device, which
> the sample doesn't mention. But if you left-shift that address, you get
> an address of 0x44, which will never work. For the sample program to
> work on the R6000, the address needs to be defined as 0x51.
>
> Am I missing something, or is this as screwy as it seems?
>
> Steve
>
Reply by ●April 4, 20122012-04-04
Hi Steve,
The left shift is required because the lower bit of the address byte is the
READ or WRITE bit.
Well spotted on the address value being wrong in the sample. 0x50 would be
correct for the first device if the address lines are all LOW.
A lot of people get tripped up by the addressing of I2C. You have to read
the documents carefully and if you decode the address byte yourself from the
timing diagram, you have to shift right the value to get the address for the
I2C function calls (that is if you include the READ/WRITE bit in your binary
input)
Dave.
From: r... [mailto:r...] On
Behalf Of seecwriter
Sent: 04 April 2012 05:44
To: r...
Subject: [rabbit-semi] I2C on R6000
Has anyone else noticed that for the R6000, the I2C driver shifts the
device address left by one bit before using it? What's up with that?
Looking at the I2C sample program for the R6000, I2C_24LC16.C, it
defines the address of the device as 0xA2. The 'A' is the device code,
and it's correct for the 24LC16. The '2' is the second device, which
the sample doesn't mention. But if you left-shift that address, you get
an address of 0x44, which will never work. For the sample program to
work on the R6000, the address needs to be defined as 0x51.
Am I missing something, or is this as screwy as it seems?
Steve
The left shift is required because the lower bit of the address byte is the
READ or WRITE bit.
Well spotted on the address value being wrong in the sample. 0x50 would be
correct for the first device if the address lines are all LOW.
A lot of people get tripped up by the addressing of I2C. You have to read
the documents carefully and if you decode the address byte yourself from the
timing diagram, you have to shift right the value to get the address for the
I2C function calls (that is if you include the READ/WRITE bit in your binary
input)
Dave.
From: r... [mailto:r...] On
Behalf Of seecwriter
Sent: 04 April 2012 05:44
To: r...
Subject: [rabbit-semi] I2C on R6000
Has anyone else noticed that for the R6000, the I2C driver shifts the
device address left by one bit before using it? What's up with that?
Looking at the I2C sample program for the R6000, I2C_24LC16.C, it
defines the address of the device as 0xA2. The 'A' is the device code,
and it's correct for the 24LC16. The '2' is the second device, which
the sample doesn't mention. But if you left-shift that address, you get
an address of 0x44, which will never work. For the sample program to
work on the R6000, the address needs to be defined as 0x51.
Am I missing something, or is this as screwy as it seems?
Steve
Reply by ●April 4, 20122012-04-04
The lib tests the address for a value greater than 128 to see if it should
create a 10-bit address. If it's less than 128, which it always is in my
case, it only uses the lower bits. So the '1' in the int is thrown away.
What I don't understand is why they changed the way the driver works. I
realize that the R6000 uses a hardware peripheral for I2C, but I see no
reason change the way the slave address is passed to the driver. Plus it
forces me to go through my code and re-define all my slave addresses that
have been working for years.
Steve
>________________________________
> From: petermcs
>To: r...
>Sent: Wednesday, April 4, 2012 12:05 AM
>Subject: [rabbit-semi] Re: I2C on R6000
>
>
>Hi Steve,
>
>I havent looked at the lib and the hardware manual in detail but the thing to remember is that the address is spassed in as an unsigned int not a char so the left shift produces a value of 0x0144. Th lib seems to shift left by 1 and puut the read/writ state into the lsb. This is probably related to how the hardware I2C registers need the data.
>
>Regards,
>Peter
>--- In r..., "seecwriter" wrote:
>>
>> Has anyone else noticed that for the R6000, the I2C driver shifts the
>> device address left by one bit before using it? What's up with that?
>>
>> Looking at the I2C sample program for the R6000, I2C_24LC16.C, it
>> defines the address of the device as 0xA2. The 'A' is the device code,
>> and it's correct for the 24LC16. The '2' is the second device, which
>> the sample doesn't mention. But if you left-shift that address, you get
>> an address of 0x44, which will never work. For the sample program to
>> work on the R6000, the address needs to be defined as 0x51.
>>
>> Am I missing something, or is this as screwy as it seems?
>>
>> Steve
>
create a 10-bit address. If it's less than 128, which it always is in my
case, it only uses the lower bits. So the '1' in the int is thrown away.
What I don't understand is why they changed the way the driver works. I
realize that the R6000 uses a hardware peripheral for I2C, but I see no
reason change the way the slave address is passed to the driver. Plus it
forces me to go through my code and re-define all my slave addresses that
have been working for years.
Steve
>________________________________
> From: petermcs
>To: r...
>Sent: Wednesday, April 4, 2012 12:05 AM
>Subject: [rabbit-semi] Re: I2C on R6000
>
>
>Hi Steve,
>
>I havent looked at the lib and the hardware manual in detail but the thing to remember is that the address is spassed in as an unsigned int not a char so the left shift produces a value of 0x0144. Th lib seems to shift left by 1 and puut the read/writ state into the lsb. This is probably related to how the hardware I2C registers need the data.
>
>Regards,
>Peter
>--- In r..., "seecwriter" wrote:
>>
>> Has anyone else noticed that for the R6000, the I2C driver shifts the
>> device address left by one bit before using it? What's up with that?
>>
>> Looking at the I2C sample program for the R6000, I2C_24LC16.C, it
>> defines the address of the device as 0xA2. The 'A' is the device code,
>> and it's correct for the 24LC16. The '2' is the second device, which
>> the sample doesn't mention. But if you left-shift that address, you get
>> an address of 0x44, which will never work. For the sample program to
>> work on the R6000, the address needs to be defined as 0x51.
>>
>> Am I missing something, or is this as screwy as it seems?
>>
>> Steve
>
Reply by ●April 4, 20122012-04-04
Hi Steve,
I see the problem now...
If you are only using 7 bit addresses, I'd be more inclined to modify the R6000 lib to remove the left shift and tweak the check for > 127. I think the problem has occurred due to the addition of 10 bit addressing modes which you don't use.
Regards,
Peter
--- In r..., Steve Trigero wrote:
>
> The lib tests the address for a value greater than 128 to see if it should
> create a 10-bit address. If it's less than 128, which it always is in my
> case, it only uses the lower bits. So the '1' in the int is thrown away.
>
> What I don't understand is why they changed the way the driver works. I
>
> realize that the R6000 uses a hardware peripheral for I2C, but I see no
> reason change the way the slave address is passed to the driver. Plus it
> forces me to go through my code and re-define all my slave addresses that
> have been working for years.
>
>
> Steve
>
>
>
>
> >________________________________
> > From: petermcs
> >To: r...
> >Sent: Wednesday, April 4, 2012 12:05 AM
> >Subject: [rabbit-semi] Re: I2C on R6000
> >
> >
> >
> >
> >Hi Steve,
> >
> >I havent looked at the lib and the hardware manual in detail but the thing to remember is that the address is spassed in as an unsigned int not a char so the left shift produces a value of 0x0144. Th lib seems to shift left by 1 and puut the read/writ state into the lsb. This is probably related to how the hardware I2C registers need the data.
> >
> >Regards,
> >Peter
> >--- In r..., "seecwriter" wrote:
> >>
> >> Has anyone else noticed that for the R6000, the I2C driver shifts the
> >> device address left by one bit before using it? What's up with that?
> >>
> >> Looking at the I2C sample program for the R6000, I2C_24LC16.C, it
> >> defines the address of the device as 0xA2. The 'A' is the device code,
> >> and it's correct for the 24LC16. The '2' is the second device, which
> >> the sample doesn't mention. But if you left-shift that address, you get
> >> an address of 0x44, which will never work. For the sample program to
> >> work on the R6000, the address needs to be defined as 0x51.
> >>
> >> Am I missing something, or is this as screwy as it seems?
> >>
> >> Steve
> >>
> >
> >
> >
> >
>
I see the problem now...
If you are only using 7 bit addresses, I'd be more inclined to modify the R6000 lib to remove the left shift and tweak the check for > 127. I think the problem has occurred due to the addition of 10 bit addressing modes which you don't use.
Regards,
Peter
--- In r..., Steve Trigero wrote:
>
> The lib tests the address for a value greater than 128 to see if it should
> create a 10-bit address. If it's less than 128, which it always is in my
> case, it only uses the lower bits. So the '1' in the int is thrown away.
>
> What I don't understand is why they changed the way the driver works. I
>
> realize that the R6000 uses a hardware peripheral for I2C, but I see no
> reason change the way the slave address is passed to the driver. Plus it
> forces me to go through my code and re-define all my slave addresses that
> have been working for years.
>
>
> Steve
>
>
>
>
> >________________________________
> > From: petermcs
> >To: r...
> >Sent: Wednesday, April 4, 2012 12:05 AM
> >Subject: [rabbit-semi] Re: I2C on R6000
> >
> >
> >
> >
> >Hi Steve,
> >
> >I havent looked at the lib and the hardware manual in detail but the thing to remember is that the address is spassed in as an unsigned int not a char so the left shift produces a value of 0x0144. Th lib seems to shift left by 1 and puut the read/writ state into the lsb. This is probably related to how the hardware I2C registers need the data.
> >
> >Regards,
> >Peter
> >--- In r..., "seecwriter" wrote:
> >>
> >> Has anyone else noticed that for the R6000, the I2C driver shifts the
> >> device address left by one bit before using it? What's up with that?
> >>
> >> Looking at the I2C sample program for the R6000, I2C_24LC16.C, it
> >> defines the address of the device as 0xA2. The 'A' is the device code,
> >> and it's correct for the 24LC16. The '2' is the second device, which
> >> the sample doesn't mention. But if you left-shift that address, you get
> >> an address of 0x44, which will never work. For the sample program to
> >> work on the R6000, the address needs to be defined as 0x51.
> >>
> >> Am I missing something, or is this as screwy as it seems?
> >>
> >> Steve
> >>
> >
> >
> >
> >
>
Reply by ●April 4, 20122012-04-04
looking at the data sheet, for a 24c16 the low 3 bits are not a device address,
they are a page number so the 2 below is not for the second device but the
second 2K page in the device.
Regards,
Peter
--- In r..., "petermcs" wrote:
>
> Hi Steve,
>
> I see the problem now...
>
> If you are only using 7 bit addresses, I'd be more inclined to modify the R6000 lib to remove the left shift and tweak the check for > 127. I think the problem has occurred due to the addition of 10 bit addressing modes which you don't use.
>
> Regards,
> Peter
> --- In r..., Steve Trigero wrote:
> >
> > The lib tests the address for a value greater than 128 to see if it should
> > create a 10-bit address. If it's less than 128, which it always is in my
> > case, it only uses the lower bits. So the '1' in the int is thrown away.
> >
> > What I don't understand is why they changed the way the driver works. I
> >
> > realize that the R6000 uses a hardware peripheral for I2C, but I see no
> > reason change the way the slave address is passed to the driver. Plus it
> > forces me to go through my code and re-define all my slave addresses that
> > have been working for years.
> >
> >
> > Steve
> >
> >
> >
> >
> > >________________________________
> > > From: petermcs
> > >To: r...
> > >Sent: Wednesday, April 4, 2012 12:05 AM
> > >Subject: [rabbit-semi] Re: I2C on R6000
> > >
> > >
> > >
> > >
> > >Hi Steve,
> > >
> > >I havent looked at the lib and the hardware manual in detail but the thing to remember is that the address is spassed in as an unsigned int not a char so the left shift produces a value of 0x0144. Th lib seems to shift left by 1 and puut the read/writ state into the lsb. This is probably related to how the hardware I2C registers need the data.
> > >
> > >Regards,
> > >Peter
> > >--- In r..., "seecwriter" wrote:
> > >>
> > >> Has anyone else noticed that for the R6000, the I2C driver shifts the
> > >> device address left by one bit before using it? What's up with that?
> > >>
> > >> Looking at the I2C sample program for the R6000, I2C_24LC16.C, it
> > >> defines the address of the device as 0xA2. The 'A' is the device code,
> > >> and it's correct for the 24LC16. The '2' is the second device, which
> > >> the sample doesn't mention. But if you left-shift that address, you get
> > >> an address of 0x44, which will never work. For the sample program to
> > >> work on the R6000, the address needs to be defined as 0x51.
> > >>
> > >> Am I missing something, or is this as screwy as it seems?
> > >>
> > >> Steve
> > >>
> > >
> > >
> > >
> > >
> > >
>
Regards,
Peter
--- In r..., "petermcs" wrote:
>
> Hi Steve,
>
> I see the problem now...
>
> If you are only using 7 bit addresses, I'd be more inclined to modify the R6000 lib to remove the left shift and tweak the check for > 127. I think the problem has occurred due to the addition of 10 bit addressing modes which you don't use.
>
> Regards,
> Peter
> --- In r..., Steve Trigero wrote:
> >
> > The lib tests the address for a value greater than 128 to see if it should
> > create a 10-bit address. If it's less than 128, which it always is in my
> > case, it only uses the lower bits. So the '1' in the int is thrown away.
> >
> > What I don't understand is why they changed the way the driver works. I
> >
> > realize that the R6000 uses a hardware peripheral for I2C, but I see no
> > reason change the way the slave address is passed to the driver. Plus it
> > forces me to go through my code and re-define all my slave addresses that
> > have been working for years.
> >
> >
> > Steve
> >
> >
> >
> >
> > >________________________________
> > > From: petermcs
> > >To: r...
> > >Sent: Wednesday, April 4, 2012 12:05 AM
> > >Subject: [rabbit-semi] Re: I2C on R6000
> > >
> > >
> > >
> > >
> > >Hi Steve,
> > >
> > >I havent looked at the lib and the hardware manual in detail but the thing to remember is that the address is spassed in as an unsigned int not a char so the left shift produces a value of 0x0144. Th lib seems to shift left by 1 and puut the read/writ state into the lsb. This is probably related to how the hardware I2C registers need the data.
> > >
> > >Regards,
> > >Peter
> > >--- In r..., "seecwriter" wrote:
> > >>
> > >> Has anyone else noticed that for the R6000, the I2C driver shifts the
> > >> device address left by one bit before using it? What's up with that?
> > >>
> > >> Looking at the I2C sample program for the R6000, I2C_24LC16.C, it
> > >> defines the address of the device as 0xA2. The 'A' is the device code,
> > >> and it's correct for the 24LC16. The '2' is the second device, which
> > >> the sample doesn't mention. But if you left-shift that address, you get
> > >> an address of 0x44, which will never work. For the sample program to
> > >> work on the R6000, the address needs to be defined as 0x51.
> > >>
> > >> Am I missing something, or is this as screwy as it seems?
> > >>
> > >> Steve
> > >>
> > >
> > >
> > >
> > >
> > >
>
Reply by ●April 4, 20122012-04-04
I just re-read the datasheet and you are correct. A few pages in it shows
that A0 to A2 are no connects and that the system can only support one
24LC16 in a system.
Pays to read the datasheet in more detail!! :o)
Dave.
From: r... [mailto:r...] On
Behalf Of petermcs
Sent: 04 April 2012 22:27
To: r...
Subject: [rabbit-semi] Re: I2C on R6000
looking at the data sheet, for a 24c16 the low 3 bits are not a device
address, they are a page number so the 2 below is not for the second device
but the second 2K page in the device.
Regards,
Peter
that A0 to A2 are no connects and that the system can only support one
24LC16 in a system.
Pays to read the datasheet in more detail!! :o)
Dave.
From: r... [mailto:r...] On
Behalf Of petermcs
Sent: 04 April 2012 22:27
To: r...
Subject: [rabbit-semi] Re: I2C on R6000
looking at the data sheet, for a 24c16 the low 3 bits are not a device
address, they are a page number so the 2 below is not for the second device
but the second 2K page in the device.
Regards,
Peter
Reply by ●April 4, 20122012-04-04
Yes it does. But I'm not using a 24LC16. It's just what the sample
program used.
But slave address is still incorrect for the R6000, which is what this sample
is for.
>________________________________
> From: Dave McLaughlin
>To: r...
>Sent: Wednesday, April 4, 2012 9:11 AM
>Subject: RE: [rabbit-semi] Re: I2C on R6000
>
>
>
>I just re-read the datasheet and you are correct. A few pages in it shows that A0 to A2 are no connects and that the system can only support one 24LC16 in a system.
>
>Pays to read the datasheet in more detail!! :o)
>
>Dave…
>
>From:r... [mailto:r...] On Behalf Of petermcs
>Sent: 04 April 2012 22:27
>To: r...
>Subject: [rabbit-semi] Re: I2C on R6000
>
>
>looking at the data sheet, for a 24c16 the low 3 bits are not a device address, they are a page number so the 2 below is not for the second device but the second 2K page in the device.
>
>Regards,
>Peter
>
>
>
>
>
But slave address is still incorrect for the R6000, which is what this sample
is for.
>________________________________
> From: Dave McLaughlin
>To: r...
>Sent: Wednesday, April 4, 2012 9:11 AM
>Subject: RE: [rabbit-semi] Re: I2C on R6000
>
>
>
>I just re-read the datasheet and you are correct. A few pages in it shows that A0 to A2 are no connects and that the system can only support one 24LC16 in a system.
>
>Pays to read the datasheet in more detail!! :o)
>
>Dave…
>
>From:r... [mailto:r...] On Behalf Of petermcs
>Sent: 04 April 2012 22:27
>To: r...
>Subject: [rabbit-semi] Re: I2C on R6000
>
>
>looking at the data sheet, for a 24c16 the low 3 bits are not a device address, they are a page number so the 2 below is not for the second device but the second 2K page in the device.
>
>Regards,
>Peter
>
>
>
>
>
Reply by ●April 4, 20122012-04-04
Hi Steve,
Please contact Digi's Rabbit Technical Support team to obtain a ZIP archive containing patched versions of the i2c_hw.lib and i2c_devices.lib libraries. Please note that these patched libraries are not final, but are expected to support I2C slave devices with Rabbit as I2C master.
Application code compatibility between Dynamic C's I2C SW and HW drivers is maintained, as the passed-in slave address is no longer left-shifted in the HW driver. In particular, the 24LC16B is known to work in both interrupt-driven and polled I/O modes.
- Bruce
--- In r..., "seecwriter" wrote:
>
> Has anyone else noticed that for the R6000, the I2C driver shifts the
> device address left by one bit before using it? What's up with that?
>
> Looking at the I2C sample program for the R6000, I2C_24LC16.C, it
> defines the address of the device as 0xA2. The 'A' is the device code,
> and it's correct for the 24LC16. The '2' is the second device, which
> the sample doesn't mention. But if you left-shift that address, you get
> an address of 0x44, which will never work. For the sample program to
> work on the R6000, the address needs to be defined as 0x51.
>
> Am I missing something, or is this as screwy as it seems?
>
> Steve
>
Please contact Digi's Rabbit Technical Support team to obtain a ZIP archive containing patched versions of the i2c_hw.lib and i2c_devices.lib libraries. Please note that these patched libraries are not final, but are expected to support I2C slave devices with Rabbit as I2C master.
Application code compatibility between Dynamic C's I2C SW and HW drivers is maintained, as the passed-in slave address is no longer left-shifted in the HW driver. In particular, the 24LC16B is known to work in both interrupt-driven and polled I/O modes.
- Bruce
--- In r..., "seecwriter" wrote:
>
> Has anyone else noticed that for the R6000, the I2C driver shifts the
> device address left by one bit before using it? What's up with that?
>
> Looking at the I2C sample program for the R6000, I2C_24LC16.C, it
> defines the address of the device as 0xA2. The 'A' is the device code,
> and it's correct for the 24LC16. The '2' is the second device, which
> the sample doesn't mention. But if you left-shift that address, you get
> an address of 0x44, which will never work. For the sample program to
> work on the R6000, the address needs to be defined as 0x51.
>
> Am I missing something, or is this as screwy as it seems?
>
> Steve
>
Reply by ●April 5, 20122012-04-05
The only SPI patch available is v1.09, dated 9/20/2011, which is what I have
been using.
>________________________________
> From: sser2k
>To: r...
>Sent: Wednesday, April 4, 2012 12:38 PM
>Subject: [rabbit-semi] Re: I2C on R6000
>
>
>
>Hi Steve,
>
>Please contact Digi's Rabbit Technical Support team to obtain a ZIP archive containing patched versions of the i2c_hw.lib and i2c_devices.lib libraries. Please note that these patched libraries are not final, but are expected to support I2C slave devices with Rabbit as I2C master.
>
>Application code compatibility between Dynamic C's I2C SW and HW drivers is maintained, as the passed-in slave address is no longer left-shifted in the HW driver. In particular, the 24LC16B is known to work in both interrupt-driven and polled I/O modes.
>
>- Bruce
>
>--- In r..., "seecwriter" wrote:
>>
>> Has anyone else noticed that for the R6000, the I2C driver shifts the
>> device address left by one bit before using it? What's up with that?
>>
>> Looking at the I2C sample program for the R6000, I2C_24LC16.C, it
>> defines the address of the device as 0xA2. The 'A' is the device code,
>> and it's correct for the 24LC16. The '2' is the second device, which
>> the sample doesn't mention. But if you left-shift that address, you get
>> an address of 0x44, which will never work. For the sample program to
>> work on the R6000, the address needs to be defined as 0x51.
>>
>> Am I missing something, or is this as screwy as it seems?
>>
>> Steve
>>
>
>
>
>________________________________
> From: sser2k
>To: r...
>Sent: Wednesday, April 4, 2012 12:38 PM
>Subject: [rabbit-semi] Re: I2C on R6000
>
>
>
>Hi Steve,
>
>Please contact Digi's Rabbit Technical Support team to obtain a ZIP archive containing patched versions of the i2c_hw.lib and i2c_devices.lib libraries. Please note that these patched libraries are not final, but are expected to support I2C slave devices with Rabbit as I2C master.
>
>Application code compatibility between Dynamic C's I2C SW and HW drivers is maintained, as the passed-in slave address is no longer left-shifted in the HW driver. In particular, the 24LC16B is known to work in both interrupt-driven and polled I/O modes.
>
>- Bruce
>
>--- In r..., "seecwriter" wrote:
>>
>> Has anyone else noticed that for the R6000, the I2C driver shifts the
>> device address left by one bit before using it? What's up with that?
>>
>> Looking at the I2C sample program for the R6000, I2C_24LC16.C, it
>> defines the address of the device as 0xA2. The 'A' is the device code,
>> and it's correct for the 24LC16. The '2' is the second device, which
>> the sample doesn't mention. But if you left-shift that address, you get
>> an address of 0x44, which will never work. For the sample program to
>> work on the R6000, the address needs to be defined as 0x51.
>>
>> Am I missing something, or is this as screwy as it seems?
>>
>> Steve
>>
>
>
>
