mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Vergesslicher, ungeduldiger atmega bei UART


Autor: Martin W. (schnuffituffi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,
ich will die Werte von 3 Hall Sensoren gerne über UART ausgeben. 
Allerdings nur dann, wenn sie sich auch ändern. Das mit dem Ausgeben 
funktioniert soweit. Das mit dem ändern allerdings nicht. Dafür hatte 
ich eine Variable   sensorold angelegt, die dann mit den aktuellen 
Sensorwerten verglichen wird. Leider wird sie immer wieder 0. In jedem 
Schleifendurchlauf! Ich versteh leider nicht warum. Auch das 
_delay_ms(500) wird scheinbar komplett ignoriert.
#include <avr/io.h>
#define F_CPU 20000000UL
#include <util/delay.h>
#define BAUD 9600L
#include <stdlib.h> 
#include <string.h>



int uart_putc(unsigned char character)
{  
  while (!(UCSR0A & (1<<UDRE0))){}    //warten bis Senden möglich
  UDR0 = character;
  return 0;
}
int main(void){
  
  //Initialisieren
  DDRD |=  0b11111100; //Phasen Ausgänge

  //Ausgangsverknüpfung (clear on compare match)
  TCCR1A |= (1<<COM1A1);
  
  //kein Vorteiler
  TCCR1B |= (1<<CS10);
  
  //Fast PWM, 10-bit
  TCCR1A |= (1<<WGM11) | (1<<WGM10);
  TCCR1B |= (1<<WGM12);
  
  //OCR1A = 500; //PWM Wert (MAX 1024)
  OCR1A = 300;

  DDRB |=  0b00000010; //PWM Ausgang

  //UART
  UCSR0B |= (1<<TXEN0);  // UART TX einschalten
  // Asynchron 8N1 ist bei mega 168 default
  UBRR0 = 129;

  // Pullups für Hall Sensoren
  PORTC|=  0b00111000;
  
  char sensor[200];
  uint8_t sensorold = 0;
  uint8_t sensorbin = 0;
  
  
  while (1){
      
    sensorbin = 0;
    
    if ( PINC & (1<<PINC5) ) {
      sensorbin += 1;
    }

    if ( PINC & (1<<PINC4) ) {
      sensorbin += 2;
    }

    if ( PINC & (1<<PINC3) ) {
      sensorbin += 4;
    }
    
    if(sensorbin != sensorold){
      if (sensorbin & 1){
        strcat( sensor, "A1\r\n" );
      }
      else{
        strcat( sensor, "A0\r\n" );  
      }
      
      if (sensorbin & 2){
        strcat( sensor, "B1\r\n" );
      }
      else{
        strcat( sensor, "B0\r\n" );
      }    
    
      if (sensorbin & 4){
        strcat( sensor, "C1\r\n" );
      }
      else{
        strcat( sensor, "C0\r\n" );
      }    
      
      uint8_t i = 0;
      uint8_t l = strlen (sensor);
    
      while (i <= l){
        uart_putc(sensor[i]);
        i++;
      };
        
      strcpy(sensor, "");// String leeren  
      _delay_ms(500);
      sensorold = sensorbin;
    }    
  }
}

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin W. schrieb:
> Auch das _delay_ms(500) wird scheinbar komplett ignoriert.
Worauf begründest du den Schein? Schließ doch mal ein LED an einen Pin 
an, der mit jedem Zyklus getoggelt wird...

BTW: der Watchdog ist ausgeschaltet?

Autor: fake (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>sensorbin = 0;
>sensorold = sensorbin;

Damit setzt Du doch bei jedem Schleifendurchlauf sensorold auf 0.

Autor: Bastian Werner (jackfrost)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

geht es mit

If(PINC != sensorold)
{
    utoa(sensor,PINC,10);
    sensorold = PINC;
     while (i <= l){
        uart_putc(sensor[i]);
        i++;
    };
}

Gruß JackFrost

Autor: Frickelfritze (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
fake schrieb:
> Damit setzt Du doch bei jedem Schleifendurchlauf sensorold auf 0.

Nö.

Autor: Martin W. (schnuffituffi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Martin W. schrieb:
>> Auch das _delay_ms(500) wird scheinbar komplett ignoriert.
> Worauf begründest du den Schein? Schließ doch mal ein LED an einen Pin
> an, der mit jedem Zyklus getoggelt wird...

Das leite ich daraus ab, das mir die Konsole innerhalb einer Sekunde 
bereits völlig zugeballert wird. Daher weiß ich ja auch, das der Rest 
funktioniert. Die ausgegebenen Sensorwerte sind richtig. Daher weiß ich 
auch, dass sensorold am ende der Schleife auf keinen Fall mit 0 
überschrieben wird. Trotzdem ist es beim Sprung in den Anfang der 
Schleife wieder 0.(hab ich mir über uart ausgeben lassen)

>
> BTW: der Watchdog ist ausgeschaltet?

Das klingt sehr spannend, aber wie finde ich das heraus? Die Fuse für 
Watchdog ist nicht gesetzt. Und von Hand hab ich da auch nix 
angeschaltet.

Autor: jb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>fake schrieb:
>> Damit setzt Du doch bei jedem Schleifendurchlauf sensorold auf 0.

>Nö.

Wohle. Ganz sicher.

Gruß J

Autor: Joachim B. (jar)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
kommst du denn überhaupt in diesen Programmteil?

du nutzt strcat! ohne erstmalig sensor[] überhaupt zu initialisieren.

vermutlich sollte es mal NULL sein aber wer weiss?

Martin W. schrieb:
> char sensor[200];

sollte besser char sensor[200]={0}; sein bevor es mit strcat weitergeht!

: Bearbeitet durch User
Autor: Rainer B. (katastrophenheinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin W. schrieb:
> völlig zugeballert wird

Was wird denn ausgegeben?
Beim ersten Scheifendurchlauf ist das char-Array "sensor" 
uninitialisert, es sei denn, der Compiler initialisiert es automatisch 
mit 0en.

Autor: Rainer B. (katastrophenheinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... guter zweiter Platz ;-)

Autor: Martin W. (schnuffituffi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jb schrieb:
>>>fake schrieb:
>>> Damit setzt Du doch bei jedem Schleifendurchlauf sensorold auf 0.
>
>>Nö.
>
> Wohle. Ganz sicher.
>
> Gruß J

Warum sollte das so sein ?

Zu beginn der Schleife wird meine Sensorspeicher (sensorbin) gelöscht. 
Dann werden die Sensoren in den Speicher geschrieben. Dass das 
funktioniert hat, weiß ich anhand der UART-Ausgabe. sensorbin ist also 
nun nicht mehr 0. Anschließend wird doch erst sensorold = sensorbin; 
ausgeführt.

Autor: jb (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
>>sensorbin = 0;
>>sensorold = sensorbin;

Für die beiden isolierten Zeilen schon, den restlichen Code habe ich 
nicht betrachtet.

Gruß J

Autor: Martin W. (schnuffituffi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> kommst du denn überhaupt in diesen Programmteil?
>
> du nutzt strcat! ohne erstmalig sensor[] überhaupt zu initialisieren.
>
> vermutlich sollte es mal NULL sein aber wer weiss?
>
> Martin W. schrieb:
>> char sensor[200];
>
> sollte besser char sensor[200]={0}; sein bevor es mit strcat weitergeht!

Hab ich geändert. Hilft nur leider nicht. Die Ausgabe bleibt die selbe, 
also z.B.:
A1
B0
C1

Aushabe erfolgt geschätzt 10 mal pro Sekunde, oder öfter.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin W. schrieb:
> Aushabe erfolgt geschätzt 10 mal pro Sekunde, oder öfter.

dann hast du ein viel größere Problem:

> _delay_ms(500);

dann sollte maximal 2mal in der sekunde etwas gesendet werden.

Autor: BlaBla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
char sensor[200];
  uint8_t sensorold = 0;
  uint8_t sensorbin = 0;

muss aus der main() heraus.

Autor: Martin W. (schnuffituffi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
BlaBla schrieb:
>
char sensor[200];
>   uint8_t sensorold = 0;
>   uint8_t sensorbin = 0;
>
> muss aus der main() heraus.

Warum ?

Peter II schrieb:
> Martin W. schrieb:
>> Aushabe erfolgt geschätzt 10 mal pro Sekunde, oder öfter.
>
> dann hast du ein viel größere Problem:
>
>> _delay_ms(500);
>
> dann sollte maximal 2mal in der sekunde etwas gesendet werden.

Ja davon sprach ich ja auch schon. Deswegen klang das mit dem Watchdog 
ja auch so gut. Aber wenn der nicht per default an ist, kanns das nicht 
sein.

Autor: Bastian Werner (jackfrost)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du das Programm mal simuliert ? Da darf ja nichts gesendet werden. 
Auch kannst du die Verzögerung messen

Gruß JackFrost

: Bearbeitet durch User
Autor: Frickelfritze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie war das doch nochmal?

Lokale Variablen werden nicht automatisch initialisiert,
globale dagegen schon.

betrifft:
char sensor[200];

Eigentlich sollte der Compiler eine Warnung ausgeben ....

Autor: Martin W. (schnuffituffi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frickelfritze schrieb:
> Wie war das doch nochmal?
>
> Lokale Variablen werden nicht automatisch initialisiert,
> globale dagegen schon.
>
> betrifft:
>
char sensor[200];
>
> Eigentlich sollte der Compiler eine Warnung ausgeben ....

Es ist egal ob Global oder nicht initialisiert oder nicht. Fehler 
bleiben leider immer die selben.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> Martin W. schrieb:
>> char sensor[200];
>
> sollte besser char sensor[200]={0}; sein bevor es mit strcat weitergeht!

Das ist suboptimal. Damit werden sämtliche 200 Speicherstellen von 
sensor in einer Schleife genullt, obwohl das gar nicht notwendig ist.

Die erste Stelle reicht nämlich (wg. strcat):
char sensor[200];
sensor[0] = '\0';

Autor: BlaBla (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
BlaBla schrieb:
>
char sensor[200];
>   uint8_t sensorold = 0;
>   uint8_t sensorbin = 0;
>
> muss aus der main() heraus.

Warum ?

Das ist so! Bei jedem Durchlauf der while-Schleife werden die Variablen 
auf Null gesetzt. Mach daraus globale Variablen, dann werden die Inhalte 
beibehalten.

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Das ist suboptimal. Damit werden sämtliche 200 Speicherstellen von
> sensor in einer Schleife genullt,

stimmt, wer packt das auch in eine Schleife im Code, das gehört sich 
anders!

Frank M. schrieb:
> Die erste Stelle reicht nämlich (wg. strcat):char sensor[200];
> sensor[0] = '\0';

auch das stimmt und ist effektiver wenn der sensor[] unbedingt im Code 
in der while stehen bleiben soll!

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
BlaBla schrieb:
> Das ist so! Bei jedem Durchlauf der while-Schleife werden die Variablen
> auf Null gesetzt. Mach daraus globale Variablen, dann werden die Inhalte
> beibehalten.

Das ist blanker Unsinn. Die Variablen werden ausserhalb der 
while-Schleife definiert und auf Null gesetzt. Da main() auch nie 
verlassen wird, bleiben sie auch als lokale Variablen die ganze Laufzeit 
am Leben.

Sorry, aber Du scheinst wenig bis gar keine Ahnung von C zu haben. Ich 
wäre vorsichtig mit solchen Vorschlägen.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
BlaBla schrieb:
> Das ist so! Bei jedem Durchlauf der while-Schleife werden die Variablen
> auf Null gesetzt.

welche schleife meinst du? Die NACH der Initialisierung?

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> auch das stimmt und ist effektiver wenn der sensor[] unbedingt im Code
> in der while stehen bleiben soll!

Die Definition von sensor[] steht gar nicht in der while-Schleife, 
sondern darüber ;-)

Ausserdem ist eine lokale Variable hier sogar ressourcensparender:

Wenn Du sensor[200] nämlich global definierst, werden trotzdem wieder 
200 Speicherstellen gelöscht, obwohl die erste komplett reicht.

Martin W. schrieb:
> strcpy(sensor, "");// String leeren
sensor[0] = '\0'

ist hier etwas eleganter. Man muss nicht unbedingt immer mit Funktionen 
auf Variablen schießen - auch wenn sie in moderneren 
C-Compiler-Umgebungen intern abgebildet werden.

: Bearbeitet durch Moderator
Autor: BlaBla (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Meine Antwort hat sich erledigt. Habe heute einen Knick in der Optik. 
Die Variablen stehen an der richtigen Stelle. Auf die Polemik von Frank 
M. werde ich nicht weiter eingehen.

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Die Definition von sensor[] steht gar nicht in der while-Schleife,
> sondern darüber ;-)

ach was solls der ganze Code ist undurchsichtig!

Autor: Werner P. (wpfundstein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin W. schrieb:
> Ich versteh leider nicht warum. Auch das
> _delay_ms(500) wird scheinbar komplett ignoriert.

wenn dem so ist dann resetet der Controller.

mach doch einfach vor der while in der main eine uart Ausgabe. Sagen wir 
Ausgabe von "start".

Dann siehst Du auf jeden Fall ob ein Reset während des Programmablaufs 
stattfindet.

Autor: Rainer B. (katastrophenheinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zurück zum Problem des TO:
 - Sind Compiler-Warnings mit -Wall eingeschaltet?
 - Ändert sich etwas, wenn du den delay-wert auf 5000 erhöhst?
 - Poste mal den Build-Output und das .lss-File

Autor: BlaBla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine Idee: liegt die richtige Spannung für 20 MHz an.

Autor: Martin W. (schnuffituffi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
BlaBla schrieb:
> Noch eine Idee: liegt die richtige Spannung für 20 MHz an.

Spannung sind 4,91V

Werner P. schrieb:
> Martin W. schrieb:
>> Ich versteh leider nicht warum. Auch das
>> _delay_ms(500) wird scheinbar komplett ignoriert.
>
> wenn dem so ist dann resetet der Controller.
>
> mach doch einfach vor der while in der main eine uart Ausgabe. Sagen wir
> Ausgabe von "start".
>
> Dann siehst Du auf jeden Fall ob ein Reset während des Programmablaufs
> stattfindet.

War ne gute Idee. Der Atmel scheint sich neu zu starten. Zumindest wird 
das Start ständig geschrieben. Der neustart erfolgt alle 16 UART Zeichen 
wenn ich mich nicht verzählt hab.
Aber woran kann das liegen ?

Autor: Werner P. (wpfundstein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin W. schrieb:
> Aber woran kann das liegen ?

Wenn der Code in deinem Eingangspost alles ist dann kann es eigentlich 
nur noch ein Hardwarefehler sein.

Schaltplan?

Edit: Was passiert wenn Du in der while mal alles ausdokumentierst?

: Bearbeitet durch User
Autor: BlaBla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine Idee: AtmelStudio 7 zeigt mir die Variable "sensorbin" nicht 
im Debugger mit der Compiler-Option -Os an. Die wird scheinbar hinfort 
optimiert. Mit der folgenden Änderung wird sie wieder sichtbar.
volatile uint8_t sensorold = 0;
volatile uint8_t sensorbin = 0;

Autor: CRätsel (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Frank M. schrieb:
>> sollte besser char sensor[200]={0}; sein bevor es mit strcat weitergeht!
>
> Damit werden sämtliche 200 Speicherstellen von
> sensor in einer Schleife genullt, obwohl das gar nicht notwendig ist.

Komisch, mein Compiler initialisiert mit dieser Art
char sensor[200]={0};

genau ein Element von sensor[], und zwar das erste. So war
ich es bisher auch gewohnt.

Frank M. scheint einen neuartigen Compiler zu haben oder einen
der einen anderen Standard verfolgt ..... vielleicht M$?

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CRätsel schrieb:
> Frank M. scheint einen neuartigen Compiler zu haben

kann nicht sein, der Frank weiss es immer besser als ich.....

Ich glaube fast ich muss das wirklich auf meinem Compiler untersuchen 
was da genau passiert obwohl es mir total schnurz ist ob

Joachim B. schrieb:
> char sensor[200]={0};

200 Byte auf 0 setzt oder nur das erste Byte

aber da Frank mir wieder mal widersprach:

Frank M. schrieb:
> Das ist suboptimal. Damit werden sämtliche 200 Speicherstellen von
> sensor in einer Schleife genullt

interessiert es mich schon ob mit Recht oder nur weil er ein 
Widerspruchsgeist ist.

CRätsel schrieb:
> Komisch, mein Compiler initialisiert mit dieser Art
> char sensor[200]={0};
> genau ein Element von sensor[], und zwar das erste. So war
> ich es bisher auch gewohnt.

dafür spricht:

http://www.tutorials.at/c/09-arrays-strings.html
Ein wichtiger Punkt bei lokal deklarierten Arrays ist deren 
Initialisierung. Ein Beispiel:

int daten[3] = { 0, 0, 0 };

Hier wird das Array daten mit 3 Elementen vom Typ int deklariert und 
zugleich definiert. Alle drei Elemente werden auf 0 gesetzt 
(initialisiert). Die einzelnen Werte werden dabei der Reihe nach 
zwischen geschwungenen Klammern { } angegeben.

int daten[] = { 4, 10, -20 };

Hier wurde die Anzahl der Elemente in eckigen Klammern weggelassen. Das 
ist immer dann möglich, wenn ein Array gleich initialisiert wird. Denn 
es geht für den Compiler aus der Initialisierungsliste ohnehin hervor, 
wieviel Speicher und Elemente reserviert werden müssen.

Das erste Element (daten[0]) wird mit 4 initialisiert, das zweite 
(daten[1]) mit 10 und das dritte (daten[2]) und zugleich letzte mit -20.

: Bearbeitet durch User
Autor: Martin W. (schnuffituffi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Werner P. schrieb:
> Martin W. schrieb:
>> Aber woran kann das liegen ?
>
> Wenn der Code in deinem Eingangspost alles ist dann kann es eigentlich
> nur noch ein Hardwarefehler sein.
>
> Schaltplan?
>
> Edit: Was passiert wenn Du in der while mal alles ausdokumentierst?

Also ich hab alles im While auskommentiert. Ergebnis: Der Kontroller 
startet permanent neu, statt in der while schleife zu verharren. :'( 
Lass ich ihn etwas Ausgeben, schafft er vor dem Absturz etwa 16 Zeichen. 
Am Reset Pin hab ich mal mit dem Oszi gemessen und konnte nix sehen was 
einen Restart rechtfertigen würde.

Schaltplan hab ich mal angehängt. Ich denke aber mal nicht, dass ich da 
etwas total verkackt habe.

Autor: Frickelfritze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin W. schrieb:
> dass ich da etwas total verkackt habe.

Naja, total nicht aber bisschen schon.

Die Abblock-Cs an Vcc und Avcc fehlen. Was das in deinem Fall
ausmacht wage ich nicht zu beurteilen, aber gut ist das nicht.

Abblock-Cs müssen übrigens direkt am Controller sein.

Autor: Frickelfritze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frickelfritze schrieb:
> Abblock-Cs müssen übrigens direkt am Controller sein.

... und dürfen nicht weggelassen werden bloss weil am
Spannungsregler schon welche sitzen .....

Autor: Martin W. (schnuffituffi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab nochmal den UART ausgemacht. Leider stürzt er immer noch ab. Hab den 
PWM Ausgang gemessen. Absturz ist zuverlässig nach exact 17,3ms .

Autor: Frickelfritze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin W. schrieb:
> Leider stürzt er immer noch ab.

Aufbau zeigen ....

Die 27pF am Quarz kommen mir etwas hoch vor, könnte die
Betriebssicherheit beeinträchtigen. 18pF müssten reichen.

Ein 78L05 als Spannungsregler ..... ob der Strom ausreicht
um alles zu speisen .... ich weiss nicht was die IRS2184
an Strom ziehen ....

... und wieviel Oberspannung hast du auf der Primärseite
des Reglers?

Autor: Martin W. (schnuffituffi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frickelfritze schrieb:
> Martin W. schrieb:
>> Leider stürzt er immer noch ab.
>
> Aufbau zeigen ....
>
> Die 27pF am Quarz kommen mir etwas hoch vor, könnte die
> Betriebssicherheit beeinträchtigen. 18pF müssten reichen.
>
> Ein 78L05 als Spannungsregler ..... ob der Strom ausreicht
> um alles zu speisen .... ich weiss nicht was die IRS2184
> an Strom ziehen ....

Der 78L05 versorgt ausschließelich die MCU.

> ... und wieviel Oberspannung hast du auf der Primärseite
> des Reglers?

12V. Die Frage hat das Problem gelöst. Von sowas hab ich noch nie 
gehört, und es ist mir echt peinlich, das die Quasi 1.Frage jeder 
Telefonhotline mein Problem löst. Auf die Frage hin, hab ich das 
Netzteil einmal aus der Steckdose gezogen um nochmal auf die 
Beschriftung zu gucken. 12V DC 800mA. Also eigentlich ok. Nach dem 
wieder reinstecken ging alles.

Ist irgendwem sowas schon mal passiert ? Ich finde das sehr Skuril. Ich 
dachte spätestens nach dem Programmieren und dem damit verbundenen Reset 
müsste ein Absturz des Prozis behoben sein... aber offensichtlich war 
das hier nicht der Fall.

Vielen Dank an alle die geholfen haben und die vielen Tipps nebenbei. 
Der Thread ist damit gelöst.

Autor: Frickelfritze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin W. schrieb:
> Der Thread ist damit gelöst.

Danke für die Rückmeldung!

Aber die Abblock-Cs baust du noch dazu! Sonst gibt's ein
schlechtes Gewissen und ......

Autor: Frickelfritze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin W. schrieb:
> Also eigentlich ok. Nach dem wieder reinstecken ging alles.

Vielleicht wird es dem 78L05 doch etwas ungemütlich wenn er
7 Volt verarbeiten und xx mA liefern muss.

Autor: Martin W. (schnuffituffi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frickelfritze schrieb:
> Martin W. schrieb:
>> Also eigentlich ok. Nach dem wieder reinstecken ging alles.
>
> Vielleicht wird es dem 78L05 doch etwas ungemütlich wenn er
> 7 Volt verarbeiten und xx mA liefern muss.

Jup. Also gut anfassen kann man ihn nicht. Ich denke ich werde ihn 
tatsächlich tauschen, zumal in der Endfassung 16,88V anliegen können 
sollen.

Das sind dann 11,88V drop. Bei den erlaubten 100mA wären das dann schon 
Rund 1,2 Watt. Andererseits darf das Ding laut Datenblatt 70°C heiß 
werden.

Autor: Frickelfritze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin W. schrieb:
> Andererseits darf das Ding laut Datenblatt 70°C heiß
> werden.

Mit nicht vorhandenen Reserven sollte man nicht spekulieren.

Das nennt man Leben auf Pump.

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frickelfritze schrieb:
>> dass ich da etwas total verkackt habe.
>
> Naja, total nicht aber bisschen schon.

L1 an AREF ist auch eher daneben, die würde eher an AVCC Sinn ergeben. 
Wenn man die Versorgungsspannung als Referenz will setzt man einfach die 
REFSn Bits in ADMUX passend.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
CRätsel schrieb:
> Komisch, mein Compiler initialisiert mit dieser Art
> char sensor[200]={0};
> genau ein Element von sensor[], und zwar das erste. So war
> ich es bisher auch gewohnt.
>
> Frank M. scheint einen neuartigen Compiler zu haben oder einen
> der einen anderen Standard verfolgt ..... vielleicht M$?

Der "neuartige" Compiler ist ein stinknormaler avr-gcc.
Testcode:
#include <string.h>

int
main ()
{
    char sensor[200] = { 0 };
    strcat (sensor, "Hello World");
}

lss-Output:
00000096 <main>:
  96:  cf 93         push  r28
  98:  df 93         push  r29
  9a:  cd b7         in  r28, 0x3d  ; 61
  9c:  de b7         in  r29, 0x3e  ; 62
  9e:  c8 5c         subi  r28, 0xC8  ; 200
  a0:  d1 09         sbc  r29, r1
  a2:  0f b6         in  r0, 0x3f  ; 63
  a4:  f8 94         cli
  a6:  de bf         out  0x3e, r29  ; 62
  a8:  0f be         out  0x3f, r0  ; 63
  aa:  cd bf         out  0x3d, r28  ; 61
  ac:  ce 01         movw  r24, r28
  ae:  01 96         adiw  r24, 0x01  ; 1
  b0:  28 ec         ldi  r18, 0xC8  ; 200
  b2:  fc 01         movw  r30, r24
  b4:  11 92         st  Z+, r1
  b6:  2a 95         dec  r18
  b8:  e9 f7         brne  .-6        ; 0xb4 <main+0x1e>
  ba:  60 e0         ldi  r22, 0x00  ; 0
  bc:  71 e0         ldi  r23, 0x01  ; 1
  be:  0e 94 6d 00   call  0xda  ; 0xda <strcat>

Die Initialisierungsroutine geht von 0xac bis 0xb8. Hier werden 200 
Bytes in einer Schleife genullt.

Und jetzt noch die Literatur dazu, dass der avr-gcc das richtig macht, 
während Du entweder irgendetwas dahingeschwätzt oder einen defekten 
Compiler hast:

  http://www.c-howto.de/tutorial-arrays-felder-initi...

Zitat:
-----------------------------
Ist die Anzahl der Werte bei der Initialisierung kleiner als die 
Feldgröße, werden die restlichen Werte auf Null gesetzt. [...]
Dadurch lässt sich ein Feld auch einfach komplett mit Null-Werten 
initialisieren:

int punkte[5] = { 0 };
-----------------------------

Weitere Links dazu:

  http://stackoverflow.com/questions/2589749/how-to-...
  http://stackoverflow.com/questions/201101/how-to-i...

Es gibt noch tausende andere Links zu diesem Thema, meinst Du, die lügen 
alle?

: Bearbeitet durch Moderator
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> dafür spricht:
>
> http://www.tutorials.at/c/09-arrays-strings.html
> Ein wichtiger Punkt bei lokal deklarierten Arrays ist deren
> Initialisierung. Ein Beispiel:
>
> int daten[3] = { 0, 0, 0 };
>
> Hier wird das Array daten mit 3 Elementen vom Typ int deklariert und
> zugleich definiert.

Ich muss Dir leider widersprechen: Das spricht überhaupt nicht dafür. 
Das ist der normale Ansatz eines Tutorial-Schreibers, wenn er dem Leser 
die Initialisierung beibringen will.

Der Autor dieses Tutorials kennt lediglich die folgende Regel nicht:

"Wenn eine Initialisierung angegeben wird und diese unvollständig(!) 
ist, wird der Rest automatisch mit Nullen gefüllt".

Die wenigsten kennen diese, obwohl sie steinalt, also keine irgendwelche 
komische "Neuerung" irgendeines Standards ist. Im Gegenteil: Das war 
schon immer so.

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich muss Dir leider widersprechen:

machst du ja gerne, aber ich räume ein eine Fundstelle ist naturgemäß 
wenig aussagekräftig.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> machst du ja gerne,

:-)

> aber ich räume ein eine Fundstelle ist naturgemäß wenig aussagekräftig.

Was Du da zitiert hast, ist ja nicht falsch - höchstens unvollständig. 
Der Autor hätte auf die zusätzliche Möglichkeit der 
Komplettinitialisierung eines Array ruhig hinweisen können.

Bei
int daten[2048] = { 0 };

hätte er nämlich sonst eine ziemliche Schreibarbeit :-)

Autor: Georg G. (df2au)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Joachim B. schrieb:
> eine Fundstelle ist naturgemäß
> wenig aussagekräftig.

Genügt dir K&R, The C Programming Language, Prentice Hall, Kapitel 4.9, 
auf Seite 84?

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Oder auch die Second Edition vom K&R-Klassiker, hier Seite 86:

"If there are fewer initializers for an array than the number specified, 
the missing elements will be zero for external, static, and automatic 
variables."

Also ist kein "neuartiger" Compiler dafür notwendig. Das war schon seit 
Anbeginn von C so.

: Bearbeitet durch Moderator
Autor: Martin W. (schnuffituffi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
guest schrieb:
> Frickelfritze schrieb:
>>> dass ich da etwas total verkackt habe.
>>
>> Naja, total nicht aber bisschen schon.
>
> L1 an AREF ist auch eher daneben, die würde eher an AVCC Sinn ergeben.
> Wenn man die Versorgungsspannung als Referenz will setzt man einfach die
> REFSn Bits in ADMUX passend.

Du hast vollkommen recht, da hab ich kacke gebaut! Wird natürlich 
korrigiert.

Autor: Joachim B. (jar)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Georg G. schrieb:
> Genügt dir K&R, The C Programming Language, Prentice Hall, Kapitel 4.9,
> auf Seite 84?

habe ich nicht, aber das hier ist auch interessant!

QC hält sich nicht an die automatische Arraygröße wenn Werte vorgegeben 
sind

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> QC hält sich nicht an die automatische Arraygröße wenn Werte vorgegeben
> sind

Die früheren C-Compiler für Windows aus den 80ern haben jede Menge 
falsch bzw. "anders" gemacht als das UNIX-Original. Wirf das QuickC-Buch 
am besten wech oder verfeuere es im Kamin, aber verschenke es 
keinesfalls. Der andere könnte darin lesen und einiges lernen, was 
schlicht und einfach falsch ist. ;-)

: Bearbeitet durch Moderator
Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Die früheren C-Compiler für Windows

sorry das war DOS! (alles weisst du auch nicht gelle :)

und das M$ immer alles anders macht weiss man ja, wieso wurde 
dennFAT16(!?) auf int 32k Cluster reglementiert? wenn es auch locker 
uint 64k Cluster sein könnten? denn negative Cluster will ja keiner.

Ich muss noch mal nach meinem Sybex Buch suchen, nur das hier fiel mir 
gerade beim Werkstattumzug in die Hände.

: Bearbeitet durch User
Autor: Georg G. (df2au)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> sorry das war DOS!

Möchtest du eine Windows Version von QC haben? Mit LCC32 erzeugt.

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg G. schrieb:
> Möchtest du eine Windows Version von QC haben? Mit LCC32 erzeugt.

habe sogar das Original, als QC für win und als VC für win aber leider 
ziemlich unbrauchbar, die hatten sogar mit Kompatiblität geworben, war 
aber nur geschönt, meinte Quellcode kompatibel, was für ein Witz, die HP 
IEEE Libs konnte man nicht nutzen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.