C-Compiler und Debugger

[Highii H. (highii)]

Hallo,

Ich suche eine kostenlose Software für den PC, mit der ich in C 
programmieren kann. Den Code möchte ich einfach debuggen können. Also 
so, das man Breakpoints setzen kann und schrittweise den Code ausführen 
kann.

Hintergrund ist, dass ich noch nicht so fit in C bin. Und wenn ich etwas 
für einen Atmega programmiere, möchte ich erstmal "offline" meinen Code 
testen, bevor ich ihn auf den Controller spiele. Mir ist bewusst, dass 
der Code noch Controller-spezifisch angepasst werden muss. Aber viele 
Teilprogramme, Schleifen oder Berechnugen kann ich gut abgeschlossen für 
sich betrachten.

Bietet Visual Studio das was ich suche? Oder kennt ihr bessere 
Alternativen?

Danke und Gruß

[TM F. (p_richner)]

NetBeans ist eine Möglichkeit, da musst du einfach noch die 
entsprechenden Compiler mit Cygwin installieren. Dies funktioniert 
ziemlich zuverlässig.

Eine weitere Möglichkeit ist CodeBlocks. Habe jedoch noch nicht viel 
damit gemacht.

[Peter II (Gast)]

Highii H. schrieb:
> Bietet Visual Studio das was ich suche?
klar

> Oder kennt ihr bessere Alternativen?
besser ist Geschmackssache. Einige halten Eclipse für besser ich nicht.

[OldMan (Gast)]

Der ist ganz gut und braucht keine riesige Installation auf der HD:
http://www.cs.virginia.edu/~lcc-win32/

Auch sind gut man-pages dabei, die die Libs vernünftig dokumentieren.

[Little B. (lil-b)]

Ich hab im Studium mit Bloodshed DevC++ gearbeitet.
Der ist mittlerweile relativ alt, aber der hat alles drin.
Dieser hat den vorteil, dass man nicht für jedes kleine Programm ein 
neues Projekt erstellen muss. Er kann auch direkt einzelne c-dateien 
kompilieren und debuggen.

http://www.bloodshed.net/dev/devcpp.html

[Highii H. (highii)]

Little B. schrieb:
> Ich hab im Studium mit Bloodshed DevC++ gearbeitet.

Kann dieser auch C?

[Little B. (lil-b)]

Highii H. schrieb:
> Little B. schrieb:
>> Ich hab im Studium mit Bloodshed DevC++ gearbeitet.
>
> Kann dieser auch C?

na sicher

[asdf (Gast)]

Little B. schrieb:
>> Kann dieser auch C?
>
> na sicher

Mal ganz nebenbei gefragt: Gibt es eigentlich einen C++ - Compiler, der 
kein C kann?

[Walter T. (nicolas)]

asdf schrieb:
> Gibt es eigentlich einen C++ - Compiler, der
> kein C kann?

MSVC kann nur C89. Das ist oft eine empfindliche Einschränkung.

[Tom (Gast)]

Seit VS2015 ist C99 wohl benutzbar. Noch nicht getestet.

[Walter T. (nicolas)]

Tom schrieb:
> Seit VS2015 ist C99 wohl benutzbar.

Das wäre ein Grund, sich das noch einmal anzuschauen. Der Debugger ist 
wirklich eine feine Sache.

Edit: Immer noch keine "compound literals". Damit ist es für mich wieder 
raus.

[Karl Käfer (Gast)]

Highii H. schrieb:
> Ich suche eine kostenlose Software für den PC, mit der ich in C
> programmieren kann. Den Code möchte ich einfach debuggen können. Also
> so, das man Breakpoints setzen kann und schrittweise den Code ausführen
> kann.
>
> Hintergrund ist, dass ich noch nicht so fit in C bin. Und wenn ich etwas
> für einen Atmega programmiere, möchte ich erstmal "offline" meinen Code
> testen, bevor ich ihn auf den Controller spiele. Mir ist bewusst, dass
> der Code noch Controller-spezifisch angepasst werden muss. Aber viele
> Teilprogramme, Schleifen oder Berechnugen kann ich gut abgeschlossen für
> sich betrachten.

