_delay_us macht eine ms

[Kein Plann (Gast)]

Hallo,
versuche gerade das RS232 Protokoll zu verstehen. Ich fange ganz langsam 
damit an in dem ich versuche einen Pin 104 µs auf hight und low 
zusetzten.

Hier scheitert es schon:
Folgendes Programm habe ich dazu geschrieben:

 
#include <avr/io.h>
#include <stdint.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#include "var.h"
#include "lcd.h" ...

 ... lcd_init();
    lcd_loeschen();
    lcd_string("Test");
    while (1)
    {
        PORTA |= (1<<PA7);
        _delay_us(104);
        PORTA &= ~(1<<PA7);
        _delay_us(104);           
    }

Problemm:
Es sind keine 104µs sondern ca. 1ms.

Ich bin auf folgen Beitrag gestoßen und habe denke alles beachtet.
Beitrag "delay us liegt weit daneben"

Komisch an der Sache ist, schalte ich die Optimierung ein, funktioniert 
das Display nicht und der Pin bleibt auf Low.

Wo ist der Hacken?

Danke für eure Hilfe.

PS: Bitte verzeiht mir meine Rechtschreibung.

[(prx) A. K. (prx)]

Kein Plann schrieb:
> Komisch an der Sache ist, schalte ich die Optimierung ein, funktioniert
> das Display nicht und der Pin bleibt auf Low.

Und ohne Optimierung bekanntermassen nicht das Delay. Was folgt daraus? 
Du hast kein Problem mit dem Delay, sondern mit dem LCD-Code.

[Andreas B. (andreasb)]

Kein Plann schrieb:

> Problemm:
> Es sind keine 104µs sondern ca. 1ms.

Weil du die Optimierung ausgeschaltet hast?

> Ich bin auf folgen Beitrag gestoßen und habe denke alles beachtet.
> Beitrag "delay us liegt weit daneben"

Sicher?

>
> Komisch an der Sache ist, schalte ich die Optimierung ein, funktioniert
> das Display nicht und der Pin bleibt auf Low.

Weil deine Displayroutine hängen bleibt und er garnicht bis zur Schleife 
kommt?

> Wo ist der Hacken?

In deiner Display Routine.

>PS: Bitte verzeiht mir meine Rechtschreibung.
Gleichfalls!


mfg Andreas

[Kein Plann (Gast)]

Schei...., ihr habt recht! (Wie immer)
Kommentiere ich die Routine aus, funktionierts.

Wie bekomme ich nun raus wo's in der Routine hängt?

DANKE!

[(prx) A. K. (prx)]

Kein Plann schrieb:
> Wie bekomme ich nun raus wo's in der Routine hängt?

(1) Selber suchen.
(2) Suchen lassen.

Die Voraussetzung für (2) zu erkennen überlasse ich dir. ;-)

[Coder (Gast)]

Mit Schweiß und Verstand... oder man nimmt sich einen Debugger zur Hand.
Vielleicht wirft der Compiler auch die eine oder andere Warnung die von 
dir ingoriert werden... Möglicherweise auch den einen oder anderen 
volatilen Fehler.

[Coder (Gast)]

Vielleicht hilft auch schon der Simulator.

[Kein Plann (Gast)]

A. K. schrieb:
> (2) Suchen lassen.

Habe die Routine mal angehängt. Aber bitte vorher setzten. Sie sieht 
katastrophal aus. Ist von einem Lehrer programmiert wurden, der glaube 
selber keine Ahnung hatte. Wir haben nur die Befehle bekommen. Was sie 
macht, kein Plan.

Coder schrieb:
> Vielleicht wirft der Compiler auch die eine oder andere Warnung die von
> dir ingoriert werden...

Warnungen ignorieren, wie kommst Du den darauf? ;-)
Ne, es werden nur 2 Stück ausgegeben. Beide weisen mich darauf hin das 
Delay nur mit Optimierung funktioniert.

[(prx) A. K. (prx)]

Wie sieht "wartems" aus?

Ausserdem wärs sehr wohl denkbar, dass 1-2 NOPs zu wenig sind. Einfach 
mal alle diese Multi-NOP-Delays durch jeweils ein einziges _delay_us(1) 
ersetzen.

[Karl H. (kbuchegg)]

Kein Plann schrieb:

> Habe die Routine mal angehängt. Aber bitte vorher setzten. Sie sieht
> katastrophal aus. Ist von einem Lehrer programmiert wurden, der glaube
> selber keine Ahnung hatte.

Danke für die Warnung.
Deine Lehrer sollte man ....


Das einzige was ich auf die schnelle sehen kann, was hängen könnte ist 
hier

