Hi, ist es irgendwie möglich einen Portpin sowohl als Eingang als auch als Ausgang laufen zu lassen? Der Pin wird über externe Pullups auf vcc gezogen. Nun sollte der AVR die Leitung auf Gnd ziehen können aber die Leitung soll auch ausserhalb vom µC auf Gnd gezogen werden können (und dieser solls mitbekommen) Kurz und gut: Was passiert wenn ich den Pin als Ausgang konfigurier und dann halt mit porta die ausgangspegel setz aber gleichzeitig mit pina die eingangspegel abrufe? Geht das? Oder muss ich zwischendurch das ddra umschalten?
Nö musst du nicht. PINx sagt dir immer den Status welcher am Port liegt Wenn jedoch der Pin als Ausgang im DDRx gestellt wird geht der Strom wahrscheinlich hoch da er den Ausgang mit 0V bzw 5V verbindet. mfg Karl
He? wrote: > Was passiert wenn ich den Pin als Ausgang konfigurier und dann halt mit > porta die ausgangspegel setz aber gleichzeitig mit pina die > eingangspegel abrufe? > > Geht das? Das geht, nennt sich open-drain Ausgang. Dazu muß das PORTx-Bit einmalig auf 0 gesetzt werden. Um eine 1 zu senden: DDRx = 0 Um eine 0 zu senden: DDRx = 1 Peter
Das was Du vorhast klingt wie I2C. Leitung wird über Pullup auf 5V gezogen und von irgendeinem der angeschlossenen Devices auf 0V gezogen. Die anderen Devices horchen währenddessen auf diesem Pin.
War tatsächlich I2C. Lief auch soweit, allerdings hatte ich das Problem das mein EEPROM nicht mitmachen wollte. Die Befehle hat es soweit angenommen (und mit ACK bestätigt sofern sie korrekt waren) das Problem ist jedoch dass vor dem Auslesen ein Dummy Write gemacht werden muss, und selbiges lief überhaupt nicht. Ich kann mal kurz die Vorgehensweise dafür schildern: 1 Start Condition 2 Device Address incl. Write Bit 3 EEPROM sendet ACK 4 Erste 8bit der Adresse werden übertragen 5 EEPROM sendet ACK 6 Zweite 8bit der Adresse werden übertragen 7 EEPROM sendet ACK 8 Dummy Daten werden übertragen 9 EEPROM sendet ACK 10 Start Condition 11 Device Address incl. Read Bit 12 EEPROM sendet ACK (auch bei falscher DEVADDR) 13 EEPROM sollte die Daten übertragen Leider tut es das aber nicht. Es könnte an 2 Dingen liegen: Nach dem Schreiben der Daten (natürlich NICHT der Dummy Daten) wird die Stop Condition falsch verstanden. Ich nehme mal an dass wen die nicht folgt die Daten nicht geschrieben werden. Desweiteren habe ich beobachtet dass bei Schritt 11 das EEPROM auch ein ACK sendet wenn die Device Adresse falsch ist, bei allen anderen Abfragen funktioniert es jedoch normal. Hat jmd von euch eine Idee? Das er eine falsche Dev-Adresse akzeptiert verblüfft mich einfach.. Vllt hab ich auch einfach das Datenblatt falsch verstanden.. Das Ganze ist eine reine Software Lösung und ich verarbeite nur Bits, deswegen ist der Code etwas unübersichtlich und lang, ich könnte ihn aber auch mal posten.. EEPROM ist das 24C128 und SDA bzw. SCL liegen auf PORTA eines AT90S8515 Vllt fällt den alten Hasen hier mal was ein :) Gruß und Danke!
He? wrote: > Die Befehle hat es soweit angenommen (und mit ACK bestätigt sofern sie > korrekt waren) das Problem ist jedoch dass vor dem Auslesen ein Dummy > Write gemacht werden muss, und selbiges lief überhaupt nicht. Wo hastn das her ? Daß der EEPROM beim Dummy-Write austillt, kann ich verstehen, sowas gibts garnicht. Du verwechselst das wohl mit SPI. Peter
He? wrote: > Das Ganze ist eine reine Software Lösung und ich verarbeite nur Bits, > deswegen ist der Code etwas unübersichtlich und lang, ich könnte ihn > aber auch mal posten.. Nö, SW-I2C muß weder lang noch unübersichtlich sein: http://home.tiscali.de/peterd/appl/soft/c51/eeprom/index.htm Peter
@Peter Aus dem Datenblatt? Schau mal: RANDOM READ: A random read requires a “dummy” byte write sequence to load in the data word address. Once the device address word and data word address are clocked in and acknowledged by the EEPROM, the microcontroller must generate another start condition. The microcontroller now initiates a current address read by sending a device address with the read/write select bit high. The EEPROM acknowledges the device address and serially clocks out the data word. The microcontroller does not respond with a zero but does generate a following stop condition (refer to Figure 5). Es ist I2C bzw. TWI. Oder bin ich im falschen Film und kann nichtmal lesen?
Andi wrote:
> Hier noch ein Bild dazu.
Und wo siehst Du auf diesem Bild Deinen Schritt 8 und 9 ?
Peter
AAArgh okok.. entweder ich bin doof und habs falsch aufgeschrieben, oder ich machs im Programm wirklich falsch. Ich habs jetz nicht hier, sitz am Notebook, aber denke mal das könnte der Grund sein. Ich glaube ich hab da wirklich noch ein Datenbyte drin. Dank dir Peter!
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.