Meistens ist der Compiler nur ein Kommandozeilenwerkzeug, das entweder 
von Hand, über make(1) oder einen anderen Build-Mechanismus, oder von 
der IDE aufgerufen wird. Da Atmel-Studio im Hintergrund den GNU c 
compiler (gcc) aus der GNU Compiler Collection (GCC) verwendet, der sehr 
gut dokumentiert, weit entwickelt, auch für Windows verfügbar ist und 
darüber hinaus einige sehr nützliche Erweiterungen mitbringt, bietet es 
sich natürlich an, denselben Compiler auch unter Windows zu benutzen, 
egal ob  mit oder ohne IDE.

[Luther B. (luther-blissett)]

Die Code::Blocks IDE ist frei verfügbar und unterstützt die gängigen 
kommerziellen (MSVC, Borland..) und nicht kommerziellen (GCC,Clang) 
Compiler. Interessant dabei ist, dass auch Cross-Copilation möglich ist, 
du also in dem Projekt auch ein Binary für deinen Atmega erstellen 
kannst:

https://www.mikrocontroller.net/articles/Code::Blocks#Erstellung_eines_AVR-Projekt

Es gibt dann noch einen Fork namens Em::Blocks der auf die Entwicklung 
für MCU spezialisiert ist.

[Optiker (Gast)]

Walter T. schrieb:
> Tom schrieb:
>> Seit VS2015 ist C99 wohl benutzbar.
>
> Das wäre ein Grund, sich das noch einmal anzuschauen. Der Debugger ist
> wirklich eine feine Sache.
>
> Edit: Immer noch keine "compound literals".

Das ist doch seit VS2013 drin, oder?

struct T
{
  int a;
  char *b;
} t2;

void g(const struct T *t);

void f()
{
  int *y = (int[]) { 1, 2, 3 };
  int *z = (int[3]) { 1 };
  
  int x[10];
  t2 = (struct T) { 43, "world" };
  g(&(struct T) { .b = "hello", .a = 47 });
  g(&(struct T) { 43, "bye" });
}

Highii H. schrieb:
> Bietet Visual Studio das was ich suche? Oder kennt ihr bessere
> Alternativen?

Bei C++ ist MS inzwischen schon auf der Höhe (C++11, C++14 und einige 
C++1z-Features), auch VS ist meiner Meinung nach gut - wenn man denn 
eine IDE verwenden will.
Für C würde ich aber, speziell wenn neuere Features verwendet werden 
sollen, eher GCC oder Clang verwenden. Code::Blocks als IDE wurde ja 
schon genannt (läuft unter Linux, Mac OS und Windows).

[Volker S. (vloki)]

Highii H. schrieb:
> Hintergrund ist, dass ich noch nicht so fit in C bin. Und wenn ich etwas
> für einen Atmega programmiere, möchte ich erstmal "offline" meinen Code
> testen, bevor ich ihn auf den Controller spiele.

Die IDE mit der du "später" den Atmega programmieren willst hat doch 
sicher so was wie einen Simulator. Also warum zwei mal anfangen?

[Walter T. (nicolas)]

Volker S. schrieb:
> Also warum zwei mal anfangen?

Der Simulator hilft nicht unbedingt immer. Ich habe mir für Tests am PC 
auch einen kleinen Emulator fürs Grafik-LCD geschrieben, um für solche 
Tests nicht immer die Firmware neu flashen zu müssen. Wenn dann noch ein 
anständiger Debugger wie der von MSVC dazukommt, ist das schon sehr 
komfortabel. Und vor allem deutlich schneller als Tests mit dem 
JTAG-Debugger. Und man kann soviele Konsolen-Ausgaben machen, wie man 
will.

[Volker S. (vloki)]

Mit zwei mal anfangen habe ich eigentlich zwei Entwicklungsumgebungen 
gemeint. Aber der Simulator bietet vermutlich kein virtuelles LCD.
Da wird man wohl eher nur die Register und Signale an den Pins anschauen 
können.

[Rainer V. (rudi994)]

Luther B. schrieb:
> Code::Blocks IDE ist frei verfügbar

Für den Anfang das CodeBlocks-Setup inkl. MinGW! Kann man auch getrennt 
runterladen, muß dann aber zur MSYS/MinGW-Installation schon vorher 
genau wissen, was man da alles selbst machen muß.

[Sheeva P. (sheevaplug)]

