F1-Drehzahlanzeige selber programmieren

[Daniel C. (apokya)]

Hallo µC-Gemeinde,

ich möchte einen ATmega programmieren.
Hierbei handelt es sich um eine Drehzahl- und Ganganzeige für ein Kart,
wie bei einem Formel 1-Wagen.

Der Schaltplan ist im Anhang und die Elektronik schon fertig gebaut.

Hier in diesem Beitrag geht es um die Programmierung des Programms. 
Vorrangig mit AtmelStudio.

Das Programm soll folgende Funktionen später enthalten:
- Drehzahl einer Hochspannungskondensatorzündung (CDI) ohne Zündspule
messen, Signalabnahme am Pickup der Lichtmaschine.

- Drehzahl über 15 LEDs als Bandanzeige anzeigen (F1-Wagen)
- Drehzahlbereich einmal 0 - 10.000 U/min für Gang "D" und/oder
- Drehzahlbereich aufgeteilt für die Gänge "1" - "5"
- Anzeige eines Problems, wenn Handbremse angezogen (Gang "P") und 
Drehzahl über Leerlauf

- Reale Ganganzeige über Pineingänge: D, N, R und P
- Gänge fiktiv nach Drehzahl anzeigen und berechnen (1, 2, 3, 4 und 5)
- Umschalten der Anzeige zwischen Gang "D" und Gänge "1" - "5" durch 
gedrückt halten der Taster ermöglichen

- Helligkeit über Soft-PWM mittels LDR
- Multiplexing der Anzeige für Drehzahl und Gang

- Nebelschlussleuchte blinken lassen, je nach Eingang, Timerabhängig
- Blinken mit Taster wechsel-, start- und stopbar
- 4 verschiedene Modi, teilweise durch Bremsen aktiviert
- Wenn der Aufwand nicht zu groß gerne auch mit zusätzlicher 
Drehzahlüberwachung: Sollte die Drehzahl beim Bremsen sehr stark 
abfallen erneutes Aktivieren in einem Modi
- Eingeschalteter bzw. gewählter Modi durch Anzeige der 4 eigenen LEDs
- Sperre für erneute Aktivierung für 5-10 Sekunden bei einem Modi


Ich bin fast Programmier-Neuling und brauche eure Hilfe. Ich brauche 
euch, indem ihr mit verständlich klar macht, wie man ein solches Projekt 
am einfachsten Angeht, welche Schritte zuerst gemacht werden müssen, 
sollten und sollten.
Was an Vorarbeit zu leisten ist und mit welchen Ansätzen man anfängt.

Und wenn etwas an der Hardware fehlt oder garnicht so ehen kann, darf 
das natürlich auch gerne angesprochen werden.

Aber eine Bitte habe ich: Keine blöden Kommentare.
Schon mal vielen Dank für alle Anregungen, Tipps und Hilfestellungen.

Mit freundlichen Grüßen
Daniel

[Mitlesa (Gast)]

Daniel C. schrieb:
> Aber eine Bitte habe ich: Keine blöden Kommentare.

Das sieht danach aus als ob wir hier die Software für
dich schreiben müssen/sollen.

[Daniel C. (apokya)]

Auf keinen Fall. Das ist dann ein Missverständnis.

Es geht um folgendes: Z.B. soll ich anfangen ein Flussdiagramm zu 
erstellen. Oder das erste ist der Aufbau des Programms. Dabei sollen 
folgende Dinge beachtet werden.

Ich würde gerne von Anfang an wissen, wie man so etwas richtig angeht 
und nicht wild anfangen und zu keinem Ziel kommen, da ich mich dauernd 
in irgendwelchen Ideen verrenne.

Gruß Danielli

[Mitlesa (Gast)]

Daniel C. schrieb:
> Auf keinen Fall. Das ist dann ein Missverständnis.

Das widerspricht aber in grossen Zügen dieser Aussage:

Daniel C. schrieb:
> Ich bin fast Programmier-Neuling und brauche eure Hilfe.

... denn Programmieren lernt man nicht von heute auf morgen.

[Daniel C. (apokya)]

Mitlesa schrieb:
> Daniel C. schrieb:
>> Auf keinen Fall. Das ist dann ein Missverständnis.
>
> Das widerspricht aber in grossen Zügen dieser Aussage:
>
> Daniel C. schrieb:
>> Ich bin fast Programmier-Neuling und brauche eure Hilfe.
>
> ... denn Programmieren lernt man nicht von heute auf morgen.

Wieso sollte ich mich wiedersprechen?
"Ich bin Programmier-Neuling". Ja das bin ich. Bis auf ein paar Ein- und 
Ausgänge kann ich noch nicht sonderlich viel Programmieren und weiß bei 
meinem Projekt auch noch nicht wo man da anfange kann.

> Daniel C. schrieb:
>> Ich bin fast Programmier-Neuling und brauche eure Hilfe.
>
> ... denn Programmieren lernt man nicht von heute auf morgen.

Habe ich mit keinem Wort gesagt, oder?


Ich möchte Programmieren lernen, es aber direkt auf meine Schaltung 
anwenden, um direkt Hard- und Software zu vereinen und meinem Ziel - dem 
fertigen Progamm- näher zu kommen.

Ich werde sicherlich nicht für ein paar Anwendungen extra Lernboard für 
zig Euro kaufen, um dort das gleiche oder ähnliche Aufgaben zu machen, 
die ich auf meinem Chip und Board auch machen kann ;)


Ich möchte, wenn es um Code geht später meinen einstellen, der von euch 
Fehlerkorrigiert wird, wenn etwas nicht stimmt. Aber was ich brauche ist 
halt jemand der mir sagt, wie man dieses komplexe Programm am cleversten 
aufbaut.

Nicht böse nehmen ;)

Gruß Daniel

[Bernd N (Gast)]

Du hast ja deine Teilaufgaben ganz gut beschrieben. Die arbeitest du 
Schritt für Schritt ab.
>> - Drehzahl über 15 LEDs als Bandanzeige anzeigen (F1-Wagen)

Nehmen wir den Teil mal heraus. Als Anfänger weisst du sicherlich schon 
wie man eine LED einschaltet ? Wenn nicht dann fang damit an. 
Anschließend machst du dich an die "Bandanzeige", Leuchtband. Bekommst 
du das schon hin ?

Wenn nicht dann mach dich ans Tutorial auf dieser Seite.
https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial

Mein Tipp, nicht Alles auf einmal.

[Michael L. (ml21)]

Ich rate dir: Fang klein an.
Versuche erst eine LED zum Leuchten zu bringen, dann mehrere, dann 
blinken.
Danach kannst du einen Sensor einlesen und den Status mit LEDs anzeigen.
Hier gibt es viele Tutorials für die simplen Dinge. Die solltest du auch 
durchlesen und selbst programmieren.

Ein Flussdiagramm kannst du machen wenn du weißt was du brauchst.
Was nützt dir das Diagramm, wenn du nicht weißt, wie sich z.B. die Timer 
verhalten. Oder wie du die LEDs ansprichst.

Und: Es gibt nicht DIE Lösung für dein Problem. Jeder wird es anders 
machen. So lange aber das Ergebnis passt, ist das OK.

[Daniel C. (apokya)]

Bernd N schrieb:
> Als Anfänger weisst du sicherlich schon wie man eine LED einschaltet ?

Ja, das bekomme ich hin. Das habe ich schnell verstanden.

> Anschließend machst du dich an die "Bandanzeige", Leuchtband. Bekommst
> du das schon hin ?

Wenn es darum geht, die nacheinander ein- bzw. auszuschalten: Ja.


Michael L. schrieb:
> Danach kannst du einen Sensor einlesen und den Status mit LEDs anzeigen.

Habe den LDR mal aus Spaß eingelesen und verarbeitet. Klappt auch 
einiger Maßen.

> Und: Es gibt nicht DIE Lösung für dein Problem. Jeder wird es anders
> machen. So lange aber das Ergebnis passt, ist das OK.

Das ist mir klar. Man bildet sich auch selbst eine Meinung zu dem 
Gesagten.



Mit dem "klein Anfangen" habt ihr beide recht. Das ist wahr. Ich werde 
aber nicht durch diese Tutorials schlau. Ich brauche irgendwie etwas 
angepasstere Hilfe. Super wäre z.B., wenn man zusammen sich Gedanken 
über den Programmaufbau machen kann und ob und in wieweit man alles 
bahandelt.

Oder halt irgendwas immer größer machen und erweitern. Hier merkt man 
schon an den Aussagen: Keine Ahnung :D

Z.B. würde ich gerne für Das Drehzahlband (DZB) und die Segmentanzeige 
eine Art Stapel anlegen. Aber da habe ich ebenso keine Ahnung von.
Ob das Sinn macht weiß ich natürlich auch nicht.

[Bernd N (Gast)]

Dann stell doch mal den Code oder die Codeschnipsel die funktionieren 
hier ein und dann werden wir dir schon helfen das zu strukturieren.

Wie sieht es mit der 7 Segment Anzeige aus ? Code auch schon fertig ?

Wie gesagt, Schrit für Schritt und dann alles zusammenbauen. Da wird man 
dir schon helfen.

[m.n. (Gast)]

Mitlesa schrieb:
> Daniel C. schrieb:
>> Aber eine Bitte habe ich: Keine blöden Kommentare.
>
> Das sieht danach aus als ob wir hier die Software für
> dich schreiben müssen/sollen.

Ein alter Hut, wie man hier nachlesen kann:
Beitrag "ATmega-Programmierer gesucht"

[Daniel C. (apokya)]

Bernd N schrieb:
> Dann stell doch mal den Code oder die Codeschnipsel die
> funktionieren
> hier ein und dann werden wir dir schon helfen das zu strukturieren.
>
> Wie sieht es mit der 7 Segment Anzeige aus ? Code auch schon fertig ?
>
> Wie gesagt, Schrit für Schritt und dann alles zusammenbauen. Da wird man
> dir schon helfen.


Ich habe viele Ideen probeweise umgesetzt, um die beste Lösung für mich 
zu finden. Deswegen sieht das so wüst aus.
Alles andere was ich habe ist in Arduino, aber das möchte ich nicht mehr 
nutzen.

#include <avr/io.h>
#include <util/delay.h>
#define F_CPU 16000000UL

/*
//Startbild-Zeiten(ms)
  #define T_SB_STATUS   50
  #define T_SB_FUELLEN  50
  #define T_SB_WARNUNG  50
  #define T_SB_LEEREN   50
  #define T_SB_ALLE     50
  #define T_SB_ZEICHEN  50
  #define T_SB_START    50*/

//Ausgänge
  #define NSL PB0        //Ausgang fuer Nebelschlussleuchte (PB0)
  #define DZB PB1        //Ausgang fuer Drehzahlband (PB1)
  #define SEG PB3        //Ausgang fuer Segment Display (PB3)

//Status-LEDs
  #define S_LED_1 PB4
  #define S_LED_2 PB5
  #define S_LED_3 PB6
  #define S_LED_4 PB7

//Gaenge
  #define DN PA4        //D/N
  #define NR PA5        //N/R
  
//Bremsen
  #define B PA7        //Bremse
  #define HB PA6        //Handbremse

int main (void) {

  DDRB = 0b11111011;      //Ausgang B0-B1, B3-B7
  DDRC = 0b11111111;      //Ausgang C
  DDRD = 0b11111111;      //Ausgang D
  PORTC = 0b00000000;      //Zustand Low 
  PORTD = 0b00000000;      //Zustand Low
  
  //PORTB |= (1 << NSL) | (1 << DZB) | (0 << SEG);  //Transistoren: 1 = Aus / 0 = An
  
  PORTB |=  (1 << PB0);    //" |= " = Aus / " &= ~ " = An
  PORTB |=  (1 << PB1);
  PORTB &= ~(1 << PB3);

  uint8_t PortCD = 0;
  uint8_t S_LED = 0;
  
  while(1) {            
    /*
    PORTB |= ((1 << PB4) | (0 << S_LED_2) | (0 << S_LED_3) | (0 << S_LED_4));
    _delay_ms(1000);
    PORTB |= ((1 << PB4) | (1 << S_LED_2) | (0 << S_LED_3) | (0 << S_LED_4));
    _delay_ms(1000);      
    PORTB |= ((1 << PB4) | (1 << S_LED_2) | (1 << S_LED_3) | (0 << S_LED_4));      
    _delay_ms(1000);
    PORTB |= ((1 << PB4) | (1 << S_LED_2) | (1 << S_LED_3) | (1 << S_LED_4));
    _delay_ms(1000);
    PORTB |= ((0 << PB4) | (1 << S_LED_2) | (1 << S_LED_3) | (1 << S_LED_4));
    _delay_ms(1000);
    PORTB |= ((1 << PB4) | (0 << S_LED_2) | (1 << S_LED_3) | (1 << S_LED_4));
    _delay_ms(1000);
    PORTB |= ((1 << PB4) | (1 << S_LED_2) | (0 << S_LED_3) | (1 << S_LED_4));
    _delay_ms(1000);
    PORTB |= ((1 << PB4) | (1 << S_LED_2) | (1 << S_LED_3) | (0 << S_LED_4));
    _delay_ms(1000);
    PORTB |= ((0 << PB4) | (0 << S_LED_2) | (1 << S_LED_3) | (1 << S_LED_4));
    _delay_ms(1000);*/
    /*
    PORTB &= ~(1 << S_LED_1);    //" |= " = Aus / " &= ~ " = An
    PORTB |=  (1 << S_LED_2);
    PORTB |=  (1 << S_LED_3);
    PORTB |=  (1 << S_LED_4);
    _delay_ms(1000);
    PORTB &= ~(1 << S_LED_1);
    PORTB &= ~(1 << S_LED_2);
    PORTB |=  (1 << S_LED_3);
    PORTB |=  (1 << S_LED_4);
    _delay_ms(1000);
    PORTB &= ~(1 << S_LED_1);
    PORTB &= ~(1 << S_LED_2);
    PORTB &= ~(1 << S_LED_3);
    PORTB |=  (1 << S_LED_4);
    _delay_ms(1000);
    PORTB &= ~(1 << S_LED_1);
    PORTB &= ~(1 << S_LED_2);
    PORTB &= ~(1 << S_LED_3);
    PORTB &= ~(1 << S_LED_4);
    _delay_ms(1000);
    PORTB |=  (1 << S_LED_1);
    PORTB &= ~(1 << S_LED_2);
    PORTB &= ~(1 << S_LED_3);
    PORTB &= ~(1 << S_LED_4);
    _delay_ms(1000);
    PORTB &= ~(1 << S_LED_1);
    PORTB |=  (1 << S_LED_2);
    PORTB &= ~(1 << S_LED_3);
    PORTB &= ~(1 << S_LED_4);
    _delay_ms(1000);
    PORTB &= ~(1 << S_LED_1);
    PORTB &= ~(1 << S_LED_2);
    PORTB &= ~(1 << S_LED_3);
    PORTB |=  (1 << S_LED_4);
    _delay_ms(1000);
    PORTB |=  (1 << S_LED_1);
    PORTB &= ~(1 << S_LED_2);
    PORTB &= ~(1 << S_LED_3);
    PORTB |=  (1 << S_LED_4);
    _delay_ms(1000);
    PORTB |=  (1 << S_LED_1);
    PORTB |=  (1 << S_LED_2);
    PORTB &= ~(1 << S_LED_3);
    PORTB &= ~(1 << S_LED_4);
    _delay_ms(1000);*/
    PORTB |=  (1 << S_LED_1);
    PORTB |=  (1 << S_LED_2);
    PORTB |=  (1 << S_LED_3);
    PORTB |=  (1 << S_LED_4);
    _delay_ms(1000);
    
    /*S_LED = 1;
    _delay_ms(1000);
    S_LED = 2;
    _delay_ms(1000);
    S_LED = 3;
    _delay_ms(1000);
    S_LED = 4;
    _delay_ms(1000);
    S_LED = 5;
    _delay_ms(1000);*/
      
    if (PortCD >= 16) {
      PortCD = 0;
    }
    else {
      PortCD++;
    }
    
    switch (PortCD) {
      case 1:    PORTC = 0b00000001; PORTD = 0b00000000;
      break;
      case 2:    PORTC = 0b00000011; PORTD = 0b00000000;
      break;
      case 3:    PORTC = 0b00000111; PORTD = 0b00000000;
      break;
      case 4:    PORTC = 0b00001111; PORTD = 0b00000000;
      break;
      case 5:    PORTC = 0b00011111; PORTD = 0b00000000;
      break;
      case 6:     PORTC = 0b00111111; PORTD = 0b00000000;
      break;
      case 7:     PORTC = 0b01111111; PORTD = 0b00000000;
      break;
      case 8:     PORTC = 0b11111111; PORTD = 0b00000000;
      break;
      case 9:     PORTC = 0b11111111; PORTD = 0b00000001;
      break;
      case 10:    PORTC = 0b11111111; PORTD = 0b00000011;
      break;
      case 11:    PORTC = 0b11111111; PORTD = 0b00000111;
      break;
      case 12:    PORTC = 0b11111111; PORTD = 0b00001111;
      break;
      case 13:    PORTC = 0b11111111; PORTD = 0b00011111;
      break;
      case 14:    PORTC = 0b11111111; PORTD = 0b00111111;
      break;
      case 15:    PORTC = 0b11111111; PORTD = 0b01111111;
      break;
      case 16:    PORTC = 0b11111111; PORTD = 0b11111111;
      break;
      default:    PORTC = 0b00000000; PORTD = 0b00000000;
      break;
    }
    /*
    switch (S_LED) {
      case 1:     PORTB &= ~(1 << S_LED_1); PORTB |=  (1 << S_LED_2); PORTB |=  (1 << S_LED_3); PORTB |=  (1 << S_LED_4);
      break;
      case 2:     PORTB &= ~(1 << S_LED_1); PORTB &= ~(1 << S_LED_2); PORTB |=  (1 << S_LED_3); PORTB |=  (1 << S_LED_4);
      break;
      case 3:     PORTB &= ~(1 << S_LED_1); PORTB &= ~(1 << S_LED_2); PORTB &= ~(1 << S_LED_3); PORTB |=  (1 << S_LED_4);
      break;
      case 4:     PORTB &= ~(1 << S_LED_1); PORTB &= ~(1 << S_LED_2); PORTB &= ~(1 << S_LED_3); PORTB &= ~(1 << S_LED_4);
      break;
      case 5:     PORTB |=  (1 << S_LED_1); PORTB &= ~(1 << S_LED_2); PORTB &= ~(1 << S_LED_3); PORTB &= ~(1 << S_LED_4);
      break;
      case 6:       PORTC = 0b00111111; PORTD = 0b00000000;
      break;
      case 7:       PORTC = 0b01111111; PORTD = 0b00000000;
      break;
      case 8:       PORTC = 0b11111111; PORTD = 0b00000000;
      break;
      case 9:       PORTC = 0b11111111; PORTD = 0b00000001;
      break;
      case 10:       PORTC = 0b11111111; PORTD = 0b00000011;
      break;
      case 11:       PORTC = 0b11111111; PORTD = 0b00000111;
      break;
      case 12:       PORTC = 0b11111111; PORTD = 0b00001111;
      break;
      case 13:       PORTC = 0b11111111; PORTD = 0b00011111;
      break;
      case 14:       PORTC = 0b11111111; PORTD = 0b00111111;
      break;
      case 15:       PORTC = 0b11111111; PORTD = 0b01111111;
      break;
      case 16:       PORTC = 0b11111111; PORTD = 0b11111111;
      break;
      default:    PORTB |=  (1 << S_LED_1);
            PORTB |=  (1 << S_LED_2);
            PORTB |=  (1 << S_LED_3);
            PORTB |=  (1 << S_LED_4);
      break;
    }*/
    
  }
                           
  return 0;
  
}

[neuer PIC Freund (Gast)]

Du kannst fast alle LEDs rausschmeißen, bis auf 2. Eine für "langsam", 
die andere für "schnell". Der LM2907 generiert ein Analogsignal. Damit 
gehst du an einen digitalen Eingang. Das ist bestimmt anders gewollt.

Und kick D22 raus.

[Daniel C. (apokya)]

neuer PIC Freund schrieb im Beitrag #4890873:
> Du kannst fast alle LEDs rausschmeißen, bis auf 2. Eine für
> "langsam", die andere für "schnell".

Welche LEDs sind gemeint?


> Der LM2907 generiert ein Analogsignal. Damit
> gehst du an einen digitalen Eingang. Das ist bestimmt anders gewollt.

Ist nur als Reckeck-Signalwandler gedacht, ja. Das ist etwas anders 
gewollt.
Ich hoffe das geht so trotzdem :D


> Und kick D22 raus.

Warum das?

[neuer PIC Freund (Gast)]

Ohja die Brücke von Pin 2-3 führt zu Figure 29. Aber wie bekommst du 
0-Potential an Pin 1. Ansonsten wäre dieses Signal besser an einem 
Timer-Eingang aufgehoben.

D22: Wenn man weiß, wofür sie gut ist, kann man sie hier weglassen. 
Höherwertige Regler haben diese teilweise schon eingebaut.

Debuggen über JTAG geht jetzt wohl nicht mehr. Würde dir als Anfänger 
sehr helfen.

[Daniel C. (apokya)]

Stefan U. schrieb im Beitrag #4891075 im Forum "ATmega-Programmierer 
gesucht":
> Sieht aus wie meine Arbeiten :-)

Danke für dein Kompliment :)


> Für den Anfang solltest du mal berichten,
>
> - wie so deine Programmierkenntnisse sind
> - ob du engliche Datenblätter lesen kannst
> - mit welchem Betriebsystem du arbeitest
>
> Hast du schonmal ein AVR Tutorial durchgearbeitet? Mit welchen
> Funktionseinheiten (Ports, ADC, Interrupts, Timer, etc) hast du dich
> vertraut gemacht? Welche hast du nur mal kurz ausprobiert aber nicht
> weiter vertieft?

Meine Programmierkenntnisse beschränken sich auf Pinbennenung, als Ein- 
oder Ausgang deklarieren, sowie auf Low und High setzen.

Ich kann englisch lesen, kann aber mit den vielen Begriffen in einem 
Datenblatt schwer umgehen. Würde es aber irgendwie hinbekommen, wenn ich 
weiß, wo ich suchen muss.

Ich habe Arduino kennen gelert und arbeite jetzt, durch die 
Verständlichkeit mit anderen, jetzt in AtmelStudio in C, bzw. GCC (wenn 
das einen Unterschied macht).

Ich habe Teile des Tutorials durchgearbeitet. Leider ist nicht alles auf 
meinem Board anwendbar, wie Hard-PWM über PWM-Pin. Da ich aber nicht 
extra dafür ein Board kauefen möchte, bleibt es bei lesen und versuchen 
zu verstehen.

Die Funktionseinheiten Ports und ADC habe ich kennen gelernt und kann 
diese anwenden. Interrupts und Timer übersteigen im Moment meine 
Fähigkeiten.


