Funktion Programm unklar

achim S.

Mitglied
16. Jan. 2010
704
13
18
Berlin Biesdorf
Sprachen
  1. ANSI C
Hallo
habe so ein Problem mit einem kleinen Stück Programm. Entweder zu doof für diese Welt oder sehe die groose Welt vor Augen nicht. Verwende dieses Stück Code:


CodeBox C
if (PINB & (1<<PINB2))                     // Taster T2 
          {                                        // Wenn T2 gedrückt...
            PORTA |=(1<<PINA0);                    // LED 2 ein
          }
        else
          {                                        // wenn nicht
            PORTA &=~(1<<PINA0);                // LED 2 aus
          }
        
        if (PINA & (1<<PINA7))                     // Taster T3 
          {                                        // Wenn T3 gedrückt...
            PORTA |=(1<<PINA1);                    // LED 3 ein
          }
        else
          {                                        // wenn nicht
            PORTA &=~(1<<PINA1);                // LED 3 aus
          }        

Die Belegung der Pins:

// Platine P173 Attiny 841 mit Quarz
// PA0 --> L2
// PA1 --> L3
// PB2 --> T2
// PA7 --> T3
// PA2 --> U/2
// PA3 --> Regler

Belegung DDR und Ports:

DDRA=0b00000011; // Port A auf Ausgang schalten
DDRB=0b00000100; // Port B auf Ausgang schalten

PORTA=0b00000011; // Port A auf aus
PORTB=0b00000100; // Port B auf aus

In der Zeile mit DDRB und PORTB liegt das Problem. Wenn ich die 1 durch eine 0 ersetze leuchtet L2 am PA0 dauerhaft.
Warum ????
achim
 
Erstens: Was heißt:
// PA0 --> L2
// PA1 --> L3
// PB2 --> T2
// PA7 --> T3
L sind Induktivitäten oder wie? Wenn das LEDs sein sollen, wohin sind die dann verdrahtet?
T sind Taster? Wohin schließen/öffnen die?
Zweitens: Wenn an B2 ein Taster hängt, warum dann
DDRB=0b00000100; // Port B auf Ausgang schalten
Drittens: Sind auch hier Deine Kommentare ungenau

Viertens: ist das ein Fehler der Codebox, oder warum passen die Einrückungen nicht?

Nachtrag:
ich dachte, "zweitens" hatten wir hier schon geklärt:
Damit aktivierst Du die Ausgangstreiber für A0, A1 und B2.
[…]
Dadurch legt das Bit im PORT-Register den effektiven Pegel des Beines fest. Bei allen anderen Beinen ist der Zustand des Port-Register-Bits wirkungslos.
Dadurch werden A0, A1 und B2 auf high Pegel geschaltet (sind ja Ausgänge). Wenn Du an B2 jetzt 'n Taster gegen Gnd schließt, hast Du 'n Kurzschluß - das schwächste Glied wird dann meiner Vermutung nach der Ausgangstreiber des Beins sein.
 
Zuletzt bearbeitet:
Hatte auch gedacht das wir es schon geklärt hatten. Doch leider funktioniert es nicht so richtig. Habe die Bezeichnungen geändert. Glaubst du wirklich das ich Induktivitäten an den Ausgang hänge? Bei L und T handelt es um die Standart Belegung für Bastler an den Pins, also LEDs und Taster.

// Platine P173 Attiny 841 mit Quarz
// PA0 --> LED 2
// PA1 --> LED 3
// PB2 --> Tast 2
// PA7 --> Tast 3
// PA2 --> U/2
// PA3 --> Regler

Ob Codebox defekt ist, kann ich weiter beurteilen. Habe es einfach reingestellt und fertig.

DDRA=0b00000011; // DDR A, A0 und A1 auf Ausgang schalten
DDRB=0b00000000; // DDR B auf Eingang schalten

PORTA=0b00000011; // Port A, A1 und A0 auf Hi
PORTB=0b00000000; // Port B auf aus

Dann könnte es so richtig sein?
Wenn ich das so eintippe und das Programm wie oben starte, leuchtet die LED 2 auf PA0 dauerhaft. Hat das wieder mit dem Pin PA0 zu tun und der Einstellung der Fuse?
 
Es hatte wieder mit der Fuse Einstellung zu tun.
Hatte das folgende:

EX 0xFF
HI 0xDF
Lo 0xEF (CF)

Die korrekte Einstellung muss sein LO 0x0F und damit laufen die Einstellungen korrekt. Da hat mich das Ding wieder verarscht. Danke Elektronik.
achim
 
