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
> Beim umcoden hab ich verschiedene Befehle von Bascom in C nachgebildet
Vergleiche gut programmiertes Basicprogramm gegen schlecht
programmiertes C-Programm? Sehr sinnvoll.
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.
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.
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.Ä..
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.
> 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: 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....
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....
> 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.
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
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.....
>>> 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.
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?
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.
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.
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.
@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.
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.
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.
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
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.
Ooops. Hab nicht mitgekriegt, dass du schon ein neues Zip gemacht hast. Sorry.
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.
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?
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.
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 | }
|
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.
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.
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.
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.