> Es gibt viele Anleitungen, wo man das Programmieren anhand kleiner
> einfacher Schaltungen (meistens auf Steckbrett, manchmal eine
> vorgegebene Platine) erlernt. Du hast hier eine eigene Schaltung.
>
> Nun ist es so, dass meistens eine Person mit viel Zeiteinsatz ein
> Tutorial schteibt, damit es viele nutzen.
>
> In deinem Fall brauchst du wohl Anleitungen von vielen für eine einzige
> persönliche Schaltung. Hier stimmt für alle betroffenen außer Dir das
> Verhältnis von Aufwand zu Nutzen nicht.
>
> Deswegen frage ich Dich, ob du bereit bist, deine Schaltung erstmal
> beiseite zu legen und das Programmieren anhand von vorgegebenen
> Schaltungen und Programmfragmenten zu üben. Du kannst dich ja gezielt
> auf die Teile konzentrieren, die für dein konkretes Ziel hilfreich sind.
> Und nach dem Tutorial stellst du in einem neuen Thread konkrete Fragen
> zur Umsetzung des Gelernten auf DEINE Schaltung. Was hälst du davon?

Das ist richtig. Nur leider möchte ich das Programmieren direkt auf 
meinem Board üben und anwenden. Es ist auch nicht so, dass ich garnichts 
verstehe, oder schwer hinterher komme. Es ist nur einfach so, dass ich 
ein wenig Starthilfe brauche und denke, dass ich das auch so hinbekomme.

D.h. im Endeffekt: Nein. Ich möchte ungerne meine Schaltung jetzt 
beiseite legen und dann für ein halbes Jahr nur an einem Board 
rumbasteln, wofür mir eigentlich viele Teile fehlen. Mein Board kann die 
gleichen Dinge, nur lerne ich direkt für mein ganzes Projekt und nicht 
für einen simulierten Fall. Oder sehe ich das falsch.


> Das waren viele Fragen. Beantworte sie, dann wird es sicher konkrete
> Vorschläge für Anleitungen, Tutorial, Bücher, Baukästen, ... hageln.

Danke für deine ausführliche Fragerunde. Ich hoffe ich konnte alles das 
beantworten, was gefragt war. :)

Gruß Danielli

[Theor (Gast)]

Daniel C. schrieb:
> Stefan U. schrieb im Beitrag #4891075 im Forum "ATmega-Programmierer
> gesucht":
>> Sieht aus wie meine Arbeiten :-)
>
> Danke für dein Kompliment :)
>
>
> [...]

>> In deinem Fall brauchst du wohl Anleitungen von vielen für eine einzige
>> persönliche Schaltung. Hier stimmt für alle betroffenen außer Dir das
>> Verhältnis von Aufwand zu Nutzen nicht.
>>
>> Deswegen frage ich Dich, ob du bereit bist, deine Schaltung erstmal
>> beiseite zu legen und das Programmieren anhand von vorgegebenen
>> Schaltungen und Programmfragmenten zu üben. Du kannst dich ja gezielt
>> auf die Teile konzentrieren, die für dein konkretes Ziel hilfreich sind.
>> Und nach dem Tutorial stellst du in einem neuen Thread konkrete Fragen
>> zur Umsetzung des Gelernten auf DEINE Schaltung. Was hälst du davon?
> [...]
> D.h. im Endeffekt: Nein. Ich möchte ungerne meine Schaltung jetzt
> beiseite legen und dann für ein halbes Jahr nur an einem Board
> rumbasteln, wofür mir eigentlich viele Teile fehlen. Mein Board kann die
> gleichen Dinge, nur lerne ich direkt für mein ganzes Projekt und nicht
> für einen simulierten Fall. Oder sehe ich das falsch.

Dann kann man eigentlich nur nochmal Stefans Bemerkung hervorheben, dass 
das Verhältnis von Aufwand und Nutzen für die Antworter extrem ist.
Meiner Einschätzung nach, wird der Thread und damit Dein Projekt 
letztlich genau daran scheitern.

Obwohl die meisten Leser durchaus bereit sind und das auch tun, 
sogenannte "triviale" Fehler zu nennen und ebensolche Sachverhalte zu 
erklären, beschränkt sich das tendentiell eher auf Einzelfälle bei denen 
noch dazu erkennbar ist, dass der Fragesteller einigermaßen sinnvoll 
vorgeht.

Als einigermaßen sinnvoll, vor allem weil millionenfach bewährt, wird 
betrachtet, vom Einfachen zum Komplexen vorzugehen.

Dein Hauptirrtum liegt, meiner Ansicht nach, darin, davon auszugehen, 
dass eine Summe von einfachen Teilen insgesamt nicht komplizierter zu 
handhaben ist, als jedes Teil für sich. Aber das trifft nicht zu.

Technisch gesehen, beeinflussen sich alle Teile mehr oder weniger stark 
gegenseitig. In der Programmierung sind eine PWM und eine Echtzeituhr 
jeweils für sich einfacher, als deren Vereinigung, die, bestimmte 
Probleme hervoruft, die gerade aus der Vereinigung entstehen.

Die Arbeitsweise selbst, wird aber zusätzlich davon beeinflusst, welche 
Kenntnisse und Fähigkeiten vorhanden sind und welche noch erworben 
werden müssen und beeinflusst wiederum ob und wie man bestimmte Probleme 
löst.

Wenn ich versuche mir vorzustellen, wie das in Deinem Fall abläuft, 
kommt etwa heraus, dass Du einen Kurzschluss in Deinem, meiner Meinung 
nach, zu engem Aufbau suchst, den nicht findest; einen Teil Deines 
Programmes nicht verstehst, den Du anstatt, anhand von Kenntnissen, aus 
der Intuition heraus für verantwortlich hälst; dann ein wenig über C 
lernst, und schliesslich dabei endest, dass Du das ohmsche Gesetz 
nochmal repetierst dann aber doch nicht weiterkommst, weil die Schaltung 
dann doch komplexer ist, als die einfachen Lehrbeispiele.

Ich vermute, mag mich aber irren, dass Dein Hauptinteresse darin liegt, 
diese eine Schaltung fertig zu kriegen und nicht mehr. An der 
Elektronik, der Programmierung bist Du nur insofern interessiert als es 
diesem Zweck dient.

Das aber ist nicht der Schwerpunkt des Interesses der Leser hier. Die 
wirklich kompetenten Leute wollen intellektuelle Herausforderungen (wie 
andere Menschen Kreuzworträtsel oder ähnliches lösen) bzw. anderen, die 
lernen wollen und am Thema insgesamt interessiert sind, weiter helfen. 
Das berühmte "helfen, sich selbst zu helfen".

Man darf sich nicht davon irreführen lassen, das hier oft durchaus 
triviale Fragestellungen beantwortet werden. Entweder ist erkennbar, wie 
oben schon erwähnt, dass der Fragesteller sich auf dem Weg befindet /um 
der Sache selbst willen/ technisches Wissen zu erwerben und anzuwenden 
oder es kostet sehr geringe Mühe die Antwort zu geben.

Aber in Deinem Fall bin ich ziemlich sicher, dass Du soviel zu lernen 
und zu üben hast, dass ein tatsächlicher Versuch Dich darin zu begleiten 
auf die Anstellung (und Bezahlung) einer Art Privatlehrer hinausläuft. 
Wobei er vermutlich einige Zeit investieren wird, Dich davon zu 
überzeugen, dass Du am Anfang beginnen musst. Wenn er sich aber 
breitschlagen lässt, es auf Deinem Weg zu versuchen, wirst Du auf jeden 
Fall viel Geld los; unter 50 oder 100 Euro die Stunde würde ich das 
jedenfalls nicht auf mich nehmen. Ist halt wie Klavierstunden. Die hören 
sich auch alles an und wenn sich die Löcher in den Socken 
zusammenziehen. Aber das ist das wovon sie leben.

Dein ursprünglicher Ansatz, jemanden zu suchen, der die Schaltung für 
Dich entwickelt, scheint mir wesentlich vielversprechender. Aber das hat 
auch nicht geklappt. Aber es kann schon sein, dass derjenige mit Dir 
oder Du nicht mit ihm "konntest". Dann versuche es besser nochmal.

Ansonsten aber kann ich nur wiederholen: Zurück auf Los. Ziehe keine 
4000 Euro ein. :-)

Dazu noch eine Bemerkung: Der Aufwand ist gar nicht so hoch, wie Du 
vielleicht annimmst. Wenn Du nochmal 20 Euro in die Hand nimmst und 
günstig einkaufst, hast Du alles was man für den Anfang brauchst. Ein 
kleines Baumarkt-Multimeter reicht auch erst mal.

Ich weiß: Sowas willst Du nicht hören. Aber überlege mal, warum sollten 
man Dir hier so etwas erzählen, wenn nicht doch etwas Wahres daran wäre? 
Ob Du Dich so oder so entscheidest, ich habe nichts davon. (Und ich 
muss, da ich so etwas schreibe, jede Möglichkeit, dass gerade ich Dein 
Privatlehrer werde, von vorne herein ausschliessen).

[Mitlesa (Gast)]

Danke Theor für deinen Beitrag, etwas viel Worte aber
ansonsten ganz im Sinne meiner Kurzfassung.

Mitlesa schrieb:
> Das sieht danach aus als ob wir hier die Software für
> dich schreiben müssen/sollen.

[W.S. (Gast)]

Theor schrieb:
> Das aber ist nicht der Schwerpunkt...

Das hast du wirklich schön gesagt, bleibt zu hoffen, daß möglichst viele 
es lesen und daraus was lernen.

Danke für deinen Beitrag.

W.S.

[Bernd N (Gast)]

Dann konzentriere dich jetzt mal auf den Bargraph. Die Bedingungen hast 
du ja ganz gut beschrieben aber davon ist im Code noch nichts zu sehen.

- Drehzahl über 15 LEDs als Bandanzeige anzeigen (F1-Wagen)
- Drehzahlbereich einmal 0 - 10.000 U/min für Gang "D" und/oder
- Drehzahlbereich aufgeteilt für die Gänge "1" - "5"

Soll der Drehzahlbereich auf dem Bargraphen über den Bereich 0 - 10000 
auf 15 LEDs dargestellt werden oder über den Bereich der 5 Gänge ? Bei 5 
Gängen wäre der Bereich ja je 0 - 2000 Umdrehungen pro Gang.

Also:
Gang1 0-2000
Gang2 2000 - 4000
Gang3 4000 - 6000
Gang4 6000 - 8000
Gang5 8000 - 10000

Die Erfassung der Drehzahl und des Gangs kann man später angehen und mit 
2 Variablen simulieren. Dann Die Bargraph Ansteuerung in eine eigen 
Funktion packen.

Bekommst du das hin ?

void BargraphAnsteuerung (uint8_t AnzahlLeds)
{
    ...
}

Die Drehzahlmessung selbst macht dann die Skalierung von Drehzahl zu 
Anzahl LEDs und gibt nur die Anzahl der LEDs an die Ausgabe Funktion.

[Daniel C. (apokya)]

Bernd N schrieb:
> Soll der Drehzahlbereich auf dem Bargraphen über den Bereich 0 - 10000
> auf 15 LEDs dargestellt werden oder über den Bereich der 5 Gänge ? Bei 5
> Gängen wäre der Bereich ja je 0 - 2000 Umdrehungen pro Gang.

Beides. Entweder oder. ;)

Ich habe dam mal was vorbereitet, bin damit aber selbst überhaupt nicht 
einverstanden. Geht sowas nicht übersichtlicher?
Die Werte hauen teilweise auch noch nicht hin, aber das ist ja erstmal 
garnicht wichtig.

//Variablen deklarieren
  uint8_t GArt;
  uint8_t Gang;
  uint16_t Drehzahl;
  uint16_t n1;
  uint16_t n2;

