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.
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