Highii H. schrieb:
> Ich suche eine kostenlose Software für den PC, mit der ich in C
> programmieren kann. Den Code möchte ich einfach debuggen können. Also
> so, das man Breakpoints setzen kann und schrittweise den Code ausführen
> kann.
>
> Hintergrund ist, dass ich noch nicht so fit in C bin. Und wenn ich etwas
> für einen Atmega programmiere, möchte ich erstmal "offline" meinen Code
> testen, bevor ich ihn auf den Controller spiele. Mir ist bewusst, dass
> der Code noch Controller-spezifisch angepasst werden muss. Aber viele
> Teilprogramme, Schleifen oder Berechnugen kann ich gut abgeschlossen für
> sich betrachten.
>
> Bietet Visual Studio das was ich suche? Oder kennt ihr bessere
> Alternativen?

Merkwürdig: erst fragst Du nach einem Compiler und einem Debugger, dann 
nach einer IDE, und hier im Thread beziehen sich bis auf einen Beitrag 
dann alle wieder nur auf IDEs.

Ich persönlich würde Dir hingegen empfehlen, erst einmal keine IDE zu 
verwenden, sondern stattdessen ganz klassisch mit einem ordentlichen 
Texteditor, und jeweils Kommandozeilenversionen eines Compilers, eines 
Debuggers und eines Buildwerkzeuges zu beginnen. Als Texteditoren sind 
Notepad++ und Geany ziemlich beliebt, für Compiler, Debugger und das 
Buildwerkzeug make bietet sich die MinGW-Software an. MinGW ist eine 
minimalistische GNU-Entwicklungsumgebung für Windows und bringt den 
Compiler gcc, den Debugger gdb und das Buildwerkzeug make mit. 
Atmel-Studio benutzt im Hintergrund genau dieselben Werkzeuge, ebenso 
viele andere IDEs.

Kommandozeilenwerkzeuge zu benutzen mag heute in der Allgegenwart von 
grafischen Benutzeroberflächen auf den ersten Blick zwar 
anachronistisch, altmodisch und vielleicht sogar unkomfortabel 
erscheinen. Aber Du wirst dabei viel besser lernen, wie der 
Entwicklungsprozeß funktioniert, und kannst eine viel bessere und 
fundiertere Entscheidung treffen, wenn Du Dich später doch einmal für 
eine IDE entscheidest. Aber das mußt Du gar nicht; vor allem unter 
Profis gibt es immer noch viele, die klassische, 
kommandozeilenorientierte Umgebungen aus Einzelwerkzeugen bevorzugen.

Den Nachteil dessen will ich Dir allerdings nicht verheimlichen: damit, 
mehr über den Entwicklungsprozeß zu lernen, geht natürlich auch ein 
etwas höherer Lernaufwand, mithin eine steilere Lernkurve einher. 
Vermutlich kommst Du mit einer IDE am Anfang zu schnelleren Erfolgen. 
Insofern mußt Du selbst entscheiden, ob Du lieber schnelle Erfolge sehen 
oder genauer verstehen willst, was im Hintergrund passiert. Beides sind 
vernünftige Vorgehensweisen. Wie Du Dich entscheidest, hängt daher vor 
allem von Dir selbst ab, und davon, was für ein Typ Mensch Du bist: der 
eine braucht schnelle Erfolge für die Motivation, ein anderer will 
vollen Durchblick und ist bereit, dafür Zeit und Lernaufwand zu 
investieren.

[Volker S. (vloki)]

Sheeva P. schrieb:
> vor allem unter
> Profis gibt es immer noch viele, die klassische,
> kommandozeilenorientierte Umgebungen aus Einzelwerkzeugen bevorzugen.

Ich kann es mir jetzt irgendwie nicht mehr vorstellen, wie ich in einer 
Komandozeilenumgebung debugge.
Kommandozeile zum compilieren habe ich zuletzt ~1993 im Praxissemester 
benutzt. Klar konnte man da auch debuggen, Einzelschritt und so weiter. 
Aber jetzt will ich eben auch mehrere Register/Variablen dabei sehen...

Eine IDE zu benutzen schließt ja zudem nicht aus, dass man weiß, was da 
im Hintergrund abläuft.

[Sheeva P. (sheevaplug)]