void DZB-Anzeige (uint8_t ALED)    //Drehzahl-Einstellungen
{
  If (GArt = 0) {          //Gang D-R
    
    if (Drehzahl >=1000) {
      ALED = 1
    }
    else if (Drehzahl >=1100) {
      ALED = 2
    }
    else if (Drehzahl >=1200) {
      ALED = 3
    }
    else if (Drehzahl >=1500) {
      ALED = 4
    }
    else if (Drehzahl >=2000) {
      ALED = 5
    }
    else if (Drehzahl >=3000) {
      ALED = 6
    }
    else if (Drehzahl >=4000) {
      ALED = 7
    }
    else if (Drehzahl >=5000) {
      ALED = 8
    }
    else if (Drehzahl >=5500) {
      ALED = 9
    }
    else if (Drehzahl >=6000) {
      ALED = 10
    }
    else if (Drehzahl >=6500) {
      ALED = 11
    }
    else if (Drehzahl >=7000) {
      ALED = 12
    }
    else if (Drehzahl >=7500) {
      ALED = 13
    }
    else if (Drehzahl >=8000) {
      ALED = 14
    }
    else if (Drehzahl >=8500) {
      ALED = 15
    }
  }
  
  else If (GArt = 1) {          //Gang 1-5
    
    if (Gang = 1) {
      n1 = 250
      
      if (Drehzahl >=1000) {
        ALED = 1
      }
      else if (Drehzahl >=1100) {
        ALED = 2
      }
      else if (Drehzahl >=1250) {
        ALED = 3
      }
      else if (Drehzahl >=(1000+(2*n1))) {
        ALED = 4
      }
      else if (Drehzahl >=(1000+(3*n1))) {
        ALED = 5
      }
      else if (Drehzahl >=(1000+(4*n1))) {
        ALED = 6
      }
      else if (Drehzahl >=(1000+(5*n1))) {
        ALED = 7
      }
      else if (Drehzahl >=(1000+(6*n1))) {
        ALED = 8
      }
      else if (Drehzahl >=(1000+(7*n1))) {
        ALED = 9
      }
      else if (Drehzahl >=(1000+(8*n1))) {
        ALED = 10
      }
      else if (Drehzahl >=(1000+(9*n1))) {
        ALED = 11
      }
      else if (Drehzahl >=(1000+(10*n1))) {
        ALED = 12
      }
      else if (Drehzahl >=(1000+(11*n1))) {
        ALED = 13
      }
      else if (Drehzahl >=(1000+(12*n1))) {
        ALED = 14
      }
      else if (Drehzahl >=(1000+(13*n1))) {
        ALED = 15
      }
    }
    
    else if (Gang = 2) {
      n2>=4500
    }
    
    else if (Gang = 3) {
      n2=6000
    }
    
    else if (Gang = 4) {
      n2=7500
    }
    
    else if (Gang = 5) {
      n2=9000
    }  
    
    
    if (Drehzahl >=(n2+00) {
      ALED = 1
    }
    else if (Drehzahl >=(n2+100) {
      ALED = 2
    }
    else if (Drehzahl >=(n2+200) {
      ALED = 3
    }
    else if (Drehzahl >=(n2+300) {
      ALED = 4
    }
    else if (Drehzahl >=(n2+400) {
      ALED = 5
    }
    else if (Drehzahl >=(n2+500) {
      ALED = 6
    }
    else if (Drehzahl >=(n2+600) {
      ALED = 7
    }
    else if (Drehzahl >=(n2+700) {
      ALED = 8
    }
    else if (Drehzahl >=(n2+800) {
      ALED = 9
    }
    else if (Drehzahl >=(n2+900) {
      ALED = 10
    }
    else if (Drehzahl >=(n2+1000) {
      ALED = 11
    }
    else if (Drehzahl >=(n2+1100) {
      ALED = 12
    }
    else if (Drehzahl >=(n2+1200) {
      ALED = 13
    }
    else if (Drehzahl >=(n2+1300) {
      ALED = 14
    }
    else if (Drehzahl >=(n2+1400) {
      ALED = 15
    }
  }
}

[Stephan (Gast)]

wie wäre es mit einem Zeiger und einer Tabelle wo die Werte für ALED und 
n2 drin stehen ?

[Eric B. (beric)]

Daniel C. schrieb:
> If (GArt = 0) {          //Gang D-R
>
>     if (Drehzahl >=1000) {
>       ALED = 1
>     }
>    ...

Das haut von vorne bis hinten nicht.
* Da fehlen überall die abschliessenden ';'-Zeichen
* ALED ist definiert als eine Eingabe-parameter, wird aber in der 
Funktion gesetzt

[Axel R. (Gast)]

Wo geht PIN1 vom XCON9 hin?
Hast Du den Schaltplan gezeichnet?
Kann man bitte diese Art von Blockschaltbild nochmal in eine Version 
bringen, mit der alle etwas anfangen können?
Ich mein, muss ja nicht. Ich würde mich freuen.
StromTuner

[Daniel C. (apokya)]

Stephan schrieb:
> wie wäre es mit einem Zeiger und einer Tabelle wo die Werte für
> ALED und
> n2 drin stehen ?

Kannst du kurz ein Beispiel zeigen?

Eric B. schrieb:
> Daniel C. schrieb:
>> If (GArt = 0) {          //Gang D-R
>>
>>     if (Drehzahl >=1000) {
>>       ALED = 1
>>     }
>>    ...
>
> Das haut von vorne bis hinten nicht.
> * Da fehlen überall die abschliessenden ';'-Zeichen
> * ALED ist definiert als eine Eingabe-parameter, wird aber in der
> Funktion gesetzt

Nicht im ernst, oder? :D
Wie müsste es denn richtig sein?


Axel R. schrieb:
> Wo geht PIN1 vom XCON9 hin?
> Hast Du den Schaltplan gezeichnet?
> Kann man bitte diese Art von Blockschaltbild nochmal in eine Version
> bringen, mit der alle etwas anfangen können?
> Ich mein, muss ja nicht. Ich würde mich freuen.
> StromTuner

Über die Beschriftung PB1 an den Controller-Pin PB1.
PB3 ist leider falsch beschriftet :D

Ist das so schlimm gezeichnet? :P

[Axel R. (Gast)]

> Über die Beschriftung PB1 an den Controller-Pin PB1.
Du siehst selbst nicht durch, scheint es fast...

Links ist ein Q1 (2x) blau eingerahmt zu finden.
X108-1 geht auf PB1, von dort auf PBT von dort auf PBC und von dort nach 
PB1?
der Portpin allein schafft es nicht, die LEDs zu treiben.
MIr jedenfalls, das ist nur ein ganz kleine wenig böse gemeint, ist das 
zu umständlich, mich dort durchzuarbeiten, um Dich gegegenenfalls auf 
Fehler hinweisen zu können.
Daher bin ich raus.

StromTuner

[Axel R. (Gast)]

Links: Eingabe
Mitte: Verabeitung
Rechts: Ausgabe

Blatt1: Eingabe
Blatt2: µC
Blatt3: Stromversorgung
Ballt4: Anschlüsse/Connectoren

Oder so. man kann das doch bitte thematisch etwas aufbereiten, gerde 
wenn andere so nett sein sollen, sich das anzusehen. menno :\

Vorhin hatte ich mich noch aufgeregt, weil jemand einen anderen genau 
deswegen angefertzt hatte. War dort nicht ganz so schlimm. dafür hatte 
jedes Netz eine andere Farbe :)

Ich lese noch n bissl mit...

StromTuner

[Daniel C. (apokya)]

Axel R. schrieb:
>> Über die Beschriftung PB1 an den Controller-Pin PB1.
> Du siehst selbst nicht durch, scheint es fast...
>
> Links ist ein Q1 (2x) blau eingerahmt zu finden.
> X108-1 geht auf PB1, von dort auf PBT von dort auf PBC und von dort nach
> PB1?
> der Portpin allein schafft es nicht, die LEDs zu treiben.
> MIr jedenfalls, das ist nur ein ganz kleine wenig böse gemeint, ist das
> zu umständlich, mich dort durchzuarbeiten, um Dich gegegenenfalls auf
> Fehler hinweisen zu können.
> Daher bin ich raus.
>
> StromTuner

Sry, für mich war es logisch, da ich den Plan entworfen habe :D

Der Controller-Pin PB1 schaltet über Q1 (PBC) die Basis des Transistors.
Dieser Transistor gibt dann über Emitter nach Collektor 5V (PBT) auf den 
Pin 1, XCON9 (PB1).

Das ist so gezeichnet, damit man bzw. ich direkt erkenne, wo der Pin des 
Controllers eigentlich hingeht. Dass dazwischen ein Transistor liegt, 
der für das Schalten zuständig ist, interessiert mich eigentlich nicht 
mehr :D
Sry, hört sich doof an.


Axel R. schrieb:
> Oder so. man kann das doch bitte thematisch etwas aufbereiten, gerde
> wenn andere so nett sein sollen, sich das anzusehen. menno :\
>
> Vorhin hatte ich mich noch aufgeregt, weil jemand einen anderen genau
> deswegen angefertzt hatte. War dort nicht ganz so schlimm. dafür hatte
> jedes Netz eine andere Farbe :)
>
> Ich lese noch n bissl mit...
>
> StromTuner

Das stimmt natürlich. Ich werde versuchen, in der nächsten Zeit ein paar 
Änderungen vorzunehmen. Bitte etwas Geduld. Aber du hast recht. Der 
Schaltplan ist zweckmäßig, aber nicht gut leserlich.

[Jörg W. (dl8dtl) (Moderator)]

Daniel C. schrieb:
>> * ALED ist definiert als eine Eingabe-parameter, wird aber in der
>> Funktion gesetzt
>
> Nicht im ernst, oder? :D
> Wie müsste es denn richtig sein?

Für die Rückgabe genau eines Wertes bietet sich immer der normale
Funktions-Rückkehrwert an.  Du deklarierst deine Funktion also
nicht "void" als Ergebnistyp, sondern "uint8_t".  Dann merkst du
dir entweder in einer Variablen den fertigen Wert:

uint8_t DZB_Anzeige (void)
{
  // ...
  uint8_t rv; // return value

  // ...
  if (...) {
     rv = 42;
  }

  // ...
  return rv;
}

Alternativ kannst du auch „mitten aus der Funktion springen“.  Das
empfinden manche zwar als schlechten Programmierstil (eine Funktion
sollte nur einen Eintritt- und einen Austrittspunkt haben), aber
es hat zusätzlich den Vorteil, mit den vielen geschachtelten "if"s
aufzuräumen:

   if (bedingung_a) return 13;
   if (bedingung_b) return 26;

Da durch das "return" der nachfolgende Code an dieser Stelle nicht
mehr interessiert, braucht man keine weiteren "else"-Zweige.

Der Aufrufer muss dann mit dem so zurückgegebenen Wert etwas
anfangen:

   var1 = DZB_Anzeige();
   // hier den Wert in "var1" weiterverarbeiten

[Bernd N (Gast)]

Dir fehlt es noch an vielen Grundlagen aber das ist ok wenn du bereit 
bist dir das zu erarbeiten

>> Z.B. würde ich gerne für Das Drehzahlband (DZB) und die Segmentanzeige
>> eine Art Stapel anlegen. Aber da habe ich ebenso keine Ahnung von.
>> Ob das Sinn macht weiß ich natürlich auch nicht.

Der Gedankengang ist durchaus richtig und was du suchst sind 
Datenfelder, Arrays, Tabellen.
http://www.c-howto.de/tutorial-arrays-felder-initialisierung.html

Alles was du benötigst ist eine Zuweisung Anzahl LEDs zu BIT Muster and 
den Ausgängen. Statt BIT Weise zu steuern könntest du auch die Ports 
direkt ansteuern (Byte). Der Code für deinen
Bargraphen sähe bei einem 8 BIT Port z.B. dann so aus...

void BargraphAnsteuerung (uint8_t AnzahlLeds)
{
    const uint8_t BarGraph [9] = {0x00, 0x01, 0x03, 0x07, 0x0F, 0x1F, 0x3F, 0x7F, 0xFF};
        
    PORTC |= BarGraph [AnzahlLeds];
}

Das lässt sich auch auf 16 BIT erweitern nur musst du dann diese wieder 
in 2x8 BIT für den jeweiligen Port zerlegen.

void BargraphAnsteuerung (uint8_t AnzahlLeds)
{
    const uint16_t BarGraph [16] = {0x00, 0x01, 0x03, 0x07, 0x0F, 0x1F, 0x3F, 0x7F, 0xFF,
                                    0x1FF, 0x3FF, 0x7FF, 0xFFF, 0x1FFF, 0x3FFF, 0x7FFF
                                   };
    PORTC |= BarGraph [AnzahlLeds] & 0xFF;
    PORTD |= BarGraph [AnzahlLeds] >> 8;
}

Innerhalb der Drehzahlmessung sorgst du nun dafür das die Anzahl der 
LEDs berechnet wird und an die Bargraph Ansteuerung übergeben wird. Du 
kannst die Berechnung aber auch in die Ausgabe packen. Das sieht dann so 
aus...

void BargraphAnsteuerung (uint16_t Drehzahl)
{
    const uint16_t BarGraph [16] = {0x00, 0x01, 0x03, 0x07, 0x0F, 0x1F, 0x3F, 0x7F, 0xFF,
                                    0x1FF, 0x3FF, 0x7FF, 0xFFF, 0x1FFF, 0x3FFF, 0x7FFF
                                   };
    PORTC |= BarGraph [(Drehzahl / 625)] & 0xFF;
    PORTD |= BarGraph [(Drehzahl / 625)] >> 8;
}

Hier werden deine 10000 Umdrehungen max. auf die Anzeige gebracht und 
linear auf den Bargraphen verteilt.

Bei allen Beispielen musst du sicherstellen das der Wertebereich von 
"Drehzahl" oder "AnzahlLeds" nicht überschritten wird!!! warum ?
Das Schlüsselwort const schaust du bitte auch nach. Wenn du die Ausgabe 
fertig hast dann stellst du mal den Code hier herein.

Wenn das soweit klar ist dann beschreibst du bitte genau wie du gerne 
den Bargraphen ins Verhältnis zur Drehzahl setzen willst... dann gehts 
weiter, wie gesagt, Schritt für Schritt.

[Johannes S. (Gast)]

Die Drehzahlbereiche ergeben sich ja schon aus den If Abfragen, die sind 
aber nicht linear verteilt. Da kann man das Array zweidimensional 
anlegen oder ein Array von Strukturen mit Drehzahl und LED Muster. In 
der while Schleife dann die passende Drehzahl suchen und das zugehörige 
LED Muster ausgeben.

[Bernd N (Gast)]

>> Die Drehzahlbereiche ergeben sich ja schon aus den If Abfragen
Stimmt aber ich habe den Eindruck er weiss selber nicht wie und daher 
wäre mir eine Beschreibung (hatte ich gefragt) lieber als der Code. 
Jedenfalls ist seine Antwort für mich nicht klar.

>> a kann man das Array zweidimensional anlegen
Soweit ist er noch nicht.

[Daniel C. (apokya)]

Bernd N schrieb:
> Stimmt aber ich habe den Eindruck er weiss selber nicht wie und daher
> wäre mir eine Beschreibung (hatte ich gefragt) lieber als der Code.
> Jedenfalls ist seine Antwort für mich nicht klar.

Oh entschuldige bitte. Dann haben wir aneinander vorbei geredet.

Als Antwort: Es gibt zwei verschiedene Arten der Drehzahlanzeige.
Einmal für die Gänge D, N und R, evtl auch P wird das DZB 
(Drehzahlband), die 15 LEDs, im kompletten Drehzhalbereich angezeigt. 
Grob gesagt 0-10.000, allerdings in meinem Fall irgendwann 1.000 - ca. 
9.000 bis 9.500.

In der Zweiten Variante wird der Gang D durch die fiktive Gänge 1-5 
ersetzt. Diese wiederrum haben einen eigenen Drehzahlbereich, je nach 
Gang.
Der 1. z.B. von 1.000 - 4.500 und der 2. von 4.500 bis 6.000, u.s.w.

Ist das die Antwort zu der Frage, oder soll ich das komplett 
aufschreiben, wie es im Code ist, nur ohne Code? Wäre kein Problem.

[Jörg W. (dl8dtl) (Moderator)]

Bernd N schrieb:
>>> a kann man das Array zweidimensional anlegen
> Soweit ist er noch nicht.

Ist glaub' ich auch bisschen viel für den Anfang.  Er sollte wohl
erstmal mit einem eindimensionalen arbeiten und sich auf einen
Gang konzentrieren.

Kommt beim AVR dann noch hinzu, dass man solche Tabellen lieber in
den Flash legen sollte, damit sie keinen RAM schlucken.

Der Anfang wäre wohl sowas:

#define NLEDS 15
uint8_t aled(int Drehzahl)
{
  static const __flash int limits[NLEDS] =
  {
    1000, 1100, 1200, 1500, 2000,
    3000, 4000, 5000, 5500, 6000,
    6500, 7000, 7500, 8000, 8500
  };
  uint8_t i;
  for (i = 0; i < NLEDS; i++)
    if (Drehzahl >= limits[i])
       return i + 1;
  return 0;  // < 1000
}

[Daniel C. (apokya)]

> Der Anfang wäre wohl sowas:
> #define NLEDS 15
> uint8_t aled(int Drehzahl)
> {
>   static const __flash int limits[NLEDS] =
>   {
>     1000, 1100, 1200, 1500, 2000,
>     3000, 4000, 5000, 5500, 6000,
>     6500, 7000, 7500, 8000, 8500
>   };
>   uint8_t i;
>   for (i = 0; i < NLEDS; i++)
>     if (Drehzahl >= limits[i])
>        return i + 1;
>   return 0;  // < 1000
> }

Würde das bedeuten, dass die Schleife nie unterbrochen wird, weil die 
Drehzahl nie unter 1.000 fällt?
Also ich kann mir ungefähr denken, was da laufen soll.

Das gefällt mir sogar richtig gut. So würde zu mindest für Gang D eine 
große Übersichtlichkeit geschaffen. Danke

[Eric B. (beric)]

Daniel C. schrieb:
>> Das haut von vorne bis hinten nicht.
>> * Da fehlen überall die abschliessenden ';'-Zeichen
>> * ALED ist definiert als eine Eingabe-parameter, wird aber in der
>> Funktion gesetzt
>
> Nicht im ernst, oder? :D
> Wie müsste es denn richtig sein?

Nein, ich werde dir dein Code nicht schreiben, das musst du schon selber 
tun.

Die Funktion könnte z.B. die Drehzahl als Eingabeparameter haben, sich 
dann ausrechnen wieviele LED aufleuchten sollen und zuletzt eine 
Anzeige-funktion aufrufen die dann die tatsächliche LED-Ansteuerung 
macht.

Mein Ratschlag wäre: lass dieses Projekt erstmal liegen und lerne 
C-Grundlagen. Die beherrscht du offensichtlich noch überhaupt nicht.

[Bernd N (Gast)]

>> Einmal für die Gänge D, N und R, evtl auch P wird das DZB
>> (Drehzahlband), die 15 LEDs, im kompletten Drehzhalbereich angezeigt.
>> Grob gesagt 0-10.000

Den Code habe ich dir geliefert und nun sag mir ob du den Code 
verstanden hast ? es ist wichtig das du jetzt am Verständnis arbeitest.

>> allerdings in meinem Fall irgendwann 1.000 - ca. 9.000 bis 9.500.

Da musst du im Code nur die Berechnung anpassen denn die Verteilung 
zwischen min und max ist immer noch linear. Ist dir die Berechnung klar 
?

>> In der Zweiten Variante wird der Gang D durch die fiktive Gänge 1-5
>> ersetzt. Diese wiederrum haben einen eigenen Drehzahlbereich, je nach
>> Gang.
>> Der 1. z.B. von 1.000 - 4.500 und der 2. von 4.500 bis 6.000, u.s.w.

Das sind weiter 5 Fall Unterscheidungen aber auch hier ist der 
Zusammenhang linear zwischen den Punkten.

Gib der Funktion einen weiteren Parameter mit und mach dann die 
Fallunterscheidungen bei der Berechnung.

void BargraphAnsteuerung (uint16_t Drehzahl, uint8_t Gang)
{...

[Jörg W. (dl8dtl) (Moderator)]

Daniel C. schrieb:
> Würde das bedeuten, dass die Schleife nie unterbrochen wird, weil die
> Drehzahl nie unter 1.000 fällt?

Nein.

Es wird das Array durchgegangen, bis die Drehzahl größer als einer
der Werte ist.  Ist sie jedoch nicht größer als irgendeiner der
Werte, würde die Schleife zum normalen Ende gelangen.  Das kann
dann eigentlich nur bedeuten, dass die Drehzahl bereits kleiner
als der erste Wert war.

Natürlich könnte man diesen Fall auch gleich am Anfang abfangen:

   if (Drehzahl < limits[0])
      return 0;
   for ...

> So würde zu mindest für Gang D eine große Übersichtlichkeit geschaffen.

Ich würde das an deiner Stelle dann auch für die anderen Gänge in
ähnlicher Weise schreiben und auf die Berechnungen im Stile von
„Drehzahl >=(1000+(7*n1))“ ganz und gar verzichten.  Die verschiedenen
möglichen Werte von „n1“ sind doch letztlich auch wieder vorab bekannt,
sodass man die Tabellen vollständig auscodieren kann.  Wenn du diese
in den Flash legst (wie mit dem Schlüsselwort __flash gezeigt), dann
stört der Speicherverbrauch mehrerer Tabellen auch kaum.

[Theor (Gast)]

Jörg W. schrieb:
[...]
> Natürlich könnte man diesen Fall auch gleich am Anfang abfangen:

Ich würde eher die Reihenfolge der Werte ändern. Oder die for schleife 
bei NLEDS-1 beginnen lassen. Oder die if-else-Orgie oben in der 
Reihenfolge umkehren.

Wenn nämlich die Drehzahl etwa 9000 ist, dann schlägt die Bedingung 
dennoch schon bei i= 0 zu. Oder die erste if-Bedingung oben (mit 1000 
als Grenze) wird sofort war. Das else verhindert, dass die weiteren LEDS 
angehen.

Jörg: In Deinem Fall ziemlich sich ein Lapsus. In dem Thread aber eher 
ein Omen. :-)

[Jörg W. (dl8dtl) (Moderator)]

Theor schrieb:
> Jörg: In Deinem Fall ziemlich sich ein Lapsus.

Stimmt. ;-)

Irgendeinen leisen Zweifel hatte ich schon im Hinterkopf, ob das
denn so OK wäre … aber nicht näher drüber nachgedacht.

Daniel soll ja programmieren lernen :-), naja, ihm gleich ein paar
Bugs vorzulegen ist sicher nicht so schön, andererseits hoffe ich
ja, dass er über kurz oder lang dazu kommt, darüber nachzudenken,
was wir ihm denn so als Tipps auf die Reise geben, um das auch alles
zu verstehen.

[Daniel C. (apokya)]

Bernd N schrieb:
> Den Code habe ich dir geliefert und nun sag mir ob du den Code
> verstanden hast ? es ist wichtig das du jetzt am Verständnis arbeitest.

Hex ist noch nicht in meinem Schädel verankert. Ich arbeite 
Übersichtliher weise, damit ich sehe, was ich da mache mit der 
Binär-Schreibweise.

Daher komme ich ein bisschen mit dem Hex durcheinander.
Aber ich kann mir denken, was gemeint ist.

Muss man dort mit 0b bzw. 0x arbeiten oder kann man sogar auch die 
definierten Pinnamen verwenden?


> Gib der Funktion einen weiteren Parameter mit und mach dann die
> Fallunterscheidungen bei der Berechnung.
> void BargraphAnsteuerung (uint16_t Drehzahl, uint8_t Gang)
> {...

Ich glaube das übersteigt jetzt meine Leistung. Das überfordert mich 
grade doch ein wenig mehr.

Eine Unterscheidung bringt doch auch garnichts, da ich doch nur die 15 
Pins für die LEDs ansteure, oder nicht? Wenn nein, habe ich es nciht 
verstanden

[Theor (Gast)]

Jörg W. schrieb:

> [...]
> Daniel soll ja programmieren lernen :-),

Naja. Er muss eigentlich nur lernen die Semikola zu setzen. ;-)

> naja, ihm gleich ein paar
> Bugs vorzulegen ist sicher nicht so schön,

Mir kommt das eher vor, als würde man jemandem, der sich, gegen allen 
Rat zu einer Allein-Weltumseglung im Jollenkreuzer entschlossen hat, 
mitten im Pazifik raten, doch mal zu überlegen, ob er wirklich die 
Absicht hatte, keinen Kompass mitzunehmen.

Aber gut. Jedenfalls meine ich, dass man ihm oben bei der If-Orgie schon 
erklären müssen, das er mal einen einfachen Vergleich und einen 
Vergleich mit zwei Werten ganz in Ruhe in Varianten ausprobieren sollte 
- und auch in Hinblick auf else, if else und die Reihenfolge der 
Vergleichswerte. Bei diesen einfachen Versuchen wären vielleicht auch 
die fehlenden Semikola abgefallen. Mir kommt das fast so vor, als hätte 
der TO noch nie einen Code durch den Compiler gejagt.

[S. K. (hauspapa)]

Voller Eifer hast Du schon angefangen Code zu schreiben. Du bist also 
bestens motiviert. Das ist gut, da geht was. Hat aber einen Haken. bei 
einem Projekt mit der von Dir angestrebten Komplexität sollte man 
erstmal ein bischen Papier produzieren.

Im Anhang ein Beispiel wie ich meine Software organisiere, am Beispiel 
der 8 Kanal Lichtsteuerung mit Triacs an welcher ich gerade sitze.
Zustandsdiagramme & Co. sind bei mir Pflicht sonst finde ich 
systematische Fehler nicht. Zu jedem Block gibt es noch eine kurze 
Beschreibung was wann und wie getan wird.

Die von Dir bereits skizzierten Teilaufgaben habe ich auch bei mir. 
Sogar noch feiner aufgeschlüsselt.

Warum das Ganze:
Ich kann einen Block umschreiben, Fehler beheben, neue Funktionen 
hinzufügen und dabei genau sehen welche Abhängigkeiten bestehen.

Mögliche Beispiele bei Dir:

Block Drehzahl einlesen,
Block Geschwindigkeit einlesen,
Block Gangberechnung,
...

Warum das? Weisst Du vorher wieviel Störungen auf welchem Signal sind 
und ob da nicht noch ein Filter rein muss?

viel Erfolg
hauspapa

[Bernd N (Gast)]

void BargraphAnsteuerung (uint8_t AnzahlLeds)
{
    const uint8_t BarGraph [9] = {0x00, 0x01, 0x03, 0x07, 0x0F, 0x1F, 0x3F, 0x7F, 0xFF};
        
    PORTC |= BarGraph [AnzahlLeds];
}

Ok, fangen wir mit dem einfachen Bargraphen an. Der Port PIN sollte 
logisch 1 haben wenn die LED eingeschaltet wird.
0x00 = 00000000
0x01 = 00000001
0x03 = 00000011
0x07 = 00000111

usw. Der Ausdruck "uint8_t BarGraph [9]" sagt wir haben eine Tabelle mit 
9 Elementen von 00 bis FF oder 00000000 bis 11111111 und das entspricht 
von alle LEDs aus bis ein. Da du an die Funktion den Parameter 
"AnzahlLeds" übergibst kann nun eine Zuordnung zwischen Eingangswert und 
Ausgabe Wertan den Port erfolgen. Rufst du die Funktion auf mit

BargraphAnsteuerung (4);

dann werden auch 4 LEDs eingeschaltet (0x0F = 00001111). Das kannst du 
ja ausprobieren.
Diese Zeile "PORTC |= BarGraph [AnzahlLeds];" weist den Wert aus der 
Tabelle dem Port zu an dem deine LEDs hängen.

Du solltest dringend ein C Buch in die Hand nehmen und dir das Wissen 
erarbeiten. Das macht nur Sinn hier wenn du die Code Beispiele 
durcharbeitest.

Zur Arbeitsweise, ich habe weder dein Board zur Hand noch den passenden 
Controller. Ich Simuliere mir einfach deine Aufgabenstellung und du 
solltest vielleicht erst einmal deine Arbeitsweise beschreiben. Hast du 
einen Debugger oder kannst du Werte auf einem Terminal ausgeben ? Du 
brauchst erst einmal einen Einstieg in das Arbeiten mit embedded 
Hardware.

Im Anhang ein Screenshot vo meiner Simulation, könntest du auch so 
machen und dann wird einiges klarer.

[Theor (Gast)]

Theor schrieb:
> Jörg W. schrieb:
> [...]

Tschuldigung Jörg.
Ich habe ja gestern schon gesagt, was ich von der Situation halte.

[Daniel C. (apokya)]

So müsste es nach meinem Verständnis aussehen.
Jetzt ist meine Frage ob ich das nach dem Prinzip von Jörg Wunsch an die 
Drehzahl anpassen kann, obwohl es mir wesentlich besser gefällt, wenn 
ich für jeden Gang das Drehzahlband anpassen kann.

void Drehzahlband (uint8_t AnzahlLeds)
{
  const uint16_t BarGraph [16] = {
    0x00, 0x01, 0x03, 0x07, 0x0F, 0x1F, 0x3F, 0x7F, 0xFF,        //Aus, PC0 - PC7
    0x1FF, 0x3FF, 0x7FF, 0xFFF, 0x1FFF, 0x3FFF, 0x7FFF, 0xFFF      //PD0 - PD7
  };
  PORTC |= BarGraph [AnzahlLeds] & 0xFF;          //PortC An?!
  PORTD |= BarGraph [AnzahlLeds] >> 8;          //PortD An?!
}

void Warnung (uint8_t AnzahlLeds)
{
  const uint16_t BarGraph [2] = {
      0b101010101010101, 0b010101010101010
  };
  PORTC |= BarGraph [AnzahlLeds];            //PortC An?!
  PORTD |= BarGraph [AnzahlLeds];            //PortD An?!
}

[Stefan F. (Gast)]

Ob du das kannst? Versuche es, dann siehst du, was du kannst.

Un wenn es nicht klappt, dann zeige deinen Versuch und bitte um Hilfe.

Mir gefällt deine passive Haltung nicht. Es scheint als ob wir Dir dein 
gesamtes Projekt vorkauen sollen.

Besser wäre, wenn du lernst und konkrete Fragen stellst. Also nicht "was 
soll ich als nächstes tun?" sondern z.b. "Mein timer interrupt wird 
scheinbar nie aufgerufen, da die Test-Led x dunkel bleibt. Ich habe das 
angehängte Programm auf minimale 150 Zeilem reduziert aber sehe den 
Fehler trotzem nicht."

Hast du inzwischen eine Möglichkeit zum Debuggen oder wenigsten zum 
Ausgeben von Log Meldungen geschaffen? Wenn micht, dann mach das mal Du 
wirst es brauchen. Blind raten macht nämlich nicht lange Spass.

Stell Dich mal darau ein, ein paar Monate zu lernen.  Ich habe ein 
bisschen den Eindruck, das du dich selbst zu sehr unter Druck stellt und 
irgendwie einen ganzen Wald auf einmal pflanzen willst, anstatt dich mit 
einzelnen Bäumen zu beschäftigen

[Daniel C. (apokya)]

Stefan U. schrieb:
> Ich habe ein
> bisschen den Eindruck, das du dich selbst zu sehr unter Druck stellt und
> irgendwie einen ganzen Wald auf einmal pflanzen willst, anstatt dich mit
> einzelnen Bäumen zu beschäftigen

Das muss ich auch, weil ich bis spätestens Mitte des Jahres fertig sein 
will. Allerdings habe ich zurzeit nicht die Möglichkeit mich voll auf 
die arbeit zu konzentrieren. Ich versuche nebenbei Stück für Stück daran 
zu arbeiten.

Deswegen auch diese Passivität. Es wird besser, allerdings erst ab Mitte 
März. Dann geht es richtig zur Sache. Bis dain versuche ich schon mal 
die ersten einfachen Schritte mit eurer Hilfe aufzubauen.

Danke dafür. :)

[Jörg W. (dl8dtl) (Moderator)]

Daniel C. schrieb:
> Bis dain versuche ich schon mal die ersten einfachen Schritte mit eurer
> Hilfe aufzubauen.

Probier' einfach viel aus.

[Cyborg (Gast)]

Daniel C. schrieb:
> Aber eine Bitte habe ich: Keine blöden Kommentare.

Wer eine vernünftige Frage stellt, braucht das auch nicht befürchten.
Ist deine Frage vernünftig? Ein Forum kann Einzelfragen oder Problemen
mit Details sicher helfen, obwohl die Fachkompetenz der User alles
andere als Verbindlich ist. Was du da vor hast ist ein Projekt und das
übersteigt die Möglichkeiten des Forums um einiges. Auch machen die
Leute hier nicht deinen Job, insbesondere wenn du damit Geld verdienst.

Daniel C. schrieb:
> Z.B. soll ich

So so, du sollst. Hast wohl jemanden mehr versprochen, als du
leisten kannst und jetzt sollen wir dir aus der Patsche helfen?
Na, du traust dir ja was. Google nach einem guten Tutorial und
arbeite dich ein. Wenn du soweit bist, kannst du hier gezielte
Fragen zu Problemen stellen oder mach eine Berufsausbildung, was
andere ja auch machen.

Mitlesa schrieb:
> ... denn Programmieren lernt man nicht von heute auf morgen.

Wahre Worte, gelassen ausgesprochen.

Daniel C. schrieb:
> Habe ich mit keinem Wort gesagt, oder?

Patzig zu werden, kommt für einen, der Hilfe sucht hier sicher nicht
gut an.

Daniel C. schrieb:
> Ich möchte Programmieren lernen, es aber direkt auf meine Schaltung
> anwenden, um direkt Hard- und Software zu vereinen und meinem Ziel - dem
> fertigen Progamm- näher zu kommen.

Mach das so, wie es vernünftig ist, entweder durch einen Kurs, eine
Berufsausbildung oder Autodidaktisch. Das Internet bietet da ausreichend
Möglichkeiten, die du dir selbst aussuchen kannst.
Hilfe hier, muss verdient werden. Die bekommt oder verlangt man nicht 
mal so. ;-b

[Daniel C. (apokya)]

Cyborg schrieb:
> Daniel C. schrieb:
>> Aber eine Bitte habe ich: Keine blöden Kommentare.
>
> Wer eine vernünftige Frage stellt, braucht das auch nicht befürchten.
> Ist deine Frage vernünftig? Ein Forum kann Einzelfragen oder Problemen
> mit Details sicher helfen, obwohl die Fachkompetenz der User alles
> andere als Verbindlich ist. Was du da vor hast ist ein Projekt und das
> übersteigt die Möglichkeiten des Forums um einiges. Auch machen die
> Leute hier nicht deinen Job, insbesondere wenn du damit Geld verdienst.

Ich bekomme im Moment von den Leuten, die hier schreiben, genau die 
Hilfe die ich mir erhofft habe und die mich weiter bringt. Also wo ist 
das Problem? Wenn irgendwann keiner mehr Bock hat hier was zu schreiben, 
werde ich das schn merken.

Gut, dass du besser über das Forum bescheid weißt, als die User in dem 
Forum selbst. Es gibt scheinbar Leute die mir helfen und helfen wollen, 
obwohl es die Forums-Möglichkeiten übersteigt, komisch.

Dass ich damit Geld verdienen will habe ich nie gesagt und wird auch nie 
so sein. Einmaliges Projekt, einmliger Prototyp.


> Daniel C. schrieb:
>> Z.B. soll ich
>
> So so, du sollst. Hast wohl jemanden mehr versprochen, als du
> leisten kannst und jetzt sollen wir dir aus der Patsche helfen?
> Na, du traust dir ja was. Google nach einem guten Tutorial und
> arbeite dich ein. Wenn du soweit bist, kannst du hier gezielte
> Fragen zu Problemen stellen oder mach eine Berufsausbildung, was
> andere ja auch machen.

Wer redet denn von "Jemandem"? Es geht um das Forum, mich und mein 
Projekt. Ich habe nicht einmal versprochen, dass ich C lerne, obwohl 
genau das eigentlich auch gesagt werden könnte.

Aus der Patsche hilft das Forum jeden. Denn wenn ich in der Patsche 
sitze, dann sind Fehler im Projekt.

Ic werde mich einarbeitne, keine Sorge.

Und jetzt sage ich dir: Werd nicht frech, Kollege. Komm mir nicht mit 
"Berufausbildung". Nur weil ich Student bin, heißt dass nicht, dass ich 
keine Berufausbildung, keinen Meister und weitere Qualifikationen 
vorweisen kann. Sowas gehört nicht einmal in so ein Forum. Übrigends: 
Das gehört für mich ganz klar zu einem blöden Kommentar.


> Daniel C. schrieb:
>> Habe ich mit keinem Wort gesagt, oder?
>
> Patzig zu werden, kommt für einen, der Hilfe sucht hier sicher nicht
> gut an.

Etwas patzig zu verstehen, erlaubt es nur, wenn man es patzig verstehen 
möchte. Ich schreibe jetzt grade patzig, weil ich mehr als sauer über so 
einen Kommentar hier bin.

> Daniel C. schrieb:
>> Ich möchte Programmieren lernen, es aber direkt auf meine Schaltung
>> anwenden, um direkt Hard- und Software zu vereinen und meinem Ziel - dem
>> fertigen Progamm- näher zu kommen.
>
> Mach das so, wie es vernünftig ist, entweder durch einen Kurs, eine
> Berufsausbildung oder Autodidaktisch. Das Internet bietet da ausreichend
> Möglichkeiten, die du dir selbst aussuchen kannst.
> Hilfe hier, muss verdient werden. Die bekommt oder verlangt man nicht
> mal so. ;-b

Und erneut. Stelle keine Vermutungen an. Besinne dich auf die Fakten und 
klaren Angaben.

Ich werde schon anfangen zu lernen. Gib mir Zeit. Und tu mir einen 
Gefallen. Wenn dir meine Art des Hilfeersuchs nicht passt, dann schaue 
auch nicht rein.

Für jegliche Hilfe, die dennoch von dir hier kommt, sowie auch die in 
deinem Kommentar stehenden Tipps und Anregungen, sind herzlich 
willkommen. Danke dafür.

[Eric B. (beric)]

Daniel C. schrieb:
> void Warnung (uint8_t AnzahlLeds)
> {
>   const uint16_t BarGraph [2] = {
>       0b101010101010101, 0b010101010101010
>   };
>   PORTC |= BarGraph [AnzahlLeds];            //PortC An?!
>   PORTD |= BarGraph [AnzahlLeds];            //PortD An?!
> }

Was passiert wenn AnzahlLeds gleich 4 ist?

[Daniel C. (apokya)]

Eric B. schrieb:
> Daniel C. schrieb:
>> void Warnung (uint8_t AnzahlLeds)
>> {
>>   const uint16_t BarGraph [2] = {
>>       0b101010101010101, 0b010101010101010
>>   };
>>   PORTC |= BarGraph [AnzahlLeds];            //PortC An?!
>>   PORTD |= BarGraph [AnzahlLeds];            //PortD An?!
>> }
>
> Was passiert wenn AnzahlLeds gleich 4 ist?

Nichts, hätte ich jetzt gesagt.
Weil es auch nur die beiden Zustände gibt. Da muss ich dann drauf 
achten, wenn bevor ich das Programm aufrufe.


Jörg W. schrieb:
> #define NLEDS 15
> uint8_t aled(int Drehzahl)
> {
>   static const __flash int limits[NLEDS] =
>   {
>     1000, 1100, 1200, 1500, 2000,
>     3000, 4000, 5000, 5500, 6000,
>     6500, 7000, 7500, 8000, 8500
>   };
>   uint8_t i;
>   for (i = 0; i < NLEDS; i++)
>     if (Drehzahl >= limits[i])
>        return i + 1;
>   return 0;  // < 1000
> }

Das habe ich gestern nicht so richtig verstanden und versuche es mal 
selbst zu erklären: NLEDS wird als Zahl 15 defniert, damit die 
Reichweite von const gegeben bzw. begrenzt wird. Unten wird dann die 
Drehzahl überprüft und dann über return an aled übergeben.
Ist also aled die variable, die von 0-15 die anzahl anhand der drehzahl 
sagt?

Würde es gehen, wenn ich aled mit dem Aufruf des Drehzahlprogramms 
ersetze, sodass wenn die Drehzahl überprüft wurde und die Anzahl der 
LEDs klar ist, diese in das Drhzahlprogramm geladen wird, damit dieses 
weiß, welche von den LEDs bitte angehen sollen?

[Bernd N (Gast)]

Deine Code Kommentare und Beschreibungen machen mir den Eindruck das du 
den Code nicht verstehst, weder meinen noch Jörgs.

> Daniel C. schrieb:
>> void Warnung (uint8_t AnzahlLeds)
>> {
>>   const uint16_t BarGraph [2] = {
>>       0b101010101010101, 0b010101010101010
>>   };
>>   PORTC |= BarGraph [AnzahlLeds];            //PortC An?!
>>   PORTD |= BarGraph [AnzahlLeds];            //PortD An?!
>> }

Beschreibe mal genau was hier passiert und zwar Zeile für Zeile.

Warum verwende ich folgende Syntax in meienm Code ?

    PORTC |= BarGraph [AnzahlLeds] & 0xFF;
    PORTD |= BarGraph [AnzahlLeds] >> 8;

Und bleib mal nur bei diesem Code.

[Eric B. (beric)]

Daniel C. schrieb:
>> Was passiert wenn AnzahlLeds gleich 4 ist?
>
> Nichts, hätte ich jetzt gesagt.

Falsch. Im besten Fall zeigen deine LEDs ein unerwartetes Muster, im 
schlimmsten Fall resettet sich dein uC.
Ausserdem kannst du mit

PORTX |= muster

nur LEDs einschalten, aber nicht ausschalten.

Nochmal: nimm ein C-Buch und lerne erstmal Grundlagen!

[Daniel C. (apokya)]

Bernd N schrieb:
> Deine Code Kommentare und Beschreibungen machen mir den Eindruck
> das du
> den Code nicht verstehst, weder meinen noch Jörgs.
>
>> Daniel C. schrieb:
>>> void Warnung (uint8_t AnzahlLeds)
>>> {
>>>   const uint16_t BarGraph [2] = {
>>>       0b101010101010101, 0b010101010101010
>>>   };
>>>   PORTC |= BarGraph [AnzahlLeds];            //PortC An?!
>>>   PORTD |= BarGraph [AnzahlLeds];            //PortD An?!
>>> }
>
> Beschreibe mal genau was hier passiert und zwar Zeile für Zeile.
>
> Warum verwende ich folgende Syntax in meienm Code ?
>
>     PORTC |= BarGraph [AnzahlLeds] & 0xFF;
>     PORTD |= BarGraph [AnzahlLeds] >> 8;
>
> Und bleib mal nur bei diesem Code.


Programm Programmname (Variable mit Größenangabe)

Konstante mit 16er Größe la sVariable Bargraph mit zwei Zuständen
Die beiden Zustände in Binärform, ah, was natürlich keinen Sinn macht, 
da man ja auch PortC und D verteilen muss ...

Da habe ich nicht nachgedacht. :D

[Johannes (menschenskind)]

Daniel C. schrieb:
> Deswegen auch diese Passivität. Es wird besser, allerdings erst ab Mitte
> März. Dann geht es richtig zur Sache.

Dann schlage ich vor, Du lernst bis dahin die Grundlagen und dann kannst 
Du wiederkommen und hier konkrete Fragen stellen.
Denn die meisten hier kotzt Deine Einstellung ganz schön an (meine 
Vermutung).
Und dann Deine empörte Reaktion, wenn hier dementsprechende Kommentare 
kommen...

[Jörg W. (dl8dtl) (Moderator)]

Cyborg schrieb:
> Was du da vor hast ist ein Projekt und das übersteigt die Möglichkeiten
> des Forums um einiges.

Er hatte im Parallelthread jemanden gesucht, der ihm das für (wenig)
Geld programmiert.  Wir haben ihn davon überzeugt, dass es sinnvoller
ist, dass er selbst programmieren lernt, und dass wir ihm dabei
helfen werden.

Solange er damit auch gedanklich Fortschritte macht, ist es zwar ein
anspruchsvolles Ziel, aber durchaus machbar.  Andere haben schließlich
auch programmieren gelernt.

Daniel C. schrieb:
> Das habe ich gestern nicht so richtig verstanden und versuche es mal
> selbst zu erklären: NLEDS wird als Zahl 15 defniert, damit die
> Reichweite von const gegeben bzw. begrenzt wird.

So in etwa.

Der Präprozessor ersetzt, noch bevor der eigentliche Compiler den
Text sieht, alles Auftreten von „NLEDS“ („number of LEDs“) durch das,
was im #define angegeben ist, hier also die Zahl „15“.  Da die
Anzahl deiner LEDs ja durch die Hardware vorgegeben ist, ist das
sinnvoll, das auch in der Software zu reflektieren.

> Unten wird dann die
> Drehzahl überprüft und dann über return an aled übergeben.

Wobei ja schon bemerkt worden ist, dass meine Auswertereihenfolge
falsch herum war: wenn bspw. die Drehzahl 3800 ist, dann würde bereits
der erste Vergleich positiv ausgehen (sie ist ja größer als 1000).
Man muss das also genau andersherum aufziehen, entweder die Richtung
des Vergleichs ändern, oder die Anordnung der Werte in der Tabelle.

> Ist also aled die variable, die von 0-15 die anzahl anhand der drehzahl
> sagt?

aled ist keine Variable, sondern aled() muss als Funktion aufgerufen
werden.  Der Wert, den die Funktion zurückgibt, kann dann an eine
Variable zugewiesen werden.

Hier ist es einfach die Anzahl der einzuschaltenden LEDs.  Wenn du
das analog zu den anderen Vorschlägen machen willst, kannst du
natürlich auch gleich die Bits für die einzuschaltenden LEDs
zurückgeben (also 0b0000000000000001 bis 0b0111111111111111).  Dann
musst du aber dieses Bitmuster innerhalb von aled() noch ermitteln.
Entweder legst du dazu eine zweite Tabelle an:

   static const __flash uint16_t ledbits[NLEDS] =
   {
      0b0000000000000001,
      0b0000000000000011,
      // ...
      0b0111111111111111
   };

Der Index in diese Tabelle ist dann die Laufvariable der vorigen
for-Schleife, an der die Schleife abgebrochen worden ist.   Der
Abbruch dürfte dabei nicht durch "return" erfolgen, sondern mit
"break" (Sprung zum Ende der Schleife).  Alternativ kannst du
dir auch eine Rechenvorschrift für diese Reihe ausdenken:

1, 3, 7, 15, 31, ... (das sind die Bitmuster)

Vielleicht klingelt's ja, wenn man sich die folgende Reihe direkt
darunter schreibt:

2, 4, 8, 16, 32, ...

;-)

Nun, dein Ziel ist anspruchsvoll.  Du wirst nicht drumherum kommen,
ein paar Tutorials zu C durchzuarbeiten.  Tipp: wenn du die Sprache
auf dem PC statt auf dem Controller lernst, hast du es einfacher.
Den gleichen GCC, den es für den AVR gibt, gibt es auch für den PC.
(Lediglich das Schlüsselwort "__flash" ist AVR-spezifisch.)

[Johannes S. (Gast)]

Daniel C. schrieb:
> Da habe ich nicht nachgedacht. :D

Atmel hat sich soviel Mühe gegeben und einen schönen Simulator in das 
Atmel Studio eingebaut. Warum benutzt du den nicht einfach mal anstatt 
immer nur zu raten? Hast du schon mal ein Stück Code durch den Compiler 
gejagt? Wurde glaube ich schon mal gefragt aber nicht beantwortet.

Starte das Atmel Studio und lege ein neues C/C++ Projekt an. Dann die 
Ziel CPU auswählen, das sollte ja der AtMega32 sein. Dann bekommst du 
schon ein paar Zeilen Code geliefert (ein leeres main()). Jetzt drückst 
du 'F10' und der Code wird übersetzt und das AS versucht den zu starten. 
Das gibt eine Fehlermeldung und es kommt der Dialog wo du die Verbindung 
zum Ziel auswählen kannst. Da ist erstmal nur 'Simulator' möglich und 
das wählst du aus. Strg+S zum Speichern und den Dialog zumachen. Wieder 
F10 drücken und es sollte compiliert und der Simu gestartet werden. Du 
siehst einen gelben Pfeil im Code der die nächste auszuführende Zeile 
markiert und du kannst jetzt immer wieder F10 drücken um den nächsten 
Schritt im Quellcode zu sehen. Unten werden Variablen angezeigt. Da das 
ein leeres Programm ist passiert da nix, aber jetzt kannst du da zB das 
Unterprogramm von Jörg reinkopieren, das im main mit ein paar 
interessanten Werten aufrufen und wieder mit F10 den Simu starten.
So kann man auch per trial & error weiterkommen, sollte aber auch ein 
C-Tutorial oder Referenz als Begleitung für offene Fragen nutzen.
Ein C-Lehrbuch alleine mag auch nicht jeder, die abstrakten Beispiele 
von Blumen und Bienen sind langweilig wenn man eine konkrete Aufgabe 
hat.

[Bernd N (Gast)]

>> Programm Programmname (Variable mit Größenangabe)

Nein, das nennt sich Funktion. Diese Funktion kann eine Variable vom Typ 
uint8_t verarbeiten / aufnehmen. Also wird diese Funktion aufgerufen und 
ein entsprechender Parameter übergeben. In deinem Fall ist das die 
Anzahl der LEDs die es einzuschalten gilt. Du willst aber nur ein 
Warnsignal ausgeben. Braucht es da eine Funktion mit Parameterübergabe ?

Funktionen können Variablen aufnehmen oder auch zurückgeben. Dir fehlen 
viele einfache Grundlagen.

>>     PORTC = BarGraph [AnzahlLeds] & 0xFF;
>>     PORTD = BarGraph [AnzahlLeds] >> 8;

Was macht das & 0xFF und das >> 8 ? Du solltest dich mit damit 
beschäftigen und herausfinden was hier passiert.
https://de.wikibooks.org/wiki/C-Programmierung:_Ausdr%C3%BCcke_und_Operatoren
http://www.c-howto.de/tutorial-variablen-bitmanipulation.html

Du musst ein bischen aktiver werden sonst wird das nichts und wir sind 
gerade mal bei dem Bargraphen.

Sei mir nicht böse aber da muss mehr von Dir kommen.

[Bernd N (Gast)]

@Johannes
Ich gebe ihm noch eine Chance und der Anfang kann ja auch mühsam sein 
aber die Hoffnung stirbt zuletzt. Es ist offensichtlich das es an Allem 
fehlt aber wenn er lernt ist das ok für mich. Daher habe ich auch mit 
dem Bargraphen begonnen und höre erst auf bis er den kapiert hat oder 
die Lage hoffnunglos wird :-).

Es würde mich freuen wenn ihm bei diesem kleinen Schritt hier jeder 
hilft und dann sehen wir weiter.

[Theor (Gast)]

Jörg W. schrieb:

[...]
> Er hatte im Parallelthread jemanden gesucht, der ihm das für (wenig)
> Geld programmiert.  Wir haben ihn davon überzeugt, dass es sinnvoller
> ist, dass er selbst programmieren lernt, und dass wir ihm dabei
> helfen werden.

Hm. Na toll. Aber dann müssen wir uns da auch durch kämpfen und ihm 
helfen, und wenn es noch so knirscht.

[Jörg W. (dl8dtl) (Moderator)]

Theor schrieb:
> und wenn es noch so knirscht.

Nein, mitmachen und was lernen muss er schon.

Das bedeutet eben auch, dass er endlich mal den Compiler anwirft und
an seiner Hardware ein paar LEDs blinken lässt.

[Theor (Gast)]

Jörg W. schrieb:
> Theor schrieb:
>> und wenn es noch so knirscht.
>
> Nein, mitmachen und was lernen muss er schon.

Ja. Sicher. Ich meinte natürlich, ihm beim lernen zu helfen.


@ Daniel

Zu den Bitschiebeoperationen kannst Du zusätzlich noch die C-Teile des 
Artikels https://www.mikrocontroller.net/articles/Bitmanipulation lesen.

Du hast mal am Anfang erwähnt, dass Du teilweise mit den Erklärungen, 
die Du bisher gelesen hast nichts anfangen kannst. Das ist an sich nicht 
weiter ungewöhnlich, denn jeder hat so seinen eigenen Schreibstil und 
das muss auch passen. (Mich versteht auch nicht jeder ;-) ) Da ist es 
nützlich wenn man sich mehrere Erklärungen durchliest. Das sammelt sich 
dann an, und ab einem gewissen Punkt, weiss man auch, was derjenige 
eigentlich sagen wollte, den man zuvor nicht verstanden hat.

Eine gute Quelle, in der C insgesamt beschrieben ist, das Material 
geordnet und in Zusammenhänge gestellt ist, ist das C-Buch hier: 
http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/

Da kannst Du auch immer wieder mal nachschlagen, wenn Dir, was Du schon 
gelesen und verstanden hast, irgendwie momentan entfleucht ist.

Viel Erfolg.

[Daniel C. (apokya)]

Auch wenn es viel gemurmel gibt, dass würde hier nichts, bin ich selbst 
sehr zuversichtlich. Ich bin ehrgeizig genug mir dir Zeit dafür zu 
nehmen und das zu lernen.

Problem ist im Moment die Zeit. Ich habe den Bereich hier aufgemacht, um 
schon mal ein paar kleine Einstiege zu bekommen. Ich habe aber noch 
nicht wirklich die Zeit mich voll drauf zu konzentrieren, aber das 
kommt.

Bitte habt etwas geduld. Ich mache das hier grade schon mal nebenbei, um 
irgendwie mal vorran zu kommen. Es lief die ganze Zeit schon schleppend.

Nun starte ich hier, mit sehr kleinen Schritten und viel Hilfe von euch 
und auch wenn es so aussieht, als habe ich keine Lust, bin ich sehr wohl 
voller Ehrgeiz.

Ich verfolge mit bestem Wissen und Gewissen alle Posts und bin dran. 
Aber bitte, ich bin grade nur nicht voll dabei.

Die Klausuren, wie schon gesagt stehen an. Und diese haben priorität. 
Ich möchte aber auch nicht ncihts tun, bis Ende März und dann vor leeren 
Tatsachen stehen.

Sobald alle Klausuren rum sind (Mitte / Ende März) werde ich, wie schon 
angedeutet, voll durchstarten und mich durch alles durchlesen, was hier 
schon angesprochen wurde.

Ich versuche nur jetzt schon mal kleine Eindrücke zu bekommen und 
versuche mit dem jetzigen Wissen, was aus kurzen C-Anfängen, sowie ein 
wenig Arduino und VBA besteht, das Beste raus zu machen und schon ein 
wenig am Projekt zu arbeiten.

Tut mir Leid, für die ganze Mühe. Wenn ihr jetzt sagt, dass hat alles 
keinen Sinn, entwerder ganz oder garnicht, dann ist es auch ok. Dann 
warten wir alle zusammen bis März, um dann durchzustarten. Aber ich 
werde da sein.


Ich verstehe schon einiges, auch wenn es manchmal nicht rüber komt, und 
auch wie Bernd mir wieder erklärt hat, habe ich das Prinizp verstanden, 
nur die falschen Begriffe, statt Funktion Programm, verwendet. Aber ich 
bin dran.

Vielen Dank :)

[Cyborg (Gast)]

Daniel C. schrieb:
> Aber ich bin dran.

Wenn dich einer erwischt, ganz sicher.;-b
Manche brauchen eben etwas länger zum kapieren.

[Jobst M. (jobstens-de)]

Beitrag "AVR asm - Befehl nur jedes 2. mal ausführen"


Gruß

Jobst

[Daniel C. (apokya)]

Cyborg schrieb:
> Daniel C. schrieb:
>> Aber ich bin dran.
>
> Wenn dich einer erwischt, ganz sicher.;-b
> Manche brauchen eben etwas länger zum kapieren.

Sehr lustig :D :)

Bernd N schrieb:
> void BargraphAnsteuerung (uint8_t AnzahlLeds)
> {
>     const uint16_t BarGraph [16] = {0x00, 0x01, 0x03, 0x07, 0x0F, 0x1F,
> 0x3F, 0x7F, 0xFF,
>                                     0x1FF, 0x3FF, 0x7FF, 0xFFF, 0x1FFF,
> 0x3FFF, 0x7FFF
>                                    };
>     PORTC |= BarGraph [AnzahlLeds] & 0xFF;
>     PORTD |= BarGraph [AnzahlLeds] >> 8;
> }

Erneuter Versuch der Erklärung:

Void: Spezifizierer (Zeiger ohne konkreten Datentyp)
BargraphAnsteuerung: Name der Funktion
(uint8_t: 8-Bit-Datentyp (0-255)
AnzahlLeds): Parameter

const: Konstante
uint16_t: 16-Bit-Datentyp
BarGraph: Name der Konstante
[16]: 16 verschiedene Parameter
0x00, 0x01, 0x03, 0x07, 0x0F, 0x1F, 0x3F, 0x7F, 0xFF, 0x1FF, 0x3FF, 
0x7FF, 0xFFF, 0x1FFF, 0x3FFF, 0x7FFF: 0b0000000000000000 - 
0b0111111111111111

PORTC: Port C
|=: Oberator (oder)
BarGraph: OperatorName
[AnzahlLeds]: Parameter
&: Operator (und)
0xFF: 0b11111111

PORTD: Port D
|=: Oberator (oder)
BarGraph: OperatorName
[AnzahlLeds]: Parameter
>> 8: 8 Bit nach rechts verschieben


>     PORTC |= BarGraph [AnzahlLeds] & 0xFF;

Port C bekommt als Biteinstellung den Inhalt aus dem Parameter 
"BarGraph" und 0xFF. D.h. wenn Bargraph 0b00001111 ist und mit 
0b11111111 und-Verknüpft wird, ergibt dies 0b00001111.
0 und 1 und-Verknüpft ergibt 0
1 und 1 und-Verknüpft ergibt 1
0 und 0 und-Verknüpft ergibt 0


>     PORTD |= BarGraph [AnzahlLeds] >> 8;

Der Parameter "BarGraph", genau gesagt das Bitmuster, wird um 8 Bit nach 
rechts verschoben. Aus z.B. 0b00001111 11111111 wird dann 0b00001111.
Dieses Muster bekommt Port D als Eingabe


Johannes S. schrieb:
> Atmel hat sich soviel Mühe gegeben und einen schönen Simulator in das
> Atmel Studio eingebaut. Warum benutzt du den nicht einfach mal anstatt
> immer nur zu raten?

Den kenne ich schon, habe den aber noch nie so wirklich in Betracht 
gezogen, danke für die Erinnerung. Gute Idee :)


Theor schrieb:
> Eine gute Quelle, in der C insgesamt beschrieben ist, das Material
> geordnet und in Zusammenhänge gestellt ist, ist das C-Buch hier:
> http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/

Super Sache! Danke für den Link. Das ist ja super erklärt. :)

[Bernd N (Gast)]

So ganz bin ich noch nicht zufrieden aber seis drum.

void BargraphAnsteuerung (uint16_t Drehzahl)
{
    static const __flash int BarGraph [16] = {0x00, 0x01, 0x03, 0x07, 0x0F, 0x1F, 0x3F, 0x7F, 0xFF,
                                              0x1FF, 0x3FF, 0x7FF, 0xFFF, 0x1FFF, 0x3FFF, 0x7FFF
                                             };
    PORTC = BarGraph [(Drehzahl / 625)] & 0xFF;                              // Anzeige LowByte
    PORTD = BarGraph [(Drehzahl / 625)] >> 8;                                // Anzeige HighByte
}

Jetzt bitte diese Funktion mal erklären. Der Drehzahlbereich 0-10000 
wird hier linear auf die Anzeige verteilt. Warum ?

[Bernd N (Gast)]

Und noch, wann geht die 1ste LED an und wann die letzte LED ?

[Daniel C. (apokya)]

Bernd N schrieb:
> So ganz bin ich noch nicht zufrieden aber seis drum.

Wo liegne denn die Fehler?


> void BargraphAnsteuerung (uint16_t Drehzahl)
> {
>     static const __flash int BarGraph [16] = {0x00, 0x01, 0x03, 0x07,
> 0x0F, 0x1F, 0x3F, 0x7F, 0xFF,
>                                               0x1FF, 0x3FF, 0x7FF,
> 0xFFF, 0x1FFF, 0x3FFF, 0x7FFF
>                                              };
>     PORTC = BarGraph [(Drehzahl / 625)] & 0xFF;
> // Anzeige LowByte
>     PORTD = BarGraph [(Drehzahl / 625)] >> 8;
> // Anzeige HighByte
> }
>
> Jetzt bitte diese Funktion mal erklären.

(uint16_t Drehzahl): Drehzahl in uint16_t (0-65535)
static: Statische Variable, behält Inhalt nach Beendigung der Funktion 
bei
__flash: Speicher in Flash (ehrlich gesagt weiß ich nicht genau was das 
bewirkt und finde nicht so richtig die Erklärung)
int: Interrupt (unterbrechungsanforderung)

Drehzahl / 625: 10.000 / 625 = 16

Der Rest ist wie oben schon beschrieben. Hoffe ich


> Der Drehzahlbereich 0-10000
> wird hier linear auf die Anzeige verteilt. Warum ?

Naja. Warum linear kann ich nicht so richtig beantworten. Ich kann nur 
vermuten, weil es einmal weniger zu Berechnen ist, für den Controller, 
und weil die Anzeige nicht exponentiell ansteigen soll. Also je höher 
die Drehzahl, desto mehr LEDs.


Bernd N schrieb:
> Und noch, wann geht die 1ste LED an und wann die letzte LED ?

Die erste LED geht bei 312,5 Umdrehungen an, da der Controller  durch 
"const" nur Ganzzahlen verwendet und die gerundet werden.
0 - 0,4 bedeutet [0], also keine LED (0 - 312,499)
0,5 - 1,4 bedeutet[1], also LED 1 (312,5 - 937,499)
15,5 - 16 bedeutet [16], also LED 15 (9.687,5 - 10.000)

[Bernd N (Gast)]

>> Die erste LED geht bei 312,5

Nö, mal ne Frage am Rande, testest du den gegeben Code nicht ? und wie 
sieht es mit dem Rechnen aus ?

Du hast 15 LEDs und mit dem Zustand "alle aus" insgesamt 16 Zustände. Du 
verteilst alle Zustände somit über die gesamte Anzeige (linear 
verteilt). Dein Verhältnis Drehzahl zur Anzeige ist / sollte immer 
linear sein oder ? Was du gerne variabel hättest wäre der Punkt ab wann 
die 1ste LED leuchtet und wann die letzte an geht. Der Bereich min bis 
max bleibt linear.

>> Drehzahl / 625: 10.000 / 625 = 16
genau, da sind deine 16 Zustände. Rechnen wir mal:
10000:625 => 16tes Element aus der Tabelle = 0x7FFF und somit alle LEDs 
ein. Wann geht also die erste an ? Wenn Drehzahl = 625 ist denn 625/625 
= 1 oder ? Die Frage war aber wann geht die letzte mit an ? kannst du 
das wirklich nicht ausrechnen ?

Das solltest du hinbekommen und dann hast du 2 Werte Paare die da sind 
Anzahl LedMin LedMax und DrehzahlMin und DrehzahlMax. Daraus lässt sich 
was ableiten! Wenn du dir das erarbeitest dann kannst du die LEDs 
beliebig zur Drehzahl anpassen.

>> Die erste LED geht bei 312,5 Umdrehungen an, da der Controller  durch
>> "const" nur Ganzzahlen verwendet und die gerundet werden.

Da denkst du mal drüber nach denn das ist Blödsinn. Gerechnet wird die 
Anzahl LEDs und es erfolgt eine Zuweisung zum Port Ausgang gemäß Tabelle 
(Array).

[Bernd N (Gast)]

Wink mit dem Zaunpfahl :-)
https://de.wikipedia.org/wiki/Steigung

Und das noch nachgeliefert: Das Schlüsselwort void (englisch für 
nichtig, ungültig, leer) wird in einigen Programmiersprachen anstelle 
eines Datentyps benutzt, um anzugeben, dass keine Daten übergeben werden 
oder der Typ der Daten nicht angegeben ist.

[Daniel C. (apokya)]

Bernd N schrieb:
>>> Die erste LED geht bei 312,5
>
> Nö, mal ne Frage am Rande, testest du den gegeben Code nicht ? und wie
> sieht es mit dem Rechnen aus ?

Nein. Ich lese die Bestandteile nach und überlege die Arbeitsweise des 
Codes.
Na ich bin davon ausgegangen, dass auf Ganzzahlen gerundet wird. Daher 
0,5 * 625 = 312,5


> Du hast 15 LEDs und mit dem Zustand "alle aus" insgesamt 16 Zustände. Du
> verteilst alle Zustände somit über die gesamte Anzeige (linear
> verteilt). Dein Verhältnis Drehzahl zur Anzeige ist / sollte immer
> linear sein oder ? Was du gerne variabel hättest wäre der Punkt ab wann
> die 1ste LED leuchtet und wann die letzte an geht. Der Bereich min bis
> max bleibt linear.

Das stimmt, So würde es sich ändern


>>> Drehzahl / 625: 10.000 / 625 = 16
> genau, da sind deine 16 Zustände. Rechnen wir mal:
> 10000:625 => 16tes Element aus der Tabelle = 0x7FFF und somit alle LEDs
> ein. Wann geht also die erste an ? Wenn Drehzahl = 625 ist denn 625/625
> = 1 oder ? Die Frage war aber wann geht die letzte mit an ? kannst du
> das wirklich nicht ausrechnen ?

Ich habe eine falsche Berechnungsgrundlage. Ich wusste nicht, dass der 
Zustand erst bei 1 auch 1 ist.

[Bernd N (Gast)]

>> Nein. Ich lese die Bestandteile nach und überlege die Arbeitsweise des
>> Codes.

Es wird Zeit das du selbst den Code ausprobierst und auf deiner 
Zielhardware testest sonst wird das nix.

>> Ich habe eine falsche Berechnungsgrundlage. Ich wusste nicht, dass der
>> Zustand erst bei 1 auch 1 ist.
Nein, du verstehst den Code nicht. Leider weisst du auch nicht wie man 
eine solche Berechnung anstellt.

>> Na ich bin davon ausgegangen, dass auf Ganzzahlen gerundet wird. Daher
>> 0,5 * 625 = 312,5
Ist 0.5 für dich eine Ganzzahl ? und wie kommst du darauf ? wie kommst 
du auf 0.5 ?

[Daniel C. (apokya)]

Bernd N schrieb:
>>> Nein. Ich lese die Bestandteile nach und überlege die
> Arbeitsweise des
>>> Codes.
>
> Es wird Zeit das du selbst den Code ausprobierst und auf deiner
> Zielhardware testest sonst wird das nix.

Als Simulation testen? Denn wenn ich das wirklich auf der Hardware 
testen soll, müss ich erst lernen, wie ich das Drehzahlsignal in 
Abhängigkeit von der Zeit als Drehzahlwert ermitteln kann.


>>> Ich habe eine falsche Berechnungsgrundlage. Ich wusste nicht, dass der
>>> Zustand erst bei 1 auch 1 ist.
> Nein, du verstehst den Code nicht. Leider weisst du auch nicht wie man
> eine solche Berechnung anstellt.

Daran könnte es auch liegen :D
Aber es ist ja nicht so, dass ich es garnicht verstehe. Ich verstehe es 
nur nicht so, wie es soll.


>>> Na ich bin davon ausgegangen, dass auf Ganzzahlen gerundet wird. Daher
>>> 0,5 * 625 = 312,5
> Ist 0.5 für dich eine Ganzzahl ? und wie kommst du darauf ? wie kommst
> du auf 0.5 ?

Nein, du hast recht. Es ist keine Ganzzahl.
Ich habe angenommen, dass der µC mit Kommazahlen, wie ein Taschenrechner 
rechnet. Und dann würde ab 0,5 aufgerundet. Daher die Annahme mit 0,5.

Das er dies nicht macht und immer mit Ganzzahlen rechnet, außer man gibt 
ihm das vor, das weiß ich jetzt und habe ich jetzt gelernt, wodurch sich 
die Lösung von 625 ganz klar ergibt.

Danke dafür :)

[Bernd N (Gast)]

>> Als Simulation testen? Denn wenn ich das wirklich auf der Hardware
>> testen soll, müss ich erst lernen, wie ich das Drehzahlsignal in
>> Abhängigkeit von der Zeit als Drehzahlwert ermitteln kann.

Du bist schon ein seltenes Exemplar. Ein bischen Phantasie und man kann 
sich doch eine Variable erzeugen welche die Drehzahl simuliert. Es gilt 
doch nur die Bargraph Anzeige anzusteuern und ein bischen zu testen.

    while (1) {
        printf ("\033[H");                                                   // cursor home
        BargraphAnsteuerung (Drehzahl);
        Drehzahl += 50;
        if (Drehzahl >= 10000)
            Drehzahl = 0;
        _delay_ms (500);
    }
}

void BargraphAnsteuerung (uint16_t Drehzahl)
{
    static const __flash int BarGraph [16] = {0x00, 0x01, 0x03, 0x07, 0x0F, 0x1F, 0x3F, 0x7F, 0xFF,
                                              0x1FF, 0x3FF, 0x7FF, 0xFFF, 0x1FFF, 0x3FFF, 0x7FFF
                                             };
    printf (("BIT Muster Port1 = %x  \n\r"), BarGraph [(Drehzahl / 625)] & 0xFF);
    printf (("BIT Muster Port2 = %x  \n\r"), BarGraph [(Drehzahl / 625)] >> 8);
    printf (("Drehzahl = %u     "), Drehzahl);
}

Was glaubst du denn wie ich das Teste ?

Kauf dir nen billiges Arduino Board und verwende das für deine Übungen. 
Die haben die UART auf die USB Schnittstelle als virtuellen COM Port 
geführt. Dann kannst du im Terminalfenster zusehen. Genauso kannst du 
aber auch schon jetzt Die LED Kette beobachten, wie gezeigt einfach eine 
Testvariable verwenden. Das kannst du für jeden Drehzahlbereich testen 
ohne das die echte Messung schon implementiert ist.

Ich meins ernst, besorg dir nen Trainingsboard oder arbeite mit deinem. 
Andernfalls stell ich meine Unterstützung hier ein.

Im Anhang mein Testcode.

[Daniel C. (apokya)]

Den Code habe ich verstanden, ohne ihn simulieren zu müssen.
Wieso soll ich den denn jetzt noch testen?

Ich würde das gerne theoretisch erarbeiten.
Und sollte es garnicht gehen oder ich zu dämlich dafür sein, simuliere 
ich den hier und dann passt das.

Aber wenn ich doch von vorne herein den Code verstehe, auch wenn ich 
nicht alles zu 100% wiedergebe, wie du es gerne hören möchtest, änder 
das doch nichts daran, dass ich es verstanden habe, oder?

Oder willst du auf etwas ganz anderes heraus, bzw. ich verstehe dich 
einfach nicht? Oder du mich nicht?

"printf" muss ich leider fragen, aber kann auf meiner Hardware doch 
garnicht ausgelesen werden?!
Das würde nur auf dem Arduino-Board gehen, oder?

Ich teste es die Tage mal.

Auf die printf-Kommandos wäre ich auhc nicht gekommen, sry dafür.

[Bernd N (Gast)]

Du brauchst doch printf nicht im Moment, du hast doch deine LED Kette. 
Mir ging es darum das du Dinge ausprobierst und erklärst lang und breit 
das geht nicht weil ja deine Drehzahlmessung noch nicht funktioniert.

Du brauchst nur einen MAX 232 und kannst dann ebenso die UART auf deinem 
Board verwenden. Warum soll das nicht gehen ?

https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART

[Bernd N (Gast)]

>> Den Code habe ich verstanden, ohne ihn simulieren zu müssen.
Das hat aber gedauert und das hättest du durch einfaches testen 
schneller verstehen können.

>> Aber wenn ich doch von vorne herein den Code verstehe
Eher selten.

>> du 2 Werte Paare die da sind Anzahl LedMin LedMax und DrehzahlMin und
>> DrehzahlMax. Daraus lässt sich was ableiten! Wenn du dir das erarbeitest
>> dann kannst du die LEDs beliebig zur Drehzahl anpassen.

Von weiter oben... schon darüber nachgedacht ? wenn du es verstanden 
hast dann wären wir einen Schritt weiter.

[Stefan F. (Gast)]

> Den Code habe ich verstanden, ohne ihn simulieren zu müssen.

Sehr gut. Allerdings habe ich ernsthafte Zweifel daran.

> Wieso soll ich den denn jetzt noch testen?

Plonk! Um zu sehen, ob er funktioniert!

> Ich habe angenommen, dass der µC mit Kommazahlen, wie ein
> Taschenrechner rechnet.

Tja, falsch gedacht. Es geht zwar, aber nicht ganz so einfach. Solange 
du davon ausgehst, dass der µC schon das tun wird, was du willst, hast 
du gar nichts verstanden. Kein mensch entwickelt mit dieser Methode 
Software. Außerdem ist in diesem Konkreten Fall ziemlich egal, wie der 
µC funktioniert, da du schon die Programmiersprache falsch angewendet 
hast.

> "printf" muss ich leider fragen, aber kann auf meiner Hardware
> doch garnicht ausgelesen werden?!

Deswegen habe ich schon vor einem halben Jahr und mehrfach zwischendurch 
dazu geraten, Dir einen I/O Pin frei zu machen, damit du ihn für 
serielle Ausgabe verwenden kannst. Ich habe Dir auch einen Link gegeben, 
wo erklärt wird, wie man das nutzt.

Nochmal der Link: http://stefanfrings.de/avr_hello_world/index.html

Uch auf die Gefahr hin, dass ich mich wiederhole: Besorge Dir einen 
Arduino Uno oder Nano, stecke ihn an deinen PC und lerne darauf die 
Grundlagen von C. Danach bist du bereit, deinen mit der Programmierung 
deines Drehzahlmessers zu beginnen.

Fließkomma-Operationen führen übrigens Ratz-Fatz zu Speicherüberlauf. 
Was nützt dein schönes theoretisch durchdachtes Programm, wenn es am 
Ende gar nicht in den µC rein passt?

[Jörg W. (dl8dtl) (Moderator)]

Stefan U. schrieb:
> Fließkomma-Operationen führen übrigens Ratz-Fatz zu Speicherüberlauf.

Ach, naja, lass mal die Ammenmärchen in der Truhe. ;-)

