Archiv verlassen und diese Seite im Standarddesign anzeigen : Pullups, I2C und das RNBFRA_1.2 Board
Ich hab folgendes Problem:
Ich habe viele viele Stunden versucht die Ultraschallentfernungssensoren (SRF-08) mit den zugehörigen Programmen in Bascom anzusteuern. Ich hab dazu einfach die Anschlüsse auf dem Board (dort wo I2C steht) direkt mit den Anschlüssen des Sensors verbunden, ohne Widerstände oder sonst was.
1. War das falsch, oder fehlen da Pullups oder mach ich pronzipiell schon was falsch?
In meiner Verzweiflung habe ich dann einmal wieder das Testprogramm 1 geladen, was bei der CD dabei war. Das ist das Programm, welches über I2C den PCF 3 Baustein anspricht und dann die Leds im Lauflicht fahren lässt.
Es funktioniert nicht mehr. Ich kann es fehlerfrei laden, aber es tut sich nix. Das "hallo" wird schon an die RS232 gesendet, aber die Leds leuchten nicht. Also hab ich weitere Testprogramme geladen, die den I2C Bus verwenden. Kein einziges funktioniert.
Kann ich mir diesen Bus kaputt gemacht haben? Wenn ja, welcher Baustein ist dann womöglich kaputt?
Ein Hinweis noch: Als ich das Board fertig aufgebaut hatte, habe ich alle Testprogramme ausprobiert, und alle haben voll und ganz funktioniert.
Ich hoffe ihr könnt mir da helfen.
mfg
Dave
pebisoft
15.12.2004, 19:07
die pullups fehlen, ohne diesen funktioniert der i2c-anschluss am avr nicht, weil der pegel undefinierbar ist.
mfg pebisoft
pebisoft
15.12.2004, 19:08
im bascomforum gibt es schöne hinweise für die sensoren, weil ich das problem auch hatte (srf04/srf08). mit programmen.
mfg pebisoft
im datenblatt der srf08 steht, dass die pullups schon drauf sind.
kann es sein, dass gemeint ist, das sie am Bus schon drauf sind?
Ich habe natürlich auch schon versucht zu messen mit pullups, aber da hat sich auch nichts getan.
warum gehen nicht einmal mehr die leds?
noch eine frage: ich will 6 stück srf08, 3 stück ad7416 (Temperatursensor) und ev. noch ein cmps03 (kompassmodul) anschließen. bleiben die pull ups immer die gleichen? oder muss ich die dimensionieren? und wenn ich das muss, wie kann ich sie mir berechnen?
pebisoft
15.12.2004, 21:31
wenn die pullups schon am modul integriert sind, brauchst du diese nicht mehr am i2c-bus realisieren, die müssten dann funktionieren.
mfg pebisoft
und wie müsste ich sie dimensionieren, wenn sie nicht drauf sind? gibts da einen fixwert, oder muss ich die berechnen?
Auf dem RNBFRA Board sind schon 10k Pullup-Widerstände drauf. Ledigliglich wenn mehr als ca. 3 oder 4 Module angeschlossen werden, dann kann es sinnvoll sein das noch irgendwo im Bus zwei 10K Pullups drauf gelegt werden. Normalerweise ist das aber nicht notwendig.
Wenn du jetzt nix am I2C dran hast und dennoch die gleichen I2C-Programme die vorher gingen nu nicht mehr gehen, könnte das natürlich ein defekter I2C-Port sein. In diesem Fall solltest du mal einen anderen Controller einsetzen.
Prüfe aber ob im Demo auch die richtigen I2C-Ports konfiguriert wurden und die richdigen Slave Adressen und Jumper gesetzt sind.
Gruß Frank
das demo würde überhaupt nicht verändert. ich habs direkt von der cd kopiert, dann kompiliert und übertragen. genau so, wie ich das schon nach dem zusammenlöten gemacht hab.
einen anderen controller (meinst du den mega32 ? ) einsetzen hab ich auch schon gemacht. hat nix geholfen. den pcf3 der beim ersten testprogramm angesprochen wird, hab ich auch schon getauscht. hilft nix. durchgang von slc und sda leitungen vom m32 zum pcf8574 hab ich auch getestet. also die verbindung kanns auch ned sein. was kann ich noch machen?
mfg
Dann kontolliere nochmal genau die Jumper Stellungen, vielleicht hast du dich bei den Slave ID Adressen vertan. Und schließe nix am Bus an, eventuell überschneiden sich Slave-ID´s.
ok, soeben kontrolliert laut rnbfra doku seite 19. alle jumper stimmen. aum bus is nix angeschlossen, geht trotzdem nicht. ich verstehs nicht.....
Hmm, da fällt mir momentan auch nix mehr ein. Notfalls musst du dir kleines Testprogramm schreiben das die Ports mal im Sekundentakt auf Low / High schaltet und Leitungen ausmessen. Am besten alle PCF´s rausziehen und erts mit dem Controller den Test machen und dann Stück für Stück den nächsten PCF dazu. Ich weiss ja nicht was du gemacht hast, vielleicht hast du irgendwann mal irgendwelche Stecker verwechselt und tatsächlich mehrer I2C-Bausteine gehimmelt.
Kommt aber selten vor! Es hilft nix, du musst systematisch suchen.
Außer Software und Jumpern kann es ja sonst nix sein.
Hallo!
Ich hab mal drüber geschlafen, hat leider nix gebracht :-(
Basic kann ich leider nicht wirklich. Ich hab mir was zusammengestoppelt, von dem ich dachte es könnte richtig sein:
$regfile = "m32def.dat"
$crystal = 8000000
$baud = 9600
Config Scl = Portc.0
Config Sda = Portc.1
I2cinit
I2cstart
Portc.0 = 1
Portc.1 = 1
Waitms 1000
Portc.0 = 0
Portc.1 = 0
Waitms 1000
return
Erst mal: stimmt das überhaupt?
Ich hab das dann in den Controller geladen und zw. Gnd und Pin 23 (SDA) Spannung (DC) gemessen. Im sekundentakt wecheslte die Spannung zw. 1,00V und 1,87V.
Klingt doch schon mal ganz gut würd ich sagen. Das Lichtspiel mit den Leds geht aber natürlich noch lang nicht aufgrund dieser weisheit :-(
Wie soll ich weiter vorgehen? Bausteine tauschen - welche?
mfg, Dave
Hi, Dave !
Da ist doch noch der CoProcessor mit seinem I2C. Ist der mit der Servo-Ware überhaupt richtig als Slave definiert ? Sonst spuckt uns der in die Suppe. (War der beim ersten LED Test, der ja gefunzt hat vielleicht gar nicht drin oder noch nicht geladen ?)
Möglicher Versuch: CoProcessor raus
Möglicher Versuch: Mega32 raus und das Ganze Testen mit dem CoProcessor, (umstecken, Test laden) mußt ja eigentlich auch gehen.
BASIC: is soweit o.k. ABER !!!
für 0 u. 1 sind 1 V <> 1.87 V allerdings unbrauchbar. da hats was mit den Pullups
ich bin auch dran robert mfg ](*,)
EDIT: Noch was: Es gibt eine vordefinierte Variable "Err". (=Fehler)
Nach jedem I2C Befehl abfragen (print)
Den CoProcessor hab ich gelöscht. Der pfuscht nicht rein. war aber beim ersten Test auch drin.
Möglicher Versuch: CoProcessor raus
Gleiches Phänomän: springt zw. 1V und 1,87V herum
Möglicher Versuch: Mega32 raus und das Ganze Testen mit dem CoProcessor, (umstecken, Test laden) musst ja eigentlich auch gehen.
Laden geht, aber beim messen hab ich auf der SDA fix: 1,93V und auf er SCL fix 4,97V. Herumspringen tut da nix mehr.
Die Pullups sollten doch schon auf dem Board sein.... 8-[
code sieht jetzt so aus:
$regfile = "m32def.dat"
$crystal = 8000000
$baud = 9600
Config Scl = Portc.0
Config Sda = Portc.1
I2cinit
I2cstart
Portc.0 = 1
Print Err
Portc.1 = 1
Print Err
Waitms 1000
Portc.0 = 0
Print Err
Portc.1 = 0
Print Err
Waitms 1000
return
Wenn ich das in den CoCOntroller lade tut sich nix im Terminal (eh klar, dürfte keine direkte Verbindung zum MAX32 haben. Wenn ich es in den M32 lade, kommt im Terminal die 0
sieht so aus:
0
0
0
0
usw. ;-)
was kann ich noch machen?
mfg
ok, weiter gehts mit der fehlersuche...
Ich hab jetzt zw. +5V und SDA bzw. zw. +5V und SCL 10k Pullups gehängt. Das ganze einfach am I2C Bus am board (an dieser einen Schwarzen Buchse) angeschlossen.
Alle Controller rein, und Spannung angelegt.
Programm geladen, folgendes Passiert:
Die Lampen blinken natürlich nicht, aber dafür hab ich jetzt andere werte:
Die SCl bleibt weiterhin Stur auf ihren 4,97V und die SDA springt jetzt im sekundentakt zw. 1,55V und 2,22V hin und her.
Ist das besser?
Poste dein Testprogramm! Nimm erst mal alle PCF´s raus! Und teste dann den Pegel. Pullups brauchst du wie gesagt nicht, solange nicht noch mehrere externe I2C Bausteine dran hängen.
Wenn du Ports richtig ein und ausschaltest dann ist das natürlich nix mit dem Pegel den du da beschreibst, deutet dann auf defekten Baustein hin. Daher erst mal aus IC-Fassung ziehen und dann Stück für Stück vorgehen.
Hi, für digital sind diese alle Werte unisant, die müssen < 1 / > 4 sein.
Die eingebauten Pullups werden gesetzt durch: (nach i2cinit)
PORTC.0 = 1
PORTC.1 = 1
Dann gibts noch einen generellen Pullup Mörder, der MUSS Null sein
SFIOR.2 = 0
mögliche Messung: Alle I2C Brüder raus (ausser MEGA)
Wenn NUR der Mega drin ist, (geladen, nur i2cInit und s.o) müssen SCL u. SDA wenigstens ~4 V zeigen (High)
Ist das nicht, hat's schon was.
Wenn ja-->
einmal NUR den LED pcf wieder rein / Messen ?
VERGISS beim Testen nicht:
CONFIG I2CDELAY = 5 oder sowas
(laut Datasheet erforderlicht, und wir wissen nicht, was der Basic treibt)
nun ? mfg robert
PS: Bei Print eine Text vor die Zahle dazuschreiben
das Testprogramm mit dem ich die SDA und SCL leitungen auf high und low schalte is ja etwas weiter oben gepostet.
und das Testprogramm mit dem ich die Leds zum leuchten bringen will ist dieses hier: (ist direkt von der Roboterboard CD)
'################################################# ##
'Testprogramm 1
'für
'RoboterNetz Standard-Roboter Board RBNFRA 1.2
'
'Aufgabe:
'Ausgabe über PowerPort per I2C testen indem
'die vier Led´s im lauflichtartig leuchten
'
'Autor: Frank
'Weitere Beispiele und Beschreibung der Hardware
'unter http://www.Roboternetz.de
'################################################# ##
$regfile = "m32def.dat"
Const Writepowerport_adr = &H72 'I2C Adr PCF 2
Const Readpowerport_adr = &H73 'I2C Adr PCF 2
Dim I2cdaten As Byte 'Datenbyte aus PCF8574
Dim I As Byte
$crystal = 8000000 'Quarzfrequenz
$baud = 9600
Config Scl = Portc.0 'Ports fuer IIC-Bus
Config Sda = Portc.1
I2cinit
'******** Diese 4 Befehle sind nur ab RNBFRA Version 1.2 (nicht in V 1.1)
' notwendig und bzw. möglich (erweiterte Energiesparfunktion und LED´s)
' Bei Board 1.1 bitte auskommentieren oder löschen
config I2CDELAY = 5
I2cstart
I2cwbyte &H74 'Schreibbefehl an PCF3 schicken
' Led´s ein ,Motorendstufen ein, Port-Peripherie ein, RBN-Bus Sleep Modus aus (also PeripherieAktiv)
I2cwbyte &B00000010 'Datenbyte an PCF3
I2cstop
'*********
I = 0
I2cdaten = 1
Do
I2cdaten = I2cdaten * 2
If I2cdaten > 16 Then I2cdaten = 1
I2cstart
I2cwbyte Writepowerport_adr 'Schreibbefehl an PCF schicken
I2cwbyte I2cdaten 'Datenbyte an PCF
I2cstop
Incr I
Waitms 100
Print "hallo"
Loop
End
Pullups raus, alle PCFs raus, Testprogramm (für die Pegel - nicht das für die Leds) ist noch im M32:
Keine der 4 Leds leuchtet (logisch)
SCL: 4,97V
SDA: 1,25V bzw. 2,41V - im Sekundentakt
Wenn du Ports richtig ein und ausschaltest dann ist das natürlich nix mit dem Pegel den du da beschreibst, deutet dann auf defekten Baustein hin.
Schalte ich denn mit diesem Programm die Ports richtig ein und aus, oder mach ich da was falsch?
mögliche Messung: Alle I2C Brüder raus (ausser MEGA)
Wenn NUR der Mega drin ist, (geladen, nur i2cInit und s.o) müssen SCL u. SDA wenigstens ~4 V zeigen (High)
Ist das nicht, hat's schon was.
gut:
alle pcf raus, cocontroller raus, das geladen:
$regfile = "m32def.dat"
$crystal = 8000000
$baud = 9600
Config Scl = Portc.0
Config Sda = Portc.1
I2cinit
SCL: 4,97V
SDA: 2,41V
was nun?
Aha, überlappt. Um zu unterscheiden, ob der Schweinehund nun IM Mega oder AUSSEN sitzt:
Mach ein Programm wie deines ganz oben , lass aber den ganzen I2C Krempel mal weg. (und alle i2c Peipherie)
CONFIG Pinc.0 = Output
CONFIG Pinc.1 = Output
DO
PortC.0 = 1
PortC.1 = 1
waitms 1000
PortC.0 = 0
PortC.1 = 0
waitms 1000
LOOP
Die SCL u. SDA Leitungen müssen jetzt deutlich tickern.
Tun sie das nicht, zieht irgendwer anderer an den Leitungen.
Umgekehrt:
CONFIG Pinc.0 = Input
CONFIG Pinc.1 = Input
PortC.0 = 1 ' (Pullup)
PortC.1 = 1 ' (Pullup)
DO
' nix ---
LOOP
Die SCL u. SDA Leitungen müssen jetzt deutlich OBEN sein (und bleiben)
mfg robert
zur sicherheit hab ich das auch noch gemacht:
PCF3 rein
das programm reingeladen:
$regfile = "m32def.dat"
$crystal = 8000000
$baud = 9600
Config Scl = Portc.0
Config Sda = Portc.1
Config I2cdelay = 5
I2cinit
Sfior.2 = 0
Portc.0 = 1
Print "Error:" ; Err
Portc.1 = 1
Print "Error:" ; Err
Waitms 1000
Portc.0 = 0
Print "Error:" ; Err
Portc.1 = 0
Print "Error:" ; Err
Waitms 1000
Return
keine led leuchtet
Hyperterminal:
Error: 0
Error: 0
usw....
SCL: 4,97V
SDA: schwankt zw. 2,48V und 2,6V - hilft also auch nix
klingt schön langsam nach defekten m32 :-(
so schnell komm ich garnimma mim testen nach ;-)
ich mach jetzt mal die letzte meldung vom robert durch
meld mich gleich wieder
gut, das schaut besser (?) aus:
alle 3 PCF draussen, cocontroller draußen, programm geladen:
$regfile = "m32def.dat"
$crystal = 8000000
$baud = 9600
Config Scl = Portc.0
Config Sda = Portc.1
CONFIG Pinc.0 = Output
CONFIG Pinc.1 = Output
DO
PortC.0 = 1
PortC.1 = 1
waitms 1000
PortC.0 = 0
PortC.1 = 0
waitms 1000
Loop
SCL: 0,02V bzw. 4,97V - wechselt im sekundentakt
SDA: 1,27V bzw. 2,42V - wechselt im sekundentakt
und weiter gehts:
alle 3 PCF draussen, cocontroller draußen, programm geladen:
$regfile = "m32def.dat"
$crystal = 8000000
$baud = 9600
Config Scl = Portc.0
Config Sda = Portc.1
CONFIG Pinc.0 = Input
CONFIG Pinc.1 = Input
PortC.0 = 1 ' (Pullup)
PortC.1 = 1 ' (Pullup)
DO
' nix ---
LOOP
SCL: 4,97V fix
SDA: 2,62V fix
:-k
mr400watt
16.12.2004, 12:31
hi dave
ich vermute mal dass sich die werte zwischen fast 0 und fast 5V bewegen sollten ... irgendwie is da was komisch ... was du misst sind nämlich keine logikpegel wie ich sie kenne
be dem ding mit prozessor und coprozessor wechseln meinte er glaub ich dass du den coprozessor aus der fassung nehmen sollst und dort hinconnecten sollst wo der mega sonst sitzt weil du ja sonst keine verbindung hast wenn der mega fehlt ... richtig?
ich werd jetzt mal testen ob das 2. RNBFRA funktioniert
greez - flo
Hi, Marsmenschen.
O:) So wie's ausschauft, ist die SCL Leitung o.k. O:)
[-( SDA gefälllt mir in beiden Fällen nicht, da sitzt noch wer drauf. [-(
(oder das Port ist tatsächlich hinüber)
Test A muß irgendwie zum hinkriegen sein, sonst brauchen wir den I2c nicht bemühen.
Platine checken (MEGA raus, Saft ran, messen SDA ?)
mfg robert
EDIT: Flo hat recht, aber der Co müßte ja eh auf dem Bus hängen ?
Hallo Dave,
da ja nach deiner Aussage ursprünglich alles mal funktionierte vermute ich, dass du beim Anschluss der Module den Controller (SDA) gehimmelt hast.
Das könnte z.B. passiert sein, wenn nur die Portleitungen angeschlossen waren (Masse nicht verbunden) und das Controllerboard und die Sensoren aus verschiedenen Netzteilen gespeist wurden. In dem Fall kann sich ein Potenzialunterschied von >10V aufbauen, der durchaus zerstörerisch wirken kann.
Ist aber jetzt von mir auch nur ne Vermutung was passiert sein könnte.
In jedem Fall hat die SDA-Leitung ein Ding weg, also entweder der Controller ist im A*** oder es ist noch was mit SDA verbunden (oder der 10K Pullup hat ne kalte Lötstelle).
BTW, im Moment eher uninteressant, aber es stand hier im Thread, die SRF08-Module haben keine bestückten PullUps - steht auch nicht so in der Anleitung.
HTH und Viele Grüße
Jörg
@Jörg: bin ich völlig d'accord, nur gab's da noch Tests mit einem zweiten Mega, der das gleiche Verhalten (besser: Nichtverhalten) zeigte.
Wir werden sehen mfg robert
anmerkung: es könnte sein, dass der 2te mega desswegen nicht gegangen ist, weil er frisch aus der packung genommen wurde, und da sind ja fuse bits und jtag noch nicht gesetzt, und das haben wir auch nicht gemacht....
Platine checken (MEGA raus, Saft ran, messen SDA ?)
mega raus - ok
saft ran - meinst du die versorgungsspannung ganz normal dranhängen?
wenn ja. dann:
scl: 4,97V
sda: 4,97V
beides konstant :D
Richtig. d.h ein für alle Mal: Pullup sin' da.
Der Platine so zumindest nix nachweisbar.
Jetzt schaut's für das SDA Port schon recht duster aus. ad hoc hab' ich mal keine Idee mehr.
Da müssen wir versuchen, den anderen Mega ernsthaft in Betrieb zu nehmen. Flo wird ja auch erzählen, wie's mit seinem Board aussieht.
*seufz* mfg robert
würde Mega32 tauschen was helfen, oder müsste (sollte) ich gleich mehr tauschen?
die letzte nachricht war natürlich von mir... ich war leider nicht eingeloggt
Hi, war unterwegs.
Ja natürlich , trotzdem mal ohne i2C-Kundschaft, Ohne Betrieb, nur Setup. Es müssen SDA u. SCL oben (>4V) sein und bleiben.
Isses so, sind wir Optimisten und checken den LED Test.
Wer das wieder geht, poltern eh alle Steine von den Herzen, dann sind wir wieder im Geschäft.
Du könntest auch wieder die SF08 probieren, was solls
Aber warten wir erst mal ab. mfg robert
Sodale
Hab jetzt den neuen Mega32 und die neuen PCFs eingebaut. Programm geladen.... und siehe da: er lebt!
Es geht alles einwandfrei
Vielen Dank für die Hilfe
mfg, Dave
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.