Volker S. schrieb:
> Sheeva P. schrieb:
>> vor allem unter
>> Profis gibt es immer noch viele, die klassische,
>> kommandozeilenorientierte Umgebungen aus Einzelwerkzeugen bevorzugen.
>
> Ich kann es mir jetzt irgendwie nicht mehr vorstellen, wie ich in einer
> Komandozeilenumgebung debugge.

"gdb programm" und dann weiter wie gewünscht. Wenn Dein Programm einen 
Coredump produziert hat, rufst Du gdb(1) mit "gdb programm core" und 
kannst dann den Coredump untersuchen, was schiefgelaufen ist.

> Kommandozeile zum compilieren habe ich zuletzt ~1993 im Praxissemester
> benutzt. Klar konnte man da auch debuggen, Einzelschritt und so weiter.
> Aber jetzt will ich eben auch mehrere Register/Variablen dabei sehen...

Kein Problem, dann sagst Du dem gdb(1) wahlweise interaktiv oder mit 
einem Startup-Skript mit dem Befehl "display", daß er Dir die 
Register/Variablen bei jedem Step/Breakpoint/Prompt/Whatever anzeigen 
soll.

Der gdb(1) ist ein extrem leistungsfähiges, flexibles und trotzdem recht 
komfortables Werkzeug (wenn man es denn zu beherrschen gelernt hat), das 
auch hinter den Kulissen vieler IDEs (wie Atmel Studio) verwendet wird. 
Durch die hohe Leistungsfähigkeit und Flexibilität des gdb(1) bieten die 
meisten IDEs und GUI-Frontends nur die wichtigsten Funktionen.

> Eine IDE zu benutzen schließt ja zudem nicht aus, dass man weiß, was da
> im Hintergrund abläuft.

Natürlich nicht. Aber Du weißt das, weil Du es im Praxissemester ~1993 
gelernt, benutzt und verinnerlicht hast. Die meisten Anfänger haben aber 
nicht mit Dir in dem Praxissemester gesessen, aber trotzdem wird sich 
ein solides Wissen über die Abläufe im Hintergrund auch für sie früher 
oder später höchstwahrscheinlich auszahlen -- und wenn es nur ist, um 
bessere und detailliertere Anfragen in diesem Forum stellen zu können 
und sich "Antworten" wie "42" oder "habe keine Glaskugel" zu ersparen. 
:-)

[Walter T. (nicolas)]

Sheeva P. schrieb:
> Der gdb(1) ist ein extrem leistungsfähiges, flexibles und trotzdem recht
> komfortables Werkzeug (wenn man es denn zu beherrschen gelernt hat)

Wenn Du eine gute Quelle kennst, wie man sich in den GDB (am besten 
unter Windows) einarbeiten kann, dann immer her damit! Vor Jahren habe 
ich mal nach einer guten Beschreibung gesucht, aber keine gefunden und 
mich letztendlich damit abgefunden, daß es unter Windows keine 
vernünftige Möglichkeit gibt, GCC-kompilierte Anwendungen zu debuggen.

[Random .. (thorstendb)]

Microsoft Visual Studio in der Express Version.
Das Visual Studio ist mMn. die beste IDE für den PC.

[Vlad T. (vlad_tepesch)]

OldMan schrieb:
> Auch sind gut man-pages dabei

super. man-pages ...

OldMan schrieb:
> Der ist ganz gut und braucht keine riesige Installation auf der HD:
> http://www.cs.virginia.edu/~lcc-win32/

ein compiler, von dem die wenigsten bisher gehört haben, der eine 
komische Lizens hat und das letzte update über 3 Jahre her ist und der 
nach two-man show aussieht.

Deine Vorschläge werden ja immer besser.

Little B. schrieb:
> Ich hab im Studium mit Bloodshed DevC++ gearbeitet.
> Der ist mittlerweile relativ alt, aber der hat alles drin.
> http://www.bloodshed.net/dev/devcpp.html

ich versteh nicht, warum der immer noch rumgeistert. offiziell bis XP 
unterstützt, das letzte update auch 3 Jahre alt und verwendet GCC 
3.irgendwas ...

[Dr. Sommer (Gast)]