Das ist kein ATtiny13 oder ATtiny2313 oder so, sondern ein ATmega32.

Dessen Flash muss er mit dem bisschen an Aufgabe erstmal gefüllt
bekommen.

Wenn Fließkommazahlen dem Verständnis der Berechnungen förderlich
sind, dann soll er sie halt benutzen.  Der Gleitkommakram auf dem
AVR ist verdammt gut optimiert, und bei irgendwelchen Skalierungen
auf Ganzzahlen kann man sich gerade als Anfänger, der Über- oder
Unterlaufprobleme bei einer Rechnung nicht so sehr im Blick hat,
schnell in die Nesseln setzen.

Allerdings muss man die Sprache schon kennen.  @Daniel:

2 / 3 ergibt in C eine glatte 0.

2 / 3.0 oder 2.0 / 3 ergibt dagegen etwa 0.67.

[Daniel C. (apokya)]

Soo, endlich kann ich mir die Zeit nehmen und anfangen mich mit Code 
auseinander zu setzen.

Ich gucke mir grade einmal die Codevorschläge der letzen Beiträge an und 
versuche nun endlich die Enderkenntnis zu erlangen.

[Daniel C. (apokya)]

Soo, habe mal alles, was ich schon gemacht habe und was ich brauche 
zusammen gepackt und den Code für die Segmentanzeige als Array 
geschrieben.

