mikrocontroller.net

Forum: Compiler & IDEs Problem beim Portieren eines Projektes


Autor: Marko (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi Forum,

ich bin gerade am Übertragen eines Bascom Codes nach C.
Grund dafür ist u.A. mal an nem richtigen Projekt mit identischem
Programmablauf die Codegröße zu vergleichen und die
Ausführungsgeschwindigkeit mal zu vergleichen.
Das Projekt besteht aus ner Kamera
C-328 an UART,
EIN EDO-RAM-Rigel SIMM30 parallel,
Ein GLCD von Optrex an SPI.

Beim umcoden hab ich verschiedene Befehle von Bascom
in C nachgebildet ... daher sieht der Code für die eingefleischten
C Programmierer vermutlich etwas wild aus, wollt aber einfach
ne schöne Gegenüberstellung haben.

Mein Problem ist nun, wenn ich im AVR-Studio die Simulation
laufen lassen will schmiert mir das Studio 4 ab.
Seltsamerweise trat der Fehler erst auf als ich an die Portierung
des URXC-Interrupts ging.

Hat jemand nen heißen Tipp für mich?

Ach so, die Subroutine Edo_clear(); wird seltsamerweise auch nicht 
angesprungen im Simulator

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Beim umcoden hab ich verschiedene Befehle von Bascom in C nachgebildet

Vergleiche gut programmiertes Basicprogramm gegen schlecht 
programmiertes C-Programm? Sehr sinnvoll.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie hast du denn das durch den Compiler gekriegt?

In C gibt es keine funktionslokalen Funktionen.
Eigentlich hätte dir der Compiler ein paar Hundert
Fehlermeldungen um die Ohren hauen müssen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast ne ganze Menge for-Schleifen nach dem Muster:

void Waitus ( unsigned char wert){
  unsigned char i;
  for (i = 0x00; i == wert ; i++){
    us1();
  }
}

Da brauch ich gar nicht analysieren, dass das so nicht
stimmen kann.
Eine for Schleife, die nicht dem Muster folgt:

   for( Variable Initialisieren; Variable < Endwert; i++ )

ist von vorne herein erst mal suspekt. Beachte das <
Das zweite Element in einem for liest sich in Deutsch:
"solange wie", nicht "solange bis"

Wer ein Programm in 2 verschiedenen Sparchen zum Zwecke
des Vergleiches schreiben will, sollte in beiden Sprachen
absolut firm sein. Alles andere hat keinen Zweck.

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HI, hab ja nicht behauptet der Crack in C zu sein,
aber arbeite daran. Der Compiler hat genaugenommen garkeine
Fehler mehr gebracht .. hat evtl. ja auch aufgegeben :o)

Warum in der For-Schleife das == nicht gehen soll
und durch < zu ersetzen ist entzieht sich auch meinem Verständnis.
Zumal diese Geschichten im Simulator exzelent liefen, keine
Beanstandung des Compilers o.Ä..

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ach so, das == lese ich dann so,
tu solange wie nicht gleich, oder liege ich da falsch?

Ich komm ansich eher aus der PHP-Ecke, da geht das so
problemlos.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ach so, das == lese ich dann so,
> tu solange wie nicht gleich

Wieso 'nicht gleich'. Da steht eindeutig ein Vergleich
auf Gleichheit.
Deine Schleife läuft solange, solange gilt:
  i  ist gleich  Wert

Wenn dein Wert nicht zufällig 0 ist, wird die Schleife
gar nicht betreten, da i eben nicht gleich Wert ist.


> Warum in der For-Schleife das == nicht gehen soll
> und durch < zu ersetzen ist entzieht sich auch meinem
> Verständnis.

Wenn das tatsächlich stimmt, dann solltest du mit
was Einfacherem als einer Portierung anfangen um in C
einzutauchen.

Gehen - im Sinne von 'durch den Compiler kriegen' - wird
es schon. Nur funktionieren - im Sinne von 'die gewünschte
Funktionalität erreichen' - wird es nicht.


Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Autor: Karl heinz Buchegger (kbuchegg)
>> Datum: 05.02.2007 13:04
>>
>> Wie hast du denn das durch den Compiler gekriegt?
>>
>> In C gibt es keine funktionslokalen Funktionen.
>> Eigentlich hätte dir der Compiler ein paar Hundert
>> Fehlermeldungen um die Ohren hauen müssen.

Klar geht das. Habe ich auch schonmal gemacht. So konnte ich wunderbar 
die Sichtbarkeit einer Variable auf die Funktion beschränken....

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: Was willst du da vergleichen? Das Programm wird unter beiden 
Programmiersprachen genau gleich langsam sein. Das musst du unter c 
anders programmieren um bessere aussagen machen zu können....

