LCD will nicht mit angehen

[Matthias (Gast)]

Hallo,
Ich rätsele schon seit einer Woche an der Sache und ich weiß nicht was 
ich machen kann.

Mein Problem:
Ich habe einen AVR Butterfly mit den ATMega 169 und das LCD Display (11 
Segment) was sich auch auf den stk501 befindet.
Zusatzinformation meine Spannungsversorgung(SMD, LM-317) wird von 15V 
auf 10V und dann auf 4,5V, für den Butterfly runterregele mit fest 
Spannungsreglern.
Muß leider so sein weil ich die 10V auch brauche, zumindest die 
Spannungen stimmen alle.
Zusätzlich hab ich an dem ADC Port den Pin5 als Analog Eingang 
angeschlossen.

Mein Problem ist nun wenn ich die 15V anschliesse läuft mein Controller 
an, aber nicht mein LCD Display!!
Ich vermute das die Spannungsregler zulange brauchen um auf ihre 4,5V 
zukommen und deshalb der Controller vor dem Display schon los rennt.
Da er schneller als das Display ist könnte ja die initialisierung des 
LCD vielleicht nicht erfolgreich durch geführt werden.

Ein kleine Hilfe vielleicht.
Wenn ich über testen die direkte Stromversorgung des Butterfly's abziehe 
und ein bissl warte und wieder anschliesse läuft alles perfekt, das 
Display springt mit an und mein Programm läuft ohne Probleme.


Was denkt ihr über das Problem?
Danke schon mal im voraus

Matthias

[Matthias (Gast)]

Ich bin's gerad nochmal!

Hab gerad nochmal probiert so an zugriegen.
Und es ging wie gesagt nicht an, aber als ich die 15V raus gezogen hab 
und wieder angeschlossen hab, ging das Display verwunderlich an!

Matthias

[Machtin (Gast)]

Hallo Matthias,

wenn der Verdacht da ist das der µC zu schnell angeht und den 
LCD-Controller initialisiert devor der bereit ist dann programmier dir 
doch ne Warteschleife vor der Displayinitialisierung.

Gruss Martin

[Matthias (Gast)]

Hm klingt gut,
sowas hatte ich auch schon gedacht und eine Delay schleife von ungefähr 
2 sekunden davor programmiert.
Aber So wirklich geholfen hat es nicht!

vielleicht eine gute Idee:
Vielleicht nach einer gewissen Zeit noch mal einen Reset über den reset 
Pin machen?
Aber was müßte ich da Hardware technisch noch realisieren???

[Condi (Gast)]

Watchdig wäre ne Lösung oder mal nach dem Brown out schauen.

[Spess53 (Gast)]

Hi

Das Display vom Butterfly hat keinen eigenen Controller. Der 169 ist der 
Displaycontroller. Also wenns nicht klappt, liegt es an der 
Programmierung.

MfG Spess

[Matthias (Gast)]

Aber wenn es an der Programmierung liegt wie kann es denn sein, dass er 
manchmal angeht und manchmal nicht?
Außerdem benutze ich größtenteils die Originalsoftware vom Butterfly. 
Habe im Prinzip nur meine Funktionen zusätzlich eingefügt.

[Matthias (Gast)]

Ja, hab mal den original Code(Butterfly) drauf gespielt und siehe da, 
das Programm läuft immer ohne Probleme!!

Also muß es anscheint doch am Programm an sich liegen.
Aber wie erklärt sich der zufall ob es angeht oder nicht.
Benutz ja den original code und schreiben meine Funktionen dazu.
Und habe dann im Menü nur den Aufruf der original funktionen raus 
genommen.
Also Querverweise oder sowas müßten noch funktionieren.
Aber ich komm nicht dahinter woran es liegt.
Ich schreibe die Funktionen gerad Schritt für Schritt nochmal rein.

Und wenn dann der Controller wieder mal nicht will kontrolliere ich die 
funktion und stelle fest das sie genau so aussieht wie die original 
funktion von der ich sie kopiert habe, nur das meine variablen drin 
sind.
Und deren deklaration ist wirklich richtig, mehrmals kontrolliert.

Woran könnte das denn liegen?

[Karl H. (kbuchegg)]

Matthias wrote:

> Und wenn dann der Controller wieder mal nicht will kontrolliere ich die
> funktion und stelle fest das sie genau so aussieht wie die original
> funktion von der ich sie kopiert habe, nur das meine variablen drin
> sind.

Was heist: "drinnen sind"

> Und deren deklaration ist wirklich richtig, mehrmals kontrolliert.
>
> Woran könnte das denn liegen?

Das könnte zb daran liegen, dass globale Variablen vom Compiler
auf 0 initialisiert werden, während das bei funktionslokalen
Variablen nicht so ist.

[Matthias (Gast)]

Gut, hab gerad nochmal kontrolliert.
Die lokalen setze ich auch auf 0!!

Aber mir ist gerad eine Idee gekommen, ich teste gerad mit dem PROGMEM.
Und es lassen sich wahrscheinlich kleine Erfolge verzeichnen, aber warum 
es damit zusammenhängen kann wüßte ich jetzt auch nicht.

Aber erstmal vielen Dank für die Hinweise!!!

[Karl H. (kbuchegg)]

Matthias wrote:
> Gut, hab gerad nochmal kontrolliert.
> Die lokalen setze ich auch auf 0!!

Tut mir leid. Aber mehr kann ich in meiner
Glaskugel nicht sehen. Die muesste wahrscheinlich
wieder mal zum Service.

[Matthias (Gast)]

Also ich glaub ich weiß jetzt wo genau das Problem liegt.

Die Menüpunkte sind wie folgt definiert:

const MENU_STATE menu_state[] PROGMEM = {
//  STATE                               STATE TEXT                  STATE_FUNC
    {ST_AVRBF,                          MT_AVRBF,                   NULL},
    {ST_AVRBF_REV,                      NULL,                       Revision},
...

... 
   {ST_OPTIONS_FSS,                MT_OPTIONS_FSS,             NULL},
    {ST_OPTIONS_FSS_MAX_WEIGHT,         MT_OPTIONS_FSS_MAX_WEIGHT,  NULL},
  {ST_OPTIONS_FSS_MAX_WEIGHT_FUNC,  NULL,            MAX_Weight_Func},
    {ST_OPTIONS_FSS_MAX_VOLTAGE,        MT_OPTIONS_FSS_MAX_VOLTAGE, NULL},
  {ST_OPTIONS_FSS_MAX_VOLTAGE_FUNC,  NULL,            MAX_Voltage_Func},
//->
    {0,                                 NULL,                       NULL},

};

Wenn ich an dieser(->) stelle nun noch einen Menüpunkt anfüge

 {ST_MESSUNG, NULL, Messung},

(Die funktion Messung existiert und auch ST_MESSUNG hab ich definiert) 
springt der Controller nicht mehr an.
Hat irgendjemand ne idee woran das liegen könnte?

[Matthias (Gast)]

Ja also Danke nochma an alle

Hab den fehler jetzt gefunden und behoben. Das Boot reset Vector fusebit 
war gesetzt. Da gabs wohl irgendwie probleme.