Hallo, meine erstes AVR-Projekt soll ein kleiner LichtWecker sein. Das Herzstück soll der ATMEGA328P sein der das Display (überlege ein I2C adapter zu verwenden), das RGB-STRIPE (PWM), evtl. eine Halogen-Lampe (12v PWM) ansteuert. Am Input hängen ein Drehencoder mit Button, die RTC, ein Fotowiderstand und ein Bluetooth-Module um später alles per Handy steuern zu können. Für das Licht sollen verschiedene Modi implementiert werden. RGB Fade Modi, Weck Modi und evtl. Temperatur zu RGB-Licht Jetzt habe ich das mal so Aufgebaut. Die beiden Interrupt Pins sind für den Button und den Encoder. Ich höffe die Verteilung der LCD Pins auf verschiedene Register ist nicht problematisch. Nun würde ich mich freuen wenn ihr mal einen Blick drauf werft.
EHobbyist schrieb: > Ich höffe die Verteilung der LCD Pins auf > verschiedene Register ist nicht problematisch. Ich würde zumindest D4-D7 fortlaufend auf einen Port legen, vorzugsweise 0-3 oder 4-7. Sonst artet jede Ausgabe in eine reine Bitschubserei aus. Die Steuerleitungen werden eh einzeln angesprochen, die kannst Du dahin legen wo noch Platz ist. Für den Drehencoder ist es auch schöner, wenn er an einem Port liegt. Es fehlen mindestens noch: 100nF zwischen 7 und 8 100nF zwischen 20 und 22 Aref (21) gehört nicht an Vcc sondern über einen Kondensator an GND, hier gehen aus 100nF Die Fets für den Stripe können noch Pulldowns am Gate vertragen.
Zusätzlich zu Olivers Anmerkungen: Die MOSFETs sind falsch. Du brauchst hier N-NOSFETS. Der ISP-Anschluss fehlt.
EHobbyist schrieb: > Die beiden Interrupt Pins sind für den Button und den Encoder. Schalter per Interrupt abfragen? Vergiß nicht, dass Schalter prellen. Es soll doch wohl reichen, wenn du alle paar Millisekunden mal timergesteuert die Stellung abfragst.
Ich habe nun die LCD-Data-Lines auf ein PORT gehängt, die Kondensatoren, Pulldowns hinzugefügt und die MOSFETS ausgetauscht und den Button auf einen 'normalen' Pin gelegt und den ISP-Connector integriert. Nun habe ich das Problem das ich keinen freien PWM Pin für den Halogentreiber mehr habe, da ich auch noch den Encoder auf nun einem PORT habe. Ich hoffe so wird es funktionieren. Vielen Dank für eure Antworten
Der Drehencoder braucht entweder PullDown-Widerstände oder Du schaltest gegen Masse und benutzt die internen PullUps, das währe üblicher.
Danke für den Tip. Ich werde die Variante mit den internen Pullups verwenden. Ist es sinnvoller den Halogentreiber per SoftPWM an Pin 14 anzusteuern oder sollte ich lieber den Drehencoder auf 2 PORTs zu verteilen und dann den Halogentreiber an den PWM-Pin 5 hängen?
Tu dir einen Gefallen und nimm statt dem ATmega8 eine neueres Modell, vorzugsweise einen ATmega328. Bei der Belegung der μC-Anschlüsse kümmerst du dich erst um spezielle Dinge, für die es keine Alternativen gibt, dann hin zu den Dingen, bei denen es keine Rolle spielt, wo sie angeschlossen werden. In deinem Fall: ISP Quarz (XTAL1, XTAL2) RTC (SDA, SCL) Bluetooth-Modul (RXD, TXD) MOSFETs (OCxx) LCD (Datenleitungen auf einen Port, z.B. PA0...PA3) Encoder-Phasen Encoder-Taster DS18B20 Die ISP-Anschlüsse kanst du auch für andere Zwecke verwenden, aber "E" vom LCD ist keine gute Idee.
EHobbyist schrieb: > Das > Herzstück soll der ATMEGA328P sein Konrad S. schrieb: > Tu dir einen Gefallen und nimm statt dem ATmega8 eine neueres Modell, > vorzugsweise einen ATmega328. Guten Morgen Konrad ;)
Mike schrieb: > Wozu dann der ATmega8 im Schaltplan? vermutlich weil der 328er bei EAGLE nicht in den mitgelieferten Bibliotheken dabei ist. Er hätte ihn natürlich im Schaltplan umbenennen können
chris schrieb: > Guten Morgen Konrad ;) OK, ich leg mich wieder hin! ;-) Ich habe nur noch auf den Schaltplan geschaut. Aber mit ATmega328 ergibt das hier überhaupt keinen Sinn: EHobbyist schrieb: > Nun habe > ich das Problem das ich keinen freien PWM Pin für den Halogentreiber > mehr habe Es sei denn, der TO hat sich vom Schaltplan selbst in die Irre führen lassen. :-\
Ich habe nun den hoffentlich den richtigen 328P-PU zusammengebastel (sorry für die Irritierung), RTC, LCD und Lampentreiber durch Pin-Header erstetzt, da diese Module bereits fertig sind und einfach angesteckt werden sollen. Sehe aber immernoch keinen freien PWM für den Halogentreiber ;-(. Und eine schöne Alternative für Display-Enabled habe ich auch noch nicht. Wahrscheinlich muss ich mir wohl noch ein Serial-LCD Adapter besorgen.
Du könntest Dir einen oder gar zwei Pins freischaufeln, wenn Du auf die RTC verzichtest, das kann der ATmega328 auch selber machen: An die XTAL Anschlüsse kommt der 32,768 kHz Uhrenquarz (Achtung, die Kondenstoren sind dann kleiner, 10pF oder weniger), der Controller muß dann mit dem internen 8MHz Oszillator laufen, was für diese Anwendung reichen sollte, Timer 2 wird so konfiguriert, daß er vom Uhrenquarz getaktet wird. Als PWM-Quellen solltest Du dann natürlich Timer 0 und Timer 1 nutzen, sind ja 4 PWM-Ausgänge. Nachteil der Lösung ist, daß Du da mehr Software machen musst. Die Uhrzeit, und das Datum musst Du dann selbst verwalten. Wenn Du den Controller in den Sleep-Mode schickst, musst Du dafür sorgen, daß Timer 2 weiterläuft, und bei Timer-Overflow den Controller weckt, damit Der die Uhrzeit aktualisieren kann. Wenn Du eine Gangreserve per Batterie haben willst (Ich sehe die CR2032 im Schaltplan), musst Du den Conroller weiterversorgen, z.B. indem Batterie und normale Versorgung über zwei Dioden zusammen auf den Controller-Versorgungspin geführt werden. Dann muß der Conroller aber, bei Ausfall der Hauptversorgung runtergetaktet werden, da er bei 8Mhz nicht mehr stabil läuft, wenn die CR2032 nicht mehr ganz frisch ist. Mann könnte ihn aber auch gleich generell bei 4Mhz laufen lassen, dann reichen 1,8V für sicheren Betrieb. Wenn man, wie bei Dir, den USART nutzen will muß man aber aufpassen, wenn man den internen 8MHz Oszillator benutzt, er ist recht ungenau. Durch Vergleich mit dem Uhrenquarz lässt sich das aber ausregeln, es gibt das OSCCAL – Oscillator Calibration Register, darüber lässt sich die Frequenz verändern, was die Software automatisch machen kann. Wie schnell ist die serielle Datenübertragung zum Bluetooth-Modul eigentlich, da hätte man bei 4MHz nicht mehr viel Spielraum. Mit freundlichem Gruß - Martin
Konrad S. schrieb: > Bei der Belegung der μC-Anschlüsse kümmerst du dich erst um spezielle > Dinge, für die es keine Alternativen gibt, dann hin zu den Dingen, bei > denen es keine Rolle spielt, wo sie angeschlossen werden. In deinem > Fall: > > ISP > Quarz (XTAL1, XTAL2) > RTC (SDA, SCL) > Bluetooth-Modul (RXD, TXD) > MOSFETs (OCxx) > LCD (Datenleitungen auf einen Port, z.B. PA0...PA3) > Encoder-Phasen > Encoder-Taster > DS18B20 > > Die ISP-Anschlüsse kanst du auch für andere Zwecke verwenden, aber "E" > vom LCD ist keine gute Idee. Namen sind zwar Schall und Rauch, sagt man, aber alle Pins des ATmega328 mit einem OCxx sind - wenn du es willst - PWM-Ausgänge, zwei davon machen auch 16-Bit-PWM. Die nochmal zitierte Liste habe ich nicht nur so zum Spaß hingeschrieben. Wenn du ein Problem mit der Belegung der Pins hast, dann nimm von unten her kommend alles aus der Schaltung raus, bis das Problem auch raus ist (also DS18B20 bis einschließlich MOSFETs; am Ende der Liste fehlt übrigens noch der PH1). Dann schließt du die Teile der Reihe nach von oben her kommend wieder an, jeweils unter Berücksichtigung evtl. einzuhaltender Beschränkungen (z.B. ¨E¨ vom LCD nicht auf einem ISP-Pin). Besondere Aufmerksamkeit brauchen die ISP-Pins, weil sie auch mit anderen Funktionen belegt werden können, möglichst aber so, dass während der Programmierung keine Verbindungen getrennt werden müssen, um Fehlfunktionen oder unerwünschtes Verhalten zu verhindern (z.B. Aktivierung des LCD oder der LED-Stripes).
Martin hat zwar recht, aber ich finde, es sind genügend Pins da. Ach ja, ist das an Pin 15 vom LCD die Hintergrundbeleuchtung? Nicht ohne Vorwiderstand!
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.