void DISPLAY_BUSY(void)
{
    uint8_t j;
    j=1;
    DDRC=0x00;
    while (!(j==0))
    {
      RS_L;
      RW_S;
      EN_S;

      if (!(PINC &(1<<PIN7)))
      {
        j=0;
      }

      EN_L;
      RW_L;
    }  
    DDRC=0xFF;
}

Schmeiss probehalber den Teil mal raus und ersetze ihn durch ein

void DISPLAY_BUSY(void)
{
  _delay_ms( 30 );
}

(Include Files für den Delay nicht vergessen)

Aber ganz ehrlich. Den LCD Code sollte man ausdrucken und ihm solange um 
die Ohren dreschen, bis nur noch Konfetti übrig sind. Das ein LCD auch 
ein Timing braucht, scheint er noch nie gehört zu haben. Und über die 
Zahlenausgaben breiten wir lieber den Mantel des Schweigens. (PS die 
letzte Routine ist falsch.)

[Karl H. (kbuchegg)]

  uint16_t hex_teilen[3];
  hex_teilen[0] = hexvar16 & 0b1111000000000000;
  hex_teilen[0] = (hex_teilen[0] >> 12);

  hex_teilen[1] = hexvar16 & 0b0000111100000000;
  hex_teilen[1] = (hex_teilen[1] >> 8);

  hex_teilen[2] = hexvar16 & 0b11110000;
  hex_teilen[2] = (hex_teilen[2] >> 4);

  hex_teilen[3] = hexvar16 & 0b00001111;

Autsch!

[(prx) A. K. (prx)]

Karl Heinz Buchegger schrieb:
> Das ein LCD auch
> ein Timing braucht, scheint er noch nie gehört zu haben.

Doch, er hat. Sonst hätte er nicht all diese lustigen NOPs verstreut. 
Nur kapiert hat ers wohl nicht, oder geht fest von 1MHz Takt oder so 
aus. Ich habe hier aber schon schlimmeren Anfängercode gesehen.

[Karl H. (kbuchegg)]

void lcd_uint16(uint16_t uint16)

Selbiges: Array Overflow.

Ich korrigiere mich: Nach der Konfetti Produktion sollte man ihn teeren 
und federn und die Lizenz zum Lehren von Programmiersprachen entziehen, 
solange bis er die erfolgreiche ABsolvierung eines Anfängerkurses 
nachweisen kann.

[Karl H. (kbuchegg)]

A. K. schrieb:

> Ich habe hier aber schon schlimmeren Anfängercode gesehen.