Vlad T. schrieb:
> Little B. schrieb:
>> Ich hab im Studium mit Bloodshed DevC++ gearbeitet.
>> Der ist mittlerweile relativ alt, aber der hat alles drin.
>> http://www.bloodshed.net/dev/devcpp.html
>
> ich versteh nicht, warum der immer noch rumgeistert. offiziell bis XP
> unterstützt, das letzte update auch 3 Jahre alt und verwendet GCC
> 3.irgendwas ...
Der wird woanders weiterentwickelt:
http://orwelldevcpp.blogspot.de/
Momentan mit GCC-Version GCC 4.9.2. Aktuell genug?

[Volker S. (vloki)]

Und ich verstehe nicht, was gegen eine Verwendung von z.B. Atmel Studio 
(oder wie immer das heißt) mit dem eingebauten Simulator spricht...
Das braucht man dann später eh UND irgendwelches Anpassungsgedöns?

[Karl Käfer (Gast)]

Volker S. schrieb:
> Und ich verstehe nicht, was gegen eine Verwendung von z.B. Atmel Studio
> (oder wie immer das heißt) mit dem eingebauten Simulator spricht...

Die Anforderung des TO.

[Volker S. (vloki)]

Karl Käfer schrieb:
> Volker S. schrieb:
>> Und ich verstehe nicht, was gegen eine Verwendung von z.B. Atmel Studio
>> (oder wie immer das heißt) mit dem eingebauten Simulator spricht...
>
> Die Anforderung des TO.

Wo genau? Meiner Meinung nach macht ein Simulator genau das was der TO 
will. Wozu soll der denn sonst da sein?

[Karl Käfer (Gast)]

Random .. schrieb:
> Microsoft Visual Studio in der Express Version.
> Das Visual Studio ist mMn. die beste IDE für den PC.

Für C jedenfalls nicht. Wenn ich mich recht entsinne, ist Microsofts 
C-Compiler bei C89 stehengeblieben und hat von den neueren C-Standards 
C99 und C11 nichts mitbekommen.

[Avr-Progger (Gast)]

wenn sowieso Software für AVR porgrammiert werden soll,
dann doch gleich AVR-Studio (mit WinAVR) und im Simulationsmodus
den Code ausführen.

[Volker S. (vloki)]

Avr-Progger schrieb:
> wenn sowieso Software für AVR porgrammiert werden soll,
> dann doch gleich AVR-Studio (mit WinAVR) und im Simulationsmodus
> den Code ausführen.

Oh noch einer, ich dachte schon ich wäre ein Alien;-)

[Vlad T. (vlad_tepesch)]

Dr. Sommer schrieb:
> Vlad T. schrieb:
>> Little B. schrieb:
>>> Ich hab im Studium mit Bloodshed DevC++ gearbeitet.
>>> Der ist mittlerweile relativ alt, aber der hat alles drin.
>>> http://www.bloodshed.net/dev/devcpp.html
>>
>> ich versteh nicht, warum der immer noch rumgeistert. offiziell bis XP
>> unterstützt, das letzte update auch 3 Jahre alt und verwendet GCC
>> 3.irgendwas ...
> Der wird woanders weiterentwickelt:
> http://orwelldevcpp.blogspot.de/
> Momentan mit GCC-Version GCC 4.9.2. Aktuell genug?

Es war (nicht nur hier) aber immer explizit von Bloodshed DevC++ 
geschrieben.
Das ist auch das, was man findet wenn man nach DevC++ sucht.
Wie kommst du also drauf, dass Orwell DevC++ gemeint war?

Volker S. schrieb:
> Wo genau? Meiner Meinung nach macht ein Simulator genau das was der TO
> will. Wozu soll der denn sonst da sein?

Er möchte offline Code testen.
Es macht durchaus Sinn, die funktionale Korrektheit in einem PC-Programm 
zu überprüfen, was um den Faktor >10000 schneller ausgeführt wird.

Parallel dazu sollte man natürlich auch verifizieren, dass der 
Targetcompiler das gleiche berechnen lässt und man nicht in irgendwelche 
Portabilitätsfallen getappt ist.

[Karl H. (kbuchegg)]

Volker S. schrieb:
> Und ich verstehe nicht, was gegen eine Verwendung von z.B. Atmel Studio
> (oder wie immer das heißt) mit dem eingebauten Simulator spricht...
> Das braucht man dann später eh UND irgendwelches Anpassungsgedöns?

