in lcd-routines pins anpassen

[S. L. (goldencue)]

hallo zusammen!

meine erste frage heut mal an die gemeinschaft. bin recht neu, versuch 
aber mal nicht dumm und nervend zu klingen. kurz also zum system:

atmega8
stk500
hd4078..blubb.display
pins uC für lcd:
pd2 = rs
pd3 = e
pd4 - pd7 sind datenpins zu d4 - d7

verwende u.a. lcd-routines in c mit avr-studio.

jetzt meine frage: wie kann ich in der lcd-routines.c ( oder .h (was ich 
nicht glaube)) die datenbins anpassen?

wenn ich meine pins auf die vorgabe einstell funzzt es. will ich aber 
nich.

ich brauche wie oben:

pd4 - pd7 > d4 - d7

...liege dem zu füßen, der mir nach erfolglosem nachlesen die antwort 
geben kann!! :)

ps: ich als neuling komme im tur tatsächlich nicht klar mit der 
beschreibung ( wie auch an anderen stellen im forum angemerkt ), was die 
pd0-pd4 belegung angeht.

...oder ich raffs einfach net...kann ja auch sein ;)

schonmal danke an alle produktivenhelfer

[Lord Z. (lordziu)]

Poste doch mal das Headerfile. In der Regel ist das der richtige Ort um 
solche Einstellungen zu machen. Woher hast du denn den Code? Ohne 
elementare Infos kann dir niemand helfen.

[Peter D. (peda)]

http://www.mikrocontroller.net/attachment/30300/lcd_drv.zip


Peter

[Karl H. (kbuchegg)]

Matthias Teichmann schrieb:

> jetzt meine frage: wie kann ich in der lcd-routines.c ( oder .h (was ich
> nicht glaube)) die datenbins anpassen?
>

* Indem man die Ausgaberoutinen lcd_command und lcd_data aus dem
  Tutorial (ich nehme mal an, dass du die benutzt) umschreibt.
  Die sind nicht allgemein genug gehalten, als dass sie in der Lage
  der Datenpins konfigurierbar sind

* Indem man eine andere Lib benutzt, in der das schon gemacht wurde
  und die man konfigurieren kann

[S. L. (goldencue)]

hallo peter, daniel und leser!

zur zip:
jip...feine sache und ich habs mir gleich angeschaut.
allerdings ist die lösung anders aufgebaut als die von mir ( als 
beginner ) benutzte. um gleich daniels antwort mit einzubinden...die 
lösung unter 
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung 
habe ich angewandt und es funktioniert ja auch. nur eben mit den 
falschen pinbelegungen für die daten. deshalb habe ich meinen code nicht 
erst mit eingestellt, da er von hier ist und eben ja auch 
funzzt...normalerweise.

jetzt glaube ich aber, dass mich das wissen, wie ich die pins PD0-PD4 
auf PD4-pd7 in der lösung 
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung 
ändere, schneller ans ziel bringen kann.

gibt es einen speziellen grund, warum peters zip-lösung besser sein 
kann? oder ist es nur ein anderer weg?


vielen vielen dank für eure hilfe!!!!

[S. L. (goldencue)]

danke auch dir karl heinz!

dazu nur eine anmerkung:
ich komme aus dem bereich c++, basic, php, perl u.u.. eigentlich 
entwickle ich also auf oop-ebene und da muss ich sagen - warum, wenn es 
avr schon so lang gibt, gibt es kaum optimierte und durchdachte 
templates wie etwa modules in perl oder steuerelemente in vb? ich habe 
irgendwie das gefühl, dass hier jeder selber basteln muss..an jedem bit 
und jeder zeile. für taster z.b. ist das tur hier im forum wohl eher 
eine beginnerlösung, die so nur bedingt gelten kann. dann sagt mir jeder 
was anderes; über interrupt, über hauptschleife...u.u. ich muss dann 
selber meine lösung finden. bei perl oder anderen beispielen muss ich 
doch auch nicht mir nen modul zusammenlesen, welches mir dann e-mail 
versendet. ein modul, paar inits und's läuft. wer macht sich dabei um 
serielle datenstrukturen beim versandt gedanken? gerade so standards wie 
lcd oder taster sollten schon lang mal von der avr-gemeinschaft 
optimiert worden sein.

aber wie gesagt...ich bin neu hier unten an den bits;)..und verstehe 
vielleicht noch nicht genug davon.

[Karl H. (kbuchegg)]

Matthias Teichmann schrieb:

> ich komme aus dem bereich c++, basic, php, perl u.u.. eigentlich
> entwickle ich also auf oop-ebene und da muss ich sagen - warum, wenn es
> avr schon so lang gibt, gibt es kaum optimierte und durchdachte
> templates