Autor: Thomas B. (yahp) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Klar geht das. Habe ich auch schonmal gemacht. So konnte ich wunderbar
> die Sichtbarkeit einer Variable auf die Funktion beschränken....

Es ging um funktionslokalen Funktionen, nicht um lokale Variablen. 
Letzere gibt es ja wirklich.


> PS: Was willst du da vergleichen? Das Programm wird unter beiden
> Programmiersprachen genau gleich langsam sein.

Das wäre ja ganz erstaunlich. Nicht mal unterschiedliche Compiler der 
selben Sprache erzeugen aus dem gleichen Quelltext gleich schnellen 
Code.

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eben nicht gleich langsam.
Wie der jeweilige Compiler z.B. mit dem Aufruf von
Variablen aus dem SRAM umgeht, z.B. Schleifen
jedesmal Lädt und Speichert oder im Register bleibt
z.B. ist n gewaltiger Unterschied um mal nur einen
zu nennen

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
thomas:
ich hatte eine Funktion a(uint8_t wert)

Dann hatte ich noch eine funktion b(void). In der Funktion b() wollte 
ich nun auf wert zugreifen. damit ich nun b(void) nicht nach b(uint8_t 
wert2) umbenennen musste habe ich b einfach innerhalb von a deklariert 
und schon hatte b auf wert zugriff ;-)
Also ich habe das schon so verstanden wies geschreiben war.....

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>> In C gibt es keine funktionslokalen Funktionen.
>>> Eigentlich hätte dir der Compiler ein paar Hundert
>>> Fehlermeldungen um die Ohren hauen müssen.
>
> Klar geht das. Habe ich auch schonmal gemacht

In Pascal vielleicht :-)

Funktionen, nicht Variablen.

Also sowas:

void foo()
{
   void bar()
   {
   }

  bar();
}

Viele C-Compiler kommen bei so einem schweren Syntaxfehler
gehörig ausser Tritt. Das mündet dann oft in eine wahre
Error-Orgie.

Autor: Rahul, der Trollige (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>In Pascal vielleicht :-)

Ja, geht...

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach so, warum das Studio nen Runtime Error hervorbringt
ist bislang aber noch gänzlich unklar geblieben.
Mit for - next wird das doch wohl kaum was zu schaffen haben, oder?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit for-next nicht.
Aber du hast durch die funktionslokalen Funktionen schwere
Fehler im Programm. Eigentlich hätte der Compiler verweigern
müssen. Warum er es nicht getan hat, wissen nur die Götter.
Auf jedem Fall kann man dem Ergebnis des Compilierlaufs
nicht trauen.

