Does anyone have a circuit for this, pref with AVR. I just need a simple
trap to catch the first Command byte- 0x Axxxx usually and then do nothing
until the next start command.

TT_Man wrote:

Does anyone have a circuit for this, pref with AVR. I just need a simple
trap to catch the first Command byte- 0x Axxxx usually and then do nothing
until the next start command.

It's not a circuit you want, it's code.

Graham

"Eeyore" wrote in message
...


TT_Man wrote:

Does anyone have a circuit for this, pref with AVR. I just need a simple
trap to catch the first Command byte- 0x Axxxx usually and then do
nothing
until the next start command.

It's not a circuit you want, it's code.

Graham


Yes, it is.... I have tried with a tiny2313 @8Mhz, but there is something
wrong with my logic as it generates multiple instances of the start
detection and I just can't figure it out.
I wanted to detect the start condition, then skip 6 clock pulses to get to
command bit 2, detect whether that bit is a 0 or a 1. Then skip and detect
the Ack ck pulse(9),then return to search for another start condition.
I'm assuming that there is adequate delay between data going low and clock
going low to detect the start bit...
I did try implementing a parallel test circuit using a 7474 to detect the
start and generate a pulse, but ended going round in circles. I suppose a
logic analyser/digital scope would help, but I have neither so fault finding
is limited to the tiny generating 'test pulses'.
Maybe I'm asking the impossible and it can ONLY be done reliably in
hardware...
I can't/don't want to go to the expense of an AVR that has inbuilt twi...

"TT_Man" schreef in bericht
...

"Eeyore" wrote in message
...


TT_Man wrote:

Does anyone have a circuit for this, pref with AVR. I just need a simple
trap to catch the first Command byte- 0x Axxxx usually and then do
nothing
until the next start command.

It's not a circuit you want, it's code.

Graham


Yes, it is.... I have tried with a tiny2313 @8Mhz, but there is something
wrong with my logic as it generates multiple instances of the start
detection and I just can't figure it out.
I wanted to detect the start condition, then skip 6 clock pulses to get to
command bit 2, detect whether that bit is a 0 or a 1. Then skip and detect
the Ack ck pulse(9),then return to search for another start condition.
I'm assuming that there is adequate delay between data going low and clock
going low to detect the start bit...
I did try implementing a parallel test circuit using a 7474 to detect the
start and generate a pulse, but ended going round in circles. I suppose a
logic analyser/digital scope would help, but I have neither so fault
finding is limited to the tiny generating 'test pulses'.
Maybe I'm asking the impossible and it can ONLY be done reliably in
hardware...
I can't/don't want to go to the expense of an AVR that has inbuilt twi...


First of all, get the I2C specifications. Make sure you fully understand at
least the start - and restart conditions.
http://www.nxp.com/acrobat_download/...8/39340011.pdf

Next have a look at the bus you want to observe. What's the busspeed? You'll
never be able to sniff a 3.4Mb/s bus using an 8MHz AVR... unless you find
one that has the required I2C hardware build in.

You can go for a hardware solution but you'll need some logic design skills
to build one. To give an idea:
- Buffer the clock and data (SCL and SDA) to prevent unnessecary load.
- Tie SCL to the data - and the *inverted* SDA to the clock of a 7474 to
detect a START condition.
- Keep this start signal until it is picked up by the logic, then reset.
- All other processing will be done with SCL as a clock until a STOP or
RESTART condition occurs.

No need to say that "other processing" includes counting pulses, detecting
command bit 2 and so on.

petrus bitbyter

On 21/05/2007 TT_Man wrote:

..
..
..
I can't/don't want to go to the expense of an AVR that has inbuilt
twi...

Why not? You can get a mega8 for less than a Starbucks coffee.

--
John B

"John B" wrote in message
t...
On 21/05/2007 TT_Man wrote:

.
.
.
I can't/don't want to go to the expense of an AVR that has inbuilt
twi...

Why not? You can get a mega8 for less than a Starbucks coffee.

--
John B
I tried all that, Petrus..... but there are multiple occurrences of the
start condition, which may or may not be right.......
I'll look at the Mega8, didn't know that had twi...
thx for all the input.... It could be that the programmer I am looking at is
issuing multiple starts, writing a few bytes at a time ( 12c512)

"TT_Man" schreef in bericht
...

"John B" wrote in message
t...
On 21/05/2007 TT_Man wrote:

.
.
.
I can't/don't want to go to the expense of an AVR that has inbuilt
twi...

Why not? You can get a mega8 for less than a Starbucks coffee.

--
John B
I tried all that, Petrus..... but there are multiple occurrences of the
start condition, which may or may not be right.......
I'll look at the Mega8, didn't know that had twi...
thx for all the input.... It could be that the programmer I am looking at
is issuing multiple starts, writing a few bytes at a time ( 12c512)


Don't know the 12C512 except for a misnomer of a 27c512. If I understand you
well, you're looking at the I2C interface inside a programmer. You can bet
there will be a lot a communication on that bus, so multiple START
conditions are normal. A sniffer should not only look for START conditions.
It starts, waits for an event (maybe a START condition), stores that event
and the following data in memory to make it available for futher
investigation. As far as your interest goes, you'd wait for the START
condition, filter the bits you want to see, display them by LEDS and then
hold the sniffer until you (manualy) restart it.

