Hallo Alle Ich hätte da eine allgemeine Frage (und ja, ich habe zuvor das Forum durchforstet) Der ATmega8 hat 3 Ports mit insgesamt 23 Anschlüssen. Davon sind 2 (PB6 und PB7) für den Quarz oder dergleichen reserviert. PC0 bis PC5 sind für ADC gedacht, PC6 für Reset und PC7 gibt es nicht. Zur Info: bei meinem Projekt benötige ich neben dem Quarz noch 4 Displayleitungen (möchte ich an Port D anschliessen), 4 Eingänge für Taster (diese sollen/müssen an PC0 bis PC3) sowie zumindest 3 Ausgänge, welche dann letztendlich Lasten bis in den Kilowattbereich bei 400VAC schalten. Meine Frage jetzt: Abgesehen von Spezialfällen werden irgendwelche Anschlüsse bevorzugt eher für Ein- oder eher für Ausgänge verwendet. Oder ist das in weitem Rahmen egal?
@ Kurt W. (surfer2000at) >Meine Frage jetzt: Abgesehen von Spezialfällen werden irgendwelche >Anschlüsse bevorzugt eher für Ein- oder eher für Ausgänge verwendet. Nein. >Oder ist das in weitem Rahmen egal? Ja.
Hi >Davon sind 2 (PB6 und PB7) für den Quarz oder dergleichen reserviert. Reserviert nur wenn ein externer Quarz benutzt wird. PB7 ist frei nutzbar bei einem externer Takt. >PC0 bis PC5 sind für ADC gedacht Nur bei aktiviertem ADC und dann auch nur der durch ADMUX gewählt Kanal. >PC6 für Reset Wenn du nicht mit der RSTDISBL-Fuse spielst ist der Pin nur Reset. >Meine Frage jetzt: Abgesehen von Spezialfällen werden irgendwelche >Anschlüsse bevorzugt eher für Ein- oder eher für Ausgänge verwendet. Wenn du nicht die alternativen Pin-Funktionen brauchst, ist das egal. MfG Spess
Ich habe dazu noch eine Zusatzfrage! Den Atmega8 gibt es ja auch im TQFP-Gehäuse. In dieser Bauform hat er zwei zusätzliche ADC-Eingänge ( ADC6 und ADC7). Diese sind aber im Datenblatt garnicht dokumentiert! Man kann sie aber benutzen, Habe ich hier vor mir in Form des Conrad/Franzis Ping-Pong-Spiels. Hat dazu jemand nähere Informationen? Oder hab ich was im Datenblatt überlesen? Joachim
Kurt W. schrieb: > Meine Frage jetzt: Abgesehen von Spezialfällen werden irgendwelche > Anschlüsse bevorzugt eher für Ein- oder eher für Ausgänge verwendet. > Oder ist das in weitem Rahmen egal? Trotzdem lasse ich mir die UART Leitungen TxD und RxD erst mal frei, wenn ich sie nicht brauche und ich ansonsten keine andere Möglichkeit zur Debug-Unterstützung habe. An die ISP Leitungen kommen bevorzugt Taster drann. Würden da Relais drann hängen, dann würden die beim Programmieren des µC sonst mitklappern. Taster sind hingegen egal (ich drück sie einfach nicht, wenn der Brenner das Programm reinschiesst) bzw. bei LED ist es auch egal, wenn die mitblinken.
Hi
>Diese sind aber im Datenblatt garnicht dokumentiert!
Sind sie. Beschreibung zu ADMUX:
Bits 3:0 – MUX3:0: Analog Channel Selection Bits
MfG Spess
J. H. schrieb: > Den Atmega8 gibt es ja auch im TQFP-Gehäuse. > In dieser Bauform hat er zwei zusätzliche ADC-Eingänge ( ADC6 > und ADC7). Diese sind aber im Datenblatt garnicht dokumentiert! Was verstehst du unter 'nicht dokumentiert'. In der Pin-Zeichnung am Anfang des Datenblatts sind sie aufgeführt und ím Abschnitt über den ADC gibt es auch einen entsprechenden Eintrag bei den MUX-Bits. Was brauchst du noch?
Nun ja, ich hätte zumindest in den Registerdefinitionen einen Hinweis erwartet...das muß man sich wohl selbst zusammenreimen.
Was passiert z.B. wenn ich den PC6 als Analog-Eingang definiere (RESET abgeschaltet), dann hätte ich ja zwei ADC6-Eingänge?
Hi
>Was passiert z.B. wenn ich den PC6 als Analog-Eingang definiere
(RESET abgeschaltet), dann hätte ich ja zwei ADC6-Eingänge?, dann hätte
ich ja zwei ADC6-Eingänge?
PC6 hat keinen Analog-Eingang. ADC6 und ADC7 gehören zu keinem Port.
Bei abgeschaltetem RESET hast du ganz andere Probleme.
MfG Spess
Ahh, jetzt ist der Groschen gefallen! Danke für die gute Erklärung! Jo
Angehängte Dateien:
-
ports_v1.png
10 KB -
ports_v2.png
9,7 KB
Hall Allseits Also, so wie ich das als Ahnungsloser sehe, dürfte es doch nicht ganz egal sein, wie man die einzelnen PIN´s beschaltet. Ich habe jetzt hier nach einigen Überlegungen 2 Versionen ausgearbeitet. Kurz zur Erklärung: An XTAL 1,2 kommt ein Quarz dran, soviel ist fix. An den Ausgängen Pumpe1 bis Pumpe3 sowie Reseviert hängen Relais dran An TempFB und TempFS stehen Spannungen zw. 0 und 5V von Temperaturfühlern an, diese müssen also jedenfalls an einen ADC Benötigt werden tatsächlich 6 Taster, bei Version 1 dienen 2 als Reserve, allerdings müssen die Taster bei Version 1 an einen ADC Eingang. Welche Version würdet Ihr empfehlen, oder etwa ganz anders? Wobei, es sollte beim ATmega8 bleiben !!!
:
Bearbeitet durch User
Eindeutig Version 2 Da sind an den ISP Leitung keine kritischen Zusatzanbauten vorhanden, die irgendwas anstellen können, wenn der Programmer ein neues Programm in den µC überträgt. Die Taster dort tun keinem weh. Taster nach GND verschalten und einfach beim Programmiervorgang nicht drücken. Einzig das Display würde ich ein wenig anders anschliessen. D4 bis D7 vom LCD kommen an PD4 bis PD7, Enable und R/S belegen dann PD2 und PD3. Der Grund: ich hab eine gewisse Abneigung dagegen, 4 Datenleitungen die zusammengehören 'mitten in ein Byte reinzuschieben'. Die meisten Prozessoren haben einfache Möglichkeiten um mit Nibbles (also einem Halbbyte) wenigstens einfache Sachen machen zu können. Da muss dann effektiv nichts großartig durch dir Gegend geschoben werden. Warum soll ich das nicht nutzen, wenn alles was es dazu braucht das Verlegen von 4 Anschlüssen an eine bitmässig andere Position am Port ist
:
Bearbeitet durch User
V2, denn die Pumpen an den ISP Pins wären bei der Programmierung eher ungünstig ;-)
Danke für die Antworten @ Karl Heinz Die Argumentation klingt logisch .... @ Falk & Karl Heinz Die ISP Leitungen waren auch der Grund für diese Anordnung, aber: Wenn das ganze Projekt mal fertig sein sollte, so möchte ich den µC mittels Sockel auf eine eigens dafür entwichelte Platine montieren, an welcher er definitiv NIEMALS programmiert werden wird. Und nur auf dieser Platine befindet sich die Steuerelektronik für die Pumpenschützen. Der einzige Ort, wo er tatsächlich programmiert wird, ist mein STK500, und dort ist es mir eigentlich egal, ob da LED´s Flackern oder nicht. Gilt dies als Argument, eventuell doch Version 1 (eventuell mit Änderungen der Pinbelegungen für das Display) zu wählen?
Du hast nen ADC, spar die die ganzen Pins für die Tasten und schließe die über eine Widerstandsleiter an.
Wozu? Er hat genug Pins. Da sind sogar noch welche frei. Es geht nicht um die Fragestellung, wie er Pins frei kriegt. Sondern aus irgendeinem Grund, will er unbedingt seine Pumpen an den ISP Pins anschliessen. Da sag ich nur: wenns ihm Spass macht, dann soll er das halt machen. Nur - wozu frägt er dann eigentlich? Die spannende Frage bei der Pinzuteilung lautet ja nicht: sind die Pins unterschiedlich? Denn das sind sie nicht. Jeder einzelne der Input/Output Pins ist mit allen anderen identisch. Die spannende Frage lautet: welche Zweitfunktionen blockiere ich mir durch die Pins. In Version 1 bleiben frei * ICP1 - Input Capture Das ist zwar eine nette Funktion, ich sehe allerdings bei einer Pumpensteuerung auch in der Zukunft keine Erweiterung, die ICP benötigen würde * SCK SCK macht nur im Zusammenhang mit MISO/MOSI/SS Sinn. Da diese Pins blockiert sind, gibt es auch keinen Bedarf an SCK * T1 Ich wüsste nicht, wozu man den Timer 1 extern takten sollte. Ok. Man könnte eventuell die 50Hz der Netzspannung anhängen, um sich so eine einigermassen langzeitstabile Uhr zu bauen. Könnte man machen. * AIN1 Da AIN0 blockiert ist, macht ein frei gehaltener AIN1 nicht wirklich Sinn. Abgesehen davon - was will man bei einer Pumpensteuerung mit dem Analog Comperator? D.h. da bleiben Pins frei, mit denen man eigentlich in der Zweitfunktion in dieser Anwendung (ausser vielleicht T1) sowieso nicht viel anfangen kann. Layoutgründe auf der Platine? Ok, wäre möglich.
:
Bearbeitet durch User
Karl Heinz schrieb: > Wozu? > Er hat genug Pins. Da sind sogar noch welche frei. Ich empfinde das quasi so ein bisschen als Verschwendung von guten IO Pins (man verschwendet ja auch keine gute Butter!) :-) Auch kann man mit der R-Leiter wunderbar einen Tiefpaß bauen, dann kann man sich jeglichen Entprell-Code sparen.
:
Bearbeitet durch User
@ Marian B. (phiarc) >Ich empfinde das quasi so ein bisschen als Verschwendung von guten IO >Pins (man verschwendet ja auch keine gute Butter!) :-) Man kann's auch übertreiben. Für gesparte IOs gibt es kein Geld zurück. Klar, man könnte einen kleineren AVR nehmen, aber hier wirds arg Erbsenzählertum, wenn man bedenkt was ein ATmega8 kostet.
Marian B. schrieb: > Ich empfinde das quasi so ein bisschen als Verschwendung von guten IO > Pins (man verschwendet ja auch keine gute Butter!) :-) > Auch kann man mit der R-Leiter wunderbar einen Tiefpaß bauen, dann kann > man sich jeglichen Entprell-Code sparen. Der Entprellcode 'kostet' aber weniger als ein Tiefpass. Im Falle des PeDa Entprellcodes mach ich mir da noch nicht einmal Gedanken darüber. Dafür kriege ich aber 'gratis' so nette Dinge wie Autorepeat, was besonders bei Zahleneingabe eine wunderbare Sache ist. Das er die brauchen können wird, schliesse ich daraus, dass die Analogen Eingänge offenbar Temperaturen einlesen. Da würde ich mal raten, dass abhängig von Temperaturen ein paar Pumpen zu schalten sind. Und dafür will man meistens einstellbare Vergleichswerte.
interessante Antworten ... @ Karl Heinz > Da würde ich mal raten, dass abhängig von Temperaturen ein paar Pumpen zu > schalten sind. Und dafür will man meistens einstellbare Vergleichswerte Gut geraten, aber ist auch kein Geheimnis. Das ganze soll im Prinzip nichts anderes werden als eine simple Solarsteuerung mit Zusatzheizung. Ich weiß, gibts fertig zu kaufen - aber wo bleibt dann der Spaß? Und wie gesagt, ich habe noch nicht zuviel Ahnung von den µC´s und noch weniger von C oder C++ ... und im Laufe dieses Projekts kann ich da hoffentlich mit eurer Hilfe einiges lernen.
Apropos Entprellcode: Ursprünglich hatte ich eigentlich die Absicht, die Tasten elektronisch mit einer Art Monoflop zu entprellen .... was haltet Ihr davon? (Hintergrundgedanke: ich bin wie gesagt keine Programmierer, aber von "diskreter" Elektronik versteh ich ein bisserl was.)
Kurt W. schrieb: > Apropos Entprellcode: > > Ursprünglich hatte ich eigentlich die Absicht, die Tasten elektronisch > mit einer Art Monoflop zu entprellen .... was haltet Ihr davon? nicht viel. Tasten an einen(!) Port. Timer aufsetzen (braucht man meistens sowieso, zb für eine Uhr), in die ISR den PeDa Entprellcode einkopieren, die paar #define anpassen und im Hauptprogramm dort wo man es braucht get_keypress aufrufen. Fertig. Wenn man ein wenig geübt ist, dauert das keine 10 Minuten und man hat erstklassig entprellte Tasten, Tastendruckauswertung samt Gimmick wie Autorepeat am laufen. Alles andere ist in meinen Augen (mit der einen Ausnahme, wenn man in Pin-Not ist) vergebliche Liebesmühe, die der PeDa Lösung nicht das Wasser reichen kann. Weder in Punkto 'Einfachheit in der Verwendung', noch in den Punkten 'Zeitbedarf zum Einbau', 'Zuverlässigkeit', 'Kosten', 'Zuverlässigkeit' bzw. 'Möglichkeiten'.
:
Bearbeitet durch User
Danke erstmal für die vielen Infos. Das mit den Ein-und Ausgängen ist mehr oder minder gelöst. Aber jetzt habe ich das nächste Problem. Ich habe in letzter Zeit viele Beiträge zu der Genauigkeit der Uhren mit Quarz und AVR durchgelesen. Irgendwann bin ich zu dem Schluss gekommen, dass eine direkt in den ATMega8 integrierte Uhr nicht wirklich das Wahre ist. Das Hauptproblem ist dabei Stromausfall, aus welchen Gründen auch immer - ich sage nur Steckerziehen oder Winterabschaltung. Eine Pufferbatterie würde eine Zeit lang reichen, aber eben nur eine Zeit lang, sicher nicht ein paar Monate - (bitte jetzt nicht mit Autoakkus auf mich werfen). Da eine Synchronisierung mit DCF ausfällt, habe ich mir gedacht, ob ich das mit einem RTC-Modul wie dem DS1307 lösen könnte. Das Ding könnte mit einer CR2032 Lithiumbatterie doch einige Jahre betrieben werden. Allerdings stellt sich mir jetzt die Frage, ob ich da mit dem ATMega8 wirklich noch weiterkomme. An Zeit-Auswertung benötige ich eigentlich nur Minuten, Stunden und Wochentage - mehr ist vollkommen sinnlos. Was meint ihr dazu ? // Erläuterungen zu meinem Vorhaben unter [[Beitrag "Pumpensteuerung"]]
Kurt W. schrieb: > ... habe ich mir gedacht, ob ich > das mit einem RTC-Modul wie dem DS1307 lösen könnte. ... > Allerdings stellt sich mir jetzt die Frage, ob ich da mit dem ATMega8 > wirklich noch weiterkomme. Wieso nicht? RTC sprechen typischerweise I2C aka TWI. Das könnten die AVRs teilweise in Hardware, immer in Software. So lange du noch 2 freie Pins hast, geht das. XL
Thread beobachten
Seitenaufteilung abschaltenBitte 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.