Hallo, Mein Programm setzt alle Variablen, die ich in einer If-Bedingung setze, damit andere if Bedingung beim erneuten Durchlauf der while-Schleife durchlaufen werden, jedes mal zu Beginn der while-Schleife auf 0. Damit keine andere Funktion auf die Variable zugreift habe ich eine Testvariable deklariert und setze diese einmal in meinem Programm auf 1 und verändere diese anschließend nicht mehr. Trotzdem wird auch diese immer wieder auf 0 gesetzt. Ob diese Variable überhaupt gesetzt wurde hab ich mit dem Debugger bereits überprüft. Woran kann es liegen, dass meine Variablen jedes mal auf 0 gesetzt werden? Gruß Lisa
:
Gesperrt durch Moderator
Lisa schrieb: > Woran kann es liegen, dass meine Variablen jedes mal auf 0 gesetzt > werden? Sehr wahrscheinlich am nicht geposteten Programm in Zeile 42.
Fehler in Zeile 42. Im Debugger Watchpoint auf die Variable setzen und damit die Stelle mit dem Buffer Overflow oder dangling Pointer finden, die wild in den Speicher schreibt.
Dr. Sommer schrieb: > Im Debugger Watchpoint auf die Variable setzen Sowas modernes hat nicht jeder µC in der Featureliste. Und der OP schrieb nix zur Umgebung oder dem verwendeten Controller. Noch besser wäre allerdings das konkrete Programm geeignet zur Fehlersuche, meine Glaskugel ist in Reparatur.
Vielleicht hilft es auch, die Variablen außerhalb der while-Schleife zu deklarieren. Sonst werden sie bei jedem Durchlauf neu angelegt und damit auch initialisiert.
Hallo Lisa, was meine Vorposter meinen, ist dass du mal dein Programm posten solltest. Dann ist der Fehler einfacher zu finden. Gruß, Knut.
Tut mir leid, dass ich das Programm nicht hier reinschreiben darf, da ich in einem Unternehmen meine Bachelorarbeit schreibe und anschließend dann wahrscheinlich meinen eigenen Code zitieren muss, da er bereits im Internet steht. Ich habe gehofft, dass es vielleicht ein gängiges Problem ist, welches ich nicht kenne. Die Programmierung von Microcontrollern ist für mich Neuland. Ich kann es einmal mit Beschreibung des Codes probieren, die für die Variable relevant sind. Variablendeklaration global Eine ISR empfängt Zeichen und speichert die in einem String
1 | int main () |
2 | {
|
3 | while (true) |
4 | {
|
5 | if( Neue Zeichenkette wurde empfangen) |
6 | {
|
7 | if (r=1) |
8 | Schalte die LED ein; |
9 | if (erstes Zeichen der Zeichenkette = !) |
10 | r=1; |
11 | |
12 | }
|
13 | else
|
14 | //Sende Fehler
|
15 | |
16 | }
|
17 | }
|
Ungefähr so sieht das Programm aus. Die Bedingung r=1 wird nie aufgerufen.
Jim M. schrieb: > Und der OP schrieb nix zur Umgebung oder dem verwendeten Controller Ich verwende einen ATmega32A und programmiere den in AtmelStudio 7.0. Zum Debuggen verwende ich einen Atmel ICE über die JTAG Schnittstelle.
Kein Gast schrieb: >> if (r=1) Es sollte sicher if (r==1) heissen. Compilerwarnungen sollte man nicht missachten
:
Bearbeitet durch User
Ingo L. schrieb: > Dann liegt hier der Fehler vor Entschuldigung ich habe in der If Bedingung r==1 und nichr r=1 geschrieben.
Naja, dann ist doch der Fehler weiterhin offensichtlich: Ingo L. schrieb: > Dann liegt hier der Fehler vor
Beitrag #5184488 wurde vom Autor gelöscht.
Thomas E. schrieb: > Vielleicht hilft es auch, die Variablen außerhalb der while-Schleife zu > deklarieren. Sonst werden sie bei jedem Durchlauf neu angelegt und damit > auch initialisiert. Kennst du irgendeinen Compiler der das nicht auf jeder Einstellung wegoptimiert und nicht alles am Anfang der Funktion anlegt? Jim M. schrieb: > Sowas modernes hat nicht jeder µC in der Featureliste. Achja, man muss ja unbedingt alte Gammel-Technik nutzen. Zum Glück haben Cortex-M das. Solche Fehler sind selbst mit Code schwierig zu finden, ohne Code kann man das vergessen. Watchpoints, Valgrind (am PC) o.ä. können helfen. Ein scharfer Blick auf alle Array & Pointer-Zugriffe, ob da nur auf das richtige zugegriffen wird, ist auch eine gute Idee.
Ingo L. schrieb: > Es sollte sicher if (r==1) heissen. Compilerwarnungen sollte man nicht > missachten In meinem Orginalprogramm gibt es keine Compilerwarnungen, weshalb ich mittlerweile echt ratlos bin.
Lisa schrieb: > weshalb ich > mittlerweile echt ratlos bin. Dann zeig doch mal den vollständigen Code. Oft ist es eine Banalität die man selbst nicht sieht.
Lisa schrieb: > In meinem Orginalprogramm gibt es keine Compilerwarnungen Gib mal "-Wall -Wextra" an den Compiler, vielleicht kommen dann doch noch welche.
Dr. Sommer schrieb: > Solche Fehler sind selbst mit Code schwierig zu finden, ohne Code kann > man das vergessen. Watchpoints, Valgrind (am PC) o.ä. können helfen. Ein > scharfer Blick auf alle Array & Pointer-Zugriffe, ob da nur auf das > richtige zugegriffen wird, ist auch eine gute Idee. Vielen Dank, für diese Antwort. Verstehen tu ich diese auch, jedoch wie ich das genau mache und letzendlich die Zugriffe verändere weiß ich nicht, aber ich kann ja in diese Richtung mich nun weiter informieren.
Ingo L. schrieb: > Dann zeig doch mal den vollständigen Code. Oft ist es eine Banalität die > man selbst nicht sieht. Ich würde gern den kompletten Code posten, jedoch findet auch mein Professor diesen dann im Internet und kann diesen nicht mir zuordnen, weshalb dieser dann denkt, ich hätte ihn nur kopiert.
Stichworte: 1. volatile 2. ATOMIC Der Compiler setzt Variablen beim Programmstart auf 0. Vielleicht folgt ein Reset, dem Anderen. Ansonsten halte auch ich es für sehr schwierig einen Fehler in einem unsichtbaren Code zu finden und zu beheben.
Arduino F. schrieb: > Der Compiler setzt Variablen beim Programmstart auf 0. Nur globale und statische. Arduino F. schrieb: > Vielleicht folgt ein Reset, dem Anderen. Einem Reset folgt automatisch eine Neu-Initialisierung durch die C-Library.
Lisa schrieb: > Ingo L. schrieb: >> Dann liegt hier der Fehler vor > > Entschuldigung ich habe in der If Bedingung r==1 und nichr r=1 > geschrieben. Genau deswegen sollst du dein Programm zeigen. Und zwar genau(!) das Programm, das das fehlerhafte Verhalten zeigt. Wenn du das nicht kannst oder willst, dann können wir dir nicht helfen. Die Chancen stehen 99:1 daß du da irgendwo einen Tippfehler ähnlich wie oben untergebracht hast.
Lisa schrieb: > Tut mir leid, dass ich das Programm nicht hier reinschreiben darf, da > ich in einem Unternehmen meine Bachelorarbeit schreibe Frag deine Hochschul- und Unternehmensbetreuer nach Rat wenn du nicht weiterkommst. Wenn die dir nicht helfen können/wollen, frag (schriftlich!) ob du im Internet fragen und dabei den Code zeigen darfst.
Dr. Sommer schrieb: > Frag deine Hochschul- und Unternehmensbetreuer nach Rat wenn du nicht > weiterkommst. Wenn die dir nicht helfen können/wollen, frag > (schriftlich!) ob du im Internet fragen und dabei den Code zeigen > darfst. Mein Betreuer konnte bisher auch nicht helfen, weshalb die schriftliche Genehmigung wohl der nächste Schritt sein wird. Bisher hatte ich die Hoffnung dass es vielleicht ein Problem ist, welches schon häufiger vorgekommen ist, sodass auch ohne Programm eine mögliche Lösung gefunden wird. Danke an alle die trotz meiner gebundenen Hände versucht haben zu helfen.
Dr. Sommer schrieb: > Gib mal "-Wall -Wextra" an den Compiler, vielleicht kommen dann doch > noch welche. Beherzige das wenigstens. Kann etwas nerven, die wichtigen Warnungen von unwichtigen zu unterscheiden, aber es schadet auch nichts, alle Warnungen zu beseitigen. Besonders verdächtig sind in deinem Fall Dinge wie 'possibly unwanted assigment in <Zeile>)'
:
Bearbeitet durch User
Matthias S. schrieb: > Kann etwas nerven, die wichtigen Warnungen von > unwichtigen zu unterscheiden, aber es schadet auch nichts, alle > Warnungen zu beseitigen. Ich würde sogar grundsätzlich immer alle Warnungen durch Code-Korrekturen beseitigen, damit die wichtigen Warnungen nicht zwischen den unwichtigen untergehen, und weil "unwichtige" Warnungen auch auf zukünftige potentielle Problem hindeuten können. Wenn man's ernt mein nimmt man noch "-pedantic"...
In Zeile 42 sieht man, dass dein Interrupt falsch benannt ist. Somit springt dein Programm da nie rein, sondern macht ein Reset. Außerdem musst Du daran denken, dass r auch als volatile deklariert ist.
Dr. Sommer schrieb: > Gib mal "-Wall -Wextra" an den Compiler, vielleicht kommen dann doch > noch welche. Matthias S. schrieb: > Beherzige das wenigstens. Ich habe das damit probiert und bekomme leider immernoch keine Fehler.
Lisa schrieb: > Ich habe das damit probiert und bekomme leider immernoch keine Fehler. Auch keine Warnungen? Es kompiliert ja trotz Warnungen, die muss man explizit anschauen. schreib einfach mal "7;" in deine main(), das sollte die Warnung "statement with no effect" provozieren. Da wo das steht könnten noch mehr Warnungen stehen.
Lisa schrieb: > Tut mir leid, dass ich das Programm nicht hier reinschreiben darf Dann mach einen Dreizeiler, der das selbe Problem hat. Den kann man anschließend untersuchen. So wie das jetzt läuft ist es nur eine brotlose Raterei. Ich könnte jetzt sicher auch ein paar Tipps geben, die auch nicht weiterhelfen... Lisa schrieb: > Ich habe das damit probiert und bekomme leider immernoch keine Fehler. Aber Warnungen?
Wenn r ein Flag ist und in der ISR gesetzt wird, um main() was mitzuteilen, sollte r wirklich als 'volatile' erklärt werden, weil sonst der Compiler dazu verleitet wird, r evtl. weg zu optimieren. Apropos Optimierung, wie stehen denn da die Optionen?
Dr. Sommer schrieb: > Auch keine Warnungen? Lothar M. schrieb: > Aber Warnungen? Nein auch keine Warnungen. Die hab ich bisher auch immer direkt beseitigt. Lothar M. schrieb: > Dann mach einen Dreizeiler, der das selbe Problem hat. Das versuche ich nun mal. Gib mir jedoch 15 min :)
Werden die Variablen in den Schleifen zweimal neu definiert? Diesen Fehler nehme ich gern.
Lutz H. schrieb: > Werden die Variablen in den Schleifen zweimal neu definiert? Nein nur einmal global als volatile int
Dr. Sommer schrieb: > Kennst du irgendeinen Compiler der das nicht auf jeder Einstellung > wegoptimiert und nicht alles am Anfang der Funktion anlegt? Ja, der ARM-Compiler von Keil z.B. Wenn ich da eine Variable am Anfang einer while-Schleife deklariere, wird die auch nur dort angelegt und nicht am Anfang der Funktion. @Lisa: ich vermute, Du musst Deine ggf. in der ISR veränderten Variablen (hier: "r"?) zusätzlich als "volatile" deklarieren, sonst kriegt das main()-Programm nicht mit, wenn die ISR die Variable verändert!
Thomas E. schrieb: > zusätzlich als "volatile" deklarieren Ich habe bereits alle Variablen als volatile deklariert, die in der ISR oder auch in anderen Funktionen verändert werden. Kann das auch das Problem sein?
Nogger schrieb: > Das sollte als Suchbegriff ausreichen. Und das deckt auch Dinge wie Buffer Overflows, Strict Aliasing, Dangling Pointers ab, welche typischer Ursachen für derartiges Verhalten sind? Thomas E. schrieb: > Ja, der ARM-Compiler von Keil z.B. Wenn ich da eine Variable am Anfang > einer while-Schleife deklariere, wird die auch nur dort angelegt und > nicht am Anfang der Funktion. Interessant, kannst du dafür ein Beispiel zeigen? z.B. wie das optimiert wird:
1 | void test2 (int a) { |
2 | printf ("%d\n", a); |
3 | }
|
4 | void test () { |
5 | int a = 0; |
6 | while (a < 100) { |
7 | int b = 7; |
8 | test2 (a + b); |
9 | }
|
10 | }
|
Der GCC macht daraus:
1 | c: b508 push {r3, lr} |
2 | e: 2007 movs r0, #7 |
3 | 10: f7ff fffe bl 0 <test2> |
4 | 14: e7fb b.n e <test+0x2> |
5 | 16: bf00 nop |
Die Variable verschwindet hier sogar komplett. In Fällen wo sie nicht verschwindet, wird sie sich wohl zwischendurch ändern, und dann ist die Neu-Initialisierung sowieso erforderlich.
Lisa schrieb: > Lothar M. schrieb: >> Dann mach einen Dreizeiler, der das selbe Problem hat. > > Das versuche ich nun mal. Gib mir jedoch 15 min :) Ich brauche für ein neues ähnliches Programm doch länger, da mein Orginal Programm schon viele einzele Kleinigkeiten beachtet, sodass umbenennen und rauslöschen sich nicht als einfach erweist.
Lisa schrieb: > Eine ISR empfängt Zeichen und speichert die in einem String --> volatile (nicht, daß das nicht schon mehrfach erwähnt worden wäre)
Lisa schrieb: > Ich brauche für ein neues ähnliches Programm doch länger Hatte ich erwartet. > da mein Orginal Programm schon viele einzele Kleinigkeiten beachtet, > sodass umbenennen und rauslöschen sich nicht als einfach erweist. Und der Nebeneffekt dieser Arbeit könnte sein, dass du den Fehler ganz allein findest...
Schreib den relevanten Programmteil - isr, main, ggf. Unterfunktionen - neu und stell ihn hier ein. Das hilft erstens bei der Kontrolle der eigenen Gedankengänge, ist zweitens vermutlich ohnehin erforderlich und führt drittens mit einiger Wahrscheinlichkeit zur Problemlösung.
Dr. Sommer schrieb: > Die Variable verschwindet hier sogar komplett. In Fällen wo sie nicht > verschwindet, wird sie sich wohl zwischendurch ändern, und dann ist die > Neu-Initialisierung sowieso erforderlich. Wenn die Variable am Anfang der while-Schleife deklariert und auch initialisiert wird, ist eh klar, daß sie bei jedem Schleifendurchlauf wieder neu initialisiert wird. Ich meinte aber eher sowas wie hier:
1 | while(1) |
2 | {
|
3 | int test; |
4 | if(test&0x80) |
5 | GPIO_ResetBits(GPIOB, GPIO_Pin_5); |
6 | else
|
7 | GPIO_SetBits(GPIOB, GPIO_Pin_5); |
8 | test++; |
9 | }
|
Man könnte meinen, daß der Port alle 128 Schleifendurchläufe getoggled wird, das funktioniert aber nicht, bzw. nur manchmal, je nach Optimierungslevel!
Thomas E. schrieb: > Wenn die Variable am Anfang der while-Schleife deklariert und auch > initialisiert wird, ist eh klar, daß sie bei jedem Schleifendurchlauf > wieder neu initialisiert wird. Nur wenn sie überhaupt zwischendurch geändert wird, ansonsten wird sie als Konstante wegoptimiert. Thomas E. schrieb: > das funktioniert aber nicht, bzw. nur manchmal, je nach > Optimierungslevel! test ist nicht initialisiert, das ist einfach falscher Code, der wird halt kaputtoptimiert... GCC warnt da auch. Ich meinte sowas:
1 | while(1) |
2 | {
|
3 | int test = 0; |
4 | if(test&0x80) |
5 | GPIO_ResetBits(GPIOB, GPIO_Pin_5); |
6 | else
|
7 | GPIO_SetBits(GPIOB, GPIO_Pin_5); |
8 | }
|
sollte ein identisches Kompilat wie
1 | int test = 0; |
2 | while(1) |
3 | {
|
4 | if(test&0x80) |
5 | GPIO_ResetBits(GPIOB, GPIO_Pin_5); |
6 | else
|
7 | GPIO_SetBits(GPIOB, GPIO_Pin_5); |
8 | }
|
liefern (allerdings ein relativ witzloses).
Thomas E. schrieb: > das funktioniert aber nicht, bzw. nur manchmal, je nach Optimierungslevel! Aber sicher dann, wenn static mit ins Spiel kommt.
Lothar M. schrieb: > Aber sicher dann, wenn static mit ins Spiel kommt. Ja, dann wird's mit 0 initialisiert. Sonst wird /irgendein zufälliger Wert/ hineingeschrieben. Es gibt aber keine Garantie über die Verteilung der Zufallswerte, die können immer 0, oder immer 42, oder sonst irgendwas sein was da gerade im Prozessor&RAM herumliegt.
Dr. Sommer schrieb: > das ist einfach falscher Code, Das weiß ich doch! ich meinte ganz oben ja auch nur, daß Lisa evtl. eben genau solchen falschen Code geschrieben haben könnte (ihren "echten" Code kennen wir ja nicht...)
:
Bearbeitet durch User
Meine verschiedenen Testvariablen sind entweder direkt am Anfang in der Main deklariert oder als globale Variablen als volatile int. In der while(1) Schleife, die ja schließlich dauerhaft durchlaufen wird, werden sie an unterschiedlichen Stellen jeweils einmal in einer If- Bedingung aufgerufen und auf 1 gesetzt. Sobald die while Schleife jedoch das nächste mal durchläuft sind alle Variablen wieder auf 0 gesetzt und wenn ich es als char deklariere wieder auf den "Wert" den ich bei der Variablendeklaration festgelegt habe. Also da ja normalerweise die while (1) -Schleife nicht verlassen wird, dürfte sich der Wert doch nicht auf das ändern was oberhalb der while festgelegt wurde. Oder gibt es die Möglichkeit, dass aus irgendeinem Grund die while-Schleife verlassen wird und das Programm sich neu initialisiert?
Lisa schrieb: > Oder gibt es die Möglichkeit, dass aus irgendeinem Grund die > while-Schleife verlassen wird und das Programm sich neu initialisiert? Ja, z.B. - Interrupt ohne ISR - HW-Reset durch Störung auf der Reset-Leitung - Watchdog läuft ab
Benutze doch mal den Debugger, den Du hast. Setze z.B. Breakpoints oder nutze den Einzelschritt. Damit sollte sich die Stelle finden lassen, wo die Variablen nullgesetzt werden. Gruß Stefan
Hier ist die while Schleife. Ein paar definitiv nicht relevante Teile habe ich rausgelassen. Die Variable "test" wurde global als volatile int definiert. Beim debuggen von Zeile zu Zeile habe ich festgestellt, dass ide Variable in der while gesetzt wird, jedoch sobald die while Schleife oben wieder beginnt wieder auf 0 gesetzt wird. Auch die Variablen get, set, und status werden nach jedem Durchlauf auf 0 gesetzt.
1 | while (1) |
2 | {
|
3 | if (complete && start == 1 ) //Überprüfen ob kompletter String erhalten wurde |
4 | {
|
5 | |
6 | str_len=0; |
7 | //Länge des Strings zählen
|
8 | while(rx_str[str_len]!='\0') |
9 | {
|
10 | str_len++; |
11 | test=1; |
12 | }
|
13 | |
14 | if (rx_str[0]=='!') |
15 | {...}
|
16 | |
17 | else if (rx_str[0]=='R') |
18 | {
|
19 | if (status==0) |
20 | {
|
21 | ...
|
22 | if (get == 1) |
23 | {
|
24 | set_relais(); |
25 | set=1; |
26 | }
|
27 | |
28 | }
|
29 | |
30 | }
|
31 | |
32 | else if (rx_str[0]=='S') |
33 | {
|
34 | if (set == 1) |
35 | {
|
36 | status = get_status ((char*)rx_str,str_len); |
37 | |
38 | if (status==1) |
39 | {
|
40 | Transmits ("901"); |
41 | }
|
42 | else
|
43 | Transmits ("902"); |
44 | }
|
45 | else
|
46 | {
|
47 | status=0; |
48 | Transmits("906"); |
49 | }
|
50 | }
|
51 | |
52 | Transmits("END"); |
53 | start=0; |
54 | |
55 | }
|
56 | else
|
57 | {
|
58 | if (status==1) |
59 | {
|
60 | PORTB &= ~(1<<PORTB4); |
61 | while (n<1) |
62 | {
|
63 | Transmits("905"); |
64 | n++; |
65 | }
|
66 | }
|
67 | |
68 | else
|
69 | {
|
70 | PORTB |= (1<<PORTB4); |
71 | n=0; |
72 | }
|
73 | }
|
R. M. schrieb: > sicher das der String nullterminiert ist ? Ja da bin ich mir recht sicher, da alles andere in meinem Programm funktioniert, also die entsprechenen Funktionen aufgerufen werden. Ich setze in meiner ISR sobald ich ein \n oder \r erhalten habe das \0. Und beim Debuggen wurde auch angezeigt, dass die Variable auf 1 gesetzt wurde.
Viktor B. schrieb: > In der geposteten While-Schleife fehlt eine }, kann das sein? Ja das ist gut möglich. Hab im richtigen Programm nachgezählt und da passt es.
Ich würde als erstes ausschliessen das der Fehler nicht in der while Loop liegt. z.B. die ISR ganz ausschalten. in den rx_str buffer etwas sinnvolles schreiben (was das musst du wissen) und dann im Einzelschritt die while Loop debuggen.
R. M. schrieb: > Ich würde als erstes ausschliessen das der Fehler nicht in der while > Loop > liegt. Danke, das werde ich morgen versuchen. Jetzt habe ich leider erst noch ein Meeting.
Lisa schrieb: > Die Variable "test" wurde global als volatile int definiert. Welchen Sinn hat diese Variable? Die wird ja nur 1x auf 1 gesetzt und sie wird nirgends verwendet... > Hier ist die while Schleife. Ein paar definitiv nicht relevante Teile > habe ich rausgelassen. Die Variable "test" wurde global als volatile int > definiert. Beim debuggen von Zeile zu Zeile habe ich festgestellt, dass > ide Variable in der while gesetzt wird Genau mit diesem Code? Denn das soll der Sinn des "Dreizeilers" sein: dass dort in wenigen Zeilen nachvollziehbar der Fehler mit drin sitzt.
:
Bearbeitet durch Moderator
Lisa schrieb: > werden sie an unterschiedlichen Stellen jeweils einmal in einer If- > Bedingung aufgerufen und auf 1 gesetzt Ist denn die if-Bedingung überhaupt erfüllt? Nicht dass doe Variablen gar nicht gesetzt werden....
Hi Lisa schrieb: > beim Debuggen wurde auch angezeigt, dass die Variable auf 1 gesetzt > wurde. Liest sich so, daß die 'test'-Variable auf 1 gesetzt wird. Wenn das Problem in diesem Code ebenfalls auftritt, dürfte dort keine Klammer fehlen, da der Code ja compiliert und geprüft wurde, wo der erneut auftretende Fehler erkannt wurde. Da doch eine Klammer fehlt, wurde irgendwo 'geschludert' ;) Nutzt Du 'test' noch irgendwo anders? Funkt dort vll. immer ein Timer-Interrupt dazwischen, der Test immer wieder auf Null setzt? MfG
Guten Morgen, Lothar M. schrieb: > Genau mit diesem Code? Nein ich habe das nicht genau mit diesem Code gemacht. Ich habe bei dem Code den ich gepostet habe Funktionsaufrufe gelöscht, von void-Funktionen, die definitiv nicht relevant sind, da dort beispielsweise nur der String ausgegeben oder verarbeitet wird, aber nicht auf die Variablen zugegriffen wird, die sich jedes mal auf 0 setzen. Patrick J. schrieb: > Nutzt Du 'test' noch irgendwo anders? die Variable "test" habe ich nur ergänzt, damit ich eine Variable habe, die in keinem anderen Teil des Programms verwendet wird, damit ich aussichließen kann, dass die irgendwo von meinem Programm aus auf 0 gesetzt wird. Ich habe heute morgen oberhalb der while Funktion eine Textausgabe hinzugefügt, die scheinbar die ganze Zeit ausgegeben wird, obwohl sie in keiner while Funktion steht. Warum startet mein Programm denn ständig neu? Kann das auch ein Hardwarefehler sein?
Lisa schrieb: > Kann das auch ein Hardwarefehler sein? Wenn man denn die Hardware kennen würde. Relevanten Teil des Programms für sichere Hardware - z.B. M328 uno - umschreiben und testen.
grundschüler schrieb: > Wenn man denn die Hardware kennen würde Ich benutze einen ATmega32A, von dem ich die Beschaltung selbst nach Datenblatt entworfen habe.
Lisa schrieb: > Warum startet mein Programm denn ständig neu? Hast du einen Interrupt aktiviert, ohne Interrupt Service Routine dazu zu haben?
Läuft deine Variable vielleicht über? 1+1, 2+1, 3+1....254+1, 255+1, 0+1.... oder vielleicht erst bei 65535?
Lisa schrieb: > Warum startet mein Programm denn ständig neu? Die gängigsten Fußangeln: - Watchdog aktiv - Interrupt Service Routine mit falschem Namen (und Warnung übersehen) - return() in main()
Georg G. schrieb: > - return() in main() Ziemlich unwahrscheinlich. Ein AVR klebt in einer Endlosschleife, sobald main per return verlassen wird.
Ich habe die Lösung nun gefunden.
Mein Programm hatte Probleme damit, dass alle ISR aktiviert werden durch
die sei() Funktion. Ich kenne die Aktivierung von meiner Hochschule und
in den Programmen hat das auch immer funktioniert. So wie ich das
verstanden habe verhindert eine Ergänzung um folgende ISR, dass ständig
ein "Reset" ausgefürt wird und mein Programm, inkl. Initialisierungen,
neu gestartet wird.
ISR(BADISR_vect)
{
}
Danke nochmal für die vielen Tipps, die letzendlich zur Lösung führten.
Lisa schrieb: > Ich habe die Lösung nun gefunden. Deine Lösung doktert nur an den Symptomen und behebt nicht die eigentliche Ursache: Das avrlibc-Manual sagt zu BADISR_vect: "This is a vector which is aliased to __vector_default, the vector executed when an ISR fires with no accompanying ISR handler. This may be used along with the ISR() macro to create a catch-all for undefined but used ISRs for debugging purposes." > Mein Programm hatte Probleme damit, dass alle ISR aktiviert werden durch > die sei() Funktion. sei() alleine bewirkt erstmal nur, dass die von Dir vorher aktivierten Interrupts freigeschaltet werden. Wenn Du vorher keine Interrupts aktiviert hast, bewirkt sei() überhaupt nichts. Fazit: Du musst für sämtliche aktivierten Interrupts auch eine ISR() definieren. Entweder hast Du da zu viele Interrupts versehentlich aktiviert oder Du hast mindestens eine ISR() vergessen. Mit der Definition von ISR(BADISR_vect) verdeckst Du nur den Fehler.
:
Bearbeitet durch Moderator
Lisa schrieb: > Mein Programm hatte Probleme damit, dass alle ISR aktiviert werden durch > die sei() Funktion. Mit sei() (global interrupt enable) werden nicht alle Interrupts aktiviert, sondern nur freigeschaltete. Um einen Interrupt zu aktivieren, muss noch zusätzlich jeder einzelne freigegeben werden und dann auch eine ISR haben. Z.B.: WDIE für den Watchdog Interrupt PCIE für den Pin Change Interrupt usw. Du hast also irgendwo so ein IE für einen einzelnen Interrupt aktiviert, aber keine ISR dazu installiert.
Das hab ich noch nicht ganz verstanden. Wo aktiviere ich genau die
Interrupts?
Das Folgende steht in meinem Code, was mit Interrupts zu tun hat.
#include <avr/interrupt.h>
ISR (USART_RXC_vect)
{
...
}
und das
sei()
in der Main
Frank M. schrieb: > Mit der Definition von ISR(BADISR_vect) verdeckst Du nur den Fehler. Ich gehe sogar noch weiter, weil das Programm ja offenbar zu Deiner Bachelor-Arbeit gehört: Wenn ein Prüfer Deine "Lösung" liest und weiß, dass BADISR_vect nur eine Notlösung ist, um einen Programmfehler zu kaschieren, dann wirkt sich das gewiss negativ auf die Bewertung Deiner Arbeit aus. Ich persönlich als Leser so eines Codes würde jedenfalls sofort denken: "Da weiß einer nicht, was er macht".
Langsam keimt in mir der Verdacht es geht um eine Batchelorarbeit in Kunst.
Frank M. schrieb: > "Da weiß einer nicht, was er macht" Ja das kann ich verstehen und so wirklich weiß ich mittlerweile wirklich nicht mehr was ich da mache. Bin gerade dabei nochmal im Datenblatt zu lesen, ob ich da etwas finde, was mir beim Verständis hilft.
Lisa schrieb: > Das hab ich noch nicht ganz verstanden. Wo aktiviere ich genau die > Interrupts? > Das Folgende steht in meinem Code, was mit Interrupts zu tun hat. > #include <avr/interrupt.h> > ISR (USART_RXC_vect) > { > ... > } Den USART_RXC-Interrupt aktivierst Du mit dem Setzen des RXCIE0-Bits im USART Control-and-Status Register B – UCSRB. Suche mal danach in Deinem Code! :-) Aber dafür hast Du ja eine ISR definiert. Irgendwo hast Du noch einen weiteren Interrupt versehentlich aktiviert - vermutlich durch Kupfern irgendwelcher anderen Initialisierungsroutinen.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Aber dafür hast Du ja eine ISR definiert. Irgendwo hast Du noch einen > weiteren Interrupt versehentlich aktiviert - vermutlich durch Kupfern > irgendwelcher anderen Initialisierungsroutinen. Pfui, wird hier angedeutet diese Koryphäe würde Code per Copy&Paste übernehmen?
Frank M. schrieb: > Den USART_RXC-Interrupt aktivierst Du mit dem Setzen des RXCIE0-Bits im > USART Control-and-Status Register B – UCSRB. Suche mal danach in Deinem > Code! :-) > > Aber dafür hast Du ja eine ISR. Irgendwo hast Du noch einen weiteren > Interrupt versehentlich aktiviert - vermutlich durch Kupfern > irgendwelcher anderen Initialisierungsroutinen. Danke, das hat geholfen, wo cih genau suchen muss! Jetzt habe ich den Fehler. Ich habe den TX-Interrupt ausversehen mit aktiviert.
Lisa schrieb: > Bin gerade dabei nochmal im Datenblatt zu lesen Du solltest eher mal allgeime Grundlagen zur µC Programmierung lesen. Damit ich hier nicht nur dumm rumschwalle: Lisa schrieb: > Das hab ich noch nicht ganz verstanden. Wo aktiviere ich genau die > Interrupts? https://www.mikrocontroller.net/articles/AVR-Tutorial:_Interrupts https://www.mikrocontroller.net/articles/Interrupt http://www.avr-tutorials.com/interrupts/about-avr-8-bit-microcontrollers-interrupts Oder als Stichworte: "interrupt enable register"
Hier die Interrupt-Vektor-Tabelle eines ATmega32:
1 | $000 jmp RESET ; Reset Handler |
2 | $002 jmp EXT_INT0 ; IRQ0 Handler |
3 | $004 jmp EXT_INT1 ; IRQ1 Handler |
4 | $006 jmp EXT_INT2 ; IRQ2 Handler |
5 | $008 jmp TIM2_COMP ; Timer2 Compare Handler |
6 | $00A jmp TIM2_OVF ; Timer2 Overflow Handler |
7 | $00C jmp TIM1_CAPT ; Timer1 Capture Handler |
8 | $00E jmp TIM1_COMPA ; Timer1 CompareA Handler |
9 | $010 jmp TIM1_COMPB ; Timer1 CompareB Handler |
10 | $012 jmp TIM1_OVF ; Timer1 Overflow Handler |
11 | $014 jmp TIM0_COMP ; Timer0 Compare Handler |
12 | $016 jmp TIM0_OVF ; Timer0 Overflow Handler |
13 | $018 jmp SPI_STC ; SPI Transfer Complete Handler |
14 | $01A jmp USART_RXC ; USART RX Complete Handler |
15 | $01C jmp USART_UDRE ; UDR Empty Handler |
16 | $01E jmp USART_TXC ; USART TX Complete Handler |
17 | $020 jmp ADC ; ADC Conversion Complete Handler |
18 | $022 jmp EE_RDY ; EEPROM Ready Handler |
19 | $024 jmp ANA_COMP ; Analog Comparator Handler |
20 | $026 jmp TWI ; Two-wire Serial Interface Handler |
21 | $028 jmp SPM_RDY ; Store Program Memory Ready Handler |
22 | ; |
Einen dieser Interrupts aktivierst Du versehentlich. Ich tippe mal auf USART_TXC. Diesen aktivierst Du durch Setzen vom TXCIE-bit in UCSRB. Suche mal danach und kommentiere diese Stelle aus. Ebenso natürlich die Definition von BADISR_vect(). Wenn das Programm dann nicht mehr fortlaufend neustartet, hast Du die Ursache gefunden. EDIT: Gerade gelesen: Lisa schrieb: > Jetzt habe ich den Fehler. Ich habe den TX-Interrupt ausversehen mit > aktiviert. Da war mein Tipp ja goldrichtig :-) Denke daran, BADISR_vect() wieder rauszunehmen.
:
Bearbeitet durch Moderator
Lisa schrieb: > Das hab ich noch nicht ganz verstanden. Wo aktiviere ich genau die > Interrupts? Schau dir mal im DB die Tabelle "Interrupt Vectors in ATmega32" an. Das sind die möglichen Interrupts und für jeden gibt es ein Bit in einem Register, mit dem du ihn aktivieren kannst - im entsprechenden Abschnitt zu der Funktion beschrieben. Diese Bits heißen meist xxIE. Für USARTs sind z.B. drei Interrupts möglich (UDR, RXC, TXC). Wenn alle drei Bits im Register UCSRB aktiviert sind, dann müssen auch drei ISRs vorhanden sein.
So ich danke nun allen nochmal, die mir geholfen haben! DANKE! Leider waren auch viele dazwischen, die sich gerne darüber lustig machen, dass man etwas nicht so gut kann wie die Person selbst. Ich weiß selbst, dass Programmieren nicht meine Stärke ist, weshalb ich auch nicht Informatik studiere. Die Programmierung ist nicht meine Hauptaufgabe in der Bachelorarbeit. Zudem bin ich in einem Unternehmen, in dem die Programmierung normalerweise von externen Firmen übernommen wird, sodass ich hier leider nicht so viel Hilfe bekommen konnte. Ich bin schon stolz darauf, dass ich es geschafft habe überhaupt ein (bis auf den einen Fehler mit dem Interupt) funktionierendes Programm zu schreiben. Das war viel Arbeit mit Durcharbeiten der Tutorials und des Datenblattes, sodass es halt, wie gerade bei den Interrupts, dazu kommen konnte, dass ich ein Detail nicht mehr wusste. Denkt beim Schreiben auch mal daran, dass jeder seine Schwächen hat. Ich weiß welche ich habe, weshalb ich mich auch nicht von den Kommentaren habe entmutigen lasse, weiter zu machen. Schließlich funktioniert mein Programm jetzt, nachdem ich das eine Bit geändert habe :)
Lisa schrieb: > Leider waren auch viele dazwischen, die sich gerne darüber lustig > machen, dass man etwas nicht so gut kann wie die Person selbst. Ich weiß > selbst, dass Programmieren nicht meine Stärke ist, weshalb ich auch > nicht Informatik studiere. Die Programmierung ist nicht meine > Hauptaufgabe in der Bachelorarbeit. Was studierst du denn und was ist deine Hauptaufgabe? > Denkt beim Schreiben auch mal daran, dass jeder seine Schwächen hat. Ich > weiß welche ich habe, weshalb ich mich auch nicht von den Kommentaren > habe entmutigen lasse, weiter zu machen. Bevor mir hier die Tränen in die Augen schießen, denke ich bei solchen Kommentaren immer: Was wenn ein angehender Chirurg oder Pilot o.ä. diese Zeilen schreiben würde? Und ich vielleicht bald mal unter dessen Messer liege oder in dessen Flugzeug ich sitzen muss und dann verschwindet mein Mitleid plötzlich und wird durch große Wut ersetzt, denn anscheinend legt heute niemand mehr Wert auf WISSEN und KÖNNEN sondern man findet immer eine Ausrede warum jetzt gerade zufällig DAS EINE nicht so gut kann (obwohl man doch gerade eine Abschlussarbeit damit macht also so weit weg von der angestrebten Profession kann es nicht sein). Und dann fragt man sich wie schmal manche Leute ihr Fachgebiet definieren und ob es überhaupt einen Bereich gibt in dem ein exzellentes Verständnis der Materie und eine sichere Anwendung derselben gegeben sind. Oder ob einfach jede Aufgabe nicht 100% passt und man deshalb irgendwas hinschludert.
:
Bearbeitet durch User
Cyblord -. schrieb: > Und ich vielleicht bald mal unter dessen Messer liege oder in dessen > Flugzeug ich sitzen muss Hör mal auf zu heulen. Es wird nicht dazu kommen, dass ein Bachelor-Student Dich operieren wird oder das Flugzeug steuert, in dem Du sitzt. Von daher ist Deine Argumentation vollkommen überzogen.
Lisa schrieb: > Die Programmierung ist nicht meine Hauptaufgabe in der Bachelorarbeit. Ich wünsche Dir gutes Gelingen.
Frank M. schrieb: > Cyblord -. schrieb: >> Und ich vielleicht bald mal unter dessen Messer liege oder in dessen >> Flugzeug ich sitzen muss > > Hör mal auf zu heulen. Es wird nicht dazu kommen, dass ein > Bachelor-Student Dich operieren wird oder das Flugzeug steuert, in dem > Du sitzt. Von daher ist Deine Argumentation vollkommen überzogen. Aber was ein Vergleich ist, ist dir klar Frank oder? Schlag mal nach wenn nicht.
Sollte im Debugger nicht sofort auffallen dass da nicht einfach nur Variablen auf 0 gesetzt werden, sondern sich gleich der ganze Controller resettet? Das ergibt ja eine völlig andere Stelle an der man suchen muss...
Frank M. schrieb: > Lisa schrieb: >> Die Programmierung ist nicht meine Hauptaufgabe in der Bachelorarbeit. > > Ich wünsche Dir gutes Gelingen. Letze Worte des Passagiers an den Piloten kurz vorm einsteigen, nach dem der Pilot erklärt hat, Landungen seien nicht so seins, aber Starts gehen für voll Knorke.
:
Bearbeitet durch User
Frank M. schrieb: > Ich wünsche Dir gutes Gelingen. Danke! PS: Meine Hauptaufgabe war die Hardwareentwicklung
Cyblord -. schrieb: > Aber was ein Vergleich ist, ist dir klar Frank oder? Ja natürlich. Trotzdem musst Du zwischen einem angehendem Bachelor und einem fertig ausgebildeten Menschen durchaus unterscheiden. Ein angehender Bachelor ist in der Regel ein noch sehr junger Mensch, welcher in der Ausbildung ist und lernt. Und auch Du weisst, dass man beim Lernen Fehler machen kann (und auch muss!). Gerade durch die Fehler lernt man. Was ich Lisa hoch anrechne: Sie hat sich mit ihrer vermeintlichen "Lösung" der Definition von BADISR_vect() nach Erklärung unsererseits nicht zufriedengegeben, sondern hat versucht, den eigentlichen Fehler doch noch auszumerzen. Gerade das unterscheidet diejenigen, die sich im Leben durchbeißen von den Sesselpupsern, die später nichts auf die Reihe bekommen. Von daher sehe ich bei Lisa einer etwaigen Piloten- oder Chirurgen-Karriere gelassen entgegen.
Dr. Sommer schrieb: > Sollte im Debugger nicht sofort auffallen dass da nicht einfach nur > Variablen auf 0 gesetzt werden, sondern sich gleich der ganze Controller > resettet? Das ergibt ja eine völlig andere Stelle an der man suchen > muss... Leider war mir das beim Debuggen nicht aufgefallen, da ich in meiner Main nur eine while Schleife habe. Wahrscheinlich habe ich beim Debuggen auch etwas falsch gemacht.
Frank M. schrieb: > Ja natürlich. Trotzdem musst Du zwischen einem angehendem Bachelor und > einem fertig ausgebildeten Menschen durchaus unterscheiden. Naja es ist ein ABSCHLUSS. Natürlich bin ich der Meinung der Bachelor sollte das nicht sein, aber die Mehrheit hier sieht das doch meist anders. Also Fertig ist Fertig aus meiner Sicht. > Von daher sehe ich bei Lisa einer etwaigen Piloten- oder > Chirurgen-Karriere gelassen entgegen. Ich sehe das als ein Prinzip. Beim Chirurg wird's halt den meisten klar, aber natürlich sollte jeder gut und sorgfältig für seinen Beruf ausgebildet sein, egal ob nun direkt Menschenleben dranhängen oder nicht. Und gerade bei Ings. ist es doch nicht ganz unwahrscheinlich dass auch Sicherheitskritische Dinge entwickelt werden sollen. Von daher ist mir deine relativierende Haltung hier nicht ganz einleuchtend.
Lisa schrieb: > Leider war mir das beim Debuggen nicht aufgefallen, da ich in meiner > Main nur eine while Schleife habe. Hmm. Fürs nächste Mal: Benutz in solchen Fällen den Single-Instruction-Modus. Da sollte es beim Reset plötzlich in eine völlig andere Stelle springen, den Startup-Code, welcher eben die Variablen neu initialisiert.
Dr. Sommer schrieb: > Sollte im Debugger nicht sofort auffallen dass da nicht einfach nur > Variablen auf 0 gesetzt werden, sondern sich gleich der ganze Controller > resettet? Das ergibt ja eine völlig andere Stelle an der man suchen > muss... Ohne hier jemanden schlecht zu reden, aber einen Debugger muss man auch korrekt bedienen können. Ich persönliche gebe am Anfang immer eine Startup Message per UART aus. Das erleichtert das Leben deutlich. Wobei das eigentlich nicht mehr relevant ist, da ARMs eh immer im Hardfault landen. mfg
Cyblord -. schrieb: > und wird durch große Wut ersetzt ... > und man deshalb irgendwas hinschludert. Den Eindruck habe ich bei deinem Post insgesamt auch irgendwie. Aber es ist schön zu wissen, dass es einen sonst fehlerfreien Menschen gibt, der Anderen selbstverständlich laufend solche Vorhaltungen machen darf. Cyblord -. schrieb: > Aber was ein Vergleich ist, ist dir klar Frank oder? Aber nicht alles was hinkt ist automatisch gleich ein Vergleich... Lisa schrieb: > Lothar M. schrieb: >> Genau mit diesem Code? > Nein ich habe das nicht genau mit diesem Code gemacht. Ich habe bei dem > Code den ich gepostet habe Funktionsaufrufe gelöscht, von > void-Funktionen, die definitiv nicht relevant sind Es war mein Verdacht, dass diese im Code nicht sichtbaren Funktionen eben doch relevant sind. Und deshalb die Nachfrage nach einem kurzen Codeabschnitt, der den Fehler nachvollziehbar noch aufweist. Und deshalb mein Hinweis, dass du bei der Reduzierung des Programms auf diesen Dreizeiler den Fehler selber finden wirst. Nämlich genau in dem Augenblick, wo du die "eigentlich nicht relevante" Zeile herauslöschst, wo der einsprechende Interrupt aktiviert wird. BTW: ich hatte den Watchdog im Verdacht. Der kann solche laufenden Neustarts auch auslösen. Naja, knapp daneben... ;-)
Cyblord -. schrieb: > Frank M. schrieb: >> Ja natürlich. Trotzdem musst Du zwischen einem angehendem Bachelor und >> einem fertig ausgebildeten Menschen durchaus unterscheiden. > > Naja es ist ein ABSCHLUSS. Du solltest genauer lesen. Ein angehender Bachelor hat bis dato überhaupt keinen Abschluss. Nichts anderes habe ich die ganze Zeit geschrieben.
Lothar M. schrieb: > Cyblord -. schrieb: >> und wird durch große Wut ersetzt ... >> und man deshalb irgendwas hinschludert. > Den Eindruck habe ich bei deinem Post insgesamt auch irgendwie. Aber es > ist schön zu wissen, dass es einen sonst fehlerfreien Menschen gibt, der > Anderen selbstverständlich laufend solche Vorhaltungen machen darf. > > Cyblord -. schrieb: >> Aber was ein Vergleich ist, ist dir klar Frank oder? > Aber nicht alles was hinkt ist automatisch gleich ein Vergleich... Billige Polemik. Fällt dir nichts besseres ein? > Du solltest genauer lesen. Ein angehender Bachelor hat bis dato > überhaupt keinen Abschluss. Nichts anderes habe ich die ganze Zeit > geschrieben. Aber die Arbeit soll doch gerade der Nachweis für die Eignung und damit für den Abschluss sein.
:
Bearbeitet durch User
> Lisa .. >Danke! > >PS: Meine Hauptaufgabe war die Hardwareentwicklung > Die Firmware schreiben zu koennen gehoert zur Hardwareentwicklung. Egal wer auch immer was anderes eraehlt. Denn sonst steht man irgendwann an einer Stelle wo ein Fehler zwischen Hardware und Software hin und hergeschoben wird. Keiner findet ihn weil er denkt, der Andere hat den Fehler gemacht.
Lisa schrieb: > Leider waren auch viele dazwischen, die sich gerne darüber lustig > machen, dass man etwas nicht so gut kann wie die Person selbst. Naja, ich empfand das Bashing in diesem Thread sehr moderat - im Vergleich zu manch anderen Stellen hier im Forum. Wenn du hier unterwegs bist, darfst du nicht sehr empfindlich sein und brauchst dich erst recht nicht entmutigen zu lassen. Man muss ja nicht auf alles reagieren ... Mich hat sogar gewundert, dass du nicht härter angegangen wurdest, weil du den fehlerhafte Code nicht gepostet hast bzw. ein auf das Problem reduziertes Beispiel. Manche haben offenbar vergessen, dass sie auch mal angefangen haben und Fehler gemacht haben.
Cyblord -. schrieb: > > Aber die Arbeit soll doch gerade der Nachweis für die Eignung und damit > für den Abschluss sein. ...und genau das hat sie getan! Sie hat sich nicht mit etwas "dahingewurschtelten" zufrieden gegeben, sondern, recht hartneckig, nach den Ursachen geforscht und, als sie nicht mehr weiter wusste, Fachleute gefragt. Gernau das sollst du mit einem akademischen Abschluss beweisen! ...und nicht wissen, welches Bit, auf welcher krusten Hardwareplattform im Detail für was verantwortlich ist. Das steht irgendwo geschrieben und ändert sich jeden Monat!
Cyblord -. schrieb: > Aber die Arbeit soll doch gerade der Nachweis für die Eignung und damit > für den Abschluss sein. Ich wiederhole mich: Du solltest genauer lesen: Lisa schrieb: > Die Programmierung ist nicht meine Hauptaufgabe in der Bachelorarbeit. Damit ist diese Arbeit ganz klar nicht hauptsächlich der Nachweis für die Eignung und damit für den Abschluss. Trotzdem hat sie diese Aufgabe gemeistert! @cyblord: Du tust immer noch so, als ob Dein persönliches Leben von der Lösung dieser Programmieraufgabe abhängt. Dann sei doch froh, dass das Forum Dir hier Deinen Arsch gerettet hat! ;-) Dein Flugzeug wird landen! Und Du wirst die Operation, die Du während des Fluges im Gepäckabteil des Fliegers durchgestanden hast, auch überleben ;-)
:
Bearbeitet durch Moderator
Sapperlot W. schrieb: >> Lisa .. >>Danke! >> >>PS: Meine Hauptaufgabe war die Hardwareentwicklung >> > > Die Firmware schreiben zu koennen gehoert zur Hardwareentwicklung. Völlig Richtig. Vor allem bei reinen Digitalschaltungen. Denn wo liegt hier bitte überhaupt eine "Hardwareentwicklung"? Ein paar Controller und Digitalzeug verbinden und routen ist doch billigst. Darauf kann man sich doch heute nicht mehr zurückziehen. Oder reden wir hier Tatsächlich von einem 10GHz Gerät für welches du die HW entwickelst hast? Oder nen 100kW Netzteil. Ich meine da gibt es schon potential für anspruchsvolle HW Entwicklung die den Namen verdient. Aber daran glaube ich in dem Fall nicht so recht. Und genau DAS meine ich doch weiter oben. Man pfuscht unwissend die Software hin, weil man ja nur HW macht? Also das ist eben keine gute Einstellung.
Cyblord -. schrieb: > Billige Polemik. Gleiches mit Gleichem. > Fällt dir nichts besseres ein? Dazu nicht, nein. Auf jeden Fall nichts was es wert wäre, daraufhin gesagt zu werden... BTW: hast du in diesem Thread eigentlich irgendwas zur Sache beigetragen? Oder nur von der Seite hereingeplärrt wie Waldorf und Statler bei der Muppet Show?
Cyblord -. schrieb: > Aber die Arbeit soll doch gerade der Nachweis für die Eignung und damit > für den Abschluss sein. Bei meiner Bachelorarbeit muss ich immernoch weiter lernen, denn das was ich für meine BA bisher gemacht habe, habe ich im Studium nur ansatzweise gelernt. Ich glaube nicht, dass mir der Fehler mit den Interrupts nochmal passieren wird, denn aus Fehlern lernt man bekanntlich am besten.
Frank M. schrieb: > Damit ist diese Arbeit ganz klar nicht hauptsächlich der Nachweis für > die Eignung und damit für den Abschluss. Trotzdem hat sie diese Aufgabe > gemeistert! Wenn du meine Posts auch mal lesen würdest, statt nur pseudo-lustige Antworten darauf zu geben, hättest du erkannt das ich genau diese Einstellung kritisiere und ich habe, sogar mit Beispielen, dargelegt warum. Wer allerdings nur Sprüche macht, kann sich auf die Sache natürlich nicht mehr ganz so gut konzentrieren.
Cyblord -. schrieb: > Ein paar Controller und > Digitalzeug verbinden und routen ist doch billigst. Darauf kann man sich > doch heute nicht mehr zurückziehen. ...och jetzt würde ich gern den Teil deiner Vita hören, wie du mit dem Hard-/Softwar-Zeugs angefangen hast...
Cyblord -. schrieb: > Wer allerdings nur Sprüche macht, kann sich auf die Sache natürlich > nicht mehr ganz so gut konzentrieren. Ich war jedenfalls konzentriert genug, um Lisa mit der Nase draufzustupsen. Ich muss mich aber nicht konzentrieren, um einem cyblord zu antworten, der mit völlig überzogenen Argumenten kommt. Das ist verlorene Zeit. Ein Pilot in der Ausbildung fliegt Dich nicht. Ein Chirurg in der Ausbildung operiert Dich nicht. Ein Bachelor in der Ausbildung baut auch keine sicherheitsrelevante Elektronik. Und damit schließe ich den Thread. Es wurde alles gesagt.
HildeK schrieb: > Manche haben offenbar vergessen, dass sie auch mal angefangen haben und > Fehler gemacht haben. zum Beispiel der "Möchtegern-Blaublütige" :-)
Thread beobachten
Seitenaufteilung abschalten