Forum: Compiler & IDEs Problem beim Portieren eines Projektes


von Marko (Gast)


Angehängte Dateien:

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

von Thomas (Gast)


Lesenswert?

> Beim umcoden hab ich verschiedene Befehle von Bascom in C nachgebildet

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

von Karl H. (kbuchegg)


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.

von Karl H. (kbuchegg)


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.

von Marko (Gast)


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.Ä..

von Marko (Gast)


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.

von Karl H. (kbuchegg)


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.


von Sven (Gast)


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....

von Sven (Gast)


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....

von Thomas B. (yahp) Benutzerseite


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.

von Marko (Gast)


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

von Sven (Gast)


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.....

von Karl H. (kbuchegg)


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.

von Rahul, der Trollige (Gast)


Lesenswert?

>In Pascal vielleicht :-)

Ja, geht...

von Marko (Gast)


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?

von Karl H. (kbuchegg)


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.

von Marko (Gast)


Angehängte Dateien:

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.

von Marko (Gast)


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.

von Funktion (Gast)


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.

von Karl H. (kbuchegg)


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.

von Karl H. (kbuchegg)


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.

von Karl H. (kbuchegg)


Lesenswert?

Nimm doch einfach das void main()
1
void main(void){         // Mainloop
2
3
  UBRRL = takt / (8 * baud3) -1;
4
  UCSRB = (1<<RXEN)|(1<<TXEN)|(1<< RXCIE);
5
  UCSRC =   (1 << URSEL)|(1<<UCSZ1)|(1<<UCSZ0);

und setzte es hier
1
 ...
2
      PORTD |= 0b00100000;            // Ras = 1
3
      PORTD |= 0b01000000;            // Cas = 1
4
      DDRA = 0b00000000;
5
  }
6
  
7
void main(void){         // Mainloop
8
9
  UBRRL = takt / (8 * baud3) -1;
10
  UCSRB = (1<<RXEN)|(1<<TXEN)|(1<< RXCIE);
11
  UCSRC =   (1 << URSEL)|(1<<UCSZ1)|(1<<UCSZ0);
12
13
  // SPI initialisieren
14
  DDRB=(1 << DDB7) | (1 << DDB5) | (1 << DDB4) | (1 << DDB3)| (1 << DDB2) | (1 << DDB1) | (1 << DDB0);
15
  SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0) | (1 << CPHA);     // SPI ein, MSB first, Clock / 4
16
  
17
  PORTB |= (1 << PB0) | (1 << PB2);     // A = 1  Portb.0 , Cs1 = 1  Portb.2
18
  PORTB &= ~((1 << PB1) | (1 << PB3));  // Cs2 = 0  Portb.3 , Res = 0  Portb.1
19
  
20
  Wait(1);                 // warte 1 Sekunde

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

von Marko (Gast)


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.

von Karl H. (kbuchegg)


Lesenswert?

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

von Marko (Gast)


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.

von Karl H. (kbuchegg)


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?

von Karl H. (kbuchegg)


Lesenswert?

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

eine Endlosschleife

  1 < takt/6000

ist eine Konstante.

von Karl H. (kbuchegg)


Lesenswert?

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

  

von Marko (Gast)


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.

von Marko (Gast)


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.

von Karl H. (kbuchegg)


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.

von Marko (Gast)


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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.