Hallo, ich baue gerade mit einem Atmega8 eine Pumpensteuerung. Er soll 3 Temperaturwerte einlesen (über ADC) und diese 3 Werte auf 6 numerischen LED-Anzeigen (8 Anschlüsse jeweils + 1 Kathode). 1) Schafft man die Anzeige flimmerfrei (dachte so min. 40/50Hz?) anzusteuern (mit C als Programmiersprache) bei 8MHz ohne Flimmern? Es müssen ja auch noch parallel die 3 Temperaturwerte ausgelesen und evtl. auf Tastendruck reagiert werden. Falls nein wie sieht es bei 16Mhz aus? 2) Für Messungen mit ADC ist es besser einen Quarz zu verwenden statt der inneren Veriante mit 8MHz? Die eingebaute Generator(?) soll ja nicht so genau sein? 3) Ich brauche nur 3 der 6 möglichen ADC PINs. Kann man die restlichen auch ohne Probleme für nicht ADC-Dinge verwenden? Ist übrigens mein erstes "Projekt" mit einen Mikrocontroller. Ich bedanke mich schon mal. MfG Oliver
1.) Ja, wobei eine höhere Taktfrequenz logischerweise Reserven schafft, es sei denn du zielst auf einen Batteriebetrieb ab. 2.) Das ist egal. 3.) Ja.
Da Du für die LED-Anzeigen sowieso Porterweiterungen brauchst, nimm gleich Treiber mit Latches (z.B. 4543 o.ä.). Dann erledigt sich das Flimmern von selbst. Du brauchst dann nur für jedes Segment eine Steuerleitung und einmal vier Datenleitungen (macht zusammen 10 µC-Pins). Die nicht verwendeten Pins von Port C kannst Du selbstverständlich für andere Zwecke nutzen, Du solltest aber auf jeden Fall drauf achten, dass, wenn Du die Pins als Ausgänge benutzt, während einer laufenden Wandlung nicht geschaltet wird, da sonst das Wandlungsergebnis schaden nehmen kann. Für den ADC reicht der interne Oszillator i.d.R. aus. Wenn Du keine serielle asynchrone Übertragung implementieren willst, geht das.
Hallo, vielen Dank ihr beiden. @Alex Habe ein Netzteil - also Stromverbrauch egal. @johnny.m Wieso brauche ich eine Porterweiterung? 8+6 Ausgänge zum Ansteuern der LEDs sollten doch ausreichen? Oder habe ich da was übersehen?
Es gibt übrigens einen Dekoder-Baustein mit integriertem Treiber (74LS47) mit dem man BCD-Code in 7-Segmentcode umwandeln kann. Dass ist für den Anfang leichter als die Daten über I^2C oder andere Datenleitungen zu senden. Das Flimmern bekommt man erst weck wenn man schneller als 100 bis 200 Herz multiplext. Dabei muß man darauf achten dass je schneller gemultiplext wird, desto weniger flimmert es. Und je mehr Anzeigen gemultiplext werden, desto dunkler wird die Anzeige. Für normale Themperaturerfassung und die Anzeige reichen sogar 1MHz aus. Für die Genauigkeit der Messwerte ist es wichtiger eine konstante, exakt bekannte Versorgungsspannung als Reverenzspannung zu haben als einen exakten Takt. Man kann die nichtbenutzten ADV-Pins mit anderen Aufgaben betrauen, man muß aber darauf achten dass nicht geschaltet wird während die Spannung gemessen wird. Wenn du Pin's sparen willst, aber keine busgesteuerten Anzeige-Bausteine verwenden willst, dann kannst du mit einem Demux (Z.B. 74LS138) mehrere Anzeigeelemente mit wenigen Pins steuern. Beim 74LS138 kannst du mit 3 Steuerpins und 4 Datenpins über 8 Transistoren bis zu 8 7-Segmentanzeigen ansteuern. Dafür benötigt man übrigens nur einen 74LS47 Dekoderbaustein.
Wenn man die 7-Segmentanzeige mit 74LS138ern Multiplext benötigt man 7 Pins für 8 Anzeigeelemente. Wenn man weitere 8 Anzeigeelemente seriell dazumultiplext benötigt man 8 Pins für die Anzeige, und wenn man die Anzeigen parallel multiplext benötigt man 11 Pins für 16 Anzeigeelemente. Das müsste eigentlich ausreichen.
Mal nachgerechnet: 6 Anzeigen á 8 Pins (7 Segmente + 1 Dezimalpunkt) = 14 Pins 3 ADC-Eingänge = 3 Pins 4-5 Pins, die mit Stromversorgung zutun haben = 5 Pins (worstcase) 1 Reset-pin = 1 Pin Sind insgesamt 23 Pins. Der Mega8 hat 28 Pins... Da braucht man solches Zeug wie TTL-Decoder (die möglicherweise abgekündigt sind) nicht verwenden. 6 Segmente bei 120Hz Bildwiederhol-Frequenz ergibt für jedes Segment eine Leuchtdauer von ca. 1,4ms. Wenn man wirklich mehr Pins am Controller braucht, nimmt man halt einen grösseren (Mega16 o.dergl.). Für den Einstieg ein nettes Projekt.
Hallo, ich habe hier noch 3er-Siebensegmentanzeigen mit gemeinsamen Anschluss, ich würde Dir einen Decoder-Chip empfehlen, z.B. ICM7218 (müsste passen, zweifel) empfehlen, der kann 8 Anzeigen selbstständig multiplexen, ist zwar etwas Programmiererei, aber das soll es ja auch und Du brauchst meine ich, nur 4 I/Os. Gruss A. Arndt
Ich würde 100Hz Anzeigefrequenz nehmen, das mancht dann bei 6 Digits 600Hz Interruptfrequenz. Bei 1MHz CPU-Takt sind das 1666 Zyklen Zeit zwischen 2 Interrupts, das reicht dicke. Die 7-segment dekodierten Bitmuster werden in 6 Bytes abgelegt und dann im Timerinterrupt immer das nächsten Byte ausgegeben, fertig. Die Digits (common Anode) treibt man mit je einem npn-Transistor (BC368) als Emitterfolger, die Segmente können über 8 Widerstände (120R) direkt an den AVR. Peter P.S.: Ich finde es schon komisch, wenn andere einem uralt TTL-Chips oder teure Spezialchips einreden wollen, ohne das man Probleme mit der Pinzahl geäußert hat.
>P.S.: >Ich finde es schon komisch, wenn andere einem uralt TTL-Chips oder >teure Spezialchips einreden wollen, ohne das man Probleme mit der >Pinzahl geäußert hat. Mein Reden!
Hallo, vielen Dank für die zahlreichen Antworten. Jetzt bin ich ja beruhigt. Wenn selbst bei 1MHz noch soviel zeitlicher Freiraum ist. Hatte schon vorm geistigen Auge: Kühlkörper auf µC und @20MHz laufen lassen. gg @Peter Dannegger: Sind 120 Ohm nicht ein bisschen zu wenig? Das wären ja 25mA. Ich dachte man darf den Atmega nur mit 20mA pro Port belasten? Meine Anzeigenelemente haben übrigens eine gemeinsame Kathode. Aber das sollte ja keine Rolle spielen. Man kann ja bestimmt den Port belasten wenn er auf 5V ist ebenso wie auf 0V. Zum Verständnis: Ich stelle mir das so vor das wenn man den jeweiligen Pin auf 0V setzt das ein NPN-Transistor/MOSFET durchsteuert (Emitter auf Masse). Bei 5V macht das dann ein PNP-Transistor/MOSFET (Emitter auf +5V) (bzw. wieder ein MOSFET). Bin jetzt nicht so der Crack in Sachen Elektronik (sagen wir mal gute Grundkenntnisse). Und noch eine Frage: Der dritte Sensor (übrigens ein KTY 81-110) soll geschätzte 30-40 Meter entfernt betrieben werden. Angeschlossen über ein im Boden verlegtes 20-adriges Flachbandkabel. Da werde ich mit der Methode KTY mit 2,7k Widerstand in Reihe schlaten vermutlich wenig Erfolg haben? Sind dann bestimmt Störungen auf dem Kabel. Und noch eine (die letzte - will ja nun nicht zu verfressen sein). Wie würdet ihr über weite Entfernungen Daten übertragen - so ~150m. Die Datenrate muss nicht besonders hoch sein - vielleicht ein KBit. Ich hatte mir das so gedacht an einen Pin einen Transistor zu hängen wo am anderen Ende der langen Leitung ein so um die 100 Ohm Widerstand als Last hängt. Da haben doch dann Störungen keine Chance? Die integrierten Lösungen wie UART oder I²C gehen ja nur für kurze Strecken. Oder kann man das "aufbohren"? Nochmals vielen Dank!! Hoffe ich kann dann später auch mal so gut weiterhelfen. MfG Oliver
@Rahul: Ich kann Deiner Rechnung nicht wirklich folgen: 6 Anzeigen á 8 Pins machen bei mir schon 48 Pins - also wirst Du wohl nicht ums multiplexen herumkommen. Du kannst natürlich auf Controller mit mehr Pins ausweichen, aber ist es nicht teurer, den größeren Controller zu nehmen als ein spezielles IC? Wie wäre es denn, statt der 6 Siebensegment-Anzeigen einfach ein kleines Text-LCD zu nehmen, die lassen sich problemlos mit 7 Pins ansteuern...
Also ich kann Rahuls Rechnung sehr gut folgen! Er geht schon von einem Multiplexbetrieb aus. Siehe seine Bemerkung zur Wiederholfrequenz. 7 Segmente + 6 Steuerleitungen (Common Cathode oder Common Anode)+ 1 Dezipoint= 14 Leitungen (Portpins). Warum LCD ? Er hat sich bei der Auswahl wohl was gedacht (z.b. grössere Ziffern).
Wieso wollen hier eigeltich (fast) alle die Anzeigen statisch realisieren? Jörg hat mich richtig verstanden. >Warum LCD ? Er hat sich bei der Auswahl wohl was gedacht (z.b. >grössere Ziffern). Bessere Ablesbarkeit im Dunklen und auf grössere Entfernung kommt auch noch dazu. Ausserdem hat der mega8 für diese Aufgabe genug Reserven, so dass man nicht noch einen Controller braucht (um ein Punkt-Mtrix-LCD zu betreiben fehlt ihm wiederum Kapazität...). Mal sehen, ob ich mir so noch ne Digital-Uhr bastel...
Hallo, Habe die Segmentanzeigen genommen weil ich diese da hatte (von TV/Receiver mal ausgeschlachtet). Ich habe hier auch noch 2 4x20 LC-Displays liegen - wollte aber mal Segmentanzeigen ansteuern - auch aus Interesse wegen. Habe mal ein Bild gemacht und angehangen. Habe jetzt soweit alles fertig zusammen gelötet. Mit meiner Routine zum Anzeigen (erst einmal testweise in einer Endlosschleife) komme ich bei 1MHz CPU-Takt auf nur 131Hz Anzeigenfrequenz (es wird nichts weiter gemacht). Ich nehme mal an das mein Code nicht so optimal ist. Naja mit 1 MHz kann man auch nicht so programmieren wie wenn man was schreibt für 1 GHz. Hatte das so gemacht (D_XX ist nur eine define auf welchen PIN das Segment sitzt): inline void set_digit(int8_t seg,int8_t digit) { static uint8_t digits[] = { /* 0 */ D_ALL & ~D_M, /* 1 */ D_TR | D_BR, /* 2 */ D_ALL & ~(D_TL | D_BR), /* 3 */ D_ALL & ~(D_TL | D_BL), /* 4 */ D_ALL & ~(D_T | D_BL | D_B), /* 5 */ D_ALL & ~(D_TR | D_BL), /* 6 */ D_ALL & ~D_TR, /* 7 */ D_T | D_TR | D_BR, /* 8 */ D_ALL, /* 9 */ D_ALL & ~D_BL, /* X */ D_ALL & ~(D_T | D_B) }; SEG_PORT = ((SEG_PORT & ~0x3F) | seg | (SEG_PORT & (1 << 6 | 1 << 7))); D_PORT = digits[digit >= 0 && digit <= 9 ? digit : 11]; } Was haltet ihr davon?
Wegen der Pinanzahl: 23 Ein/Ausgänge habe ich zur Verfügung. 14 sind benutzt für die Anzeige und 3 für die Sensoren. Hab so noch 6 übrig.
Die Routine kann man leider nicht übersetzen, da ja haufenweise defines fehlen, aber vom Gefühl her sollte sie nicht sonderlich Zeit kosten. Die 130Hz müssen also ne andere Ursache haben. Um zu prüfen, ob ein Index innerhalb einer Tabelle liegt, nehme ich lieber den sizeof() Operator, dann kann man die Tabelle später erweitern und außerdem bin ich zu faul zum abzählen. Hier mal ein komplettes Multiplex Beispiel von mir: http://www.mikrocontroller.net/forum/read-4-210743.html#new Peter
Mir fällt gerade ein das nur 4 übrig sind. 2 werden noch für die Relais gebraucht.
Hallo, wenn man ausgeschlafen ist findet man seine Fehler auch schneller g. Ich hatte ursprünglich in der while-Schleife eine for-Schleife drin die die Zahlen von 0-9 hochgezählt hat (um zu schauen ob alles stimmt). Ich hatte also jedes mal das Setzen der Pins pro Display 10x wiederholt. Jetzt sind es 1,2kHz - das sollte jetzt so passsen (von der Geschwindigkeit her). Also genügend Freiraum für anderes. Hinter den defines befinden sich wie gesagt nur die Zahl welcher Pin. Nochmals danke an alle!!! ----- #define PIN0 (1<<0) #define PIN1 (1<<1) #define PIN2 (1<<2) #define PIN3 (1<<3) #define PIN4 (1<<4) #define PIN5 (1<<5) #define PIN6 (1<<6) #define PIN7 (1<<7) #define D_PORT PORTB #define SEG_PORT PORTD // T=Top L=Left R=Right B=Bottom M=Middle PT=Point #define D_TL PIN0 #define D_T PIN1 #define D_TR PIN2 #define D_BL PIN3 #define D_B PIN4 #define D_M PIN5 #define D_PT PIN6 #define D_BR PIN7 #define D_ALL (0xff & ~D_PT) #define D_NONE 0 -----
Hallo, jetzt haut nun soweit alles hin. Die Schaltung liegt schon in der Heizung und schaltet brav die Pumpen. Was noch fehlt ist der 3. Sensor, welcher ca. 30-40m entfernt liegt. Ich hoffe mal das es da keine Störungen auf der Leitung gibt. Nochmals Danke! MfG Oliver
Wenn du die Möglichkeit hat, 4 Adern zu verwenden, solltest du den 4-Leiter-Betrieb nutzen (google, wikipedia, Elektronik-/Messtechnik-Buch...). In der Software solltest du dann irgendwie die Messwerte mitteln, um Störungen "herauszufiltern".
Wenn du so große stecken überwinden musst empfehle ich dir digitale tempsensoren. z.b. DS1820 kostet zwar n bisschen mehr aber du kannst die leitungen ziemlich lang machen, wenn du den sensor entsprechend langsam ausliest. (laut dem großen C gehen sogar 100m)
die digitalen Signale kannst du noch weiter schicken mit hilfe eines Schmittrigger
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.