#include <avr/io.h>
#include <util/delay.h>
#define F_CPU 16000000UL


//Ausgänge
#define NSL PB0        //PIN Nebelschlussleuchte (PB0)
#define DZB PB1        //PIN Drehzahlband (PB1)
#define SEG PB3        //PIN Segment Display (PB3)

//Status-LEDs
#define S_LED_1 PB4      //PIN Status-LED 1
#define S_LED_2 PB5      //PIN Status-LED 2
#define S_LED_3 PB6      //PIN Status-LED 3
#define S_LED_4 PB7      //PIN Status-LED 4

//Gaenge
#define DN PA4        //PIN für Gang D & N
#define NR PA5        //PIN für Gang N & R

//Bremsen
#define B PA7        //PIN für Fußbremse
#define HB PA6        //PIN für Handbremse


int main(void)
{  
  DDRB = 0b11111011;      //Ausgang B0-B1, B3-B7; außer Eingang für Drehzahlsignal (PB2)
  DDRC = 0b11111111;      //Ausgang C      (Drehzahlband Hälfte 1)
  DDRD = 0b11111111;      //Ausgang D      (Drehzahlband Hälfte 2)
  PORTC = 0b00000000;      //Zustand Low    (Drehzahlband C auf 0V)
  PORTD = 0b00000000;      //Zustand Low    (Drehzahlband D auf 0V)
  
  //PORTB |= (1 << NSL) | (1 << DZB) | (0 << SEG);  //Transistoren: 1 = Aus (5V) / 0 = An (0V)
  //" |= " = Aus / " &= ~ " = An
  
  //  PORTB &= ~(1 << NSL);  // An
    PORTB |=  (1 << NSL);  // Aus
  //  PORTB &= ~(1 << DZB);  // An    
    PORTB |=  (1 << DZB);  // Aus
  //  PORTB &= ~(1 << SEG);  // An
    PORTB |=  (1 << SEG);  // Aus
  

  uint16_t i;
  i = 0;

  while (1)
  {
    //Drehzahlband(i);
    BargraphAnsteuerung(i);
    i = i + 20;

  }
}


void Drehzahlband (uint8_t AnzahlLeds)
{
  const uint16_t BarGraph [16] = {
    0x00, 0x01, 0x03, 0x07, 0x0F, 0x1F, 0x3F, 0x7F, 0xFF,        //PC0 - PC7
    0x1FF, 0x3FF, 0x7FF, 0xFFF, 0x1FFF, 0x3FFF, 0x7FFF          //PD0 - PD7
  };
  PORTC |= BarGraph [AnzahlLeds] & 0xFF;
  PORTD |= BarGraph [AnzahlLeds] >> 8;
}
  

void Segmentanzeige (uint8_t Zeichen)
{
  const uint16_t Segment [9] = {
    0b1001000111010011,    //D = 0
    0b0000000000110010,    //1 = 1
    0b1100100011011001,    //2 = 2
    0b1000000011011011,    //3 = 3
    0b0000110000011010,    //4 = 4
    0b1000110011001011,    //5 = 5
    0b0100011000010110,    //N = 6
    0b0100110011011100,    //R = 7
    0b0100110011011000,    //P = 8
    0b0000100000001000    //- = 9
  };
  PORTC |= Segment [Zeichen] & 0xFF;
  PORTD |= Segment [Zeichen] >> 8;
}

Rein gedanklich würde ich jetzt weiter machen mit der Unterteilung für 
die Gänge D bzw. 1-5

Allerdings fange ich dann wieder mit if an. Wäre da ein Array 
sinnvoller?

Ich habe leider variable Drehzahlen, die teilweise nicht im ganzen 
Drehzahlband linear laufen.

Ich hätte jetzt ein Array sonst gemacht, indem statt der Hex- oder 
Bin-Werte die Drehzahl steht.

Einen Link zur helfenden Hilfeseite wäre super. Dann kann ich mir das 
mal durchlesen. Finde durch fehlendes Wissen über die Begriffe kaum 
helfende Seiten. Das GCC-Tutorial ist leider doch sehr allgemein 
geschrieben, finde ich.

[Schreiber (Gast)]

