Hi, ich programmiere den Mega8 in Pascal und benutzte dazu den AVRco von E-Lab (die Mega8-Spezialversion von www.embedit.de ). Bei dieser Umgebung bleibt für ein LCDisplay faktisch nur Port D. Da ich für mein nächstes Projekt (zur Kommunikation mit einem PC) jedoch auch den UART brauche (PD 0/1), meine Fragen: hat hier jemand pos. oder neg. Erfahrungen bzgl. einer solchen Doppelnutzung ? Wenn ich das Manual richtig verstehe, brauche ich nur RXEN/TXEN in UCSRB entsprechend zu setzten (enable bei ser. Kommunikation, disable bei LCD-Ausgabe). PC-seitig wird das Ganze letztlich wohl nicht in meine Verantwortung fallen. Deshalb sollte es auf dieser Seite möglichst einfach sein. Also möglichst keine Try-and-Error oder Timeout Geschichten. Vielleicht wäre es deshalb auch ganz sinnvoll, mit freien Ports einen RTS/CTS Handshake vorzusehen (klar, mit Pegelwandlung). Oder DSR/DTR ? Hat da jemand Erfahrung ? Schöne Grüße Gunter p.s.: falls es hilft - es geht ganz grob um Folgendes: der User kann auf dem LCD (und einem weiteren Device) Texte (aus dem EEPROM) anzeigen lassen. Diese Texte sollen von einem PC aus ggf. editiert werden können.
Die Uart-Pins kannst Du nicht doppelt nutzen. Aber Du kannst ein LCD mit nur 3 Drähten ansteuern: http://www.mikrocontroller.net/forum/read-4-23408.html Peter
Hi Peter, Danke für Deine Antwort ! >Aber Du kannst ein LCD mit nur 3 Drähten ansteuern da ich gerne den AVRco benutzen möchte, versuche ich mit der 7-Draht Lösung (und den vorgefertigten Routinen) weiter zu kommen. anyway: >Die Uart-Pins kannst Du nicht doppelt nutzen ich vermute, Du meinst, weil sonst der V24-"Partner" auch alle LCD-Ausgaben mitkriegt ? Die Gefahr besteht jedoch nicht - ich muß doch etwas weiter ins Detail gehen. Da ich min. 2 ser. Verbindungen brauche (1*PC, 1*externes Display), werde ich entweder sowas wie MAX232 mit Enable (wenn's das gibt) oder TriState-Buffer einsetzen. Somit stelle ich sicher, daß an der ser. SS nur dann Signale anliegen, wenn diese auch gemeint ist. Ansonsten ist mein Nachtrag (trotz zweimaligem Versuch) nicht im Forum angekommen: es handelt sich um ein Text-LCD und Port D0..3 sind die Datenleitungen (4-Bit-Mode). Ein Toggle der Steuerleitungen des LCD kann also nicht norkommen. Any Ideas, wie unter WIN32 ein "leichtes" Ansteuern der ser. SS ermöglicht werden kann (RTS/CTS und/oder DTR/DSR) ? Gruß Gunter
Du kannst auf allen Pins des LCD beliebige Signale anlegen, solange der E-pin auf Low ist. Nur bei E = 1 muüssen alle andern stabil sein. Deshalb funktioniert meine 74HC164-Lösung auch. Das Umschalten der UART stelle ich mir nicht einfach vor. du must ja irgendwie sicherstellen, daß nicht einer sendet, der garnicht durchgeschaltet ist. D.h. die TX-Leitung kann man umschalten, aber die RX-Leitung kann Probleme machen. Ich würde daher eine UART ständig anschließen, und die langsamere in Software machen. Was ist an dem "AVRco" denn so kompliziert, daß es sich nicht mit meinen Routinen verträgt ? Man muß doch auch fremden Code einbinden können. Peter
Software-UART - geht, aber man muß höllisch mit dem Timing aufpassen, über den Daumen gepeilt ist bei 9600Baud Schluss, Programmierung ist bei Duplex-Verkehr schon recht kompliziert, ob es mit einer Hochsprache überhaupt etwas wird??? Aber ne andere Lösung: Maxim hat ein UART mit SPI-Schnittstelle (MAX31xx) im Programm, astrein das Teil.
Sinnvollerweise sollte man für diese Aufgabe einen MEGA161/162 einsetzen. Dieser hat dann 2 Hardware UARTs und ausreichen I/O. Diese Lösung dürfte in der Summe die preiswerter und eleganter sein. Allerdings liegen natürlich beim Pascal Compiler ca. 450 Euro Preisdifferenz. Für ein Hobbyprojekt schon ganz schön heftig.
Hi, >Du kannst auf allen Pins des LCD beliebige Signale anlegen, solange der E-pin auf Low ist. OK. So hatte ich's auch verstanden. Danke für die Bestätigung. > Das Umschalten der UART ..., daß nicht einer sendet, der garnicht durchgeschaltet ist. yep ! Genau deshalb meine 2. Frage, ob es hier vielleicht jemand gibt, der unter Win32 (NT/2000) schon mal mit der ser.SS kommuniziert hat und mir sagen kann, ob es da vielleicht sowas wie eine Standard-Library / DLL (?) gibt und/oder ob praktisch immer ein Handshake unterstützt wird. Vielleicht sollte ich deshalb mal einen neuen Thread mit entspr. Titel aufmachen. >Ich würde daher eine UART ständig anschließen, und die langsamere in Software machen. wär mir schon lieber, wenn ich mich um das dazu notwendige Timing drücken könnte .... Ob das ext. Display überhaupt sendet, weiß ich gar nicht. Wenn, kann's nicht viel sein. Vielleicht "ACK" oder so. Werde ich mir am Montag mal ansehen. Würde die Sache bestimmt einfacher machen, wenn ich nur den XMit umschalten müßte. > Was ist an dem "AVRco" denn so kompliziert, daß es sich nicht mit meinen Routinen verträgt ? > Man muß doch auch fremden Code einbinden können. Klar geht das. Aber wie gesagt - ich versuche bei diesem Projekt möglichst wenig "Baustellen" zu haben und soweit möglich mit den schon getesteten Modulen auszukommen. Aber ich werde Deine 3-Draht Lösung sicher mal probieren Nur möchte ich dann den (im Sinne des "AVRco") "sauberen" Weg gehen und einen speziellen "Device Treiber" schreiben. Das wird dann schon etwas aufwändiger. Alleine schon, daß ich nur im Header der Source die Taktfrequenz angebe und sich das Timing des LCD-Treibers dann anpaßt. So macht's die mitgelieferte 7-Draht Lösung und so komfortabel stelle ich mir auch meinen User-defined Device Treiber vor ... Gunter
"... im Header der Source die Taktfrequenz angebe ..." Wenn Du Dir meine Sourcen ansiehst, steht da irgendwo .equ xtal = 1200000 ;1.2MHz Und alle Delayzeiten werden damit automatisch berechnet. Allerdings funktioniert das nicht für jede Frequenz. Wenn Du z.B. einen ATTINY26 mit 16MHz nimmst, dürfte der Delaywert nicht mehr in ein 8Bit Register passen. Die Delayroutine müßte man dann für 16Bit Werte aufbohren. Etwas Handarbeit ist also immer nötig. Eine Universalbibliothek, die sich immer auch an die extremsten Anforderungen anpaßt, ist bei Hardwarezugriffen nie möglich. Deshalb nehme ich nie vorgefertigte Bibliotheken als Black-Box, sondern höchstens solche, die im Quelltext vorliegen. D.h. ich kann prüfen, ob sie mit der geänderten Pinbelegung, AVR-Typ, Taktfrequenz usw. auch klarkommen und gegebenenfalls selbst Hand anlegen. Besonders wichtig ist das, wenn Bibliotheksfunktionen einen Timer mitbenutzen wollen. Man kann ja im Timerinterrupt mehrere Funktionen aufrufen. Aber nur, wenn man auch kontrollieren kann, daß die sich nicht gegenseitig auf die Füße treten. Peter
Hi, @crazy horse "..MAX31xx.." Danke. Werde ich nächste Woche (habe dann wieder einen DSL-Zugang) mal stöbern. @mikki "Allerdings liegen natürlich beim Pascal Compiler ca. 450 Euro Preisdifferenz. Für ein Hobbyprojekt schon ganz schön heftig" das hast Du aber sehr "vorsichtig" formuliert ;-) Für mich sind 450 Euro nicht heftig - das ist ein K.O.-Kriterium. 'ne non-Profit-Version, analog Eagle, wäre da wirklich wünschenswert. Gunter
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.