[AVR-ATmega8] LCD-Menü mit 2 Tastern

schluck
Welche IC´s sollst du testen?

Standard IC´s...

And
Or
Not
Nand
Nor

Huhu...


das LCD ansteuern klappt ja....
Das mit den Arrays auch...
Nur dass er den nächsten Text auf das LCD schreibt, wenn ich einen 
Taster gedrückt hatte, klappt nicht...

HiHo..

Also irgendwie.....
Ich weiß nicht..
Alles was ich versuche klappt nicht....

Mag mir vllt jmnd. das kleine Stück Quellcode schreiben?
Oder besser gesagt genauer erklären?

Ich erkläre mal genau, wies ablaufen soll:

Programmstart...Erste Zeile:    1. IC´s testen
                                2. IC´s simulieren

Nach Tastendruck (bsp. PB5):    1. IC´s testen
                                - AND

Nach Tastendruck (bsp. PB6):    1. IC´s testen
                                - OR

Nach Tastendruck (bsp. PB5):    IC: OR
                                Bits senden...

PB5 soll also "OK" und PB6 "Weiter" darstellen...

So ungefähr dachte ich es...aber er reagiert NIE auf einen Tastendruck 
:/

mfg Theo

Sehe ich es richtig, dass das Problem nicht das Menu ist, sondern, dass 
ein Tastendruck nicht erkannt wird?

Grüße,

Peter

Kann man so sagen...