Daniel C. schrieb:
> Hier in diesem Beitrag geht es um die Programmierung des Programms.
> Vorrangig mit AtmelStudio.

Ich würde mit Arduino anfangen und mal ein paar Tutorials durcharbeiten

Daniel C. schrieb:
> Und wenn etwas an der Hardware fehlt oder garnicht so ehen kann, darf
> das natürlich auch gerne angesprochen werden.

Steckbrett kaufen und einfach mal ausprobieren. Dszu ein paar 
Arduino-Module (aus China)

[kgkjlfgy (Gast)]

Daniel C. schrieb:
> Ich habe leider variable Drehzahlen, die teilweise nicht im ganzen
> Drehzahlband linear laufen.

Linear zu was?

kgkjlfgy

[kgkjlfgy (Gast)]

Daniel C. schrieb:
> Soo, habe mal alles, was ich schon gemacht habe und was ich brauche
> zusammen gepackt

Nein.
Es fehlt mindestens "BargraphAnsteuerung"

kgkjlfgy

[Daniel C. (apokya)]

kgkjlfgy schrieb:
> Daniel C. schrieb:
>> Ich habe leider variable Drehzahlen, die teilweise nicht im ganzen
>> Drehzahlband linear laufen.
>
> Linear zu was?
>
> kgkjlfgy

Es ging um die Ansteuerung des Bargraphen, der mit der Drehzahl als 
Parameter diese durch 625 geteilt hat.
Dadurch wäre ein lineares Profil entstanden.


kgkjlfgy schrieb:
> Daniel C. schrieb:
>> Soo, habe mal alles, was ich schon gemacht habe und was ich brauche
>> zusammen gepackt
>
> Nein.
> Es fehlt mindestens "BargraphAnsteuerung"
>
> kgkjlfgy

Stimmt, hatte für Test-Zwecke den Namen auf "Drehzahlband" geändert. Ist 
jetzt natürlich falsch. Danke für den Hinweis :)

[Bernd N (Gast)]

>> Rein gedanklich würde ich jetzt weiter machen mit der Unterteilung für
die Gänge D bzw. 1-5

Rein gedanklich würde ich auf keinen Fall weitermachen sondern praktisch 
auf einer Hardware testen. Code erschliesst sich dir nicht gedanklich 
sondern praktisch.

Hast du mittlerweile entsprechende Hardware zum testen ?

[Daniel C. (apokya)]

Bernd N schrieb:
>>> Rein gedanklich würde ich jetzt weiter machen mit der
> Unterteilung für
> die Gänge D bzw. 1-5
>
> Rein gedanklich würde ich auf keinen Fall weitermachen sondern praktisch
> auf einer Hardware testen. Code erschliesst sich dir nicht gedanklich
> sondern praktisch.
>
> Hast du mittlerweile entsprechende Hardware zum testen ?


Ich glaube so kommen wir nicht weiter. Schade.
Ist echt lieb, dass du mir helfen möchtest, aber ich glaube so wird das 
dann doch nichts. Ich bräuchte nur einen Gedankanstoß, was als nächsten 
Schritt eine gute Idee wäre und ggf. Literatur dazu. Dann würde ich mich 
einlesen, programmieren und ggf. testen.

Ich nutze meine Hardware zum Testen.
Ich werde, ja das ist stur, nur meine Hardware verwenden.
Wenn es jetzt darum geht eine LED zum Blinken zu bekommen geht das auch 
mit meiner Hardware. Die Codeschnipsel die wir hier schon 
durchgearbeitet haben funktionieren darauf auch.

Wofür dann noch extra ein Board mit Platine, wo alle Registernamen 
anders sind, der Aufbau komplett unterschiedlich ist und ähnliches?


Sorry, wenn ich so schorf reagiere.

Bis jetzt hat es ja "gut" geklappt.

[Stefan F. (Gast)]

> Ich bräuchte nur einen Gedankanstoß, was als nächsten
> Schritt eine gute Idee wäre und ggf. Literatur dazu.

Ich habe das Gefühl, dass es Dir sehr schwer fällt, komplexe Aufgaben in 
einfache Aufgaben zu zerlegen. Vermutlich kann man das nicht durch Lesen 
von Literatur lernen, da es sich meiner Meinung nach um ein Talent 
handelt.

> Gedankenanstoß

Macht in diesem Fall wohl eher Sinn.

> was als nächsten Schritt eine gute Idee wäre

Das musst Du Dir schon selbst ausdenken. Du schriebst etwas von 
Aufteilung der Gänge. Was bedeutet das konkret? Was ist der Input, und 
was ist der Output. Wann müssen die Gänge "aufgeteilt" werden. Wenn das 
klar ist, kann man darüber sinnieren, wie man es tut.

[Daniel C. (apokya)]

Stefan U. schrieb:
> (...) Du schriebst etwas von Aufteilung der Gänge.
> Was bedeutet das konkret?

Aufteilung:
-> Gang D bekommt ein Drehzahlband von, nach neuen Kenntnissen, ca. 1500 
- ca. 8500 RPM.
-> Gang 1-5 hingegen bekommen Teile des kompletten Drehzahlbandes.
Gang 1 in dem Fall ca. 1500 bis ca. 5500 RPM.
Gang 2 in dem Fall ca. 5500 RPM bis 6500 RPM oder so.

> Was ist der Input, und was ist der Output.

Input ist in dem Fall erst einmal die Drehzahl. Die Einstellung, ob Gang 
D oder Gang 1-5 soll über die beiden Taster erledigt werden.
Dabei dachte ich erst einmal an:
Beide für 3 Sekunden gedrückt halten. (PA2 & PA3)

Output ist in dem Fall die Anzahl der LEDs für die Drehzahlanzeige und 
der Gang.

>Wann müssen die Gänge "aufgeteilt" werden.

Wie oben schon beschrieben, bei Einstellung durch die Taster.
Die Gänge ändern sich im Bezug zur Drehzahl.
Allerdings ist mir schon beim Fahren aufgefallen, dass ich in dem 
jeweiligen Gang andere Hoch- und Runterschalt-Drehzahlen habe.

Wenn z.B. bei über 6500 RPM in den 3. hochgeschaltet werden soll, darf 
erst bei 5000 RPM in Gang 2 zurück geschaltet werden.


Was kompliziert :D

[Daniel C. (apokya)]

Ich raff das nicht.

Ich versuche mich grade an den Gängen D, N, R und P.
Egal was ich mache. Entweder ich lass an den richtigen Stellen das ! weg 
oder pack es rein und schriebe stattdessen eine 0 hin, es wird immer 
etwas anderes gemacht.

Ich habe das alles mehrfach simluiert, immer mit dem richtigen Ergebnis.

Eingänge werden nach GND geschaltet.

Wenn es so, wie es jetzt ist, programmiert wird, dann bekomme ich als 
Ergebnis eine 0.
Schalte ich HB nach GND wird es wie gewollt eine 8.
Schalte ich NR nach GND bekomme ich eine 6, statt 7.
Schalte ich DN oder DN mit NR nach GND bekomme keine Änderung, es bleibt 
bei 0.

Bin ich blöd? Was ist denn falsch, wenn der Simulator immer richtig 
arbeitet?

PORTA = 0b11110000;

if (!(PINA & (1 << HB)))                  //P  Low
    {
      j = 8;
    }
    else if  ((!(PINA & (1 << DN))) && (!(PINA & (1 << NR))))  //N  Low & Low
    {
      j = 6;
    }
    else if ((!(PINA & (1 << DN))) && ((PINA & (1 << NR))))    //D
    {
      j = 0;
    }
    else if  (((PINA & (1 << DN))) && (!(PINA & (1 << NR))))  //R
    {
      j = 7;
    }
    else if  (((PINA & (1 << DN))) && ((PINA & (1 << NR))))    //-
    {
      j = 9;
    }

[Bernd N (Gast)]

>> Ich glaube so kommen wir nicht weiter. Schade.
scheint eher so das du nicht weiter kommst :-) und erzähl mir nix von 
Simulator. Wenn du auf deiner Hardware testen kannst dann siehst du die 
reale Welt.

Tips hast du genug bekommen auch von mir inklusive links aber gelesen 
hast du die nicht. Wenn doch dann hast du es nicht verstanden.

[Stefan F. (Gast)]

Dein Code ist viel zu nahe an der Hardware, den raffe ich auch nicht. 
Ich würde eher sprechende Variablen erwarten, etwa so:

if (drahzahl_steigt)
{
    if (drehzahl>8000)
    {
        fakeGangAnzeige=5;
    }
    else if (drehzahl>7000)
    {
        fakeGangAnzeige=4;
    }
    ...
    else
    {
        fakeGangAnzeige=1;
    }
}
else if (drehzahl_sinkt)
{
    if (drehzahl<1000)
    {
        fakeGangAnzeige=1;
    }
    else if (drehzahl<2000)
    {
        fakeGangAnzeige=2;
    }
    ...
    else
    {
        fakeGangAnzeige=5;
    }
}
else // drehzahl hat sich nicht geändert
{
    ; // nix tun
}

Was diese Buchstaben D, R, N usw. bedeuten, weiss ich nicht. Aber die 
bekommst du sicher auch noch in dieses Code-Schema hinein.

Nach dieser "Berechnung" überträgst du dann die Variable fakeGangAnzeige 
auf die Hardware (I/O Pins).

[Patrick J. (ho-bit-hun-ter)]

Stefan U. schrieb:
> Buchstaben D, R, N

'Drive'
'Neutral'
'Rückwärts' / 'Retour'
Nebenbei wurde auch noch P genannt:
'Park'

... liest sich, wie ein Automatik-Getriebe
(so richtig mit Schalten wirst Du in der F1 wohl eh nichts mehr zu tun 
haben, ohne die ganzen 'Tausendfüßler' müssten die Jungs wieder selber 
rennen)

[Daniel C. (apokya)]

Bernd N schrieb:
> scheint eher so das du nicht weiter kommst :-) und erzähl mir nix von
> Simulator. Wenn du auf deiner Hardware testen kannst dann siehst du die
> reale Welt.

Ohne den Simulator hätte ich die Fehlereingrenzung nicht machen können 
:P


> Tips hast du genug bekommen auch von mir inklusive links aber gelesen
> hast du die nicht. Wenn doch dann hast du es nicht verstanden.

Das ist richtig. Das verstehen, soll ja kommen ;)


Stefan U. schrieb:
> Dein Code ist viel zu nahe an der Hardware, den raffe ich auch
> nicht.
> Was diese Buchstaben D, R, N usw. bedeuten, weiss ich nicht. Aber die
> bekommst du sicher auch noch in dieses Code-Schema hinein.

Patrick J. schrieb:
> 'Drive'
> 'Neutral'
> 'Rückwärts' / 'Retour'
> Nebenbei wurde auch noch P genannt:
> 'Park'

Wie Patrick schon richtig schreibt, war im oberen Code, der von mir wohl 
Fehler ausgespuckt hat, die Gänge D, N, R und P gemeint.
Da war noch nichts mit der Drehzahl.

Die kommt erst jetzt. Aber da danke ich dir auf jeden Flal schon mal für 
den Code. Wenn ich alles per umständlichem If programmiert habe, werde 
ich den Code hier mal posten. Vlt. gibt es da doch noch etwas mehr zu 
machen.

Timer muss ich leider auch noch machen ... Das wird ein Spaß :D


Aber ich kann verkünden, dass ich den Fehler gefunden habe:
Ein Hardware-Defekt lag vor, weil eine Zender-Diode durchgebrannt ist.
Dadurch wurde der Pin, der für das Signal DN zuständig ist, die ganze 
Zeit auf Masse gezogen und hat mir somit ein "falsches" Signal erzeugt.

Der Code war von Anfang an richtig.



> ... liest sich, wie ein Automatik-Getriebe
> (so richtig mit Schalten wirst Du in der F1 wohl eh nichts mehr zu tun
> haben, ohne die ganzen 'Tausendfüßler' müssten die Jungs wieder selber
> rennen)

Das ist wahr. Die Gänge werden später auch per Drehzahl "geschaltet"

[Stefan F. (Gast)]

> Ohne den Simulator hätte ich die Fehlereingrenzung nicht machen können

Hast du denn immer noch keine Möglichkeit, debug Meldungen seriell 
auszugeben, wie ich vor (gefühlt) Monaten empfahl?

[Daniel C. (apokya)]

Stefan U. schrieb:
>> Ohne den Simulator hätte ich die Fehlereingrenzung nicht machen
> können
>
> Hast du denn immer noch keine Möglichkeit, debug Meldungen seriell
> auszugeben, wie ich vor (gefühlt) Monaten empfahl?

Nein. Ich habe die Platine nach Schaltplan gebaut und einen 
stinknormalen ISP-Programmer.

Eine Debug-Lösung ist durch die USART-Pins nicht mehr möglich (belegt) 
und die Info, dass es auch per PinA0 geht habe ich bis jetzt nciht 
umgesetzt, da eigentlich keine großen Fehler auftreten.

Bis jetzt funktioniert alles simuliert und wenn ich programmiere meist 
auch.

Ich habe mich noch nicht eingelesen, was ist denn als Aufwand damit 
verbunden?


Mal was anderes:
Kann ich _delay_us(t) nicht mit einer Variable füttern?
Ich würde die, weil es scheinbar funktioniert gerne als 
Helligkeitsregelung nutzen.
Allerdings meckert Atmel dann.

Würde gerne per if-Abfrage den LDR auslesen und die Einstellung in µs 
umrechnen. Das Ergebnis dann _delay zuweisen.

Wenn ich in meinem Porgramm nämlich _delay weg lassen, sind sie nur noch 
halb so hell. Und je mehr _delay in µs ich dazwischen packe, desto 
heller werden sie :D

Oder ist das ein Fehler?

[Patrick J. (ho-bit-hun-ter)]

Hi

Denke, die Delay-Funktion wird ein fester Code-Block, Der bei der 
angegebenen Quarz-Frequenz eben so-und-so-viele-Takte Zeit verbrät.

Zumindest ist Das so beim Assembler-Makro:
https://www.mikrocontroller.net/articles/AVR_Assembler_Makros#Verz.C3.B6gerung_um_X_Nanosekunden
Generiert sehr wenig Code (vom Platz), um die angegebene Zeit 
'totzuschlagen' - allerdings während des 'Compilieren'/Assemblieren 
generiert, deshalb nicht mit Variablen benutzbar.
(hab mir das Delay auf µs umgestrickt, da Makro, braucht's erst 
Speicherplatz, wenn's eingebunden wird)

MfG

[Daniel C. (apokya)]

https://www.mikrocontroller.net/articles/Soft-PWM

Ich habe jetzt zum Testen mal die erste Verion und die dritte Version 
versucht.

Bei 16 MHz macht die 3. Version garnichts, wenn ich die PWM-Schritte 
ändere.
Nur die 1. Version funktioniert wie es soll.

Mein Problem ist aber, ich hoffe da könnt ihr mir helfen, dass ich gerne 
die 3. Version verwenden möchte, allerdings
1. nicht weiß, woran es hapert, ob es der Prescaler ist, oder was 
anderes und
2. ich die Änderung der PWM-Schritte gerne Variabel habe, sodass ich 
diese über den ADC-Eingang machen kann. Ist das ohne weiteres möglich?

Danke schon mal :)

[Stefan F. (Gast)]

Du kannst von diesem Projekt abgucken, wie man einen normalen I/O Pin 
für Debug Ausgaben nutzt: 
http://stefanfrings.de/avr_hello_world/HelloTiny.zip

> da eigentlich keine großen Fehler auftreten.
Dafür bist du aber schon sehr lange am herum fummeln.

> was ist denn als Aufwand damit verbunden?

Minimal

[Daniel C. (apokya)]

Stefan U. schrieb:
>> da eigentlich keine großen Fehler auftreten.
> Dafür bist du aber schon sehr lange am herum fummeln.

Ich muss ja auch erstmal alles lernen.
Ich habe vor ein paar Tagen erst richtig angefangen. Davor habe ich 
nichts gemacht, wegen Prüfungen ;)


Okay. Das ist der Code. Danke.

So wie mir scheint, zeigt er mir nur eine LED, die an oder aus ist. Ist 
das richtig?
Wie soll ich dann etwas über Fehler erkennen?

[Stefan F. (Gast)]

> So wie mir scheint, zeigt er mir nur eine LED, die an oder aus ist.
> Ist das richtig?

Nein, das Programm gibt auch Textmeldungen seriell auf einem I/O Pin 
aus. Auf dern zugehörigen Webseite findest du eine ausführliche 
Erklärung.

[Daniel C. (apokya)]

Stefan U. schrieb:
>> So wie mir scheint, zeigt er mir nur eine LED, die an oder aus ist.
>> Ist das richtig?
>
> Nein, das Programm gibt auch Textmeldungen seriell auf einem I/O Pin
> aus. Auf dern zugehörigen Webseite findest du eine ausführliche
> Erklärung.


Dafür brauche ich doch extra noch einen Receiver, oder nicht?
So etwas habe ich doch nicht.


Tut mir Leid, ich weiß leider nicht, wo ich auf der Webseite die Hilfe 
dazu finden soll.

[Daniel C. (apokya)]

Folgenden Code heute geschrieben:

void Startbild(uint8_t Modus, uint8_t ALEDStart, uint16_t DauerStart)    //0, 1, 3000
{
  uint8_t MultiplexStart = 0;
  uint8_t ALEDH = 0;
  uint8_t ALEDR = 15;
  
  for (ZeitStart = 0; ZeitStart < DauerStart;)    //Bis ZeitStart >= DauerStart (3000)
  {  
    if (ALEDH < 15)
    {
      if (ZeitDZB >= WZDZBH)            //Startet, wenn ZeitDZB >= WZDZBH (75)
      {
        ALED = ALEDH;
        ZeitDZB = 0;
        Multiplex(MPDZB);
        ALEDH++;
      }
    }
    else if (ALEDH >= 15)
    {
      if (ALEDR <= 15)
      {  
        if (ZeitDZB >= WZDZBR)
        {
          ALED = ALEDR;
          ZeitDZB = 0;
          Multiplex(MPDZB);
          ALEDR--;
        }
      }
    }
  }
}

Das Raufzählen funktioniert ohne Probleme.
Beim Runterzählen macht er aber nichts.
Die TestLEDs, dich ich in jeder if-Abfrage im unteren Bereich drin 
hatte, zeigte mit, dass alle Abfragen korrekt durchlaufen wurden.

Aber warum wird nicht mehr runter gezählt?
ALEDR wird nicht um ein verringert.

Was übersehe ich, oder ist mir nicht bekannt?
Ich sitze schon Stunden da dran und kenne die Lösung nicht.

[Patrick J. (ho-bit-hun-ter)]

Hi

Wie ich das Programm verstehe:
Schleife von 0 bis 3000
Die ersten 15 Durchläufe (ALEDH<15) wird ALED auf ALEDH gesetzt und 
ALEDH erhöht
-> denke, eine Art Lichterbalken wird gefüllt
Danach wird im ELSEIF-Zweig auf ALEDH>=15 geprüft (unnötig, da wir 
'nicht kleiner 15' sind, MÜSSEN wir 'größer oder gleich 15' sein).
Dort sollte ebenfalls (dieses Mal 14) Mal der Wert verringert und 
ausgegeben werden.
Danach (~2970 Durchläufe) wohl dann Nichts mehr.

Daniel C. schrieb:
> if (ZeitDZB >= WZDZBH)            //Startet, wenn ZeitDZB >=
> WZDZBH (75)

Daniel C. schrieb:
> if (ZeitDZB >= WZDZBR)

Passt hier der Endbuchstabe? 1x H, 1x R
Wo wird WZDZBH bzw. WZDZBR gesetzt? Wird Das auch gesetzt?
Definiert müsste die Variabel sein, denke, sonst würde der Compiler 
meckern.

MfG

[Daniel C. (apokya)]

Patrick J. schrieb:
> Hi
>
> Wie ich das Programm verstehe:
> Schleife von 0 bis 3000
> Die ersten 15 Durchläufe (ALEDH<15) wird ALED auf ALEDH gesetzt und
> ALEDH erhöht
> -> denke, eine Art Lichterbalken wird gefüllt
> Danach wird im ELSEIF-Zweig auf ALEDH>=15 geprüft (unnötig, da wir
> 'nicht kleiner 15' sind, MÜSSEN wir 'größer oder gleich 15' sein).
> Dort sollte ebenfalls (dieses Mal 14) Mal der Wert verringert und
> ausgegeben werden.

Ja, ist richtig ;)


> Danach (~2970 Durchläufe) wohl dann Nichts mehr.

Ist noch nicht komplett, desswegen nichts :D


> Daniel C. schrieb:
>> if (ZeitDZB >= WZDZBH)            //Startet, wenn ZeitDZB >=
>> WZDZBH (75)
>
> Daniel C. schrieb:
>> if (ZeitDZB >= WZDZBR)
>
> Passt hier der Endbuchstabe? 1x H, 1x R

Ja. Einmal für "Hoch" und einmal für "Runter"


> Wo wird WZDZBH bzw. WZDZBR gesetzt? Wird Das auch gesetzt?

Werden unter #define mit Wert 75 gesetzt


> Definiert müsste die Variabel sein, denke, sonst würde der Compiler
> meckern.

Ich glaube schon, ja.



Hast du schon eine Idee, warum er das Runterzählen verweigert?

Danke ;)

[Patrick J. (ho-bit-hun-ter)]

Hi

Daniel C. schrieb:
> Hast du schon eine Idee, warum er das Runterzählen verweigert?

Nein, nicht wirklich.
Die beiden If-Abfragen unterscheiden sich nur durch das 'R' bzw. 'H' - 
sehe da momentan keinen Grund, warum Das nicht laufen soll.

MfG

[Stefan F. (Gast)]

> Dafür brauche ich doch extra noch einen Receiver, oder nicht?

Du brauchst ein USB-UART Kabel oder Adapter - braucht man sowieso früher 
oder später und kann man ab 3 Euro bekommen.

> Tut mir Leid, ich weiß leider nicht, wo ich auf der Webseite
> die Hilfe dazu finden soll.

Dann geh mal zum Augenarzt. Ich schätze aber eher, dass du die Seite gar 
nicht gelesen hast. Ich bekomme immer stärker das Gefühl, dass du lieber 
endlose Diskussionen führst, als auch nur einen Absatz Text zu lesen.

So wird man nicht Klug.

[Joachim S. (oyo)]

Stefan U. schrieb:
>> Tut mir Leid, ich weiß leider nicht, wo ich auf der Webseite
>> die Hilfe dazu finden soll.
>
> Dann geh mal zum Augenarzt. Ich schätze aber eher, dass du die Seite gar
> nicht gelesen hast. Ich bekomme immer stärker das Gefühl, dass du lieber
> endlose Diskussionen führst, als auch nur einen Absatz Text zu lesen.

Da muss ich den Threadstarter mal teilweise in Schutz nehmen:
Bzgl. soft-serial hast Du weiter oben geschrieben:

> Auf dern zugehörigen Webseite findest du eine ausführliche
> Erklärung.