Dann lass dir mal vom Atmel Studio zu Testzwecken mittels ein paar 
printf Zwischenergebnisse auf einer Konsole ausgeben.
Es gibt viele Dinge, die man im Vorfeld wunderbar auf einem PC mit 
seinen einfachen Ausgabemöglichkeiten entwickeln und debuggen kann.

[Volker S. (vloki)]

Vlad T. schrieb:
> Er möchte offline Code testen.
> Es macht durchaus Sinn, die funktionale Korrektheit in einem PC-Programm
> zu überprüfen, was um den Faktor >10000 schneller ausgeführt wird.

Warum sollte das 10000 mal schneller sein als der Simulator der doch 
auch nur "offline" auf dem PC läuft?

[Karl H. (kbuchegg)]

Vlad T. schrieb:

> Parallel dazu sollte man natürlich auch verifizieren, dass der
> Targetcompiler das gleiche berechnen lässt und man nicht in irgendwelche
> Portabilitätsfallen getappt ist.

Am wichtigsten wäre meiner Meinung nach, einen Compiler zu finden, bei 
dem ein int 2 Byte gross ist. Ansonsten können einen Überläufe in 
Berechnungen, die auf dem PC nicht auftreten, heftig narren.

[Tom (Gast)]

Karl H. schrieb:
> einen Compiler zu finden, bei
> dem ein int 2 Byte gross ist.

int16_t aus stdint.h

[Karl H. (kbuchegg)]

Tom schrieb:
> Karl H. schrieb:
>> einen Compiler zu finden, bei
>> dem ein int 2 Byte gross ist.
>
> int16_t aus stdint.h

Das ist aber nur die halbe Miete. Denn während einer Berechnung wird ja 
implizit auf int hochgecastet.
Ein

   int16_t j = 9000;
   int16_t i = j * j / 8000;

liefert bei einer sizeof(int) von 2 ein falsches Ergebnis, während es 
bei einer sizeof(int) von 4 ein richtiges Ergebnis liefert. Und du 
kannst nichts dagegen tun ausser aufpassen.

[Sheeva P. (sheevaplug)]

Walter T. schrieb:
> Sheeva P. schrieb:
>> Der gdb(1) ist ein extrem leistungsfähiges, flexibles und trotzdem recht
>> komfortables Werkzeug (wenn man es denn zu beherrschen gelernt hat)
>
> Wenn Du eine gute Quelle kennst, wie man sich in den GDB (am besten
> unter Windows) einarbeiten kann, dann immer her damit! Vor Jahren habe
> ich mal nach einer guten Beschreibung gesucht, aber keine gefunden und
> mich letztendlich damit abgefunden, daß es unter Windows keine
> vernünftige Möglichkeit gibt, GCC-kompilierte Anwendungen zu debuggen.

Naja, von der FSF selbst gibt es da eine hervorragende und ausführliche 
Dokumentation namens "Debugging with GDB", online hier: [1], als 
gzip-komprimiertes PDF hier: [2] und auf totem Holz hab' ich es auch 
schonmal irgendwo gesehen. Außerdem gibt es die offizielle Dokumentation 
hier: [3] und das Tutorial von Richard M. Stallman hier: [4].

Eine besondere Quelle für Windows kenne ich nicht, wüßte aber auch 
nicht, warum der gdb(1) unter Windows anders funktionieren sollte als 
unter UNIX. Allerdings kann man aus dem gdb(1) heraus auch 
Shell-Kommandos aufrufen, welche dafür natürlich verfügbar sein müssen; 
die Cygwin-Umgebung machts möglich, damit habe ich vor ein paar Jahren 
mal unter W2k gearbeitet und kann mich nicht an Abweichungen zwischen 
der Benutzung des gdb(1) unter Windows und meinen gewohnten Systemen 
erinnern.

Probier's einfach mal aus. Ich würde mich sehr freuen, etwas über Deine 
Erfahrungen zu hören.

[1] https://sourceware.org/gdb/onlinedocs/gdb/
[2] http://sourceware.org/gdb/current/onlinedocs/gdb.pdf.gz
[3] http://www.gnu.org/software/gdb/documentation/
[4] http://www.unknownroad.com/rtfm/gdbtut/gdbtoc.html

[Volker S. (vloki)]

Karl H. schrieb:
> Es gibt viele Dinge, die man im Vorfeld wunderbar auf einem PC mit
> seinen einfachen Ausgabemöglichkeiten entwickeln und debuggen kann.

