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ß
:
Verschoben durch Admin
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.
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.
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.
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. schrieb: > Little B. schrieb: >> Ich hab im Studium mit Bloodshed DevC++ gearbeitet. > > Kann dieser auch C? na sicher
Little B. schrieb: >> Kann dieser auch C? > > na sicher Mal ganz nebenbei gefragt: Gibt es eigentlich einen C++ - Compiler, der kein C kann?
asdf schrieb: > Gibt es eigentlich einen C++ - Compiler, der > kein C kann? MSVC kann nur C89. Das ist oft eine empfindliche Einschränkung.
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.
:
Bearbeitet durch User
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.
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.
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?
1 | struct T |
2 | {
|
3 | int a; |
4 | char *b; |
5 | } t2; |
6 | |
7 | void g(const struct T *t); |
8 | |
9 | void f() |
10 | {
|
11 | int *y = (int[]) { 1, 2, 3 }; |
12 | int *z = (int[3]) { 1 }; |
13 | |
14 | int x[10]; |
15 | t2 = (struct T) { 43, "world" }; |
16 | g(&(struct T) { .b = "hello", .a = 47 }); |
17 | g(&(struct T) { 43, "bye" }); |
18 | }
|
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).
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?
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.
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.
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ß.
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.
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.
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. :-)
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.
Microsoft Visual Studio in der Express Version. Das Visual Studio ist mMn. die beste IDE für den PC.
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 ...
:
Bearbeitet durch User
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?
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?
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.
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?
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.
wenn sowieso Software für AVR porgrammiert werden soll, dann doch gleich AVR-Studio (mit WinAVR) und im Simulationsmodus den Code ausführen.
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;-)
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.
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.
:
Bearbeitet durch User
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?
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.
Karl H. schrieb: > einen Compiler zu finden, bei > dem ein int 2 Byte gross ist. int16_t aus stdint.h
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
1 | int16_t j = 9000; |
2 | 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.
:
Bearbeitet durch User
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
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;-)
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.
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.
:
Bearbeitet durch User
Warum wird eigenlich bei solchen Fragen immer der Hinweis auf Pelles-C vergessen? :) http://www.smorgasbordet.com/pellesc
Mehmet K. schrieb: > Warum wird eigenlich bei solchen Fragen immer der Hinweis auf Pelles-C > vergessen? :) Alter Schwede! ;-) MfG Paul
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. :-)
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
1 | sprintf( txt, "%d.%02d", wert / 100, wert % 100 ); |
schnell geschrieben, einfach .... und falsch. Negative Zahlen. Grummel. Da steht dann zb
1 | -1.-30 |
dort. Fast aber nicht ganz. Lasst sich aber leicht beheben.
1 | 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.
1 | int main() |
2 | {
|
3 | int wert; |
4 | |
5 | for( wert = -500; wert < 500; wert += 10 ) |
6 | printf( "%d.%02d\n", wert / 100, abs(wert % 100) ); |
7 | }
|
Jaaa. Jetzt siehts gut aus. Oder doch nicht?
1 | ... |
2 | -1.50 |
3 | -1.40 |
4 | -1.30 |
5 | -1.20 |
6 | -1.10 |
7 | -1.00 <---- Hä? Wasn hier los? |
8 | 0.90 |
9 | 0.80 |
10 | 0.70 |
11 | 0.60 |
12 | 0.50 |
13 | 0.40 |
14 | 0.30 |
15 | 0.20 |
16 | 0.10 |
17 | 0.00 |
18 | 0.10 |
19 | 0.20 |
20 | 0.30 |
21 | 0.40 |
22 | 0.50 |
23 | 0.60 |
24 | 0.70 |
25 | 0.80 |
26 | 0.90 |
27 | 1.00 |
28 | 1.10 |
29 | 1.20 |
30 | 1.30 |
31 | 1.40 |
32 | ... |
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?
:
Bearbeitet durch User
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)
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... :-)
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.
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...
:
Bearbeitet durch User
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.