Die besagte Webseite von Dir 
(http://stefanfrings.de/avr_hello_world/index.html) finde ich zwar echt 
klasse - aber das spezielle Thema "soft-serial" erklärst Du dort nicht 
wirklich ausführlich, sondern erwähnst es nur ganz beiläufig beim Link 
auf HelloTiny.zip.

Ansonsten @Threadstarter:
Ich kann Stefan grundsätzlich nur zustimmen: Besorg Dir unbedingt 
irgendeinen USB-UART-Konverter, falls Du noch keinen hast. Die kosten ja 
fast nix (zur Not bei Aliexpress bestellen, dann bekommst Du einen ab 75 
Cent, inkl. Porto), und erleichtern die Fehlersuche etc. extrem.

Wenn man mit Mikrocontrollern arbeitet, kommt man um ein beliebigen 
USB-UART-Konverter eigentlich nicht herum; nicht ohne Grund hat wohl 
fast jedes Mikrocontroller-Entwicklungs-Board (Arduino, NodeMCU etc.) 
sowas bereits onboard.

[Daniel C. (apokya)]

Tut meir Leid. Ich wollte deine Seite nicht als "Schlecht" bewerten.
Sie hat bestimmt durchaus ihr Vorteile.

Allerdings habe ich mit dem von dir gegeben Link durch löschen der 
Linkbestandteile mich auf der Startseite wiedergefuden.
Dort habe ich entweder den wichtigen Artikel übersprungen oder den 
Artikel geöffnet, aber den Inhalt nicht als den erkannt, der er hätte 
sein sollen.

Daher habe ich die Informationen nicht gefunden.


Nach deinem Thread habe ich mal nur das Linkende mit "zip" gelöscht und 
habe deine Seite gefunden.


Nun mein Problem. Es wird dort von TxD und RxD gesprochen. Beide diese 
Pins sind schon belegt.


Ich komme nicht mit dem Code klar aber sehe ein, dass ich das brauche. 
Macht ja auch Sinn.

So muss ich den Code nicht immer zur Kontrolle mit LEDs versehen, die 
mir zeigen, dass er auch das macht, was sache ist.

Ich habe auch irgendwo gelesen, dass ein Timer für einen 1ms-Takt 
verwendet werden muss. Diesen habe ich schon in Verwendung: Timer2


Vlt. raffe ich auch alles nicht, weil ich grade aufgestanden bin.
Ich schaue mir das morgen mal an. Aber danke nochmal und entschuldige 
bitte ;)

[Stefan F. (Gast)]

Ei-ei-ei, manchen leuten muss man alles auf dem Präsentierteller 
darlegen:

Download: http://stefanfrings.de/avr_hello_world/HelloTiny.zip
Dazugehörige Seite: http://stefanfrings.de/avr_hello_world/

Dort erkläre ich realtiv knapp, wie man den Pin mit einem Computer 
verbindet und benutzt. Ausführlichere Anleitung findet man in meinem 
Buch, welches sich im Inhaltsverzeichnis der Seite direkt eine Zeile 
darunter befindet: 
http://stefanfrings.de/mikrocontroller_buch/index.html

> Ich komme nicht mit dem Code klar

Warum nicht? Was hast du erwartet, was passiert stattdessen? Wir sind 
keine Hellseher.

> Ich habe auch irgendwo gelesen, dass ein Timer für einen
> 1ms-Takt verwendet werden muss.

Für meine "serialconsole" brauchst du keinen Timer.

> Vlt. raffe ich auch alles nicht, weil ich grade aufgestanden bin.

Ja vielleicht. Das Beispielprogramm zeigt doch, wie es geht:

Du musst nur die Dateien driver/serialconsole.c, driver/serialconsole.h 
und hardware.h zu deinem Projekt hinzufügen. In main.c gehören dann 
diese Zeilen:

#include <stdio.h>
#include <stdlib.h>
#include "driver/serialconsole.h"

In der Initialisierungs-Sequenz rufst du einmal initSerialConsole(); 
auf. Und danach kannst du nach Herzenlust println(), puts() und alle 
anderen Ausgabefunktionen aus der STandard C Library verwenden.


> Nun mein Problem. Es wird dort von TxD und RxD gesprochen. Beide
> diese Pins sind schon belegt.

Deswegen verwendest du ja die Software-Emulation, die kannst du auf 
jeden beliebigen I/O Pin legen und sie kann nur Ausgabe (also nur 
virtual-TxD).

[Daniel C. (apokya)]

Ist der, der Richtige?

http://www.ebay.de/itm/CP2102-6-Pin-USB-2-0-nach-TTL-UART-serial-serieller-Konverter-Kabel-Arduino-/112277718377?hash=item1a24460569:g:J8wAAOSw5cNYg-SI

[Stefan F. (Gast)]

Der ist gut, vor allem weil er ohne Tricks sowohl 3,3V als auch 5V pegel 
unterstützt. Allerdings würde ich einen mit Gehäuse bevorzugen.

[Daniel C. (apokya)]

Stefan U. schrieb:
> Der ist gut, vor allem weil er ohne Tricks sowohl 3,3V als auch 5V
> pegel unterstützt

Das freut mich, danke.


Ich habe gestern noch deinen Code hinzugefügt.
Allerdings kommen folgende Fehler:

