Universal I2c-Slave

[Alois Bachmeier]

Hallo,
ich versuche einen I2C-Slave, implementiert mit einem ATtiny85, an einem Raspberry zu nutzen und laufe dabei in I/O-Probleme.
Der Slave funktioniert in Verbindung mit einem ATmega (Master) problemlos.
Ich suche jemand, der Erfahrung mit AVM-Chips am Raspberry hat.

Zur Info noch den BASCOM-Code, den ich auf dem ATtiny am Laufen habe:


'(
This Coding Is Used To Count Input Pulses And Send Them Over To I2c

ATtiny85: PortB0 (Pin5) = SDA
PortB1 (Pin6) = signal LED Orange
PortB2 (Pin7) = SCL
PortB3 (Pin2) = count input
PortB4 (Pin3) = singnal LED Blau
PortB5 (Pin1) = Reset

After each reading counting is set back to zero
Critical: timing procedure of master <> timing of slave
')
$regfile = "attiny85.dat"
$crystal = 8000000
$hwstack = 40
$swstack = 16
$framesize = 24
$programmer = 19 ' 19=USBasp

Config Portb.5 = Input : Pinb.5 = 1 'Reset pull-up to Vcc
Config Portb.1 = Output 'LED can be used or not
Orange Alias Portb.1
Config Portb.4 = Output
Blau Alias Portb.4
Dim _trans(10) , _i As Byte
Dim _count As Word

'Reset procedure
'1 > no light / 0 > light (active low)
Blau = 1 : Orange = 0 'LED indicators
For _i = 1 To 50
Toggle Blau : Toggle Orange
Waitms 50
Next
Blau = 1 : Orange = 1 'LED off
Wait 1

Config Watchdog = 2048
Config Debounce = 5

'Config I2C slave -----------------------------------------------
Config Usi = Twislave , Address = &HA0 'bascom uses 8 bit i2c address (7 bit shifted to the left with one bit)

'Main loop ------------------------------------------------------
Start Watchdog
Enable Interrupts
Config Pinb.3 = Input 'Pin2 = count input
Portb.3 = 1 'set pullup

Do
Reset Watchdog
Debounce Pinb.3 , 0 , Inc , Sub
_trans(1) = Low(_count)
_trans(2) = High(_count)
Loop

End


'Twi jump lables ------------------------------------------------
'the following labels are called from the library when master send stop or start
Twi_stop_rstart_received:
' Print "Master sent stop or repeated start"
Return
'master sent our slave address and will not send data
Twi_addressed_goread:
' Print "We were addressed and master will send data"
Return

Twi_addressed_gowrite:
' Print "We were addressed and master will read data"
Return

'SEND >>> from master
Twi_gotdata:
Select Case Twi_btw
Case 1 : _trans(5) = Twi '---- may be Case 1 is Init procedure
Case 2 : _trans(5) = Twi
End Select
If _trans(5) = &H0F Then
Blau = 0
End If
Return

'READ >>> send to master 2 bytes here --------------------------
'ATTENTION: master read all bytes in ONE sequence
'there is NO handshake! Take care, not to have any delay sequenze within the code called herein
'block all other activities while master is reading
Twi_master_needs_byte:
Select Case Twi_btr
Case 1 : Twi = _trans(2) 'byte 1 low
Case 2 : Twi = _trans(1) 'byte 2 high
Case 3 : Twi = _trans(5) 'back comunication
End Select

Return

Inc:
Incr _count
Return

[Alois Bachmeier]

Also, ich hab jetzt rum gemessen und verbessert:
1. Die Spannungsversorgung auf der Testplatine gepuffert.
Die Messung am Oszilloskop zeigte beim Schalten einer naheliegenden Neonröhre Spitzen über Vcc im MHz-Bereich. Im Bit-Strom konnte man auch sehr kurze "Fehl-Bits" beobachten, die dann wohl auch sporadisch zum Abbruch führten.
>> Ferit-Perle (3,3mH) in die Vcc-Leitung und 2,2µ + 47n parallel.

2. Es gab Berichte im Netz, die auf Probleme mit Geschwindigkeit und Einschwingverhalten auf dem Bus hindeuten. Deren Lösung war, den Ablauf in herkömmlichen Warteschleifen zu verzögern.
Ich habe jetzt die Geschwindigkeit am Slave durch "Config I2cdelay = 20[/b]" auf 50kHz verringert.

3. Die Busgeschwindigkeit am Raspberry habe ich dann auch noch auf 50kHz verringert.