Ich suche gerade nach den #define, Die die Arduino IDE erstellt, je nachdem, welchen Arduino/µC man ausgewählt hat.
Momentan geht's mir darum, den Sketch bei einem MEGA anders zu kompileren, als bei einem Uno/Nano, da ich den externen Zugriff auf die µC-eigenen I2C/SPI/seriellen Pins nicht zulassen möchte - die restlichen Pins aber durchaus verändert werden dürften.
Seriell bei Beiden 0 und 1 (sollte auch ohne #ifdef hinzubekommen sein)
I²C 18/19 zu 20/21 (ab hier wird's 'kompliziert und knifflig')
SPI 10...13 zu 50...53
Denke, daß ich per #ifdef die µC entsprechend behandeln möchte - oder gibt's hier eine bessere Lösung?
postmaster-ino:
Momentan geht's mir darum, den Sketch bei einem MEGA anders zu kompileren, als bei einem Uno/Nano,
Neben den defines für den Prozessor gibt's ja auch noch die defines für das Board, die in der boards.txt festgelegt werden. Zur Unterscheidung der Boards sind die vielleicht besser geeignet. Diese defines werden dem Compiler per -D Kommandozeilenoption mitgeteilt. Die kannst Du sehen, wenn Du die 'ausführliche Ausgabe während Kompilierung' einschaltest.
postmaster-ino:
Einen Schalter, daß der Kompiler alle gerade bekannten #define ausspuckt, gibt's also nicht.
Doch, das geht auch. Wenn Du alle vom Compiler selbst generierten defines wissen willst, kannst Du in einem Verzeichnis ein leeres .cpp file erzeugen, und dann dort eine Eingabeaufforderung starten und dieses Kommando eingeben( Den Pfad zum avr-g++ musst Du natürlich gegebenenfalls anpassen ): "C:\\Program Files (x86)\\Arduino\\hardware\\tools\\avr/bin/avr-g++" -Os -E -mmcu=atmega2560 -dM testprog.cpp >>definesCpp.txtDurch anpassen des Prozessors in der -m Option kannst Du die prozessorspezifischen defines sehen. Allerdings musst Du in der Menge der defines schon ein wenig danach suchen - die Zahl der defines ist schon beachtlich. Am besten im File nach 'AVR' suchen
Auch Dir ein herzliches Danke - Das klingt nach einer Arbeit, Die man Seinem Feind nicht wünscht
Ich versuche mich vorerst an den von mir oben schon genannten defines, Das müsste für meine Zwecke derzeit locker reichen.
Akut möchte ich ja nur beim Uno Eingaben 0...12 - wie beim Mega 0...62 und bei Beiden Werte ab 0x80 für gültig erklären (eigene Pins zu Port-Expander-Pins).
da ich den externen Zugriff auf die µC-eigenen I2C/SPI/seriellen Pins nicht zulassen möchte - die restlichen Pins aber durchaus verändert werden dürften.
Damit bist du aber noch nicht fertig
Stelle ich mir auch schwierig vor, wie man alle möglichen Varianten von z.B. pinMode(0, OUTPUT);
verhindern könnte.
Oder du hackst die Zuordnung Pin-Niummer -> {PORT, Bit} im Innern der Arduino IDE. Die ist schon hardware-abhängig. Hoffentlich stört das nicht die interne Verwendung der Pins z.B. in HardwareSerial.
Nur um zwischen Mega und UNO/Nano zu unterscheiden sind die #defines für den Prozessortyp wohl am einfachsten. Wenn Du auch noch UNO/Nano unterscheiden willst wären die boardspezifischen defines besser. Aber das ist in deinem Fall ja gar nicht gewünscht, da sich UNO und Nano in der Beziehung gleich verhalten.
Alle defines auszugeben ist soo aufwändig jetzt auch nicht. Für deinen Anwendungsfall aber sich nicht notwendig. Aber trotzdem interessant, was der Compiler so alles vordefiniert ( sind über 500! defines ).
Wen's interessiert ( aber sich die 'Mühe' nicht machen will ) ein Beispiel im Anhang
Aktuell verwende ich UNOs, um im Heizungskeller über Digital-Pins SSRs anzusteuern.
Da für Logik UND Relais-Know-How nicht genug Platz im Steinchen ist, übernimmt das Denken ein externer Uno, wird aber ein Mega werden, wo eine Art SPS werkeln wird (Was die Sache ungemein aufbläht).
Dieser Master verarbeitet Sensor- und Aktor-Informationen, Die bei mir im CAN-Bus rumsausen und entscheidet damit, welcher Schieber wohin gefahren wird, ob der Ölkessel anspringen soll, die Pumpe für die thermische Solar-Anlage abgeschaltet werden kann oder ob der WC-Wasservorrat im Speicher mit außerhalb gefangenem Regenwasser aufgefüllt werden soll.
Da wollte ich mir die Relais-Knoten so bauen, daß ich von Außen (also über CAN) ein weiteres Relais ansteuern kann, ohne den Knoten-Arduino neu flashen zu müssen - langsam wandern Die nämlich an die Wand und sind dort auch fest montiert - das Provisorium weicht einer Fest-Installation.
Ok, etwas weiter ausgeholt ...
Wenn nun von Außen der Befehl kommt, den 27.ten Pin als Output auf LOW zu schalten, schaut der Relais-Knoten nach, welcher physikalische Pin Das denn wäre - somit komme ich SO auch nicht an 'die verbotenen Pins' heran - Die sind gar nicht in der Liste (werden wohl Bereichsabfragen per IF werden) vorhanden sind.
Aber JA, auch INPUT (also HIGH-Z) ist geplant.
Damit wird der Knoten zwar fast schon zum Sensor-Knoten (die Abfrage der Pins fehlt), ich werden wohl sehen, in welche Richtung die Reise zum Schluss gegangen ist.
MfG
PS: Toll, nun habe ich auch noch ein Beispiel, Welches ich mir anschauen kann ... so komme ich NIE zum Arbeiten
Danke Euch für Eure Ausführungen!