Weil eine allgemeine Lösung für dieses Problem nun mal den Nachteil hat, 
dass sie mehr Code verbraucht. Auf einem PC spielt das keine Rolle, ob 
eine bestimmte Aktion in 4 OpCodes oder in deren 8 oder 12 (oder...) 
implementiert wird. Auf einem AVR kann das aber im Extremfall einen 
Unterschied machen, ob das Programm noch in den Flash passt oder nicht.

Um Kentnisse und Fertigkeiten in den Bitmanipulationen mit UND, ODER, 
NICHT kommst du in der µC Programmierung nicht umhin.

> ich habe irgendwie das gefühl, dass hier jeder selber basteln
> muss..an jedem bit und jeder zeile.

'One size fits all' funktioniert auf Systemen wie einem AVR mit den 
limitierten Resourcen nun mal nicht sooo besonders gut. Von daher ist 
man immer gut beraten, wenn man Ideen portiert und diese Ideen an die 
tatsächliche Aufgabenstellung anpasst. Das bedingt aber naturgemäss: 
Copy&Paste Programmierung funktioniert nur in Ausnahmefällen

[Stefan B. (stefan)]

Matthias Teichmann schrieb:

> gerade so standards wie
> lcd oder taster sollten schon lang mal von der avr-gemeinschaft
> optimiert worden sein.

Sind sie doch.

Wenn du mit einer Standard-Hardware ankommst. Eine solche Lösung wäre 
z.B. eine Arduino-Plattform. Dafür gibt es passende Shields, d.h. 
Hardwareerweiterungen, und die dazugehörigen Libraries bzw. eine 
komplette Programmierumgebung.

Wenn du offen sein willst und eine eigene Hardware mit eigener 
Pinbelegung haben willst, dann musst du selbst die Software dafür 
schreiben. Die Tutorials und Codebeispiele (Entprellung, Drehgeber, 
Sensoren, Busse) sollen den Weg dahin erleichtern, indem sie das Prinzip 
aufzeigen. Und in bestimmten Fällen können die Programmbeispiele sogar 
1:1 übernommen werden, wenn man bei der Planung der Hardware die 
Randbedingungen der Software berücksichtigt.

[Karl H. (kbuchegg)]

Matthias Teichmann schrieb:

> eine beginnerlösung, die so nur bedingt gelten kann. dann sagt mir jeder
> was anderes; über interrupt, über hauptschleife...u.u. ich muss dann
> selber meine lösung finden.

Ja, das ist so.
Allerdings sind typische AVR Anwendungen ja auch nicht Megabytes gross, 
sondern mit ein paar Zehn bis Hundert Programmzeilen findet man leicht 
das auskommen.

> bei perl oder anderen beispielen muss ich
> doch auch nicht mir nen modul zusammenlesen, welches mir dann e-mail
> versendet. ein modul, paar inits und's läuft.

Das liegt aber auch daran, dass sich perl auf eine weitgehend 
standardisierte Hardware/Betriebssystem Grundlage stützen kann. Die paar 
Abweichungen können dann auf der speziell angepassten Perl-Version 
ausgebügelt werden, so dass sich die Funktionalität für dich als Perl 
Programmierer immer gleich präsentiert. Der dabei notwendige Overhead 
spielt da kaum eine Rolle.

Auf einem AVR ist das aber anders. Den Overhead will man sich nicht 
leisten.

> wer macht sich dabei um
> serielle datenstrukturen beim versandt gedanken? gerade so standards
> wie lcd oder taster sollten schon lang mal von der avr-gemeinschaft
> optimiert worden sein.

Für Taster gibt es zb. die PeDa Routinen. Die sind einige der wenigen 
'Paste and Forget' Funktionalitäten. Aber das stimmt schon: Das meiste 
muss man anpassen.
Allerdings: Wenn man sein Handwerk in der Bitmanipulation beerrscht, hat 
man das schneller angepasst, als man hier eine Posting zusammenschreibt 
und auf Tippfehler durchsieht :-)

[Karl H. (kbuchegg)]

Und dann gibt es natürlich noch BASCOM.
Dort ist das von dir herbeigesehnte Prinzip durchgezogen. 'Geräte' 
werden in Standard-'funktionen' gekapselt und können weitgehend 
konfiguriert werden. Hat allerdings den Nachteil, dass du darauf 
angewiesen bist, dass dir der Hersteller eine entsprechende Komponente 
zur Verfügung stellt. Wenn nicht, musst du wieder auf Bitebene runter.