Autor: Marko (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Will mir ja nicht nachsagen lassen nicht lernfähig zu sein,
gleiches Listing nach Euren Anregungen umgestrickt und
der Compiler bringt keinen Error und keine Warnings,
aber das Studio steigt mit Runtime Error aus wenn
ichs im Simulator laufen lassen will.

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit "funktionslokalen Funktionen" meinst Du die Deklaration
einer Funktion innerhalb
einer Funktion wenn ich Dich richtig interpretiere?

Es ging mir dabei darum Werte von einer Funktion in die nächste
und übernächste zu retten ohne zig hin und her Geschiebe.

Autor: Funktion (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@KarlHeinz

Ich will ja nicht Dein C Weltbild zerstören aber im AVR-GCC geht 
FUNKTIONIERT das problemlos!  Probier es aus und gib in der bar() 
Funktion (void bar(void) muss da noch rein) mal irgendwas über die 
serielle aus.
Das klappt :)


So einen Kram hatten wir sogar in der Uni - zwar nicht C spezifisch aber 
sowas ist üblich in vielen anderen Programmiersprachen - und in C ja 
scheinbar auch.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was irgendwelche Compiler machen oder auch nicht, ist mir
ehrlich gesagt egal. Mich interessiert was im C-Sprachstandard
normiert ist. Das gilt. Auf diese Funktionalität kann ich
mich verlassen.
Und der C-Sprachstandard sagt eindeutig: Das ist kein
gültiges C.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marko wrote:
> Mit "funktionslokalen Funktionen" meinst Du die Deklaration
> einer Funktion innerhalb
> einer Funktion wenn ich Dich richtig interpretiere?
>
> Es ging mir dabei darum Werte von einer Funktion in die nächste
> und übernächste zu retten ohne zig hin und her Geschiebe.

Das hat damit wenig zu tun.
Dafür hast du ja globale Variablen eingeführt.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm doch einfach das void main()
void main(void){         // Mainloop

  UBRRL = takt / (8 * baud3) -1;
  UCSRB = (1<<RXEN)|(1<<TXEN)|(1<< RXCIE);
  UCSRC =   (1 << URSEL)|(1<<UCSZ1)|(1<<UCSZ0);

und setzte es hier
 ...
      PORTD |= 0b00100000;            // Ras = 1
      PORTD |= 0b01000000;            // Cas = 1
      DDRA = 0b00000000;
  }
  
void main(void){         // Mainloop

  UBRRL = takt / (8 * baud3) -1;
  UCSRB = (1<<RXEN)|(1<<TXEN)|(1<< RXCIE);
  UCSRC =   (1 << URSEL)|(1<<UCSZ1)|(1<<UCSZ0);

  // SPI initialisieren
  DDRB=(1 << DDB7) | (1 << DDB5) | (1 << DDB4) | (1 << DDB3)| (1 << DDB2) | (1 << DDB1) | (1 << DDB0);
  SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0) | (1 << CPHA);     // SPI ein, MSB first, Clock / 4
  
  PORTB |= (1 << PB0) | (1 << PB2);     // A = 1  Portb.0 , Cs1 = 1  Portb.2
  PORTB &= ~((1 << PB1) | (1 << PB3));  // Cs2 = 0  Portb.3 , Res = 0  Portb.1
  
  Wait(1);                 // warte 1 Sekunde

wieder ein.
Dann sind wir zunächst mal in diesem Punkt auf Standard C

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
check, hab ich gemacht.

das void main(void) hab ich auch gleich in
int main (void)
gewandelt, aber der
Simulator streikt nochimmer.

Ach so, SP4 hab ich natürlich installiert versteht sich.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ooops.
Hab nicht mitgekriegt, dass du schon ein neues Zip
gemacht hast. Sorry.

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die == in <
und Mainloop nach hinten.
Ist auch schon beim vor oder vorvorletzten Posting von mir als Anhang.

im Übrigen schonmal vielen Dank für die tatkräftige Unterstützung.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du die ISR auskommentierst, musst du auch die Interrupt
Freigabe

  UCSRB = (1<<RXEN)|(1<<TXEN)|(1<< RXCIE);

rausnehmen. Ansonsten kommts beim ersten RXCIE Interrupt
zu einem Reset.
Ist aber auch nicht das Problem im Simulator.

Wie weit kommst du noch mal im Simulator, wenn du mittels
F11 durchsteppst?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast hier
void ms1 (void) {              // Wartefunktion
  unsigned int i;            // Lokale Variable deklarieren
  for (i = 0x00; 1<takt/6000; i++){  // warte ca. 1 ms
  }
}

eine Endlosschleife

  1 < takt/6000

ist eine Konstante.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ditto

void us1 (void) {              // Wartefunktion
  unsigned int i;            // Lokale Variable deklarieren
  for ( i = 0x00; 1<takt/6000000; i++){
  }    // warte ca. 1 ms
}

  

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
huch, Tippfehler, Danke !!!!

Tja bis zum durchsteppen komm ich garnicht.
Sobald ich den Simulator starte hauts das
Studio mit Runtime Error raus seltsamerweise.
Das kam als ich die Interruptroutine einbaute
aber ist nicht mehr gegangen nachdem ich sie
auskommentierte.

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab dann mal probiert
n neues Projekt im Studio anzulegen und hab dann den Code
per Copy and Paste ins neue Projekt kopiert.
Die Fehlermeldung ist mit dem Code reproduzierbar bei
mir auf 3 verschiedenen Systemen.
Irgendwas am Code mag der Simulator definitiv nicht.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
2 Möglichkeiten:
* Den Source Code abspecken, bis es wieder geht.
  Im Extremfall kommentierst du alles bis auf

  int main()
  {
  }

  aus. Das muss auf jeden Fall wieder gehen.
  Danach beginnst du Teile wieder einzukommentieren.
  In kleinen Happen

* Wenn dir allerdings der Simulator schon beim Starten
  abschmiert, habe ich den starken Verdacht, dass inzwischen
  die Projektkonfiguration vom AVR-Studio selbst gelitten hat.
  Ich würde mal ein neues Projekt anfangen und dort den
  Code in kleinen Happen einbauen.

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo und vielen Dank für Eure Unterstützung,
ich hab den Code dann in nem neuen Projekt Stück für Stück
eingefügt und irgendwie gings dann wieder ... warum auch
immer.
Nebenbei habt Ihr mir geholfen n paar haarige Bugs raus zu
filtern, vielen herzlichen Dank

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:

> Was irgendwelche Compiler machen oder auch nicht, ist mir
> ehrlich gesagt egal. Mich interessiert was im C-Sprachstandard
> normiert ist. Das gilt. Auf diese Funktionalität kann ich
> mich verlassen.

Es ist eine dokumentierte C-Spracherweiterung des GCC.  Vermutlich
war die Funktionalität auf Grund das Pascal-Frontends sowieso nötig.

Allerdings ist mir so, dass diese Funktionalität für das AVR-Target
möglicherweise buggy sein könnte, wenngleich ich mich gerade nicht
genau daran erinnern kann, was der Grund dafür ist.

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.