Wenn ich initSerialConsole(); in die Initialisierungs-Sequenz, also nach 
meinem Verständnis in "int main(void)" schreibe, komme ich folgende 
Fehler:
- recipe for target 'Programm 1.elf' failed
- undefined reference to `initSerialConsole'

Dann habe ich mal nachgeschaut und in der serialconsole.h steht 
initSerialConsole(); noch einmal drinnen. Wo liegt der Fehler bei mir?


Und: Die hardware.h muss ich doch richtiger Weise auf meinen freien Pin 
(PA0) legen, korrekt?

[Daniel C. (apokya)]

Habe den TTL-UART-Converter über 5V, GND und TxD angeschlossen.

Aber über CMD mit "avrdude -P COM4 -b 2400 -p m32 -c" und dem COntroller 
dahinter kann ich keine Verbindung aufbauen.

Antweder bleibt er bei "Connecting    . " stehen.
Oder ich habe ein Timeout.
Oder er findet Dateien nicht.

COM4 ist richtig.
baurate nach hardware.c eingestellt

Ich weiß nicht weiter.
Ich dachte es wäre einfach, aber irgenwie ist sehr viel mehr dabei zu 
tun


Wo liegen meine Fehler?

[Joachim S. (oyo)]

Daniel C. schrieb:
> Habe den TTL-UART-Converter über 5V, GND und TxD angeschlossen.
>
> Aber über CMD mit "avrdude -P COM4 -b 2400 -p m32 -c" und dem COntroller
> dahinter kann ich keine Verbindung aufbauen.
>
> Antweder bleibt er bei "Connecting    . " stehen.
> Oder ich habe ein Timeout.
> Oder er findet Dateien nicht.
>
> COM4 ist richtig.
> baurate nach hardware.c eingestellt

Was willst Du mit dem avrdude-Befehl, was genau soll der bringen?

Wenn ich Dich richtig verstehe versuchst Du doch gerade, den Vorschlag 
von Stefan umzusetzen und soft-serial über den freien Pin PA0 Deines 
Mikrocontrollers zum Laufen zu kriegen, um darüber zu Debug-Zwecken etc. 
beliebige Meldungen an den PC schicken zu können.
Falls ja: Dafür brauchst Du PC-seitig nicht avrdude, sondern ein 
x-beliebiges Terminalprogramm für die serielle Schnittstelle, das Dir 
die über die entsprechende serielle Schnittstelle empfangenen Daten 
anzeigt.

[Daniel C. (apokya)]

> Wenn ich Dich richtig verstehe versuchst Du doch gerade, den Vorschlag
> von Stefan umzusetzen und soft-serial über den freien Pin PA0 Deines
> Mikrocontrollers zum Laufen zu kriegen, um darüber zu Debug-Zwecken etc.
> beliebige Meldungen an den PC schicken zu können.

Genau das ist der Plan :p


> Falls ja: Dafür brauchst Du PC-seitig nicht avrdude, sondern ein
> x-beliebiges Terminalprogramm für die serielle Schnittstelle, das Dir
> die über die entsprechende serielle Schnittstelle empfangenen Daten
> anzeigt.

Oh, ok. Dachte ich mir schon irgendwie.
Allerdings weiß ich überhaupt nicht welches dafür am Besten geeignet 
ist.
Ich habe die Tage HTerm runter geladen. Damit funktioniert es irgendwie 
nicht.
Hast du Vorschläge, welches Programm dafür am Besten geeignet sein 
könnte?
Am liebsten auf Deutsch, aber Englisch tut es auch. :D

[Stefan F. (Gast)]

> Ich habe die Tage HTerm runter geladen.

HTerm ist eine sehr gute Wahl.

> Damit funktioniert es irgendwie nicht.

Was ist "es" und was bedeutet "irgendwie"? Zu erst solltest du mal das 
fertige Programmbeispiel von meiner Seite ausführen, um deine 
Softwareinstallation zu prüfen.

Außerdem kannst du dein UART-Kabel prüfen, indem du an dessen Ende keine 
Elektronik anschölißt sondern einfach nur RxD mit TxD verbindest. Dann 
müsstest du alle Zeichen wuasi als "Echo" empfangen, die zu sendest.

> undefined reference

Das bedeutet, dass du vergessen hast, die serialconsole.c zu deinem 
Projekt hinzuzufügen. Der Compiler hat sie nicht Compiliert oder nicht 
gelinkt, daher ist die Funktion undefiniert.

[Daniel C. (apokya)]

Stefan U. schrieb:
>> Ich habe die Tage HTerm runter geladen.
>
> HTerm ist eine sehr gute Wahl.

Das freut mich


>> Damit funktioniert es irgendwie nicht.
>
> Was ist "es" und was bedeutet "irgendwie"? Zu erst solltest du mal das
> fertige Programmbeispiel von meiner Seite ausführen, um deine
> Softwareinstallation zu prüfen.

Wenn du mit "Programmbeispiel" AvrDude meinst, klappt es auch nicht.
Habe ich kurz vorher in einem Beitrag geschrieben.

Wenn du ein anderes Programm meinst, welches?


> Außerdem kannst du dein UART-Kabel prüfen, indem du an dessen Ende keine
> Elektronik anschölißt sondern einfach nur RxD mit TxD verbindest. Dann
> müsstest du alle Zeichen wuasi als "Echo" empfangen, die zu sendest.

Kurz ausprobiert: Funktioniert


>> undefined reference
>
> Das bedeutet, dass du vergessen hast, die serialconsole.c zu deinem
> Projekt hinzuzufügen. Der Compiler hat sie nicht Compiliert oder nicht
> gelinkt, daher ist die Funktion undefiniert.

Wie von dir beschrieben, habe ich
#include "driver\serialconsole.h"
ganz am Anfang vom Quellcode eingetragen.

Trotzdem keine Reaktion bei init...

[Theor (Gast)]

Daniel C. schrieb:
>> Wenn ich Dich richtig verstehe versuchst Du doch gerade, den Vorschlag
>> von Stefan umzusetzen und soft-serial über den freien Pin PA0 Deines
>> Mikrocontrollers zum Laufen zu kriegen, um darüber zu Debug-Zwecken etc.
>> beliebige Meldungen an den PC schicken zu können.
>
> Genau das ist der Plan :p
>
>
>> Falls ja: Dafür brauchst Du PC-seitig nicht avrdude, sondern ein
>> x-beliebiges Terminalprogramm für die serielle Schnittstelle, das Dir
>> die über die entsprechende serielle Schnittstelle empfangenen Daten
>> anzeigt.
>
> Oh, ok. Dachte ich mir schon irgendwie.

Vielleicht erlaubst Du mir eine oder zwei Bemerkungen die Dir helfen 
soll, das lernen zu lernen.

Stell Dir einmal vor, in einem Cart-Forum stellst sich jemand hin und 
fragt, welches Cart denn für sein Problem besser geeignet wäre, als das 
was er gerade verwendet. Wenn er seines versucht, dann gelingt es ihm 
einfach nicht die Ziellinie zu erreichen. Ja, er kommt nicht mal von der 
Startlinie weg. Er klappe das Cart ordnungsgemäß aus und raste es ein. 
Die Klinge sei auch frisch geschärft und er richte sie auch immer gerade 
zur Fahrbahn aus.

Hmmm, denkst Du vielleicht. Was soll denn dieser Blödsinn!

In gewisser Weise geht uns das ähnlich mit Dir. ardude ist kein 
Programm, mit dem man nach RS232-Standard gesendete Daten empfangen und 
anzeigen kann.

Nun, bei einem "Cart", das man ausklappen kann und dessen Klinge frisch 
geschärft ist, ist Dir ohne weiteres klar, dass es sich wohl nicht um 
ein Cart handelt und der Fragesteller einem geradezu absurden Irrtum 
unterliegt. Aber irgendwann wusstest Du das auch noch nicht. Du hast es 
gelernt. So lächerlich ist das gar nicht - wie Du an Deinem Beispiel 
sehen kannst.

Ebenso ist es zweckmäßig in einem neuen Wissensgebiet erstmal 
nachzuschauen, ob das "Gerät", dass Du verwenden willst, den Zweck 
überhaupt erfüllt. Und so etwas solltest in diesem Fall immer tun.

Es geht nicht darum, dass Du Dich dabei auch immer wieder mal irren 
wirst. Aber versuchen solltest Du es und es auch hier dokumentieren. In 
der Art:
Ich habe nachgeschaut, womit ich die gesendeten Daten empfangen kann. 
Dort (hier ein z.B. Link) habe ich gelesen, dass XYZ geeignet ist, 
insbesondere weil dort steht: "<was immer da steht>".

Selbst falls Du, was da steht falsch gedeutet hast, gibt das einen 
Ansatzpunkt, je nachdem, warum Du etwas falsch gedeutet hast, 
korrigierend zu helfen. Das ist auf lange Sicht für Dich nützlicher als 
wenn man Dir einfach sagt, das nicht XYZ sondern ZUI geeignet ist.



Daniel C. schrieb:

> Ich habe die Tage HTerm runter geladen. Damit funktioniert es irgendwie
> nicht.


Stell Dir einmal vor, in einem Cart-Forum stellst sich jemand hin und 
fragt, welches Cart denn für sein Problem besser geeignet wäre, als das 
was er gerade verwendet. Wenn er seines versucht, dann geht es irgendwie 
nicht.

Aha. Denkst Du. Irgendwas macht er wohl falsch. Aber was? Ich weiss ja 
gar nicht "was" er genau macht. Ob er überhaupt irgendwas tut, ausser 
das Cart vor die Ziellinie zu rollen.

Du fängst also an zu fragen: Benzin drin? Motor gestartet? Bremse 
gelöst? Ja, das hat der Fragesteller alles gemacht. Trotzdem geht es 
nicht.
Hmm. So geht es nicht weiter, denkst Du. Da frage ich ja ewig. Du musst 
also eine "offene Frage" stellen. Du fragst: Was geschieht denn 
überhaupt?
Du kriegst zu Antwort: Ja. Einmal ist der Motor kurz gestartet, aber 
dann ist er verreckt und nun passiert nichts mehr.
Hmmm. Seltsam, denkst Du. Klingt irgendwie nach einem Problem mit dem 
Motor. Aber da immer noch Details fehlen, musst Du weiterfragen: Was 
füllst Du denn in den Tank (alles reine Intuition - Du hast ja keinen 
realen Anhaltspunkt dafür, dass es daran liegt, das ist nur eine 
Möglichkeit von vielen)?
Der Fragesteller antwortet: Ich habe da Diesel von der Tankstelle 
geholt. Von Aral. Gibt es da besseren Diesel, etwa von Shell?

Ich glaube ich brauche nicht auszuführen, was wohl Deine Reaktion wäre.

Was bedeutet das nun für dein Problem: Für jedes komplexere Ding, gibt 
es immer Randbedingungen dafür, dass es funktioniert. Das sind oft ganz 
verschiedene Dinge. Das Cart muss nicht nur an der Startlinie stehen um 
ein Rennen zu gewinnen. Es musst nicht nur einfach eine brennbare 
Flüssigkeit im Tank sein, es muss eine bestimmte sein. Und so weiter und 
so weiter.

Ein "besser geeignetes Cart" hilft in dem Fall überhaupt nichts.

Übertragen auf Dein Problem bedeutet das, Du musst nicht nur das 
geeignete Terminalprogamm haben. Es muss auch passend eingestellt sein. 
Und damit man nun nicht alle wichtigen Daten von Dir erfragen muss, wäre 
es hilfreich wenn Du Dich erstens darüber schlau machst, was wichtige 
Einstellungen sind, sondern die auch ohne Nachfrage nennst.

Es geht nicht darum, dass Du sofort alle wichtigen Parameter kennst und 
nennst. Aber versuchen solltest Du es und es auch hier dokumentieren. In 
der Art: "Ich habe nachgeschaut, welche Einstellungen wichtig sind und 
wovon sie in welcher Weise abhängen und diese und jene gefunden und wie 
folgt eingestellt, weil ..."

Selbst falls Du, was da steht falsch gedeutet oder etwas ausgelassen 
hast, gibt das einen Ansatzpunkt, um korrigierend zu helfen. Das ist auf 
lange Sicht für Dich nützlicher als wenn man Dir einfach sagt, das der 
Parameter XYZ wichtig ist. Du kannst auch lernen, warum das so ist.


Hoffe das hilft Dir weiter.

[Theor (Gast)]

Daniel C. schrieb:
> Stefan U. schrieb:

>>> undefined reference
>>
>> Das bedeutet, dass du vergessen hast, die serialconsole.c zu deinem
>> Projekt hinzuzufügen. Der Compiler hat sie nicht Compiliert oder nicht
>> gelinkt, daher ist die Funktion undefiniert.
>
> Wie von dir beschrieben, habe ich
> #include "driver\serialconsole.h"
> ganz am Anfang vom Quellcode eingetragen.
>
> Trotzdem keine Reaktion bei init...


Ich nehme das zum Anlass, was ich oben schrieb noch einmal zu 
verdeutlichen. Allerdings ist das Problem ein wenig umfangreicher.


Wenn Du auf einen Satz stösst, der Dir nichts sagt, dann kannst Du 
einfach mal im Internet suchen. In diesem Fall kommt dabei im 
wesentlichen heraus, was Stefan U. geschrieben hat. Hmm. Hilft auch 
nicht viel weiter.
Aber da tauchen neue Fragen auf: Was ist denn ein "Projekt" überhaupt? 
Was ist ein Compiler? Was ist "linken"? Was heisst es, wenn eine 
Funktion "undefiniert" ist? Was heisst es, wenn sie "definiert" ist?

Kannst Du alles im Internet nachlesen. OK. Erstmal viele Worte, mit 
denen Du nichts anfangen kannst. Aber es gibt sich ein Bild - wie wenn 
man eine Fremdsprache lernt. "Compilieren" ist danach wohl ein Vorgang, 
bei dem aus dem Programm (die nennen das auch "Quellcode" - hmm, was ist 
das wohl?) ein ausführbares Programm (komisch, was ist da wohl der 
Unterschied) macht.

Und so weiter und so fort.

Jedesmal wenn Du Dich fragst, was ein neuer Begriff wohl zu bedeuten 
hat, ist das wertvoll. Trau Dich nachzuschauen. Setz das Puzzle 
zusammen. Das hilft Dir.

Wichtig ist, dass Du nicht einfach hinnimmst, wenn Du etwas nicht 
verstehst, sondern versuchst die Lücke zu füllen. Wenn das beim ersten 
Versuch auch noch so falsch ist, ist das in Ordnung. Aber wenn Du Dir 
klarmachst (z.B. aufschreibst), das ein Versuch von Dir auf diesem 
Verständnis beruht, dann kannst Du Dein Verständnis ändern, was Dich 
weiterbringt. Und wenn Du das nicht allein schaffst, kannst Du auch 
nachfragen.

So. Genug Sermon für heute. Viel Erfolg weiterhin.

[Daniel C. (apokya)]

Du hast ja recht ;)


Okay. Bisschen blöd jetzt.
Statt
#include "driver/serialconsole.h"
hätte
#include "driver/serialconsole.c"
eingetragen weden müssen.

Das passiert, wenn man nur abschreibt :D


Danach leuchtete die TXD LED am Converter.
Aber ich habe nichts empfangen.

Also umgesteckt auf RXD und siehe da: Ich bekomme jede Menge Daten.


Blöder Weise läuft mein eigentliches Programm auf dem COntroller nicht 
mehr weiter UND ich bekomme nur wirres Zeug als Info angezeigt:


U?}z?N??U?U?j]????UU????&???W?U???&fM?UU???&??????U??=v??.???U??V??6v?V? 
U?bM????V?U???7ve???U??jMnl-zUU??F???????U?+fd?.>U<21>??+fdM.~??U???fdM} 
UQ????&fem??U????E&f??U??6vte?U?U???????UU??Fnlm]???<21>?je????V?U??eMn? 
?V?U?????&???U?V???????U?bM^lm}UU??kd]???V?EUje??e???U??kdM???V?U?ke]??? 
??U?b]??6?V?U??.lM.z?U??b]??????U??K.nm?W?U?kdM.n?UE????fde???U??jEM??<2 
3>?U??zM&fe??U?]?EM????U????6?????U???{??v?V?U??K.nl}UU??+fdE]}UU??}tE?: 
%??U????6vt?V?U???<23>vt???U???EM??e??U?????????U??K.???V?T??iIY??QU???? 
??E?U?U?V???n???U?????e??UU??????&???U????[?yUU??V???????U?V?????V?U?jE? 
?o}UU???N?%]???U????fdM}UU???&fdE}??U????&fe??U??w??????U???6vE??UU??}tM 
fdm+?U???&fe}+?U??jeM????U?????E????U??????????U???6?e?U?U?????&?U?U?j]? 
???UU??????????U?&nlmM}UU????????V?U??fdeM?UU???E&???W?U??{??&f??U??]


Die Fragezeichen sind hierbei die Kästchen-Zeichen


Aber jetzt kenne ich mich Null aus und wüsste auch nicht wonach ich 
googeln soll



Also Baudrate auf 115200 in HTerm und hardware.h geändert.

Nun läuft wenigstens das Programm weiter

[Theor (Gast)]

Daniel C. schrieb:
> [...]
> Okay. Bisschen blöd jetzt.
> Statt
> #include "driver/serialconsole.h"
> hätte
> #include "driver/serialconsole.c"
> eingetragen weden müssen.

OK. Auf welcher Information beruht diese Änderung und wie genau ging 
Deine Schlussfolgerung.

Es gibt noch einen anderen Weg, der "formal" gesehen korrekt ist. Er 
ergibt sich aus den Informationen daraus, was ein Compiler und ein 
Linker ist und tut und was in dem Kontext des AVRStudio ein Projekt ist.


> Blöder Weise läuft mein eigentliches Programm auf dem COntroller nicht
> mehr weiter UND ich bekomme nur wirres Zeug als Info angezeigt:

[...]

> Aber jetzt kenne ich mich Null aus und wüsste auch nicht wonach ich
> googeln soll

> Also Baudrate auf 115200 in HTerm und hardware.h geändert.

Was bestimmt denn die Baudrate im Mikrocontroller? Wie genau geht das? 
Was gibt es an einem Terminalprogramm noch einzustellen? Welche 
Parameter gibt es überhaupt bei einer RS232-Verbindung? Wie und wo sind 
die in dem Code von Stefan U. ge- oder beschrieben?

> Also Baudrate auf 115200 in HTerm und hardware.h geändert.

Ja schon. Aber leider weisst Du nicht wieso sich die Funktion dadurch 
ändert. Also lediglich ein Glückstreffer und kein Lernerfolg.


Das kannst Du besser hinkriegen.

[Stefan F. (Gast)]

> Wenn du ein anderes Programm meinst, welches?

Als Programmbeispiel meine ich das Programm in der ZIP Datei 
HelloTiny.zip, aus der du die serialconsole.h entnommen hast.

Du solltest mal lernen, Fragen zu beantworten. Ich habe Dir jetzt 
zweimal geschrieben, dass du auch die Datei serialconsole.c zu deinem 
Projekt hinzufügen sollst. Ob und wie du das gemacht hast, hast du nicht 
beantwortet. Offensichtlich hakt es genau daran, das erkennt man an der 
Fehlermeldung, die ich Dir bereits erklärt habe.

Da Du nicht auf meine Frage eingegangen bist, kann ich Dir nicht weiter 
helfen. Ich habe auch ehrlich gesagt keine Geduld mehr. Diese F1 Anzeige 
ist eine Never-Ending Stroy, du hast Dich mit diesem projekt total 
übernommen. Fanng mal mit einfachen Projekten an und lerne zuerst mal, 
deine Arbeitsmittel zu benutzen.

Links zu Tutorials hast du ja auch schon massenweise bekommen. Wie viele 
davon hast du wirklich durchgearbeitet (nicht nur gelesen)?

> Statt
> #include "driver/serialconsole.h"
> hätte
> #include "driver/serialconsole.c"
> eingetragen weden müssen.

Ganz Sicher nicht, Du hast die allerersten Grundlage deiner 
Programmiersprache nicht verstanden. In solchen Fällen könnte man 
einfach von laufenden Beispielen abschreiben, aber du machst es einfach 
anders. Warum nur? Hälst du dich in dieser Hinsicht für schlauer als 
ich?

Auf meiner Homepage siehst du Screenshots, die belegen, dass das 
Beispielprogramm funktioniert. Warum hälst du dich nicht an meine 
Anleitung? Wie soll ich Dir jetzt noch helfen?

>> Also Baudrate auf 115200 in HTerm und hardware.h geändert.
> Was bestimmt denn die Baudrate im Mikrocontroller?

Ich mische mich da mal ein. Im Falle der serialconsole.h und 
serialconsole.c aus der HelloTiny.zip bestimmt eine Warteschleife die 
Baudrate. Wenn du die Baudrate so belassen hast, wie ich in meinen 
Beispielprogramm geschrieben habe, dann sollst du das Terminalprogramm 
auf 2400 Baud stellen.

Je nach Taktfrequenz des Mikrocontrollers sind 115200 Baud 
problematisch. Bei nur 1Mhz Takt kann er die Baudrate nicht genau genug 
berechnen. Du solltest daher meine Anleitung befolgen und es erstmal mit 
niedrigen Baudraten versuchen.

Beschäftige dich mal mit Fuse Bits und Taktquelle - lies das Datenblatt 
deines Mikrocontrollers! Ich wette, da liegt der Hase im Pfeffer.

Ich denke, das war jetzt mein letzer Beitrag zu dem Thema, mein 
Geduldsfaden ist nämlich am Ende. Die ganze Garnrolle ist aufgebraucht.

[Daniel C. (apokya)]

Dann danke ich dir schon mal für deine Mühe.

Leider habe ich alles genau so gemacht, wie du sagtest.
Ich komme mit der Erklärung auf deiner Seite nicht klar.
Erst redest du dort von AVRdude. Dann plötzlich von einem Makefile und 
dann von irgend einem anderen Programm  - habe es grade nicht auf dem 
Schirm.
Zum Großteil in Linux.

Dabei gehst du davon aus, dass man als Leie weiß, was gemeint ist.

Ich wollte allerdings nur wissen, wie ich am besten die Fehler auslesen 
kann und wie das am besten zu machen ist.

Ich habe einfach nicht verstanden was du mit "hinzufügen" meinst. Noch 
nie gemacht.


Aber ist auch nicht weiter schlimm. Jetzt habe ich zwar den 
UART-Converter hier liegen, aber er war nicht teuer.

Mein Projekt ist auch ohne Serielle Konsole zu mind. 25% fertig 
gestellt.

Zu 100% wird es wahrscheinlich nie fertig. Aber wenn 75% erreicht sind, 
ist das mehr als genug.

Es ist halt blöd, immer wieder den Quellcode zu ändern und dann wieder 
zu laden, um zu gucken, wie es läuft, aber wesentlich einfacher, als 
sich mit etwas rumzuschlagen, wovon man keinen blassen schimmer hat und 
es bei den Projekt eigentlich helfen sollte.
Aber leider überfordert es mich mehr und bremst mich aus.


Freut mich trotzdem, dass du so lange dabei warst.
Machs gut

[Franz K. (leitung2)]

Hallo Leute, ist das Projekt aufgegeben worden? bräuchte dringend so ein 
Led drehzahlband anzeige mit schaltblitz oder rote LEDs am ende 
Drehzahlbegrenzer für meine Rennmaschine xD.
Ich hoffe das geht hier noch weiter.
Wurde es denn schwierig werden das zu machen? also nur DZM mit 
Leuchtdioden statt zahlen ? Damit könnte man erstmal anfangen;-)  Mfg 
Franc.

[Daniel C. (apokya)]

Franz K. schrieb:
> Hallo Leute, ist das Projekt aufgegeben worden? bräuchte dringend so ein
> Led drehzahlband anzeige mit schaltblitz oder rote LEDs am ende
> Drehzahlbegrenzer für meine Rennmaschine xD.
> Ich hoffe das geht hier noch weiter.
> Wurde es denn schwierig werden das zu machen? also nur DZM mit
> Leuchtdioden statt zahlen ? Damit könnte man erstmal anfangen;-)  Mfg
> Franc.

Hallo Franz

Nach über einem Jahr bin ich mit der Programmierung immer noch nicht 
feritg, aber dem Ende sehr Nahe.
D.h.: Nicht aufgegeben.

Allerdings musste ich statt der Drehzahl auf Geschwindigkeit gehen.
Die Drehzahl war zu verzerrt für den µC oder mich. Ich konnte diese 
nicht vernünftig einlesen.
Jetzt bin ich zur Geschwindigkeit übergegenangen und habe grade gestern 
noch einmal eine Kleinigkeit geändert, die mich jetzt sehr 
zuversichtlich stimmt.

Die Prüfung beim Fahren wird es ergeben.



Zu Drehzahlbegrenzern gibt es schon viele Forenbeiträge. Viele kappen 
dann die Signale, viele widerrum machen etwas anderes. Kappen würde ich 
keines Falls machen, da der Sprit nicht verbrannt wird.

Aber zu mindest könntest du dir anzeigen lassen, wenn du die Drehzahl zu 
hoch ziehst. Die LEDs, die ich verbut habe, sind sehr hell. Musste sie 
schon dimmen, weil es im Schatten doch gut blendet :D

Ich habe zur Anzeige auch nur LEDs, das ist die kleinste Übung.

[Daniel C. (apokya)]

So sieht es eingebaut aus.

[npn (Gast)]

Daniel C. schrieb:
> So sieht es eingebaut aus.

hm, schön - ein Lenkrad...

[Daniel C. (apokya)]

npn schrieb:
> Daniel C. schrieb:
>> So sieht es eingebaut aus.
>
> hm, schön - ein Lenkrad...

Falsches Bild, Sorry

Jetzt das richtige Bild :D

[Franz K. (leitung2)]

Hi,apokya
Das sieht schon mal gut aus, Respekt das du das nochmal hingekriegt 
hast. ich kenne das mit der Drehzahl bei hohen Geschwindigkeiten oder 
bei beschleunigen sieht man es kaum, wenn das in zahlen dargestellt 
wird. ich habe mir schon mal den anderen Thred durchgelesen wo die 
motordrehzahl in zahlen dargestellt wird, die ist dann gut wenn man 
Einstellungen vornimmt aber beim rennen muss man sich auf den Gegner und 
verkehr Konzentrieren dann sind LEDs eigentlich besser. und das Problem 
mit blenden musste man durch dimmen oder Glasfilter in den griff 
bekommen.

naja, auf jeden fall hätte ich gerne so eine anzeige mit Dioden an 
meinem Motorrad, das noch analoge Instrumente hat. ist ein ninja bj 2000 
750ccm.
 jetzt könnte ich den zahlen Drehzahlmesser nachbauen und dran machen, 
aber da sieht man kaum beim beschleunigen. das ding ist mega schnell im 
anzug ,irgendwas mit 3,4 sec auf 100 XD.
jetzt wusste ich nich wo ich fragen soll wie das geht die zahlen durch 
lichter zu ersetzen, für eine antwort were ich sehr dankbar.

[Franz K. (leitung2)]

Die gang anzeige ist natürlich auch gut.

[Daniel C. (apokya)]

Wie du siehst, abgesehen von der Zeit bis heute, relativ einfach.

Ich habe einen µC genommen, alles an Kabeln drangebastelt, was ich 
brauche und haben wollte und kann nun alles so prgrammieren wie ich 
will.

Wie gesagt: Nur das Eingangssignal über Drehzahl war schwer zu erfassen.
Wenn du das hinbekommst, hast du ja schon einen Großteil.

Darüber gibt es aber auch ein paar Sachen in Google zu finden.


Ich habe nur Vorwärts- und Rückwärtsgang, sowie neutral.
Auf dem Display wird dann D, N, oder R angezeigt.
Da ich aber einen Chip habe, habe ich mir in Abhängigkeit der 
Geschwindigkeit die Gänge "durchlaufen" / "durchrechnen". Also wird 1-8 
angezeigt.
Umschaltbar durch Taster

So kannst du auch alles programmieren wie du willst. Das war mit einen 
Grund darauf zu gehen.
Z.B. die LEDs. Im Gang D laufen alle LEDs einzeln im Bereich 0-100 durch 
und über 100 blinkt das komplette Band
Wenn ich auf den Modus 1-8 stelle, werden immer in 5er-Segmenten die 
Geschwinigkeit angezeigt und die "Gänge" geändert.
Wenn ich die Handbremse angezogen habe steht "P" im Display und wenn ich 
über eine bestimmte Geschwindigkeit fahre, Blinken die LEDs abwechselnd.

Das kannst du aber alles machen, wie du willst ;)

[Franz K. (leitung2)]

Hallo Daniel, danke schon mal, die Drehzahl nehme ich von Zündkabel.
 Ich wollte erstmal das hier nachbauen; 
http://www.guido-speer.de/Board-gross.pdf
aber das sind Buchstaben. aber für den Anfang ok. kann ich auch 
gebrauchen. löten und teile zusammen stellen kann ich. mit dem Chip 
Programieren da muss ich jemanden fragen. welchen ich da nehmen soll 
weiss ich auch noch nicht.

hast du vielleicht dein eigenen Bauplan? oben habe ich ein gesehen aber 
ist er auch richtig hier gepostet oder hast du inzwischen Veränderungen 
vorgenommen?
 Das drehzahlband geht ja bis 13- 14K UMP. bei mir. Gruss

[Daniel C. (apokya)]

Franz K. schrieb:
> Hallo Daniel, danke schon mal, die Drehzahl nehme ich von
> Zündkabel.
>  Ich wollte erstmal das hier nachbauen;
> http://www.guido-speer.de/Board-gross.pdf
> aber das sind Buchstaben. aber für den Anfang ok. kann ich auch
> gebrauchen. löten und teile zusammen stellen kann ich. mit dem Chip
> Programieren da muss ich jemanden fragen. welchen ich da nehmen soll
> weiss ich auch noch nicht.
>
> hast du vielleicht dein eigenen Bauplan? oben habe ich ein gesehen aber
> ist er auch richtig hier gepostet oder hast du inzwischen Veränderungen
> vorgenommen?
>  Das drehzahlband geht ja bis 13- 14K UMP. bei mir. Gruss

Es gibt einen etwas aktuelleren Schaltplan, ja.

Okay. Das würde z.B. der µC nicht verkraften (zu hohe Spannung). 
Deswegen die Frage. Aber er muss es auch erkenen können.

Also mit dem Chip kann ich dir nur sagen, dass ich mit meinem sehr 
zufrieden bin: Atmel Atmega32. Er hat 40 Pins, wovon 32 Pins nutzbar 
sind. Der Speicher ist schön groß. Jede Menge PWM-Anschlüsse und so 
weiter. Kostet auch "kaum" was.

Bzgl. programmieren kannst du ja mich fragen :P Ich kann eig. den Anfang 
zeigen und dich ranführen.

Die Drehzahl müsste er eigentlich erkennen, wenn er richtig verarbeitet 
wird. Max. 5,5V verträgt ein µC. Die Zündspule hat aber weitaus mehr :P


Ich weiß auch nicht, was dir die Anleitung von
> http://www.guido-speer.de/Board-gross.pdf
bringt. Der Signaleingang ist nicht wie du ihn nutzen musst und sowas 
kann man super leicht programmieren :D - Das ich sowas mal sage hätte 
ich auch nie gedacht :D

[Franz K. (leitung2)]

OK. Super Danke. Wo kann ich den sonst das Signal abzapfen, dann muss 
ich Strom messen am meinen Analogen Drehzahlmesser? der ist ja mit 
Drähten verbunden, also muss er da ein Signal bekommen? oder kann ich 
die Volt zahl von der Zündspulle irgendwie mit einen Wiederstand 
reduzieren auf 5,5 V ?

Vielleicht später mit dem Zusatz Funktionen, paar Temperaturen bräuchte 
ich auch noch. XD Aber gut zu wissen das der Atmega32 das Kann.:D


ich kann das alles erstmal auf einem Steckbrett nachbauen und gucken ob 
es funktioniert.

[Daniel C. (apokya)]

Franz K. schrieb:
> OK. Super Danke. Wo kann ich den sonst das Signal abzapfen, dann
> muss
> ich Strom messen am meinen Analogen Drehzahlmesser? der ist ja mit
> Drähten verbunden, also muss er da ein Signal bekommen? oder kann ich
> die Volt zahl von der Zündspulle irgendwie mit einen Wiederstand
> reduzieren auf 5,5 V ?
>
> Vielleicht später mit dem Zusatz Funktionen, paar Temperaturen bräuchte
> ich auch noch. XD Aber gut zu wissen das der Atmega32 das Kann.:D
>
> ich kann das alles erstmal auf einem Steckbrett nachbauen und gucken ob
> es funktioniert.

Die stellen sind schon alle richtig.
Entweder zwischen Pickup und CDI oder zwischen CDI und Zündspule oder 
ohne Kontakt als umkickelten Draht um das Zündkabel, welches zur Kerze 
geht.

Nur Spannung misst der µC für eine Signalverarbeitung. Dabei kann man je 
nach Pin aussuchen, ob er nur 0V und Versorgungsspannung vergleicht oder 
auch eine Spannung in dem Bereich erkennt.
Aber bei allem muss die Spannung UNTER 5,5V liegen. 5V ist bei mir z.B. 
die Versorgungsspannung. Man kann auch auf 3,3V ändern. Wenn du aber 
über 5,5V gehst, riskierst du den µC zu grillen. Ist mir schon passiert. 
Ärgerlich.

DU kannst es mit einem Widerstand reduzieren, ja. Habe ich auch mal 
gemacht. Habe da dann mit 1MOhm gearbeitet. Und dann geschaut, was an 
Signal ankommt. Allerdings habe ich es nie auf die richtige Drehzahl 
geschafft. Vlt. auch irgendwas falsch programmiert. Keine Ahnung.

Temperaturen ist absolut kein Problem. Theoretisch könntest du 8 
Temperaturen messen.

Kannst du. Aber vlt. solltest du nicht alles nachbauen. Vieles ist für 
meine Zwecke angepasst.

[Jörg W. (dl8dtl) (Moderator)]

Daniel C. schrieb:
> Allerdings habe ich es nie auf die richtige Drehzahl geschafft.

Weil so ein Zündfunken eben typischerweise nicht nur ein einzelner
schöner Impuls ist, sondern ein Haufen rundrum, einschließlich viel
erzeugter HF (nicht umsonst ist im Kerzenstecker oder Zündkabel ein
Widerstand drin zu Bedämpfen der HF-Schwingungen).

Früher™ wurde der Zündimpuls für den Drehzahlmesser mit einem lose
um das Zündkabel geschlungenen Draht erfasst (kapazitive Kopplung).
Allerdings war das damals auch relativ langsame Analogtechnik; kann
also gut sein, dass man am Mikrocontroller einen Tiefpass voranschalten
muss und außerdem nach jedem erfassten Impuls eine Totzeit einbauen,
innerhalb derer kein zweiter Impuls erfasst werden kann (der für den
Motor mögliche Drehzahlbereich ist ja recht überschaubar).

[Philipp G. (geiserp01)]

Jörg W. schrieb:
> Früher™ wurde der Zündimpuls für den Drehzahlmesser mit einem lose
> um das Zündkabel geschlungenen Draht erfasst (kapazitive Kopplung).
> Allerdings war das damals auch relativ langsame Analogtechnik; kann
> also gut sein, dass man am Mikrocontroller einen Tiefpass voranschalten
> muss und außerdem nach jedem erfassten Impuls eine Totzeit einbauen,
> innerhalb derer kein zweiter Impuls erfasst werden kann (der für den
> Motor mögliche Drehzahlbereich ist ja recht überschaubar).

Das macht die Abblitzpistole noch heute so.

[Franz K. (leitung2)]

Ja bloß nichts überstürtzen, momentan wollte ich nur die Drehzahl in 
LEDs schaffen, als Lichterkette die dann erst gelb blitzen tut bei 
erreichen von sagen wir mal ab 11K und dann rot :-D. Aber was brauche 
ich da eigentlich für, dein plan ist ja viel zu groß mit den ganzen 
Zusatz Funktionen xD. das ist mir dann doch zu viell. Ich wollte erstmal 
was einfaches für die DZ.(gang anzeige). Womit soll ich anfangen wenn 
der plan von Guido Speer nicht so gut geeignet ist für das vorhaben.?

Jörg W. schrieb:
> dass man am Mikrocontroller einen Tiefpass voranschalten
> muss und außerdem nach jedem erfassten Impuls eine Totzeit einbauen,
> innerhalb derer kein zweiter Impuls erfasst werden kann (der für den
> Motor mögliche Drehzahlbereich ist ja recht überschaubar).

Danke,das muss man also machen, denke auch bei der hohen Drehzahlen :-o

Daniel C. schrieb:
> Temperaturen ist absolut kein Problem. Theoretisch könntest du 8
> Temperaturen messen.

 JO;Hab mir schon diverse Temperaturplatinen mit Flüssigkeitdichten 
Sensoren aus fern Ost bestellt. Die waren nicht so teuer, kann ich mal 
dann testen. Aussen, Wasser, Öl, Abgastemperatur am Auslassventilen bzw. 
in der nähe von x4, wehren schon wichtig oder gibt es da noch was 
sinnvolles was man messen könnte? ich könnte die Temperaturen separat 
nicht auf einer Platine mit der DZM anzeige dann Anschliessen. alles 
erstmal nur Theorie.

[Jörg W. (dl8dtl) (Moderator)]

Franz K. schrieb:
> Danke,das muss man also machen, denke auch bei der hohen Drehzahlen :-o

Hoch?  Für den Motor sind 12000 U/min hoch, elektrisch sind das gerade
mal 200 Hz, tiefster NF-Bereich.

Den Tiefpass brauchst du vor allem, damit du ggf. auftretetende
Mehrfachschwingungen bei der Zündung sicher ausblendest.  Kann man
aber auch rein in Software machen: 200 Hz heißt, es sind 5 ms Zeit,
bis der nächste Impuls ankommen kann.  Das ist für heutige Controller
eine kleine Unendlichkeit.

[Franz K. (leitung2)]

Könnte mir vielleicht jemand eine Skitze machen, ich kann aber immer hin 
nur nach Zeichnung arbeiten. und was für Teile Brauch ich dafür? weil 
der obere Plan sagt mir jetzt nicht was Drehzahl ist und was Zusatz 
Funktionen sind. ich muss ja irgendwie ein Anfang machen. Danke schon 
mal im voraus.

[Stefan F. (Gast)]

Franz, du stellst Dir das zu einfach vor. Dieses Projekt besteht nicht 
nur aus einer Handvoll Bauteilen, sondern auch aus einem Programm das 
exakt darauf zugeschnitten ist. Kannst du AVR Mikrocontroller 
programmieren?

[Franz K. (leitung2)]

Ok, vielleicht bin ich zu übereifrig geworden XD. ich werde erstmal 
Programieren lernen oder jemanden finden der das kann.:-p naja ist halt 
nicht so einfach alles.

[Daniel C. (apokya)]

Also ich habe mir erst überlegt, was ich machen will, dann geschaut, was 
ich an Bauteilen brauche und geschaut, welche Pins ich nutzen muss, um 
mein Ergebnis zu finden. Zum Schluss alles zusammen gebaut.
Und erst dann angefangen zu programmieren.

Und was soll ich sagen: Nach dem letzten Test: Es läuft gut :)

[Franz K. (leitung2)]

Ach so meinst du das, danke für den Tipp.
Jetzt hab ich kapiert ;)

[Stefan F. (Gast)]

@Franz: Da du angedeutet hast, eventuell das Programmieren lernen zu 
wollen:

Vielleicht hilft Dir mein Buch dabei: 
http://stefanfrings.de/mikrocontroller_buch/index.html

Nach dem Durcharbeiten des Buches würde ich Dir dazu raten, einen großen 
40Pin AVR zu verwenden (z.B. ein ATMega644), denn der hat reichlich I/O 
Pins wo du deine LEDs direkt anschließen kannst. Das ist zwar etwas 
teurer und klobiger, als nötig, aber einfacher als die sonst übliche 
Matrix.

Falls du lieber einen "moderneren" 32 Bit µC verwenden möchtest, schau 
hier: http://stefanfrings.de/mikrocontroller_buch2/index.html Diese 
Anleitung ist allerdings ziemlich oberflächlich. Sie erklärt im Grunde 
nur die allerersten Schritte, wie man damit überhaupt irgendwas ans 
Laufen bringt. Bei 32bit Controllern musst du viel mehr Seiten 
Datenblatt/Referenzhandbuch lesen - geht aber, wenn man davor nicht 
zurück schreckt.

Schau mal rein. Wenn du meine Texte wenigstens halbwegs verstehst könnte 
das ein neues Hobby werden. :-)

[Franz K. (leitung2)]

Danke, für die links. :)