Variablen setzen sich auf 0

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.

Variablen setzen sich gerne auf die 0, weil die so weich ist.

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.

wo wird denn der Wert von r geändert?

Lisa schrieb:
> if (erstes Zeichen der Zeichenkette = !)
Dann liegt hier der Fehler vor

Kein Gast schrieb:
>> if (r=1)
Es sollte sicher if (r==1) heissen. Compilerwarnungen sollte man nicht 
missachten

Naja, dann ist doch der Fehler weiterhin offensichtlich:

Ingo L. schrieb:
> Dann liegt hier der Fehler vor

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

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>)'

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.

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?

Werden die Variablen in den Schleifen zweimal neu definiert?
Diesen Fehler nehme ich gern.

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!

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

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:
> das funktioniert aber nicht, bzw. nur manchmal, je nach Optimierungslevel!
Aber sicher dann, wenn static mit ins Spiel kommt.

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

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

Lisa schrieb:
> while(rx_str[str_len]!='\0')  <-- sicher das der String nullterminiert ist ?

In der geposteten While-Schleife fehlt eine }, kann das sein?

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.

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.

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

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.

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.

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

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.

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?

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.

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.

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.

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.

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.

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.

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.

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

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 ;-)

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?

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.