Hatte mich am Anfang wohl etwas falsch ausgedrückt. `Tschuldigung..

mfg Theo

Was läuft denn schon alles?
Kannst du den Code posten?


edit:
Ein Schaltplan wäre auch praktisch...


Peter

Was läuft ist:

LCD Ausgabe

Mehr aber auch nicht, da er ja keinen Tastendruck "erkennt".

Theoretisch bin ich natürlich schon wieter...


mfg Theo

Also verwendest du Taster 1 und Taster 2, die beide auf dem Mainboard 
sind. Und das Display ist das, was im MyAVR Shop dazu passend verkauft 
wird.

Das macht ja zumindest Fehler in der Hardware unwahrscheinlich.

Es wäre natürlich trotzdem hilfreich, wenn du mal das posten könntest, 
was du bisher programmiert hast, sonst kann dir hier niemand helfen.

Welchen Compiler verwendest du?
Ich hab die Verkaufsseite von MyAVR nur gerade überflogen und gesehen, 
dass es eine eigene IDE gibt für verschiedene Programmiersprachen und 
wohl auch eigene Bibliotheken.

Als einfache Übung könntest du etwas programmieren, das nur eine 
Leuchtdiode einschaltet, wenn das Programm startet.
Als nächste Übung wäre es sinnvoll, die Leuchtdiode erst einzuschalten, 
wenn ein Taster gedrückt worden ist.
Damit wäre die Funktionalität der Taster und entsprechende 
Bibliotheksverwendung überprüft.

Peter

Ich verwende den AVR-Studio..

Der momentane Code:

1

#include <avr/io.h>

2

#define F_CPU 3686400UL    

3

4

#include "myavr_lcd.h"     

5

#include <util/delay.h>

6

#include <avr/pgmspace.h>

7

#include <string.h>

8

#include <stdio.h>

9

10

const char haupt[] PROGMEM= "Hauptmenue";

11

const char test[] PROGMEM= "1. IC testen    ";

12

const char sim[] PROGMEM= "2. IC simulieren ";

13

14

int main()

15

{

16

  lcd_init(LCD_DISP_ON);    

17

18

19

    lcd_puts_p(haupt);  

20

21

    lcd_gotoxy(0,1);    

22

    lcd_puts_p(test);  

23

24

  if ((PINB&0b00010000)==1)

25

  {

26

    lcd_puts_p(haupt);  

27

28

      lcd_gotoxy(0,1);    

29

      lcd_puts_p(test);

30

  }

31

32

    while(1)

33

    {

34

35

    }

36

37

    return 0;

38

}

mfg Theo

Und du bist sicher, dass der Taster an Pin B5 angeschlossen ist?
Zieht er denn nach Vcc oder nach Gnd?
Das entscheidet ja darüber ob du auf ==1 oder ==0 abfragen musst.

Dann solltest du noch den Pullup einschalten, bevor du den Taster 
benutzt:
PORTB |=0b00010000;

Peter

Und ich sehe noch etwas:

Die Endlosschleife ist leer, die Tasterabfrage passiert nur einmal 
davor. Das heißt, der Taster müsste gerade in dem Moment des 
Programmstarts gedrückt sein, damit etwas passiert.

Wird denn der Testtext angezeigt?

Peter

Den internen PullUp hab ich nun eingeschaltet...

(Er zieht nach Vcc)

Und trotzdem passiert nun nichts...

|0-0-0-1-0-0-0-0|
-----------------
|7-6-5-4-3-2-1-0|

Das heißt doch, dass er an Pin 5 ist, oder nicht?...

Theo

Probiers mal so:

1

#include <avr/io.h>

2

#define F_CPU 3686400UL    

3

4

#include "myavr_lcd.h"     

5

#include <util/delay.h>

6

#include <avr/pgmspace.h>

7

#include <string.h>

8

#include <stdio.h>

9

10

const char haupt[] PROGMEM= "Hauptmenue";

11

const char test[] PROGMEM= "1. IC testen    ";

12

const char sim[] PROGMEM= "2. IC simulieren ";

13

14

int main()

15

{

16

  lcd_init(LCD_DISP_ON);    

17

  PORTB |=0b00010000;

18

19

20

    lcd_puts_p(haupt);  

21

22

    lcd_gotoxy(0,1);    

23

    lcd_puts_p(test);  

24

25

    while(1)

26

    {

27

      if ((PINB&0b00010000)==0)

28

      {

29

        lcd_puts_p(haupt);  

30

        lcd_gotoxy(0,1);    

31

        lcd_puts_p(test);

32

        while(1);

33

      }

34

    }

35

    return 0;

36

}

Er wird von Anfang an angezeigt....

Meinst du ich soll die Tasterabfrage in eine Schleife einfügen?

edit: OK ich versuchs mal so

Theo

>Das heißt doch, dass er an Pin 5 ist, oder nicht?...

Ja.

Es ist aber doch nicht gesagt, dass das stimmt, oder steht das irgendwo 
so?
Aus dem Layout kann man nichts erkennen, weil es wohl mehr als 2 Layer 
sein müssen, die nicht alle dargestellt sind. Ansonsten sieht es nämlich 
so aus, als wäre der Taster nicht angeschlossen.

Darf ich sagen, dass du ein schatz bist? =D

Nun kommt die zweite auswahl zum Vorschein...danke dir erstmal ;)

Theo

Und wenn er nun nach einem weiteren Tastendruck wieder "IC testen" 
anzteigen soll, muss ich dich folgendes schreiben, oder nicht? :

1

main:

2

3

    lcd_puts_p(haupt);  

4

    lcd_gotoxy(0,1);    

5

    lcd_puts_p(test); 

6

7

while(1)

8

{

9

    if ((PINB&0b00010000)==0)

10

    {

11

      lcd_puts_p(haupt);  

12

      lcd_gotoxy(0,1);    

13

      lcd_puts_p(sim);

14

15

      if((PINB&0b00010000)==0)

16

      {

17

        goto main;

18

      }

19

20

      while(1);

21

    }

22

23

}

mfg Theo

Jetzt würde ich dir empfehlen mehr zum Thema Tasterentprellung und 
Statemachines zu lesen, das werden die nächsten beiden Probleme sein.

Ich teile meine Programme immer in mehrere Funktionsblöcke. Einer 
üblicherweise für das Userinterface (Display, Taster, Lampen...), einer 
für die Menunavigation, ein Echtzeitblock, der alles zeitkritische 
erledigt und dann jede Menge Funktionen, die den Rest machen.

Das sieht dann etwa so aus:

1

void display(int number)

2

{

3

  switch (number)

4

  {

5

    case 0:

6

      print(...);

7

    break;

8

    case 1: usw...

9

  }

10

11

}

12

13

interrupt timer...

14

{

15

  //hier der Echtzeitteil, z.B. Tasterentprellung

16

}

17

18

int main()

19

{

20

  int state = 0;

21

  init_everything(); //ist irgendwo definiert

22

23

  while(1)

24

  {

25

    switch(state)

26

    {

27

      case 0:

28

        display(0);

29

        state = 1;

30

      break;

31

      case 1:

32

      if (Taster1) 

33

      {

34

        state = 3;

35

        display(2);

36

      }

37

      break;

38

      usw.

39

    } 

40

  }

41

}

so lassen sich recht schnell aufwändige Menüs realisieren.

Peter

Danke für die Tipps, aber magst du mir vllt eben meine Frage 
beantworten?^^

mfg Theo

Das mit den goto Sprüngen ist ziemlich unübersichtlich, wenn man davon 
mehrere hat.
Deswegen verwendet goto so gut wie niemand und man empfiehlt es auch 
nicht weiter.

Der Code wird so auch nicht richtig funktionieren, weil ich da ein 
while(1); eingebaut habe, das an der entsprechenden Stelle eine 
Endlosschleife darstellt.

Versuch das am besten so zu strukturieren, wie ich es oben aufgezeigt 
habe.

Peter

Noch ein Tip für bessere Lesbarkeit am Rande:

Das kommt ganz oben in den Code:
#define Taster1  !(PINB & (1<<PB5))

hilft enorm, man kann dann so abfragen:

if (Taster1)
usw..

Peter

Hier noch ein Beispielcodeschnippsel zur Tasterentprellung mit 
Unterscheidung ob der Taster nur einmal pro Drücken ausgewertet werden 
soll oder immer solange gedrückt wird:

Beitrag "Re: Atmel Mega 8 verhält sich nicht wie in AVR Studio Simulation"

Peter

Ich habs nun mit den Arrays soweit, dass ich zweischen -IC testen- und 
-IC simulieren- "switchen" kann...
Nur macht er es auch schon automatisch...er zeigt immer beide einträge 
ganz schnell hintereinander an..wie kann ich das umgehen?

Theo

Das Problem habe ich nun gelöst, indem ich einfach ein wenig warte 
(   _delay_ms(20)    )....nun gehts daran die einzelnen IC´s auswählen 
zu können...

mfg Theo

Leider bin ich noch nicht weiter...Denn ich weiß nicht wie ich in ein 
Sub-Menü einsteigen soll..wenn ich es mit switch-case versuche, bleibt 
er einfach "hängen"..


mfg Theo

Nur mal so nebenbei...

Ich habe grad gemerkt, dass wenn ich mein USB-Kabel aus dem Port ziehe, 
dass dann die Taster nicht mehr funktionieren...

Woran kann das liegen?


mfg Theo

Ich packe den funktionierenden Quellcode mal als Anhang hier hinein.

Ich versuche nun schon seid ewigen Stunden ein Untermenü zu erstellen, 
aber er geht nur durch zufall in ein Untermenü. Nicht wenn ich drücke.


[c]
case 1:
 if(Tweiter)
 {
   _delay_ms(50);
   _delay_ms(50);
   while(Tweiter);

   display (0);
   menue = 2;
 }

 switch(submenue)
 {
   case 0:
    if(Tok)
    {
     display(1);
    }
    break;
 }

break;

Theo Rettisch schrieb:
> Ich packe den funktionierenden Quellcode mal als Anhang hier hinein.
>
> Ich versuche nun schon seid ewigen Stunden ein Untermenü zu erstellen,
> aber er geht nur durch zufall in ein Untermenü. Nicht wenn ich drücke.

Weil der ganze Ansatz scheisse ist.

Du holst dir jetzt erst mal von hier
http://www.mikrocontroller.net/articles/Entprellung#Komfortroutine_.28C_f.C3.BCr_AVR.29
die Routinen für die Tastenbehandlung und bringst die zum laufen.


Dein Programm könnte zb so aussehen

1

lcd_put_choice_p( uint8_t row, const char* text )

2

{

3

  lcd_gotoxy( row, 2 );

4

  lcd_puts_p( text );

5

}

6

7

void Menu1()

8

{

9

  uint8_t choice;

10

11

  lcd_clear();

12

  lcd_put_choice_p( 0, "AND" );

13

  lcd_put_choice_p( 1, "OR" );

14

  lcd_put_choice_p( 2, "Exit" );

15

16

  choice = 0;

17

  lcd_gotoxy( 0, 0 );

18

  lcd_putc( '>' );

19

20

  while( 1 ) {

21

    if( get_key_press( 1<<KEY0 ) ) {

22

      lcd_gotoxy( choice, 0 );

23

      lcd_putc( ' ' );

24

      choice++;

25

      if( choice == 3 )

26

        choice = 0;

27

      lcd_gotoxy( choice, 0 );

28

      lcd_putc( '>' );

29

    }

30

31

    if( get_key_press( 1<<KEY1 ) ) {

32

      if( choice == 0 )

33

        PerformAnd();

34

35

      else if( choice == 1 )

36

        PerformOr();

37

38

      else if( choice == 2 )

39

        break;       // ausbrechen aus der while Schleife

40

    }

41

  }

42

}

43

44

int main()

45

{

46

  ....

47

48

  while(1) {

49

50

51

    if( get_key_press( 1<<KEY0 ) )

52

      Menu1();

53

54

    else if( get_key_press( 1<<KEY1 )

55

      Menu2();

56

  }

57

 }

Du willst dir auch die Menüsteuerung nach Möglichkeit so organisieren, 
dass du die eigentliche Menübearbeitung nur einmal hast und die 
Menütexte zb in einem Array zusammenfasst.

Magst du mir nicht lieber erklären warum er nicht so toll ist?

Weil mit "weil der ganze Ansatz scheiße ist" kann ich recht wenig 
anfangen.

Theo

Theo Rettisch schrieb:
> Magst du mir nicht lieber erklären warum er nicht so toll ist?
>
> Weil mit "weil der ganze Ansatz scheiße ist" kann ich recht wenig
> anfangen.

Weil du das Thema Tastenentprellung komplett ignorierst. Und mit dem

if ( !(PINB & (1<<PB5)) )

wirst du sowieso nicht glücklich werden, egal wie oft du das umformst. 
Du willst nämlich das Drücken einer Taste detektieren, also das 
Umschalten von 1 auf 0 und nicht ob die Taste gedrückt IST. Die Taste 
ist nämlich aus Prozessorsicht eine halbe Ewigkeit gedrückt und wenn er 
in 1 Sekunde diese If-Abfrage 120000 mal durchläuft, dann wird dein 
Programm 120000 mal in dieses If hineingehen.

Und für den Rest: Ich hab dir im vorhergehenden Posting mal skizziert, 
wie so etwas aussehen könnte. Wie du siehst, nimmt dir die Entprellung 
aus dem Link die ganze Arbeit der Tastenbehandlung ab. Du brauchst nur 
noch die Ergebnisse abholen.

Wenn ich aber nach einem Tastendruck eine gewisse Zeit warte, ist das 
doch auch ein "entprellen"....
Oder nicht?

Theo

Theo Rettisch schrieb:
> Wenn ich aber nach einem Tastendruck eine gewisse Zeit warte, ist das
> doch auch ein "entprellen"....
> Oder nicht?

Ich habe die Post erst gesehen, nachdem ich meine geschrieben habe.
Ja das stimmt schon. Trotzdem fährst du mit den verlinkten-Funktionen 
besser. Schon alleine, weil du nirgends ein delay drinnen hast. Die 
Funktion get_key_press liefert TRUE, wenn seit dem letzten Aufruf die 
angegebene Taste gedrückt wurde und managed alles andere. Du brauchst 
dich um nichts weiter kümmern. Damit hast du die Behandlung der Tasten 
aus dem Weg und kannst dich ganz darauf konzentrieren, wie deine Menüs 
funktionieren sollen :-) (zb das Scrollen mehrere Menüeinträge in einem 
2 (4?) - zeiligem Display, zb. wie der Benutzer sieht, welcher 
Menüeintrag jetzt gerade der aktive ist, zb ...)

Die Tastenfunktionalität konfigurieren nicht vergessen. Aber das sollte 
eh selbstverständlich sein.

Es ist ein zweizeiliges LCD mit 16 Spalten.

Theo

Theo Rettisch schrieb:
> Es ist ein zweizeiliges LCD mit 16 Spalten.

Na denn.

Tasten zum laufen bringen.
Und schon kannst du dir ein Konzept zurechtlegen, wie du 20 Menüeinträge 
mit einem 2-zeiligen LCD handhabst.

Aber zu deinem Code.

Ich denke, der Taster, der dich momentan interessiert ist an PB5?

Warum schaltest du dann hier

  PORTB |=0b00010000;

den Pullup für PB4 ein?

(Genau das ist der Grund, warum man die Schreibweise

     PORTB |= ( 1 << PB5 );

bevorzugt. Dann mancht man nämlich nicht so dumme Fehler und verzählt 
sich in der Position des 1 Bits)

Ich hab nun die entprellung außenvor gelassen und mich damit 
beschäftigt, wie ich denn in ein Submenue komme...

1

case 1:

2

           if(Tweiter)

3

        {

4

          _delay_ms(50);

5

          _delay_ms(50);

6

          while(Tweiter);

7

8

          display (0);

9

          menue = 2;

10

        }

11

12

        switch(submenue)

13

        {

14

          case 0:

15

            if(Tok)

16

            {

17

              _delay_ms(50);

18

              _delay_ms(50);

19

              while(Tok);

20

21

              display(1);

22

              submenue = 1;

23

            }

24

          break;

25

26

          case 1:

27

            if(Tweiter)

28

            {

29

              _delay_ms(50);

30

              _delay_ms(50);

31

              while(Tweiter);

32

33

              display(2);

34

              submenue = 2;

35

            }

36

            break;

37

        }

38

39

        break;

Er geht dann nur ins Submenue wenn ich bei Menu case 1 den Tok 
drücke...ansonsten nicht...(und auch nur beim ersten mal)

Theo Rettisch schrieb:
> Ich hab nun die entprellung außenvor gelassen

Es hindert Dich niemand daran, bewährte Lösungen zu ignorieren und 
selber was zu probieren.

Erwarte aber nicht, daß sich die Leute den Mund fusselig reden, um Dich 
zu bekehren.

Wenn es also nicht geht, weißt Du inzwischen ja, wo Du zu suchen hast.


Peter

P.S.:
Es hat sich landläufig als äußerst praktisch erwiesen, den Hausbau nicht 
mit dem Dach (Menüführung), sondern mit dem Fundament (Tasten einlesen) 
zu beginnen.

Eine schöne Übungsaufgabe dazu:
2 Taste + 2 LEDs, jede Taste muß ihre LED togglen, völlig unabhängig 
voneinander.


Peter

Peter Dannegger schrieb:
> P.S.:
> Es hat sich landläufig als äußerst praktisch erwiesen, den Hausbau nicht
> mit dem Dach (Menüführung), sondern mit dem Fundament (Tasten einlesen)
> zu beginnen.

Full ACK.

Und ehe man anfängt ein Menüsystem zu programmieren (wenn man dann 
soweit ist), setzt man sich hin und überlegt zuerst wie das Menü 
aussehen soll, welche Einträge es gibt, wie die zusammenhängen, wie die 
Tasten benutzt werden sollen, welche Angabe wo am LCD auftaucht, etc.
Bevor man dann den ersten Code schreibt, spielt man das dann am Papier 
durch. Dann sieht man zb. dass es höchst wahrscheinlich nicht sinnvoll 
sein wird, wenn auf dem LCD

 +------------------------------------+
 | > IC auswählen                     |
 |   IC simulieren                    |
 +------------------------------------+

steht und sonst nichts. Denn es erhebt sich die Frage: Wenn ich jetzt 
auf "IC simulieren" gehe, welches IC wird dann eigentlich simuliert? Wo 
sehe ich das?

Es lohnt sich daher (nachdem man seine Vorübungen mit Tasten und LCD 
abgeschlossen hat), sich die Menüstruktur auf dem Papier aufzumalen und 
im Geiste Bediener zu spielen und nach Schwachstellen, Inkonsistenzen 
und Unlogik in dieser aufgezeichneten Menüstruktur zu suchen.

ZB. Könnte man auf die Idee kommen, dass das Programm die ganze Zeit ein 
Gatter simuliert, im Hauptschirm auch angezeigt welches und durch Druck 
auf OK erscheint eine Liste von möglichen Gattern, aus denen eines 
ausgewählt wird (mittels der Taste "Weiter" kann man in einer Richtung 
durch diese Liste durchgehen und durch Druck auf OK wird es ausgewählt. 
Nach Auswahl geht es wieder zurück in den Hauptschirm, wo das momentan 
ausgewählte Gatter hingeschrieben wird und das Programm fängt sofort an, 
dieses Gatter zu simulieren.

Ooops. Jetzt braucht man gar keine Submenüs mehr :-) Der 'Menüpunkt' "IC 
simulieren" hat sich in Wohlgefallen aufgelöst.

> Der 'Menüpunkt' "IC simulieren" hat sich in Wohlgefallen aufgelöst.

Die zweite Taste auch...

Im Auswahl-Menü:
Kurz drücken = Blättern
Lang drücken = Simulieren

In Simulation:
Kurz oder lang drücken: Zurück zum Auswahlmenü

;-)

...

Hannes Lux schrieb:
>> Der 'Menüpunkt' "IC simulieren" hat sich in Wohlgefallen aufgelöst.
>
> Die zweite Taste auch...
>
> Im Auswahl-Menü:
> Kurz drücken = Blättern
> Lang drücken = Simulieren
>
> In Simulation:
> Kurz oder lang drücken: Zurück zum Auswahlmenü


Dazu muss man dann aber zwischen Kurz und Lang drücken unterscheiden 
können. Die PeDa Routinen können das aus dem Stand :-)

Wobei ich hier eher das Feature "Autorepeat" einsetzen würde, wenn die 
Liste der Auswahlmöglichkeiten lang wird und damit wohl oder übel wieder 
2 Tasten brauche.

> die Liste der Auswahlmöglichkeiten lang wird...

Das wird wohl nicht der Fall sein. Denn es wird ja ein myAVR-Board mit 
Mega8 eingesetzt, da gibt es nur 6-Bit-Ports, von denen das LCD schon 
einen kompletten Port braucht. Tasten brauchen auch Pins, somit bleibt 
nicht mehr viel zum Simulieren (Eingänge für Schalter, Ausgänge für 
LEDs). Es wird wohl daher bei der einkanaligen Darstellung der Boolschen 
Grundfunktionen bleiben, wie sie Theo bereits weiter oben genannt hat:

And
Or
Not
Nand
Nor

Da käme dann vielleicht noch  EXOR und EXNOR dazu, aber dann hört es 
langsam auf (nagut, FFs und MUX gehen auch noch).

Na egal, ohne vernünftige Tastenentprellung geht da sowiso nichts. Ich 
habe es inzwischen aufgegeben, auf Peters Algorithmus zu verweisen, es 
sieht ja sonst so aus, als bekäme ich Prozente... ;-)

Ich benutze diesen Entprellalgorithmus sehr häufig (in ASM) und fahre 
ganz gut damit. Wer das nicht nutzen will, ist selbst schuld, wenn seine 
Programme spinnen...

;-)

...

Erstmal vielen Dank für die vielen Antworten.

Ich habe nun die Tastenentprellung nach Peter Dannegger gemacht. Klappt 
ganz gut soweit.

Nun mach ich mich an die Sub-Menüs.


mfg Theo

Wenn ich ein Sub-Menü erstelle, muss ich es ja nicht in einem neuen case 
machen sondern in dem case wo er in das Submenü springen soll.

Leider macht er es nicht. Wenn ich den neuen switch für das Sub-Menü in 
das case einbaue überspringt er das und geht da rein nachdem man mehrere 
male das Hauptmenü durchlaufen hat.

Weiß jmnd woran das liegt?

1

case 1:

2

   if(get_key_short( 1<<KEY0))

3

   {

4

      display (0);

5

      menue = 2;

6

7

      switch(sub)

8

      {

9

         case 0:

10

            if(get_key_long( 1<<KEY0))

11

            {

12

               display(1);

13

               sub = 1;

14

            }

15

            break;

16

17

         case 1:

18

            if(get_key_short( 1<<KEY0))

19

            {

20

               display(2);

21

               sub = 2;

22

            }

23

            break;

24

      }   

25

   }

26

   break;

27

28

case 2:

29

...

30

...

31

...

mfg Theo

Wie? Normales Menü?

Ich pack den Quellcode mal als Anhang...

Mein "normales" Menü läuft..ich drück einmal T1 dann erscheint "IC 
testen" ich drück nochmal T1 dann kommt "IC simulieren"...Wieder T1 
gedrückt erscheint wieder "IC testen".

Meinst du das?

Und wie soll ich deine Frage verstehen? Wie meinst du das mit "von 
hinten anfangen" ?

mfg Theo

Jetzt verstehe ich deine Frage...(und die Beiträge vorher) Ich soll 
einfach nur die IC´s anzeigen lassen und bei einem kurzen Druck soll er 
z.b. testen und bei einem langen simulieren...oder?

mfg Theo

Ich würde keine Submenus programmieren. Ich würde in diesem Fall alles 
in einer Menustruktur bearbeiten.

Je nach dem, wie groß die Variable ist, die den Menustatus kodiert, sind 
ausreichend viele Einträge in der Switch case Auswertung möglich.

Mal dir einfach mal ein Zustandsübergangsdiagramm auf, das alle 
Displayanzeigen (also Menupunkte) zeigt und wie man von einem in den 
nächsten kommt (z.B. durch Drücken von Tasten oder durch Timer oder 
durch Fertigstellung irgendwelcher Hintergrundprozesse).

Dann kannst du jedem Menupunkt eine Nummer geben.
Die Nummer sollte dem Zustand in der Statemachine entsprechen.

Und damit gibt es keine Submenus mehr, es ist alles in einer Case 
Anweisung untergebracht.

Peter

Du musst Dich erstmal entscheiden, was Pflicht_ und was _Kür ist. Geht 
es in der Aufgabestellung vorrangig um ein Menü mit Untermenüs, oder 
geht es um die Realisierung der Simulation der logischen Verknüpfungen. 
Danach entscheidet sich dann, wie umfangreich das Menü werden soll.

Es ist auch noch nicht bekannt (habe ich vielleicht übersehen), wie die 
Simulation aussehen soll. Sollen echte Pins als Ein/Ausgänge benutzt 
werden, an denen Schalter und LEDs angeschlossen werden? Oder soll die 
Simulation lediglich als Visualisierung auf dem LCD stattfinden? Es gibt 
da die verschiedensten Möglichkeiten.

...

Ich hab das nun so gemacht, dass man nur die einzelnen IC´s wählen kann 
und bei einem langen T1 druck soll getestet werden und bei einem langem 
T2 druck soll simuliert werden..

Simulation soll wie folgt laufen: Vom Lehrer bekomm ich n anderes Board 
mit mehr Ports. Somit kann ich mir einen "großen Sockel" bauen. Wenn 
dann ein "AND" IC gewählt wird soll an z.b. PC1 und PC2 drauf geachtet 
werden, dass wenn da eine -1- ist, dass dann an PC3 auch eine -1- 
ausgegeben wird.


mfg Theo

Hannes Lux schrieb:
> Du musst Dich erstmal entscheiden, was Pflicht_ und was _Kür ist.

Ein wahres Wort.

Neulinge tendieren gerne dazu, ihre Zeit mit Nebensächlichkeiten zu 
vertun (Sieht man oft):
Es ist ganz wichtig, dass ein Programm beim Hochfahren 5 verschiedene 
Startup Screens ausgibt, in denen in 7 verschiedenen Sprachen der Name 
des Programms und das Copyright ausgegeben wird. Um das zu 
implementieren brauchen sie 3 Wochen .... und dann wissen sie nicht mehr 
weiter und brauchen Hilfe weil der Abgabetermin schon morgen ist :-)

Neulinge tendieren auch gerne dazu, einen wunderschönen Programmheader 
zu malen. Da ist dann ihr halber Lebenslauf drinn und die komplette GPL, 
möglichst ansprechend formatiert und mit Rahmen aus * versehen. Dann 
schreiben sie noch  int main() {} und dann wissen sie nicht weiter.

Ich sag nicht, dass das alles nicht wichtig wäre. Das hat alles 
sicherlich seine Berechtigung. Aber wichtiger wäre zunächst, dass das 
Programm zumindest in Ansätzen seine Funktion erfüllt. Ein 
funktionierendes Programm ohne GUI ist zunächst erst mal ein Programm, 
dass eine Funktion erfüllt. Ein nicht funktionierendes Programm mit 
wunderschöner GUI hingegen ist zu nichts zu gebrauchen ausser als 
Anschauungsobjekt für einen Kunden um ihm zu zeigen was einmal werden 
wird. Und dann wird sowieso meistens alles ganz anders.

> Simulation soll wie folgt laufen: Vom Lehrer bekomm ich n anderes
> Board mit mehr Ports. Somit kann ich mir einen "großen Sockel"
> bauen. Wenn dann ein "AND" IC gewählt wird soll an z.b. PC1 und
> PC2 drauf geachtet werden, dass wenn da eine -1- ist, dass dann
> an PC3 auch eine -1- ausgegeben wird.

Bevor du deine Zeit jetzt mit großartigen Menüsteuerungen verbrauchst: 
Hast du den Teil schon versucht? Nimm einfach an, dein fiktiver Benutzer 
hätte AND ausgewählt. Kannst du ein Programm schreiben, welches genau 
dieses AND an den Pins PC1, PC2 und PC3 simuliert?

Was ist, wenn die Vorgabe ein OR Glied ist?

Was, wenn beide Gatter gleichzeitig im Programm sein sollen, und mit 
einer Taste soll umgeschaltet werden (Einen Tastendruck kannst du ja 
jetzt schon sauber auswerten). Wie kannst du programmintern 
unterscheiden, welche Einstellung jetzt gilt bzw. wie kannst du anhand 
dieser Einstellung die Gatterfunktion durchführen? Wie kannst du mehrer 
Gatterfunktionalitäten im Programm sinnvoll organisieren?

Und dann kannst du verallgemeinern auf mehrere verschiedene Gattertypen.
In deinem Fall (und das ist oft so) ist die einfachere Art der 
Entwicklung die, bei der Funktionalität anzufangen und sich von dort aus 
zum GUI vorzuarbeiten. Die Benutzerführung ergibt sich dann ganz von 
alleine und auch welche Benutzerführung sinnvoll und zweckmässig ist. 
Gerade unerfahrene Entwickler neigen oft dazu viel zu komplizierte 
Benutzerführungen mit 100-tausend Menüebenen zu entwerfen nur um dann 
festzustellen, dass das alles nicht praxistauglich ist, bzw das die 
Entwicklungszeit um ist und die eigentliche Funktionalität nicht richtig 
funktioniert.

Aber auch wenn du schon mit dem Menü anfängst, ist es sinnvoll eine Idee 
davon zu haben, wie das Programm in seiner eigentlichen Funktionalität 
intern funktionieren wird.

Zb. versteifst du dich im Moment darauf, dass es eine Unterscheidung 
zwischen "Auswahl" und "Simulation" geben muss. Aber wozu diese 
Unterscheidung? Warum kann das Programm nicht ständig irgendein Gatter 
simulieren und mit Tastendruck wird dieses 'irgendein' gegen ein anderes 
ausgetauscht.

1

void DisplayGatter( int was )

2

{

3

  lcd_clrscr();

4

5

  lcd_gotoxy( 0, 0 );

6

7

  if( was == 1 )

8

    lcd_puts( "AND / 1,2=I 3=O" );

9

10

  else if( was == 2 )

11

    lcd_puts( "OR  / 1,2=I 3=O" );

12

13

  else

14

    lcd_puts( "Fehler" );

15

}

16

17

int main()

18

{

19

   ...

20

21

  Gatter = 1;    // 1 ist UND, 2 ist ODER

22

  DisplayGatter( Gatter );

23

24

  while( 1 ) {

25

26

    if( Gatter == 1 )

27

      ... Funktionalität für UND

28

29

    else if( Gatter == 2 )

30

      ... Funktionalität für ODER

31

32

33

    if( get_key_short( 1<<KEY0) ) {   // Umschalttaste gedrückt worden?

34

      Gatter++;

35

      if( Gatter == 3 )

36

        Gatter = 1;

37

38

      DisplayGatter( Gatter );

39

    }

40

41

  }

42

}

Das implementiert zb. genau diese Funktionalität: Das Programm simuliert 
ein bestimmtes Gatter und mit Tastendruck wird auf ein anderes Gatter 
umgeschaltet. Und das alles in weniger Code als dein Menü mit Submenü 
verbraucht. Es ist einfacher zu implementieren, es ist einfacher und 
intuitiver zu benutzen. Ich will ein anderes Gatter, also drück ich auf 
den Knopf. Mehr braucht ein Benutzer nicht zu tun. Insbesondere muss er 
sich nicht merken, dass er mit einem langen Tastendruck zuerst die 
Simulation stoppen muss, dann mit einem anderen Tastendruck in die 
Auswahl gehen, dort das Gatter auswählen, dort wieder mit einem langen 
Tastendruck bestätigen, mit wieder einem anderen Tastendruck die 
Simulation wieder starten. Wenn das nicht kompliziert ist im Vergleich 
zu: Ich drück auf eine Taste und schalte damit auf das nächste Gatter 
um, dann weiß ich auch nicht.

Und wenn man will, könnte man da auch noch einen 2.ten Taster mit der 
Funktion "Simulation ein/ausschalten" einbauen. Wie der ins System 
eingreifen könnte sollte sich auch für Einsteiger völlig logisch 
ergeben.

Aber das fällt genau unter den Fall: zuerst machen wir mal die 
Funktionalität fertig und dann kommen die Komfortfunktionen dazu.

Aus Softwaresicht wäre es zunächst wichtiger die obige einfache Struktur 
so umzugestalten, dass sie gut auf 200 Gatter erweitert. D.h. zb das man 
sich darüber Gedanken macht, wie man die 200 if-else_if in 
Display_Gatter los werden kann. Das man sich Gedanken darüber macht, wie 
man zb die notwendige Umkonfigurierung der Ein/Ausgabepins beim 
Umschalten so gestaltet, dass das alles nicht in endlos lange 
switch-case Strukturen ausartet. Da warten noch viele Detailprobleme, 
die nichts mit Menüs oder langen und kurzen Tastendrücken zu tun haben 
oder damit, dass das Programm beim Hochfahren den zuletzt gewählten 
Gattertyp wieder automatisch selektiert (weil der im EEPROM steht).

gast schrieb:
> wie wird das teil mit strom versorgt ?

Es wird über einen externen Gleichspannungsregler an´s Board 
geschlossen.

Desweiteren bekommt das Board über das mySmart USB einm wenig 
Stromzufuhr.

mfg Theo