Und natürlich bist du von einer standardisierten Sprache weit, weit weg.

[Peter D. (peda)]

Matthias Teichmann schrieb:
> gibt es einen speziellen grund, warum peters zip-lösung besser sein
> kann? oder ist es nur ein anderer weg?

Sie geht einen völlig anderen Weg.
Es werden Bitbefehle verwendet und damit ist die Pinzuordnung völlig 
egal. Jede Kombination von 6 IO-Pins ist erlaubt und benötigt keinerlei 
Änderung am Code. Einfach die Pins definieren und das wars.

Außerdem kopieren viele andere LCD-Routinen die Nibble-Funktion an viele 
Stellen, statt sie aufzurufen. Daher ist meine Lib auch im Codeverbrauch 
deutlich kleiner (braucht dafür 2 Bytes Stack mehr).


Peter

[S. L. (goldencue)]

genau das meinte ich:) bisherige lösungen sind zugeschnitten ( wohl 
wegen des overheads - klar ). aber eine lösung a la:

//init
/*Alles raus hier vom standard was nich drin sein muss und der rest 
configuriert
//init ende

//libfunktionen
/*Alles raus hier an routinen was nich drin sein muss
//libfunktionen ende

geht los...

wäre doch gut oder net? wenn ich platz sparen will, optimiere ich eh den 
code der libs ( sofern möglich ). nur würde man im standard nicht jedes 
mal das rad neu den berg rauf schieben müssen.

zum vorschlag bascom:
den ersten tag hatte ich ein bascomprojekt. es hat sogar alles gleich 
funktioniert...am ersten tag! aber am ersten tag hab ich mich auch auf c 
umgestellt, da ich als entwickler bei bascom quasi ohne eier dasteh. das 
ist ja einer der vorteile an c - das bitweise bearbeiten.

deine lib hab ich jetzt mal implementiert. funzzt noch nicht, aber das 
liegt eher an meinem unwissen und wird sich ändern ;)...unbändiger 
code...wo gibts denn sowas!

[Karl H. (kbuchegg)]

Matthias Teichmann schrieb:

> funktioniert...am ersten tag! aber am ersten tag hab ich mich auch auf c
> umgestellt, da ich als entwickler bei bascom quasi ohne eier dasteh. das
> ist ja einer der vorteile an c - das bitweise bearbeiten.

LOL
Bildlicher Vergleich.
Lass das mal nicht die BASCOM Jünger hören :-)
Denn auch in BASCOM kann man auf Bitebene arbeiten und jedes Register 
beim Vornamen ansprechen. So ist das ja nun auch wieder nicht.

(Was nicht heißen soll, dass ich BASCOM deswegen mag. Aber wenn wir 
gerecht sein wollen, muss man das auch anführen)

[S. L. (goldencue)]

sorry...aber weil mer grad ma bei sind:

../lcd_drv.h:4: error: expected ')' before 'd'
../lcd_drv.h:5: error: expected ')' before 'd'
../lcd_drv.h:6: error: expected ')' before '*' token
../lcd_drv.h:8: error: expected ')' before 'line'

ist noch mein prob zum funzzen?!

[S. L. (goldencue)]

ich möchte niemanden diskreditieren! ob bascom oder nicht. hat alles 
seine berechtigung. nur mich stört schon allein der bootloader.

also sry an die bascom-freaks!

[Karl H. (kbuchegg)]

Matthias Teichmann schrieb:
> sorry...aber weil mer grad ma bei sind:
>
> ../lcd_drv.h:4: error: expected ')' before 'd'
> ../lcd_drv.h:5: error: expected ')' before 'd'
> ../lcd_drv.h:6: error: expected ')' before '*' token
> ../lcd_drv.h:8: error: expected ')' before 'line'
>
> ist noch mein prob zum funzzen?!

Ändere mal in lcd_drv.h

#ifndef _lcd_drv_h_
#define _lcd_drv_h_

#include "Mydefs.h"                 // <---- der hier fehlt

void lcd_command( u8 d );
void lcd_data( u8 d );
void lcd_text( u8 *t );
void lcd_init( void );
void lcd_pos( u8 line, u8 column );

#endif

Auch Header Files sollten alles für sie Notwendige includieren. Hier 
wird u8 benutzt, also sollte man auch den Header includen, der u8 
definiert. Ansonsten ist man immer darauf angewiesen, das derjenige, der 
lcd_drv.h benutzt, die richtigen Header vorab includiert.

[S. L. (goldencue)]

gute idee aber jetzt zeigt er mir das:

E:\Growmatic\myProjects\timer0\timer_tasten\default/../timer_tasten.c:23 
9:  undefined reference to `lcd_init'
E:\Growmatic\myProjects\timer0\timer_tasten\default/../timer_tasten.c:24 
1:  undefined reference to `lcd_pos'
E:\Growmatic\myProjects\timer0\timer_tasten\default/../timer_tasten.c:24 
2:  undefined reference to `lcd_text'

und...

ich hab die main.h mal in lcd_main umbenannt ( war denk ich was 
unglücklich gewählt ) und...

werden nicht macros hier groß geschrieben? aber das sind doch keine 
macros!...oder hab ich da als was falsch verstanden?


und...danke, danke, danke für die hilfe!

[Karl H. (kbuchegg)]

Matthias Teichmann schrieb:
> gute idee aber jetzt zeigt er mir das:
>
> E:\Growmatic\myProjects\timer0\timer_tasten\default/../timer_tasten.c:23 9:
> undefined reference to `lcd_init'
> E:\Growmatic\myProjects\timer0\timer_tasten\default/../timer_tasten.c:24 1:
> undefined reference to `lcd_pos'
> E:\Growmatic\myProjects\timer0\timer_tasten\default/../timer_tasten.c:24 2:
> undefined reference to `lcd_text'

Du musst nicht nur das Header File includieren. Du musst auch die lcd 
Routinen zum Projekt mit aufnehmen und dazulinken

> werden nicht macros hier groß geschrieben? aber das sind doch keine
> macros!...oder hab ich da als was falsch verstanden?

Das hat nichts mehr mit dem Compiler zu tun.
'Undefined reference' ist eine Linkermeldung.

http://www.mikrocontroller.net/articles/FAQ#Ich_hab_da_mehrere_.2A.c_und_.2A.h_Dateien._Was_mache_ich_damit.3F

[S. L. (goldencue)]

das habe ich! in meinem project sind jetzt meine und deine .c und .h 
enthalten. also auch die LCD_DRV.c in der ja die funktionen liegen. und 
diese .c muss ich doch in meinem mainfile ( watt ja auch nur .c ist ) 
nicht expli mit angeben?!

und mit den großbuchstaben bei macros meinte ich eigentlich deine files, 
nicht die errors.

[Karl H. (kbuchegg)]

Matthias Teichmann schrieb:
> das habe ich! in meinem project sind jetzt meine und deine .c und .h
> enthalten.

Irgendwo in diesem Umfeld muss es aber einen Fehler geben.
Der Linker hat immer recht :-)
Wenn er Funktionen nicht findet, dann sind sie auch nicht da.

Hast du die lcd_drv.c im Projekt mit drinnen? Damit ist nicht gemeint: 
Ist es auf demselben Verzeichnis. Auf dem verzeichnis können viele Files 
sein! Du musst auch AVR-Studio sagen, dass lcd_drv.c zum Projekt 
dazugehört!

> und mit den großbuchstaben bei macros meinte ich eigentlich deine files,
> nicht die errors.

Auf Windows ist die Schreibweise der Dateinamen egal. (Nur die Endung 
sollte nicht mit einem grossen C geschrieben sein)

[S. L. (goldencue)]

ich sende dir mal mein project. aber bitte nicht lachen...ist alles zum 
test.

[S. L. (goldencue)]

es soll hier auch nicht um den anderen code gehen. nur das display ist 
hier wichtig.

[Karl H. (kbuchegg)]

Benenne jetzt ganz schnell LCD_DRV.C um in LCD_DRV.c

Die Dateiendung muss mit kleinem c sein

[S. L. (goldencue)]

"Du musst auch AVR-Studio sagen, dass lcd_drv.c zum Projekt
dazugehört."

wie mache ich das genau?

[Martin e. C. (eduardo)]

Matthias Teichmann schrieb:
> es soll hier auch nicht um den anderen code gehen. nur das display ist
> hier wichtig.

dann würde ich z.B. nur den LCD Code testen bis es funktioniert, dann 
Schritt für Schritt, taste usw. einfügen. Ich habe den LCD Code von 
Peter Dannegger Kompilliert und kein Problem, kein Fehler, übrigens 
nette Sache!

[Karl H. (kbuchegg)]

Und benutze bitte NULL ausschliesslich in einem Pointer-Kontext.

Wenn du einen 'char' auf 0 setzen willst, dann schreib das auch so
    i = 0;
und nicht
    i = NULL;

Ausserdem: den Datentyp 'char' reservierest du ausschliesslich für alles 
was mit Textverarbeitung zu tun hat. Wenn du einen Datentyp benötigst 
für 'kleiner Integer', dann benutzt du entweder 'signed char' oder 
'unsigned char' (oder int8_t oder uint8_t), je nachdem ob du Vorzeichen 
brauchst oder nicht. Aber du benutzt NIEMALS plain vanilla 'char'

[S. L. (goldencue)]

ha:) genau das wars!! DAAAAANKE! und eben ein schusselfehler vor dem 
herrn...!!

[S. L. (goldencue)]

ja finde ich auch gut umgesetzt und vor allem...er hat mir sehr geholfen 
heute!!!

das stepbystep-entwickeln mache ich ja. es lag ja an nem schreibfehler ( 
der dieses mal zum glück nich von mir war...kaaarl heinz;;;) aber - 
unwichtig! ums ziel gehts und das wurde mit eurer hilfe erreicht.

ich danke sehr und die nächste frage lauert..;)

[Karl H. (kbuchegg)]

Matthias Teichmann schrieb:

> das stepbystep-entwickeln mache ich ja. es lag ja an nem schreibfehler (
> der dieses mal zum glück nich von mir war...

Schau noch mal ins Zip-File
Die Datei heisst dort Lcd_drv.c
Mit einem kleinen c

> kaaarl heinz;;;) aber -
> unwichtig!

Hab ich was anderes behauptet?
Lies nochmal nach:

Beitrag "Re: in lcd-routines pins anpassen"

Du sagst, die Datei heißt bei dir LCD_DRV.c
Wäre an sich völlig richtig. Nur halt gelogen, denn bei dir heißt sie 
LCD_DRV.C

Auf deine explizite Nachfrage dann die Antwort

Beitrag "Re: in lcd-routines pins anpassen"

mit der Warnung, dass die Dateiendung NICHT *.C lauten darf

Und zur Erläuterung
 Der Compiler betrachtet alle .c als C-Code Files
 Der Compiler betrachtet alle .C als C++-Code Files

[S. L. (goldencue)]

du hast vollkommen recht! nur:

1.ich sagte...es ist ein test!...also teils wirrer/toter code
2.bin ich mit speicher für datentypen verwöhnt am pc. da hier der 
speicher im test nicht voll war, hab ich einfach verschiedenes probiert. 
defensives progen, wartezeiten, VarInt...vollkommen falsch, und und. ich 
weiß.

bevor es an ein richtiges project geht wird dann durchgefegt;)

danke aber für die tipps trotzdem. ich wusste es noch nicht und sie sind 
sehr wertvoll!

[S. L. (goldencue)]

du hast recht und den teufel werd ich tun mit dir zu steiten. ich lieg 
dir zu füßen:)

nur in der zip von oben ist die datei mit .C drin!

sry!

[S. L. (goldencue)]

Karl heinz Buchegger schrieb:
> Und zur Erläuterung
>  Der Compiler betrachtet alle .c als C-Code Files
>  Der Compiler betrachtet alle .C als C++-Code Files

das ist ja klar und ich hätte das auch sehen können. zumal mir die 
großschreibung ja auffiel.

[Karl H. (kbuchegg)]

Matthias Teichmann schrieb:

> nur in der zip von oben ist die datei mit .C drin!

Ooops.
Ich nehme alles zurück und behaupte das Gegenteil.

(Ich könnte allerdings schwören, dass ich dir ZIP aufgemacht habe, und 
da war sie mit kleinem c drinnen.)

[S. L. (goldencue)]

wie gesagt - das ziel zählt und du hast meinen vollen respect!

->schau mir grad nochmal die datentypen und deren handhabung an;)

[Peter D. (peda)]

C++ sollte doch eigentlich abwärtskompatibel sein.
Tritt denn eine Fehlermeldung auf bei dem "lcd.C"?

Mit dem Compilerschalter "-xc" kann man C erzwingen.
Dann können Anfänger sogar ihre geliebten *.txt compilieren.
*.doc und *.pdf gehen natürlich trotzdem nicht.

Ich hab früher gerne nen DOS-Editor benutzt, weil der so schön schnell 
ist. Und unter DOS wird alles automatisch groß benannt.


Peter

[Martin e. C. (eduardo)]

Peter Dannegger schrieb:
> Tritt denn eine Fehlermeldung auf bei dem "lcd.C"?

also ich habe die Dateien vom Peter ("lcd_drv.zip") so wie drin sind 
(nur util/delay.h geändert) mit WinAVR (Notepad) Compilliert und hat 
gleich gefunkt also ohne irgend welche Fehlermeldung und ich habe gar 
kein .C oder .c geändert

Gruß
Martin

[Karl H. (kbuchegg)]

Peter Dannegger schrieb:
> C++ sollte doch eigentlich abwärtskompatibel sein.

Stichwort: name mangling