PCB - how to separate ISP and I2C ???

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

I usualy program the attiny, unplugging SCL/SDA lines, then pluging them back in

 

is there a more efficient way to do this ? like with diodes or something

 

should I put diodes on the SCL/SDA lines or the ISP CLK/MOSI lines ? or both ???

 

any advice are most welcome

 

thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


AVR042 H/W considerations, shows when ISP pins are shared with other devices, an small resistor is inserted inline after the ISP connections to isolate the pins.

This may not work for I2C pins.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SCL, SDA shares pins with ISP.

 

ISP programming will not normally interfere with a USI Master.   But if your target is a USI Slave it is possible that the foreign Master is holding the SDA and SCL lines.

 

So yes,   you can disconnect SDA, SCL during ISP programming.   Or program via debugWIRE.

 

It is just a consequence of choosing a chip with limited resources.

 

David.

 

p.s.  external series resistors are not suitable for I2C.

They are not necessary for SPI  providing you have all external SPI devices deselected by external pullups (or pulldowns for theusch)

Last Edited: Tue. Jan 12, 2021 - 06:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I remember discussing 'isolating the ISP pins' here ages ago ! ;)
Using a 4066 type switch chip was mentioned amongst other possible solutions ...

https://www.avrfreaks.net/forum/...

Try searching for '4066' ... ;)

But yes ... A small chip + a 4066 ... might just as well choose a bigger AVR to start with ! 

Last Edited: Tue. Jan 12, 2021 - 06:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use 4066 (or similar to isolate the pins already)

 

but since I am making my first pcb with attiny and t's supposed to be "in vivo"...

 

I thought I could get away with this with diodes from the ISP header

Last Edited: Tue. Jan 12, 2021 - 06:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please explain what you are doing.

 

I guess that your unspecified Tiny application implements an I2C Slave with USI peripheral.

During development the I2C Master is always live and liable to address either your Tiny or another Slave on the I2C bus.

 

Yes,  it is a pain to unplug SDA, SCL during development.

But you are never going to ISP the finished Slave when it is running in a remote field.

 

So a buffer chip is overkill.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not use SPI instead of I2C?  Then you can easily isolate your external devices from the AVR.  Or, do your external devices have an en or reset pin so perhaps they can be told to ignore pulses on the I2C?  

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

- the attiny's are used as slave

 

- I use a raspberry pi as the master and it's hat is monopolizing the ISP bus as usual, otherwise I'd surely do ISP, not I2C

 

so I don't mind plugging/unpluging the ISP connector once in a while

 

I'll add jumpers for the I2C bus around the attiny, it really messes ISP programming...I guess on a final product, I'd remove all these

 

pretty sure I read somewhere I could use diodes or something

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have never used a Raspberry Pi.

I seem to remember when the first one appeared it did not play cricket on the I2C bus.

 

I presume that any non-conformance would have been fixed by now.

 

You still have a problem if the RPi is actively talking to the I2C bus when you are using an external programmer like USBASP or ATMEL-ICE.

 

Since this particular Slave is "off-line" during ISP programming,  you might just as well disconnect SDA, SCL.

 

Yes,  you can use a buffer,  tri-state lines,  ..., AND gate, ...

The enable/disable function could be controlled by the /RESET pin.   i.e. the external programmer would automatically disconnect the I2C bus when it asserts /RESET.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

I seem to remember when the first one appeared it did not play cricket on the I2C bus.

 

Anyone trying to play cricket on a bus should be left beside the road.

 

More helpfully, consider jumper blocks?  Pull them to program, re-install to run.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yes I'll use jumpers

I dont know what is cricket

 

and indeed the RESET line could be use to drive a tri state

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

phil1234567 wrote:
I dont know what is cricket

(and I'm old enough to remember and have enjoyed watching Ian Botham in 1981- truly incredible!) 

Last Edited: Thu. Jan 14, 2021 - 02:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cricket is a game that involves throwing things at people with sticks, the idea being that if the thing is hit with the stick then it goes somewhere else and everyone runs around for awhile.  As entertainment, there are stupider things on television.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

phil1234567 wrote:

and indeed the RESET line could be use to drive a tri state

 

Unless you really need it, don't monkey with the RESET pin.  That way leads to a lot of useless chips in a big hurry.  Yeah, you CAN blow the RSTDISABL fuse and get one more I/O pin - but that doesn't mean you SHOULDS.

 

Edited to add emphases

Last Edited: Thu. Jan 14, 2021 - 02:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:

phil1234567 wrote:

and indeed the RESET line could be use to drive a tri state

 

Unless you really need it, don't monkey with the RESET pin.  That way leads to a lot of useless chips in a big hurry.  Yeah, you CAN blow the RSTDISABL fuse and get one more I/O pin - but that doesn't mean you SHOULDS.

 

Edited to add emphases

 

You don't need to blow the RSTDISABL fuse to use the RESET pin to drive a tri state ! 
I've got a 74HC4053 multiplexer with the selects connected to the reset pin. When programming, the ISP drives the reset low and the 4053 selects the ISP, in normal operation it's the other way around.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jussishow wrote:

You don't need to blow the RSTDISABL fuse to use the RESET pin to drive a tri state ! 

I've got a 74HC4053 multiplexer with the selects connected to the reset pin. When programming, the ISP drives the reset low and the 4053 selects the ISP, in normal operation it's the other way around.

 

Clever!  But I'd use a 74HCT4053 - the T guarantees TTL compatibility.  Like circuits without decoupling caps, they might work - for awhile - and then get weird for no obvious reason.  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:

jussishow wrote:

 

You don't need to blow the RSTDISABL fuse to use the RESET pin to drive a tri state ! 

I've got a 74HC4053 multiplexer with the selects connected to the reset pin. When programming, the ISP drives the reset low and the 4053 selects the ISP, in normal operation it's the other way around.

 

Clever!  But I'd use a 74HCT4053 - the T guarantees TTL compatibility.  Like circuits without decoupling caps, they might work - for awhile - and then get weird for no obvious reason.  S.

Might well be a T in there as well ! :) Must buy a better/more powerful magnifying glass and doublecheck ! ;-) 

Found it mentioned in a similar thread from the 'old days' when searching for '4066' !