Immer diese dämlichen Hexzahlen - die Bits haben doch Namen...

Im Low-Fusebyte des Tiny(241)/441/841 sind folgende Bits:
  • Bit7 - CKDIV8, Takt durch 8 geteilt, Default aktiviert=0
  • Bit6 - CKOUT, Taktausgabe am CLKO-Pin (=B2), Default deaktiviert=1
  • Bit5 - unused, Default deaktiviert=1 (sollte auch immer mit 1 beschrieben werden)
  • Bit4 - SUT, Start up Time, legt zusammen mit den folgenden Bits die Startup time fest, Default aktiviert=0
  • Bit3 - CKSEL3
  • Bit2 - CKSEL2
  • Bit1 - CKSEL1 - Selektieren zusammen die Clocksource (beim Start, kann im laufenden Betrieb aber umgeschaltet werden, Default ist nur CKSEL1 deaktiviert=1, alle anderen sind aktiviert=0, was den internen 8MHz Oszillator aktiviert
  • Bit0 - CKSEL0
0xEF wäre 11101111, also CKDIV8 deaktiviert (Main Clock Prescaler beim Start auf 1), CKOUT deaktiviert (keine Ausgabe des Taktes), Bit5 deaktiviert, SUT aktiviert, alle vier CKSELs aktiviert (externer Quarz/Resonator mit mehr als 8MHz).

0xCF wäre 11001111, der einzige Unterschied wäre also das ungenutzte Bit, welches jetzt aktiviert wird (aber eben keine Auswirkung hat

0x0F wäre 00001111, also CKDIV8 aktiviert (Main Clock Prescaler beim Start auf 8), CKOUT aktiviert (Clockausgabe an CKOUT), unused Bit aktiviert, SUT aktiviert.

Wenn CKOUT aktiviert wird, wird:
  • der interne Pullup am Pin via Override deaktiviert (also unabhängig vom Inhalt des PUExn)
  • die Datenrichtung des Pins via Override auf Ausgang gesetzt (also unabhängig vom Inhalt des DDRxn)
  • der Eingang des Ausgangstreibers (und damit der Pegel des Pins) via Override (also unabhängig vom Inhalt des PORTxn) mit der System_Clock verbunden - als Ergebnis hat man den effektiven Systemtakt am Pin.
CKOUT hat aber keinen Einfluß auf den Signalweg vom Pin zum PINxn (Schmitt-Trigger, Synchronizer usw) - grundsätzlich kannst Du den Pin also lesen. Inwiefern das Sinn macht, da der Synchronizer ja auf den Systemtakt … äh … synchronisiert, da müßte man erstmal in den Timings des Synchronizers genauer nachsehen, was da überhaupt gelesen werden würde möglicherweise liefert der so immer 'ne "1".

Wenn Du den Pin jetzt aber mittels Taster auf Gnd zwingst, und der Ausgangstreiber als schwächstes Glied einknickt, würdest Du auch 'ne "0" im PINregister lesen. Wie lange der Treiber das mitmacht, ist 'ne andere Frage - ich mag keine Kurzschlüsse in meinen Projekten...

Bei L und T handelt es um die Standart Belegung für Bastler an den Pins, also LEDs und Taster.
Was ist da wo von wem wie standardisiert?
WAS Du anschließt, wird durch Dein Projekt festgelegt.
WO Du es snschließt, ist Deine Sache, allerdings eignen sich einige Beine aufgrund ihrer Alternativfunktionen für bestimmte Funktionen besser als andere. Andererseits konkurrieren einige Funktionen um bestimmte Beine.
WIE du 'ne LED oder'n Taster anschließt ist auch Deine Sache.
Wenn der Taster 'n High oder Low Pegel liefern soll, brauchst Du entweder sowas wie'n Um-Taster, der selbst einen der beiden Pegel auf den Pin schaltet, oder Du verwendest 'n Pull-Widerstand auf den einen Pegel und der Taster schließt auf den anderen. Da die (mir bekannten) AVR nur Pullups und keine Pulldowns besitzen (bei den XMegas mag das anders sein), bietet es sich an die (statt externer) zu nutzen, und den Taster gegen Gnd schließen zu lassen) - aber standardisiert ist da nichts.

Bei den LEDs (und Lasten allgemein) mußt Du Dich an die zulässigen Ströme der einzelnen Beine, Beingruppen und des ganzen Controllers halten. Inzwischen sind die meisten halbwegs aktuellen AVR diesbezüglich symmetrisch (ein Pin kann genauso viel Strom liefern, wie er aufnehmen kann). Somit steht es Dir also frei, Deine LEDs gegen Vcc oder Gnd zu schalten.
Beim Tiny441/841 hast Du jetzt die Besonderheit, daß A7 und A5 mehr Strom aufnehmen können ((extra)high sink) - wenn Du entsprechende Lasten schalten willst, bieten sich diese Pins also als Low Side Schalter an.
 
Hallo achim S

Bei Deinem P173 (welches Du ja hier verwendest), hast Du einen 16MHz Quarz - wozu soll der sein, wenn Du mit den 1MHz arbeitest (CKDIV8 gesetzt) - oder täusche ich mich da mit den 1MHz?
Da hat mich das Ding wieder verarscht. Danke Elektronik.
achim
Naja ... da ist wohl weniger die Elektronik dran schuld ;)

mfg

Hero_123
 
Du kennst ja die Sache, das grösste Problem sitzt vor dem Schirm ...
CKDIV8 habe ich rausgenommen. Damit ergibt sich Lo 0x8F. So richtig? Beide Taster und beide LEDs schalten jetzt korrekt.
achim
 
Hallo achim S.

CKDIV8 habe ich rausgenommen. Damit ergibt sich Lo 0x8F. So richtig? Beide Taster und beide LEDs schalten jetzt korrekt.
achim

Du hast (hoffentlich) auch das beachtet:

Im Low-Fusebyte des Tiny(241)/441/841 sind folgende Bits:
  • Bit7 - CKDIV8, Takt durch 8 geteilt, Default aktiviert=0
  • Bit6 - CKOUT, Taktausgabe am CLKO-Pin (=B2), Default deaktiviert=1
  • Bit5 - unused, Default deaktiviert=1 (sollte auch immer mit 1 beschrieben werden)
  • Bit4 - SUT, Start up Time, legt zusammen mit den folgenden Bits die Startup time fest, Default aktiviert=0
  • Bit3 - CKSEL3
  • Bit2 - CKSEL2
  • Bit1 - CKSEL1 - Selektieren zusammen die Clocksource (beim Start, kann im laufenden Betrieb aber umgeschaltet werden, Default ist nur CKSEL1 deaktiviert=1, alle anderen sind aktiviert=0, was den internen 8MHz Oszillator aktiviert
  • Bit0 - CKSEL0
0xEF wäre 11101111, also CKDIV8 deaktiviert (Main Clock Prescaler beim Start auf 1), CKOUT deaktiviert (keine Ausgabe des Taktes), Bit5 deaktiviert, SUT aktiviert, alle vier CKSELs aktiviert (externer Quarz/Resonator mit mehr als 8MHz).

0xCF wäre 11001111, der einzige Unterschied wäre also das ungenutzte Bit, welches jetzt aktiviert wird (aber eben keine Auswirkung hat

0x0F wäre 00001111, also CKDIV8 aktiviert (Main Clock Prescaler beim Start auf 8), CKOUT aktiviert (Clockausgabe an CKOUT), unused Bit aktiviert, SUT aktiviert.

Wenn CKOUT aktiviert wird, wird:

  • der interne Pullup am Pin via Override deaktiviert (also unabhängig vom Inhalt des PUExn)
  • die Datenrichtung des Pins via Override auf Ausgang gesetzt (also unabhängig vom Inhalt des DDRxn)
  • der Eingang des Ausgangstreibers (und damit der Pegel des Pins) via Override (also unabhängig vom Inhalt des PORTxn) mit der System_Clock verbunden - als Ergebnis hat man den effektiven Systemtakt am Pin.
CKOUT hat aber keinen Einfluß auf den Signalweg vom Pin zum PINxn (Schmitt-Trigger, Synchronizer usw) - grundsätzlich kannst Du den Pin also lesen. Inwiefern das Sinn macht, da der Synchronizer ja auf den Systemtakt … äh … synchronisiert, da müßte man erstmal in den Timings des Synchronizers genauer nachsehen, was da überhaupt gelesen werden würde möglicherweise liefert der so immer 'ne "1".

Wenn Du den Pin jetzt aber mittels Taster auf Gnd zwingst, und der Ausgangstreiber als schwächstes Glied einknickt, würdest Du auch 'ne "0" im PINregister lesen. Wie lange der Treiber das mitmacht, ist 'ne andere Frage - ich mag keine Kurzschlüsse in meinen Projekten...

wenn nicht, dann ....

mfg

Hero_123
 
Danke, ich dachte schon, ich tipp mir hier'n Wolf...

0x8F wäre 10001111, also also CKDIV8 deaktiviert (Main Clock Prescaler beim Start auf 1), CKOUT aktiviert (Clockausgabe an CKOUT), unused Bit aktiviert, SUT aktiviert.
 
Hallo achim S.

zu dieser "Fuse" Orgie - da hatte doch Dirk Dir schon mal geantwortet - siehe https://www.makerconnect.de/index.php?threads/ausgang-schaltet-nicht.4226/
(Beitrag #20) außerdem stehen die Fuses doch auch in Deinem Pamphlet (;)) "I2C Bus und der Attiny841" - siehe https://www.makerconnect.de/index.p...e-module-einzeln-oder-als-slave-anwendbar.79/
daher versteh' ich Deine Problematik nicht so ganz ...

Mir ist außerdem nicht klar, warum Du 5 (!) Boards kreiert hast, wo eines gereicht hätte, wenn Du die verfügbaren Ports per Stecker zugänglich gemacht hättest - dann könnte man viel mehr damit anfangen (also ein "Masterboard" mit nur der korrekten Beschaltung für den Prozessor und ein "Spielboard", auf dem man das hätte nachbilden können, was Deine 5 Boards machen).
So wie's jetzt ist, ist man funktional doch etwas .... eingeschränkt.
Zudem ist der ATiny841 ein SMD Bauteil - ob so viele Bastler damit zurechtkommen - ich könnte kein SMD Bauteil löten...

Hast Du schon mal per I2C oder SPI mit Deinen Boards kommuniziert (z.B. ein Board als "Master", eines als "Slave" und dann Daten zwischen beiden ausgetauscht)? Oder mit einem ATMega1284 Daten per I2c/SPI ausgetauscht?

mfg
Hero_123
 
Hallo Hero
ja es stimmt, hatte das gleiche Problem schon mal. Hatte aber angenommen das ich es richtig eingstellt hatte. Hatte auch nach den letzten Kommentaren gesucht, aber leider das falsche genommen.
Das mit den 5 Boards ist einfach erklärt. Es gibt ein Start Up, das Encoder und andere Sachen die nicht I2C Bus tauglich sind auf kleine Platinen baut und einen kleinen Prozessor dazu programmiert damit sie am Bus zu betreiben sind. Leider geht das mit einem Pic und ob der Code frei ist kann ich nicht sagen. Bei diesem Board werden auch mehrere Adressen gesetzt um die Sachen universal zu verwenden. Da jeder Hersteller seine eigenen Grössen verwendet passt nichts zusammen.
Ein universell Board ist auch nicht schlecht, doch welche Funktionen sollen drauf? Wie soll das "umstecken" für eine andere Funktion erfolgen? Was passiert wenn ich es falsch stecke? Bei den Preisen für einen Ati 841 sollte es kein Problem sein.
Zur Anwendung. Wenn ich einen Schrittmotor betreiben will brauche ich einen entsprechenden IC mit I2C dazu. die sind leider am aussterben, weil es zu langsam ist (nach Angabe eines namhaften Herstellers). Mit SPI habe ich nichts gemacht, da es wahrscheinlich nicht so einfach ist 5 Module per Bus mit wenigen Kablen zu verbinden. Mache Aufbauten betreibe ich mit zu 15 Modulen.
Eine Kommunikation zwischen 2 Ati 841 kann nicht so erfolgen da beide dann Slave sind. Die Kommunikation zwischen einem Atmega 128 als Master und einem Ati 841 läuft ohne Probleme in beide Richtungen. Der Master kann somit die Steuerung von mehreren intellegenten Slaves übernehmen und sich auf das wichtigste beschränken.
Auch du kannst SMD mit 1,27 mm löten, mit entsprechendem Werkzeug geht das ohne Probleme. Habe ICs mit 80 Beinen (Bauart sorry ??) einlöten müssen, da lernt man sowas.
Es gibt auch ein "Masterboard" mit ganz anderen Funktionen, z.B. Servotester als Solo oder Bus mit Anzeigen zum Winkel und anderen, z.B. Radar.

Achim

PS: Bitte verwende das Wort Plamphlet nicht mehr. Es hat zu viele negative Bezüge. Darauf hatten wir uns schon mal geeinigt. Wenn dir meine Sachen nicht gefallen, brauchst du sie nicht zu lesen. Ansonsten habe ich auf einer anderen Seite jeden Monat ca. 2500 bis 3000 Downloads. Auch auf dieser Seite gibt es Beiträge mit ca. 200 Downloads.
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)