Nein, Probleme bringt das nicht. Aber die komplette Großschreibung bei Makros ist halt eine allgemeine Konvention. Ob man sich dran hält, bleibt letztendlich jedem selbst überlassen.
Mitlerweile ist die Verwendung von Makros generell zur Glaubensfrage geworden. Manche Programmierer verpöhnen Makros und setzen stattdessen nur noch Inline-Funktionen ein. Siehe auch http://www.mikrocontroller.net/articles/Makro
Ich denke, man sollte Makros weiterhin benutzen, find das ne tolle Sache \Zitat von askazo
/
Anders sehen das sicher die eingefleischten Programmierer, die sonst nichts anderes machen, kennen sicher auch den Code in und auswendig, dass sie ihre Werte direkt in den Code schreiben und den Zusammenhang sofort erkennen.
Danke für deine Hilfe
Hei, das ist eine schön-lehrreiche Unterhaltung. Ich habe gleich die BitSet-Definitionen übernommen und um #define IsBitClr(ADDR,BIT) ((!(ADDR) & ~(1<<BIT))) erweitert (das ist halt MEIN Faulheitsfaktor).
Als C(äh)-Newbie seit Sept. 07 liegen mir viele Fragen auf der Zunge, ich schreib mal ne wichtige her. Ich versuche ja einigermassen strukturiert zu programmieren, habe aber immer nur eine eigene Headerdatei.
Die ist so ne Art Projektübersicht und enthält mehrere Abschnitte mit defines, Variablendeklarationen die eher nach den Softwarepaketen (Beispiel: "Motordaten: Steuerung, Motortests", "Encoderbedienung und Zeitdaten" und so ähnlich) gruppiert sind. Dahinter kommt die (hoffentlich) aktuelle Modulliste mit allen Funktionsprototypen. Damit habe ich in diesem Header eine Kurzübersicht des Programms und weiß, wo ich ALLE globalen Variablen schnell finde. Könnt ihr das so als passabel durchgehen lassen?Code:// ================================================================================= #include <stdlib.h> #include <avr/io.h> // Includiert u.A. auch iomx328p.h #include <avr/interrupt.h> #include "D01-3_40_com_x21.h" // commonvariable #include "D01-3_40_dme_x21.c" // irDME Routinen #include "D01-3_40_gpd_x21.c" // ADC-Routinen für GP2D120 und Aufruf Regelung #include "D01-3_40_inf_x21.c" // Info-Ausgaben #include "D01-3_40_kal_x21.c" // Kalibrierungen, z.B.: irDME´s #include "D01-3_40_mot_x21.c" // Motorroutinen incl. PWM, Regelung Motor #include "D01-3_40_tmr_x21.c" // Timer, PWM #include "D01-3_40_tst_x21.c" // Testroutinen #define MCU = AVR_ATmega328p
Ciao sagt der JoeamBerg
Copious,
noch ein Vorteil der starken Modularität, die askazo Dir mit guten Gründen empfiehlt, ist, dass Du jedes Modul einzeln austesten kannst. Z.B. wenn Du ein Modul für die RS232 hast, dann testest Du's mit einem eigenen kleinen Testprogramm, bis es läuft. Fehler findest und beseitigst Du so viel schneller, als wenn das Modul schon im Gesamtprogramm eingebunden ist. Auch später, wenn Änderungen an dem Modul erforderlich werden, ist es ratsam, die geänderte Version erst wieder in der einfachen Testumgebung auszuprobieren. Erst, wenn es da zuverlässig läuft, wird es wieder in das Gesamtprogramm eingefügt. - Noch ein Tip: Ändere nie ein funktionierendes Modul! Immer erst unter einem neuen Namen speichern (z.B. mit angehängter fortlaufender Versionsnummer ..._VXX). Dann kannst Du immer auf die alten, erprobten Versionen zurückgreifen. Ich möchte die Stunden nicht zählen, die ich schon mit der Reparatur verschlimmbesserter Programmteile verbracht habe
.
Ciao,
mare_crisium
@mare_crisium: Für sowas gibt es Versionsverwaltungssysteme
@oberallgeier: Du strukturierst nur deinen Code, nicht aber das eigentliche Programm - letztendlich landet alles in einem großen File und wird erst dann kompiliert.
Wenn man richtig modularisiert (das geht auch nicht immer), hat jedes Modul einen oder mehrere Header und du greifst nur über die Deklarationen in diese(n) Header(n) auf das Modul zu.
Die Implementierung des Moduls selbst bleibt komplett verborgen, du könntest es dann jederzeit gegen eine Library austauschen oder die interne Struktur ändern, solange die Schnittstelle (die im Header definiert wird) gleich bleibt.
Leider ist das insbesondere bei hardwarenahen Sachen eine sehr schwierige Sache und führt bei konsequenter Anwendung mal zu sehr hässlichen Schnittstellen und nur suboptimalem Code.
Spätestens wenn man in C versucht, Pseudo-Objekte halbwegs sauber zu kapseln wird es seeeeehr unangenehm (mein momentaner Versuch, einen universalen (und ungenießbaren) Funkstack für die RF(M)-Reihe zu entwicklen)
mfG
Markus
was mir in hinsicht auf kapselung recht gut gefallen hat, war V-USB (vormals AVR-USB) von obdev; das könnt man sich als inspiration anschauen.
wenn man anderer leute code liest, weil man ihn debuggen oder erweitern muß, bekommt man mit der zeit ein gefühl für code-qualität. bei mir haben jedenfalls eineinhalb jahrzehnte basteln an *nix open source code dazu geführt, daß ich nach 5 minuten weiß, ob ich den code mag oder nicht, und auch warum.
wesentlich ist dabei, daß man einfach und ohne umwege das findet, was man im code sucht -- "wo passiert X, und womit hängt es zusammen?". jedenfalls wenn man, wie ich meistens, in "use the source, luke"-manier nur mal kurz was in einem größeren haufen code ändern oder erweitern will. ich denke aber, das gilt genauso für µC-projekte, wo man vielleicht in ein paar monaten oder jahren nur punktuell was ändern will.
und das matcht eigentlich ganz gut mit den üblichen programmier-empfehlungen -- kapselung, prägnante doku, vermeidung von seiteneffekten, wo es geht, und so. aber bitte nicht übertreiben, wenn man einen funktionsaufruf einmal durch 3 layer von wrappern in 3 directories verfolgen darf, wird's mühsam. kommentare wieauch.Code:i++; // inkrementiere i
daß mein eigener code allerdings meinen ästhetischen ansprüchen genügen würde, ist meistens nicht der fall, ich glaub, dazu bin ich zu ungeduldig, wenn's funktioniert, kann ich mich der nächsten baustelle widmen
ja, und versionskontrolle ist essentiell. wenn man viel codet, sollte man sich einmal einen abend oder ein wochenende mit versionskontrollsystemen auseinandersetzen und sich ein repository anlegen.
ciao,
cm.
Genau das ist für mich in diesen ersten Monaten wichtig zu lernen. Dass ich/man mit der Zeit besser "sprechen" lernt und sich auch kürzer/besser "ausdrücken" kann - na ja, das ist ein zusätzlicher Wunsch, der sich irgendwann für mich erfüllen wird.
Ansätze dazu + Absichten sind bei mir vorhanden. Aber, danke - es ist manchmal für Anfänger wie mich nach den ersten Schritten ziemlich wichtig die allgemeine Richtung (neu) zu erkennen bzw. darauf gestoßen zu werden.
Ja, das mit dem Sich-zurechtfinden ist ein Teil dessen, warum ich meinen Code so strukturiere und auf verschiedene Pakete aufteile oder zusammenfasse.
Versionskontrollsysteme kenne ich nicht, das ganze Thema wurde mir erst jetzt durch Dich und markusj klar(er). Aber elementare Ansätze sind vorhanden: ich sichere meine komplette Projektdirectory einschließlich zugehöriger hex-Datei teilweise täglich mit einem halbwegs aussagekräftigen Directorynamen in eine subdirectory "alter code". Ausserdem schreibe ich einen "Fortschrittsbericht" in dem ich Hard-, Software- und Testarbeiten, auch Anmerkungen und Wünsche dokumentiere. Und seit vielen Jahren weiß ich: ... wenn ich "alles" aufschreibe, dann habe ich ungefähr die Hälfte von dem, was ich in drei oder sechs Monaten oder später brauche, um bestimmte Dinge wieder zu finden oder zu rekapitulieren.
Jedenfalls danke für Eure Ratschläge.
Ciao sagt der JoeamBerg
@oberallgeier: Sieh dir mal TortoiseSVN an (ich nehme an, dass du unter Windows entwickelst)
Es ist relativ einfach möglich, ein lokales Repository einzurichten, die Dokumentation zu dem Thema ist auch sehr gut.
Der Fortschrittsbericht findet dann ganz von alleine statt, weil man zu jedem "Commit" eine "Commit-Message" schreibt, die die Änderungen zusammenfassen sollte.
Eclipse bietet einem nach etwas Fingerbrechen sogar die Möglichkeit, solche "Commit-Messages" automatisch vorzubereiten.
mfG
Markus
PS: Im übrigen fällt es mir, evtl. auch weil ich objektorientiert Programmieren gelernt habe, teilweise verdammt schwer, die saubere Trennung von Modulen in C zu realisieren - vor allem weil man auf µCs dann auf malloc & co. verzichtet / verzichten sollte.
Schrecklich - so etwas nennt man "einen alten Mann überfordern". Ok, markusj, danke für den Hinweis. Ich kam mit diesem Hinweis in ein Land, das mir völlig unbekannt war und in dem ich noch keinerlei Orientierung habe. SCM, Heap, malloc - alles Bäume, die ich nicht kannte. Und davon ein ganzer Wald - aber es scheint wirklich interessant zu sein. Da ich C - in meiner Variante Cäh - erst seit etwas über einem Jahr nutze und noch jede Menge holpriger Lösungen in meinen Code einbaue, ist dieser Wald interessant, aber für mich derzeit gefährlich bzw. recht verwirrend. Ich werde in Stück für Stück erforschen.
A propos holprige Lösungen. Die beiden Kunstruktionen (das u ist hier gewollt) verstehe ich nicht wirklich:
(((ADDRESS) & (1<<BIT))?1:0) . . . . sowie mein eigenes Oevre
((!(ADDR) & ~(1<<BIT))) . . . . . . . . .// Fragt Bit = 0?
Vielleicht kann ich meinen Kernighan/Ritchie nicht richtig lesen. Was bedeutet im ersten Statement "?1:0 " und was bedeutet das "((!(" - aus dem KR lese ich "..Der Operand des Operators ! muss einen arithmetischen Typ besitzen oder ein Zeiger sein.." Äähhhh ? ? ? Ausserdem kann ich in meiner Erfindung doch das äusserste Klammernpaar weglassen ! ? ! ? Oder nicht?
Danke im Voraus für Eure Hilfe.
Ciao sagt der JoeamBerg
Das Fragezeichen ist in C so eine Art IF ... Then .... Else...., nur hat für Werte. Bei einem Ausdruck A ? B : C wird erst A ausgewertet, wenn A = 0 ist kreigt der Ausdruck den Wert von C, sonst von B.
Wenn der Ausdruck einefach nur einer Variable zugewiesen wird kann man die Klammer außen wohl weglassen, in einem IF , While oder so natürlich nicht. Aber ein paar Klammern mehr als nötig sind ja nicht so schlimm, wie eine zu wenig.
Berechtigungen
Zitieren
Lesezeichen