Hi all Wie im Betreff zu lesen, ist es möglich im Code den eingestellten Typ auszulesen, der im Makefile hinterlegt ist. Hintergrund für die Sache. Ich habe ein Projekt welches für den ATMega324P geschrieben ist und nun sind ATMega324PA bestellt worden. Leider ist hier die komplette SPI anders definiert und ich müsste zwei Codes verwalten, was ich aber wegen der Redundanz natürlich vermeiden will. Gibts hier eine saubere und einfach Möglichkeit und wenn ja welche gg Danke für die Infos! Gruß MB
In der Art? #if defined (_AVR_ATmega8_) ... #elif defined (_AVR_ATmega168_) ... #endif
Günter R. schrieb: > Wie im Betreff zu lesen, ist es möglich im Code den eingestellten Typ > auszulesen, der im Makefile hinterlegt ist. > > Gibts hier eine saubere und einfach Möglichkeit und wenn ja welche *gg* Schaue dir mal beispielsweise die Datei io.h an, danach sollte klar sein, wie man mit ein paar #ifdef den Code für zwei Controller anpassen kann.
Das kommt drauf an, welche Programmiersprache, Compiler, Entwicklungsumgebung du einsetzt. MfG
Der ATMega324PA ist binärkompatibel zum ATMega324P. Das heißt Code, der für den ATMega324P erstellt worden ist, läuft ohne Änderungen auch auf dem ATMega324PA! Und Umgekehrt, solange man nicht die paar wenigen beim ATMega324PA neu hinzugekommenen Funktionen nutzt. Das kannst du leicht selber überprüfen, indem du einfach die Register Belegung am Ende der beiden Datenblätter vom ATMega324P und ATMega324PA vergleichst. Es gibt bei Atmel übrigens Migration Notes, die genau die Unterschiede zwischen einzelnen µC Typen erklären. Wenn es also nur darum geht eine fertig entwickelte Software für den ATMega324P ausnahmsweise, wegen Beschaffungsproblemen, auf einem ATMega324PA laufen zu lassen, dann ist das Möglich. Der einzige (wirkliche) Unterschied sind andere Signaturbytes. Wenn du aber wirklich neu Kompilieren möchtest, dann macht man das am besten über die oben erwähnten #ifdef Präprozessor Direktiven.
Erst mal danke für die Antworten! Wie SF richtig sagt, ist der PA wirklich komplett kompatibel zum P, bis auf die ID. Hab nun die header files durch gesehen und in der Tat liegt es nur an denen, dass der Code beim SPI nicht gleich sein darf. So wird zB aus "SPCR" beim PA "SPCR0". Warum machen die Herrn von AVR sowas?? Gibts hier einen wirklich guten Grund dafür? Ich bin ja normal in der PC SW Welt zu Hause, aber mich würde man "schlagen", wenn ich sowas verbreche gg So denn,
Wahrscheinlich gibt es beim -PA nicht nur ein "SPCR0" sondern auch ein "SPCR1", wo dann weiter Bits untergebracht sind.
Matthias schrieb: > Wahrscheinlich gibt es beim -PA nicht nur ein "SPCR0" sondern auch ein > "SPCR1", wo dann weiter Bits untergebracht sind. Das ist ja das witzige, dass es eben nicht so ist. Aus meiner Sicht ist hier eine andere Definition nicht nötig...
Günter R. schrieb: > Warum machen die Herrn von AVR sowas? Das "machen" die Herren die Günter R. schrieb: > die header files machen...
Günter R. schrieb: > Hab nun die header files durch gesehen und in der Tat liegt es nur an > denen, dass der Code beim SPI nicht gleich sein darf. So wird zB aus > "SPCR" beim PA "SPCR0". Wenn sich beim PA wirklich nur der Registername geändert hat, z.B. von "SPCR" in "SPCR0" kannst du natürlich etwas unsauber auch einfach ein #ifndef SPCR #define SPCR SPCR0 #endif einfügen, so dass du im Code weiterhin SPCR einfach verwenden kannst Mfg
Läubi .. schrieb: > Günter R. schrieb: >> Warum machen die Herrn von AVR sowas? Ist letztlich eine Form von Standardisierung. Egal ob der Controller ein SPI-Interface hat oder mehr, das erste hat am Ende immer eine 0. Durchgängig sieht man dies bereits bei den ATXmega.
Günter R. schrieb: > Hab nun die header files durch gesehen und in der Tat liegt es nur an > denen, dass der Code Ähh, der Quellcode. Der Binärcode dürfte identisch sein. > beim SPI nicht gleich sein darf. So wird zB aus > "SPCR" beim PA "SPCR0". Der AVR kennt diese symbolischen Namen nicht. Diese gelten nur zwischen Quellcode und Compiler (bzw. Assembler). Und sie representieren nur die Adresse (bzw. Bitposition). Die Adresse beider Registernamen dürfte gleich sein. > Warum machen die Herrn von AVR sowas?? Weil es inzwischen immer mehr AVRs gibt, die üppiger mit Peripherie-Features ausgestattet sind (z.B. 2 USART, 2 SPI). Als viel schlimmer empfinde ich, dass etliche I/O-Register (auch ohne Änderung des Namens) in einen anderen Adressbereich verschoben wurden (vom I/O-Soace, der mit IN/OUT angesprochen werden kann, zum extended-I/O-Space, der wie SRAM mit LDS/STS oder über Pointer angesprochen werden muss). > Gibts hier einen wirklich guten > Grund dafür? Ja, man will die Bezeichner vereinheitlichen. Deshalb werden bei neuen Typen auch die Peripherie-Einheiten mit Suffix "0" gekennzeichnet, die nur einmal vorhanden sind, aber bei anderen Typen doppelt verfügbar sind. Das ist zwar in der Übergangszeit etwas nervig, hat aber langfristig Sinn. > Ich bin ja normal in der PC SW Welt zu Hause, aber mich > würde man "schlagen", wenn ich sowas verbreche gg Das glaube ich nicht, die "Verbrechen" sind beim PC viel größer. Aber das steht hier und jetzt nicht zur Debatte. ...
Christoph Budelmann schrieb: > Läubi .. schrieb: >> Günter R. schrieb: >>> Warum machen die Herrn von AVR sowas? > > Ist letztlich eine Form von Standardisierung. Egal ob der Controller ein > SPI-Interface hat oder mehr, das erste hat am Ende immer eine 0. > Durchgängig sieht man dies bereits bei den ATXmega. OK das macht Sinn, von der Seite hab ich das nie betrachtet. Lange Rede kurzer Sinn mit den genannten Infos krieg ich das nun hin. Danke an alle! Gruß MB
Glaskugel schrieb: > Das kommt drauf an, welche Programmiersprache, Compiler, > Entwicklungsumgebung du einsetzt. > MfG Schmarrn. Das ist einer der wenigen Fälle wo man mit Schema-F zum Ziel kommt.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.