Ich gebe nie was aus. Ich halte immer an und schau rein. Alternativ kann 
z.B. der MPLABX Simulator auch noch so eine Art Logicanalyzer Fenster 
anzeigen, an dem zeitliche Verläufe von Signalen angezeigt werden 
können.

Vermutlich sind meine Programme einfach zu einfach;-)

[Karl H. (kbuchegg)]

Volker S. schrieb:

> anzeigen, an dem zeitliche Verläufe von Signalen angezeigt werden
> können.

Es geht nicht um Signale.
Es geht um Dinge wie zb tabellengestützte lineare Interpolation oder 
Umrechnung von Messwerten oder die Speicherverwaltung einer 
Zeitpunkttabelle oder .....
Kann man alles perfekt auf dem PC vorbereiten und dann in einer Schleife 
den Wertebereich abrasen lassen und sich ansehen ob man irgendwo 
Unregelmässigkeiten entdeckt.

> Vermutlich sind meine Programme einfach zu einfach;-)

Kann ich nicht beurteilen.

[Walter T. (nicolas)]

Karl H. schrieb:
> [...] mittels ein paar
> printf Zwischenergebnisse auf einer Konsole ausgeben.

Karl H. schrieb:
> [...] auf dem PC vorbereiten und dann in einer Schleife
> den Wertebereich abrasen lassen und sich ansehen ob man irgendwo
> Unregelmässigkeiten entdeckt.

Volker S. schrieb:
> Verläufe von Signalen

 - Screenshots von LCD-Inhalten machen, die man z.B. für die Anleitung 
gut gebrauchen kann

 - Vergleiche mit einer Referenzimplementierung (automatisch) laufen 
lassen, z.B. mit Matlab/Octave/Python

 - Auf dem PC mal schnell etwas vorführen können, ohne die Hardware auf 
dem Schreibtisch aufzubauen oder den Simulator zu installieren (die 
erstellte .EXE kann ich einfach per Email verschicken).

- Der PC-Debugger ist oft komfortabler

Das alles sind für mich ausreichende Gründe, mir einen PC-Compiler für 
ein µC-Projekt zu wünschen.

[Mehmet K. (mkmk)]

Warum wird eigenlich bei solchen Fragen immer der Hinweis auf Pelles-C 
vergessen? :)
http://www.smorgasbordet.com/pellesc

[Paul B. (paul_baumann)]

Mehmet K. schrieb:
> Warum wird eigenlich bei solchen Fragen immer der Hinweis auf Pelles-C
> vergessen? :)

Alter Schwede!
;-)
MfG Paul

[Sheeva P. (sheevaplug)]

Volker S. schrieb:
> Ich gebe nie was aus. Ich halte immer an und schau rein.

Man kann seine Software natürlich auch in C modular aufbauen (mit C++ 
geht das sogar noch einfacher) und die Module dann mit Unittests 
checken, bevor man sie in den Produktionscode übernimmt. Damit kann man 
viele Fehler schon von vorneherein ausschließen -- und der beste 
Debugger ist ja bekanntlich immer der, den man gar nicht benötigt.

> Vermutlich sind meine Programme einfach zu einfach;-)

Vielleicht sind die der anderen auch nur einfach zu kompliziert. :-)

[Karl H. (kbuchegg)]

Sheeva P. schrieb:

> Vielleicht sind die der anderen auch nur einfach zu kompliziert. :-)

muss nicht sein.
Manchmel macht man auch ganz einfach 'dumme' Fehler.

Ist schon eine Weile her.
Ausgabe von Messwerten in Fixpunkt Arithmetik mit einem Skalierfaktor 
von 100.
Da keine Zeitnot bestand, Flash auch genügend vorhanden war

  sprintf( txt, "%d.%02d", wert / 100, wert % 100 );

schnell geschrieben, einfach .... und falsch.
Negative Zahlen. Grummel. Da steht dann zb

  -1.-30

dort. Fast aber nicht ganz. Lasst sich aber leicht beheben.

  sprintf( txt, "%d.%02d", wert / 100, abs(wert % 100) );

Jetzt hauts hin. Der Wert vom DS1820 stimmt bei Raumtemperatur und wenn 
er in der Tiefkühltruhe ist, ist auch alles ok. 2 Stichproben sollten ja 
wohl reichen.