Aber nicht viel schlimmer.
Die meisten Anfänger haben den Dreh schnell raus, dass
* in C bei 0 begonnen wird zu zählen (siehe die Cursor Positionierung
* daraus folgt, dass der maximal mögliche Array Index um 1 kleiner
  ist, als die definierte Größe.

Noch schlimmer ist allerdings, dass dieses Machwerk von seinem Lehrer 
stammt, der eigentlich kein Anfänger sein sollte.

[(prx) A. K. (prx)]

Der kommt garantiert von Microsoft-Basic. Da hat ein Array(10) 
tatsächlich 11 Elemente.

[Kein Plan (Gast)]

Karl Heinz Buchegger schrieb:
> void DISPLAY_BUSY(void)
> {
>   _delay_ms( 30 );
> }


Okay, auch das hat funktioniert.
Aber damit vergeude ich nun Zeit?
Wo liegt nun in der Routine der Fehler?

Ihr seit wie immer spitze!!!

Danke!

[Karl H. (kbuchegg)]

Kein Plan schrieb:
> Karl Heinz Buchegger schrieb:
>> void DISPLAY_BUSY(void)
>> {
>>   _delay_ms( 30 );
>> }
>
>
> Okay, auch das hat funktioniert.
> Aber damit vergeude ich nun Zeit?
> Wo liegt nun in der Routine der Fehler?

Wahrscheinlich darin, dass er sich einen Dreck um Timings geschi.... 
hat.
Man kann nicht einfach 'Pin hoch' - 'Pin runter'. Da muss eine Wartezeit 
dazwischen. Dem LCD muss man schon einen Puls mit Mindestbreite zeigen, 
damit es auch eine Chance hat, den Puls als solchen zu sehen.

Wie ist denn die Pinbelegung im lcd.h?

(Dass er da einfach den Port C komplett von Ein auf Ausgang umschaltet, 
stösst mir auch sauer auf. Wozu gibts denn die schönen #define in der 
lcd.h! Amateur)

[(prx) A. K. (prx)]

Ich tippe auf hier:

      EN_S;

      if (!(PINC &(1<<PIN7)))

denn da fragt er den Pin ab, noch bevor E überhaupt richtig oben ist. 
Jedenfalls wenns ein ATmega ist. Bei einem 1MHz AT90 hingegen dürfte das 
funktionieren, da denen die Input-Latch-Kette zur Vermeidung 
metastabiler Zustände fehlt und daher zwischen der Aktivierung von E und 
dem abgefragten Zustand etwas Zeit bleibt.

[Kein Plan (Gast)]

Karl Heinz Buchegger schrieb:
> Man kann nicht einfach 'Pin hoch' - 'Pin runter'. Da muss eine Wartezeit
> dazwischen. Dem LCD muss man schon einen Puls mit Mindestbreite zeigen,
> damit es auch eine Chance hat, den Puls als solchen zu sehen.

Wie meinst Du das?

Im Anhang noch die LCD.h.

[Karl H. (kbuchegg)]

A. K. schrieb:
> Ich tippe auf hier:
>

>       EN_S;
> 
>       if (!(PINC &(1<<PIN7)))
>

> denn da fragt er den Pin ab, noch bevor E überhaupt richtig oben ist.

Jo, hätt ich jetzt auch gesagt.
Ich weiß aber nicht auswendig, welche Wartezeit da angemessen ist.
Ich würds mal mit ein paar µs versuchen. Sagen wir mal 50. KLeiner gehen 
kann man immer noch (oder im Datenblatt nachsehen)

[(prx) A. K. (prx)]

Kein Plan schrieb:
> Wie meinst Du das?

Schau mal ins aktuelle Datasheet vom ATmega8 (wegen der Seitennummer) 
auf Seite 53. Der Abschnitt "Reading the Pin Value".

Karl Heinz Buchegger schrieb:
> Ich würds mal mit ein paar µs versuchen. Sagen wir mal 50.

_delay_us(1) reicht.

[Karl H. (kbuchegg)]

A. K. schrieb:
> Wie sieht "wartems" aus?

Guter Einwand.
Sollte man auch durch die gcc-Standard Routine ersetzen. Wer weiß, was 
da wieder dahinter steckt.

[Karl H. (kbuchegg)]

A. K. schrieb:

>> Ich würds mal mit ein paar µs versuchen. Sagen wir mal 50.
>
> _delay_us(1) reicht.

Ah. ok. Danke

Also. Vorschlag

void DISPLAY_BUSY(void)
{
    uint8_t j = 1;
    DDRC=0x00;
 
    while ( j )
    {
      RS_L;
      RW_S;
      EN_S;

      _delay_us( 1 );

      if (!(PINC &(1<<PIN7)))
      {
        j=0;
      }

      EN_L;
      RW_L;
    }  
    DDRC=0xFF;
}

[Kein Plan (Gast)]

Ihr seit so gut!!!!!

So siehts jetzt aus:

void DISPLAY_BUSY(void)
{
     uint8_t j;
    j=1;
    DDRC=0x00;
    while (!(j==0))
    {
      RS_L;
      RW_S;
      EN_S;
      _delay_us(1);
      
      if (!(PINC &(1<<PIN7)))
      {
        j=0;
      }

      EN_L;
      RW_L;
    }  
    DDRC=0xFF;
}

Ausserdem habe ich alle Multi-NOP-Delays ersetzt.

DANKE!!

Guten Rutsch und macht auch im Jahr 2013 genau so weiter.

[Karl H. (kbuchegg)]

Wenns damit erst mal klappt, dann machen wir den nächsten Schritt.

Ich kann nämlich dieses Elend nicht mehr sehen.
Die Zahlenausgaben ersetzt du durch

void lcd_char(char c)
{
  RS_S;
  DISPLAY_PORT = c;
  DISPLAY_EN();
  DISPLAY_BUSY();
}

void lcd_string( const char* str )
{
  while( *str )
    lcd_char( *str++ );
}

void lcd_uint8(uint8_t uint8)
{
  char str[4];

  utoa( uint8, str, 10 );
  lcd_string( str );
}

void lcd_uint16(uint16_t uint16)
{
  char str[6];

  utoa( uint16, str, 10 );
  lcd_string( str );
}

static void lcd_nibble(uint8_t nibble)
{
  nibble &= 0x0F;

  if( nibble < 10 )
    lcd_char( nibble + '0' );
  else
    lcd_char( nibble - 10 + 'A' );
}
 
void lcd_hex8(uint8_t hexvar8)
{
  lcd_nibble( hexvar8 >> 4 );
  lcd_nibble( hexvar8 );
}

void lcd_hex16(uint16_t hexvar16)
{
  lcd_nibble( hexvar8 >> 12 );
  lcd_nibble( hexvar8 >> 8 );
  lcd_nibble( hexvar8 >> 4 );
  lcd_nibble( hexvar8 );
}

Das ist übrigens keine Frage der Schönheit. Die Originalroutinen sind 
schlicht und ergreifend fehlerhaft (mal ganz davon abgesehen, dass sie 
horrend umständlich programmiert sind).

Und über die lcd_komma reden wir nochmal, wenn du sie brauchst. Die ist 
auch falsch.

[Karl H. (kbuchegg)]

Und tu mir noch einen Gefallen

Da kriegt man ja Augenkrebs

    while (!(j==0))

ersetzen durch

    while (j != 0)

oder gleich

    while (j)

[Kein Plan (Gast)]

Danke euch zwei.
Habe fast alles umgesetz und soga verstanden.
Außer:

Karl Heinz Buchegger schrieb:
> void lcd_uint8(uint8_t uint8)
> {
>   char str[4];
>
>   utoa( uint8, str, 10 );
>   lcd_string( str );
> }
>
> void lcd_uint16(uint16_t uint16)
> {
>   char str[6];
>
>   utoa( uint16, str, 10 );
>   lcd_string( str );
> }

"utoa" habe ich gerade gelesen braucht viel Speicher. Deshalb hab ichs 
gelassen.

DANKE!!!

[Karl H. (kbuchegg)]

Kein Plan schrieb:

> "utoa" habe ich gerade gelesen braucht viel Speicher.

utoa braucht auch nicht viel Speicher. Du verwechselst das mit printf.

Abegesehen davon. Was glaubst du, was der Original-Code da braucht? Wer 
sowas schreibt, dem spreche ich das Recht ab, sich über 
Speicherverbrauch Gedanken zu machen :-)