A quick look at the ATmega8 datasheet learns that you can make a pretty good
sniffer with it. Even pieces of code are given. You can store up to a 1000
bytes of data. Of course you will need a display or an RS232 interface to
make that data visible.

Whatever you choose, there's no quick solution. You will have to do some
serious work, which will take its time.

petrus bitbyter

SNIP

Don't know the 12C512 except for a misnomer of a 27c512. If I understand
you well, you're looking at the I2C interface inside a programmer. You can
bet there will be a lot a communication on that bus, so multiple START
conditions are normal. A sniffer should not only look for START
conditions. It starts, waits for an event (maybe a START condition),
stores that event and the following data in memory to make it available
for futher investigation. As far as your interest goes, you'd wait for the
START condition, filter the bits you want to see, display them by LEDS and
then hold the sniffer until you (manualy) restart it.

A quick look at the ATmega8 datasheet learns that you can make a pretty
good sniffer with it. Even pieces of code are given. You can store up to a
1000 bytes of data. Of course you will need a display or an RS232
interface to make that data visible.

Whatever you choose, there's no quick solution. You will have to do some
serious work, which will take its time.

petrus bitbyter

sorry, a typo.... I meant 24C512.
I've had a look at mega 8 and a deeper look at tiny 2313. Surprisingly, the
tiny has a USI that sets an interrupt flag on a start condition .....
Basically, what I am trying to do is this....... support for 24C1024 devices
is next to nil..... but it has a simple algorithm to program it's upper 512.
It looks to see if bit2 in the SLA is set... If it is, it takes this as the
17th bit of the devices address.
So, I can sniff the start condition, count ck's until the 6th one and then
jam the SDA (during clock 7) high to force ( kid) the 24C1024 that it
should write its data to the high block...
I'm getting there now....

"TT_Man" schreef in bericht
...
SNIP

Don't know the 12C512 except for a misnomer of a 27c512. If I understand
you well, you're looking at the I2C interface inside a programmer. You
can bet there will be a lot a communication on that bus, so multiple
START conditions are normal. A sniffer should not only look for START
conditions. It starts, waits for an event (maybe a START condition),
stores that event and the following data in memory to make it available
for futher investigation. As far as your interest goes, you'd wait for
the START condition, filter the bits you want to see, display them by
LEDS and then hold the sniffer until you (manualy) restart it.

A quick look at the ATmega8 datasheet learns that you can make a pretty
good sniffer with it. Even pieces of code are given. You can store up to
a 1000 bytes of data. Of course you will need a display or an RS232
interface to make that data visible.

Whatever you choose, there's no quick solution. You will have to do some
serious work, which will take its time.

petrus bitbyter

sorry, a typo.... I meant 24C512.
I've had a look at mega 8 and a deeper look at tiny 2313. Surprisingly,
the tiny has a USI that sets an interrupt flag on a start condition .....
Basically, what I am trying to do is this....... support for 24C1024
devices is next to nil..... but it has a simple algorithm to program it's
upper 512. It looks to see if bit2 in the SLA is set... If it is, it takes
this as the 17th bit of the devices address.
So, I can sniff the start condition, count ck's until the 6th one and
then jam the SDA (during clock 7) high to force ( kid) the 24C1024 that
it should write its data to the high block...
I'm getting there now....


So what you really want is programming a 24C1024. I need to say that the way
you try to achive this may be original but not effective. Besides, pulling a
line high while a transceiver pulls it low will not work. The bus is meant
to have an overiding low which can easily be concluded from the specs. The
protocol is based on it. Worst case you destroy a transceiver.

As the 24C1024 has a I2C interface, it can be easily programmed from a
parallel printerport of an (old) PC by bitbanging. Use a PC that runs DOS or
WIN9x so you can write directly to the port. Even old GWBASIC can be used to
write the program. It's a lot of work but less then what you're trying to do
now.

petrus bitbyter

SNIP

So what you really want is programming a 24C1024. I need to say that the
way you try to achive this may be original but not effective. Besides,
pulling a line high while a transceiver pulls it low will not work. The
bus is meant to have an overiding low which can easily be concluded from
the specs. The protocol is based on it. Worst case you destroy a
transceiver.

As the 24C1024 has a I2C interface, it can be easily programmed from a
parallel printerport of an (old) PC by bitbanging. Use a PC that runs DOS
or WIN9x so you can write directly to the port. Even old GWBASIC can be
used to write the program. It's a lot of work but less then what you're
trying to do now.

petrus bitbyter

I had in mind a 220R series resistor in line with SDA from the programmer
and pulling up the 24C1024 side with the Tiny.
Anyway, original as you say, but today I found a solution... There is some
software called PonyProg that I use for something else. Whilst browsing the
..INI file, there was a variable called I2CBaseAddress, set to a default
value of 0XA0. I changed this to 0xA2 in the hope that it would set the bit
I wanted. After restarting PonyProg, sure enough, with the 24C512 device
selected, the upper block was read.
Happy ending and much effort saved.If anyone is interested in PonyProg, the
address is Lancos.com
Thanks for all the help from everyone.