Sicherheitshalber, dauert ja nur ein paar Sekunden. Aber eigentlich bin 
ich mir sicher.

int main()
{
  int wert;

  for( wert = -500; wert < 500; wert += 10 )
    printf( "%d.%02d\n", wert / 100, abs(wert % 100) );
}

Jaaa. Jetzt siehts gut aus.



Oder
doch nicht?

...
-1.50
-1.40
-1.30
-1.20
-1.10
-1.00                       <---- Hä? Wasn hier los?
0.90
0.80
0.70
0.60
0.50
0.40
0.30
0.20
0.10
0.00
0.10
0.20
0.30
0.40
0.50
0.60
0.70
0.80
0.90
1.00
1.10
1.20
1.30
1.40
...

Ja klar. Natürlich. -50 / 100 ergibt 0. Und 0 hat kein negatives 
Vorzeichen.

Hand aufs Herz. Wer hätte letzteres genauso übersehen, wie ich es beim 
ersten mal auch übersehen habe?

[Volker S. (vloki)]

Sheeva P. schrieb:
> Man kann seine Software natürlich auch in C modular aufbauen (mit C++
> geht das sogar noch einfacher) und die Module dann mit Unittests
> checken...

Natürlich baut man C Programme modular auf;-)
Bei den Unittests hat man sicher auf einer Umgebung für PC Software 
bessere Unterstützung. Muss ich doch gleich man schauen wie das 
eigentlich mit (m)einer uC IDE geht.
(habe ich zugegeben wenig Ahnung von. Wird Zeit sich mal damit 
anzufreunden)

[Rolf M. (rmagnus)]

Karl H. schrieb:
> Ja klar. Natürlich. -50 / 100 ergibt 0. Und 0 hat kein negatives
> Vorzeichen.

Tja, hättest du eine Maschine mit Einerkomplement genommen... :-)

[Sheeva P. (sheevaplug)]

Volker S. schrieb:
> Sheeva P. schrieb:
>> Man kann seine Software natürlich auch in C modular aufbauen (mit C++
>> geht das sogar noch einfacher) und die Module dann mit Unittests
>> checken...
>
> Natürlich baut man C Programme modular auf;-)

Das macht leider nicht jeder... ;-)

> Bei den Unittests hat man sicher auf einer Umgebung für PC Software
> bessere Unterstützung. Muss ich doch gleich man schauen wie das
> eigentlich mit (m)einer uC IDE geht.

Letztlich geht es darum, in C auf dem PC eine Umgebung zu schaffen, die 
der auf Deinem Mikrocontroller ähnlich genug ist, um Deine Funktionen 
darunter ablaufen lassen und testen zu können.

[Alejandro P. (alejandro_p79)]

Mann kann mit UT und ein vernüftiges HAL schon viel erreichen. Gute Unit 
Tests sind eine Kunst die man leider nicht fürh genug lernt/nutzt :(...
Wenn man IO und Algorithmen trennen kann... Hardware-nähe Treibers... da 
kann man weniger aufs PC machen... :(

Edit: Was spricht gegen Eclipse/CDT/MinGW ? Auf Windows geht es ganz 
gut. Netbeans geht auch, aber es ist ein bisschen langsamer als 
Eclipse...

[AH (Gast)]

Highii H. schrieb:
> Bietet Visual Studio das was ich suche? Oder kennt ihr bessere
> Alternativen?

Linux als Programmierplattform mit gcc und gdb und gas.

Bei Windows ist es einfacher, Windowsoptimierte Programme zu benutzen. 
Das wären in erster Linie Visual Studio und Open Watcom. Das Open Watcom 
Packet enthält einen sehr guten Konsoleeditor und läßt sich recht 
einfach installieren, auch auf Usbsticks usw. Von der Kompatibilität her 
ist das OW-Packet eher noch auf Windows/Dos Zwischenwelten abgestimmt. 
In neueren Windowsversionen sind andere Bibliotheken bestimmend, so dass 
z.B. das oben genannte Lcc-System nicht mehr mit allen Windowsversionen 
kompatibel ist, vor allem nicht mit älteren, die Compilerprogrammierer 
wollen ja auch updaten.
OW enthält hier deutlich mehr "Tiefenschärfe" (Stichwort "Dos-Extender) 
und
Verlässlichkeit.