[Kein Plan (Gast)]

Hallo,

Leider muss ich dieses Thread zum leben erwecken.

Ich brauche eine Funktion die unsigned char ausgibt.
Habe es wie folgt versucht:

void lcd_uchar(unsigned char c)
{
  RS_S;
  DISPLAY_PORT = c;
  DISPLAY_EN();
  DISPLAY_BUSY();
}

Geht aber natürlich nicht.

Was muss ich ändern?

[C.Type (Gast)]

Kein Plan schrieb:
> Geht aber natürlich nicht.

Dem Port ist das egal, wie der Datentyp heißt. Hauptsache die Bits sind 
richtig.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Kein Plan schrieb:
> Ich brauche eine Funktion die unsigned char ausgibt.

Möchtest du einen Buchstaben auf dem LCD haben oder einen Hexwert? Für 
den Hexwert hat Karl Heinz eigentlich alles vorbereitet:

static void lcd_nibble(uint8_t nibble)
{
  nibble &= 0x0F;

  if( nibble < 10 )
    lcd_char( nibble + '0' );
  else
    lcd_char( nibble - 10 + 'A' );
}
 
void lcd_hex8(uint8_t hexvar8)
{
  lcd_nibble( hexvar8 >> 4 );
  lcd_nibble( hexvar8 );
}

An lcd_hex übergibst du den Wert, der dann als Hex (00-FF) auf dem LCD 
angezeigt wird.

[Kein Plan (Gast)]

Danke für die Antworten.

Kurz mein Vorhaben:
Zitat aus der I2C Routine von Peter Fleury:

unsigned char i2c_readAck(void)
{
  TWCR = (1<<TWINT) | (1<<TWEN) | (1<<TWEA);
  while(!(TWCR & (1<<TWINT)));    

    return TWDR;

}

Denn erhaltenen Wert würde ich gerne als dezimal Zahl ausgeben.

[Achim M. (minifloat)]

itoa() selbstgestrickt:
http://www.mikrocontroller.net/articles/FAQ#Eigene_Umwandlungsfunktionen

Den erhaltenen String kannste dann auf dein LCD schieben. mfg mf

[Karl H. (kbuchegg)]

Kein Plan schrieb:
> Danke für die Antworten.
>
> Kurz mein Vorhaben:
> Zitat aus der I2C Routine von Peter Fleury:
>

> unsigned char i2c_readAck(void)
> {
>   TWCR = (1<<TWINT) | (1<<TWEN) | (1<<TWEA);
>   while(!(TWCR & (1<<TWINT)));
> 
>     return TWDR;
> 
> }

>
> Denn erhaltenen Wert würde ich gerne als dezimal Zahl ausgeben.

die lcd_uint8 von oben macht das.

unsigned char ist auch nichts anderes als ein uint8_t