Moin,
ich habe folgende Situation: Ich programmiere in der Arduino IDE, möchte
das entstehende .hex-File aber in einen externen uC brennen(ohne
Bootloader), dank vorhandenen ISP-Programmer auch nicht das Problem.
Der externe uC soll jedoch nicht mit einem 16MHz Quarz laufen, sondern
einen Baudratenquarz zur Verfügung gestellt bekommen.
Wie kann ich dem in der arduino IDE verwendeten Compiler mitteilen, dass
ich nicht 16MHz als Takt nutzen möchte, sondern einen eigenen?
Im atmel Studio kann ich ja im Programm per
1
#define F_CPU xxx
ja bekannt machen, mit welcher Frequenz der Controller später laufen
soll.
Kann ich dies hier auch anwenden, oder überschreibt die Einstellung im
Makefile diese Zeile?
Gruß
Marco G. schrieb:> Wie kann ich dem in der arduino IDE verwendeten Compiler mitteilen, dass> ich nicht 16MHz als Takt nutzen möchte, sondern einen eigenen?
Einfach mal so ins Blaue geraten:
Du baust dir eine passende Boardbeschreibung zusammen und bindest die
mit Hilfe des Boardverwalters ein.
Marco G. schrieb:> Im atmel Studio kann ich ja im Programm per#define F_CPU xxx ja bekannt> machen, mit welcher Frequenz der Controller später laufen> soll.
Nö, diese Angabe wird nur im Software-Programmcode verwendet, z.B. bei
der "delay" Funktion...
Die Frequenz legst Du über den Anschlossen Quarz oder sonstige
Taktquelle fest... wichtig, die Fuses müssen passen zur gewählten
Taktquelle...
Skyper schrieb:> Marco G. schrieb:>> Im atmel Studio kann ich ja im Programm per#define F_CPU xxx ja bekannt>> machen, mit welcher Frequenz der Controller später laufen>> soll.
Da habe ich mich ein wenig missverständlich ausgedrückt. Das die
eigentlich Taktquelle per Fuses eingestellt wird weiß ich, da ich ohne
die Arduino IDE schon viele AVRs programmiert habe. Nur muss ich dem
Compiler ja mitteilen, mit welcher Taktfrequenz der uC später betrieben
wird, damit die Funktionen, wie z.B. _delay_ms()korrekt funktionieren
und nicht zu schnell oder zu langsam ablaufen.
Mir geht es hauptsächlich um die passende Baudrateneinstellung, nicht um
den eigentliche delay.
Trotzdem ist mir leider noch nicht klarer, ob die einstellung in einem
Makefile gegenüber der im Code Priorität hat oder umgekehrt.
Marco G. schrieb:> Kann ich dies hier auch anwenden, oder überschreibt die Einstellung im> Makefile diese Zeile?
Die Definition im Code hat Vorrang vor der Definition im makefile.
Marco G. schrieb:> Mir geht es hauptsächlich um die passende Baudrateneinstellung, nicht um> den eigentliche delay.
Und wer oder was hindert Dich daran, die im Kopf berechneten Werte für
die Baudratenregister von Hand zu setzen? Ist alles kein Hexenwerk und
auf Maschinenebene sehr überschaubar.
Und ja, das überlässt man dem Präprozessor des Compilers, aber doch nur
dann, wenn man ihm vertraut, weil man seine Arbeitsweise kennt. ;-)
MfG
Harry L. schrieb:> Marco G. schrieb:>> Kann ich dies hier auch anwenden, oder überschreibt die Einstellung im>> Makefile diese Zeile?>> Die Definition im Code hat Vorrang vor der Definition im makefile.
Ja. Außerdem schmeißt der Compiler mindestens eine Warnung raus, wenn
man das gleiche Präprozessormakro ein zweites Mal definiert.
Am besten aufgehoben ist das im Makefile, denn dann ist es überall im
Code sichtbar (und gleich). Ein #define im Code ist nur dann
gleichwertig, wenn das Projekt nur aus einem einzigen File besteht.
Axel S. schrieb:>...> Ja. Außerdem schmeißt der Compiler mindestens eine Warnung raus, wenn> man das gleiche Präprozessormakro ein zweites Mal definiert.
Die wird man los indem man vorher #undef benutzt.
Du kannst deinen "eigenen Arduino" in der
{ARDUINO}/hardware/arduino/boards.txt datei einstellen. Da kannst du die
Taktfrequenz und vieles mehr einstellen. In der IDE musst du dann nur
das richtige Board vor dem Upluad auswählen
Tim schrieb:> Warum von Hand anpassen? Das macht doch schon#define F_CPU xxxAxel S. schrieb:> Am besten aufgehoben ist das im MakefileKarl schrieb:> Du kannst deinen "eigenen Arduino" in der> {ARDUINO}/hardware/arduino/boards.txt datei einstellen
das sind immer tolle Tipps
1.#define hilft nix, jedenfalls nicht dem Bootloader
2. makefile wäre richtiger, nur bekommt der bootloader auch nix ab davon
3. klar kann man das machen, nur wer ändert dann den bootloader
ich habe hier etliche arduino mighty 1284p die mit 16MHz klasse laufen
zum Bootloader patchen bin ich noch nicht gekommen für Baudratenquarze
14,xxxMHz oder 21,xxxMHz wären ja nett
16MHz ist nur nett bei 1M upload aber typische 115k klemmen halt
Joachim B. schrieb:>> das sind immer tolle Tipps>> 1.#define hilft nix, jedenfalls nicht dem Bootloader
Er will keinen Bootloader
> 2. makefile wäre richtiger, nur bekommt der bootloader auch nix ab davon
Braucht er auch nicht. Er will keinen
> 3. klar kann man das machen, nur wer ändert dann den bootloader
Wozu, wenn er ihn gar nicht will?
Marco G. schrieb:> möchte das entstehende .hex-File aber in einen externen uC> brennen(ohne Bootloader)
Joachim B. schrieb:> 3. klar kann man das machen, nur wer ändert dann den bootloader
Den bootloader kann man auch vorgeben.
> ich habe hier etliche arduino mighty 1284p die mit 16MHz klasse laufen>> zum Bootloader patchen bin ich noch nicht gekommen für Baudratenquarze>> 14,xxxMHz oder 21,xxxMHz wären ja nett
Das ist kein patchen, sonder ein anpassen.
> 16MHz ist nur nett bei 1M upload aber typische 115k klemmen halt
Was soll uns das sagen?
The D. schrieb:> Axel S. schrieb:>>...>> Ja. Außerdem schmeißt der Compiler mindestens eine Warnung raus, wenn>> man das gleiche Präprozessormakro ein zweites Mal definiert.>> Die wird man los indem man vorher #undef benutzt.
Das ist dann die blödeste Idee überhaupt. Etwas so wichtiges wie die
Taktfrequenz des Controllers will man zuverlässig und für alle
Programmteile zentral konfigurieren. Genau deswegen schrieb ich auch
Axel S. schrieb:> Am besten aufgehoben ist das im Makefile
bzw. für die Benutzer irgendwelcher IDE sollte das #define irgendwo in
den Projekteinstellungen gemacht werden.
Wenn man das dann irgendwo im Code per #define überschreibt, dann ist
das Pfusch und der Präprozessor weist vollkommen zurecht auf diesem
Pfusch hin. Das per #undef abzustellen, ist noch viel schlimmerer
Pfusch.
Wenn wir beide jetzt in der Situation wären, daß ich entscheiden sollte
ob du eingestellt wirst oder nicht, dann hättest du dich gerade
disqualifiziert.
Axel S. schrieb:>> Wenn wir beide jetzt in der Situation wären, daß ich entscheiden sollte> ob du eingestellt wirst oder nicht, dann hättest du dich gerade> disqualifiziert.
Bestreitet niemand, daß das nicht die beste Lösung ist. Für den
einmaligen Einsatz im Hobbybereich aber akzeptabel. Ob du mich wegen
dieses Kommentars nicht mehr lieb hast ist mir ehrlich gesagt ziemlich
egal.
Also ich habe zwei Arduino Nano's mit 16Mhz und einem ESP8266 bei 115200
Baud zwei Wochen lang im Dauertest gehabt. Lief ohne Probleme fehlerfrei
durch.
Dennoch ist die Kombination 16Mhz / 115200 Baud nicht optimal. Verkaufen
würde ich sowas nicht - nur basteln.
Stefan U. schrieb:> Dennoch ist die Kombination 16Mhz / 115200 Baud nicht optimal. Verkaufen> würde ich sowas nicht - nur basteln.
Nenn das Kind doch beim Namen: Der Abtastzeitpunkt gegenüber einem
echten 115200 Baud Signal ist beim letzten Bit um knapp 20% verschoben.
Ob das tolerierbar ist, hängt von Fehlerfreunlichkeit des
Datenprotokolls und von der Qualität der Übertragungsstrecke ab.
@ Stefan Us (stefanus)
>Dennoch ist die Kombination 16Mhz / 115200 Baud nicht optimal. Verkaufen>würde ich sowas nicht - nur basteln.
Der systematische Baudratenfehler ist mit 3,4% arg grenzwertig.
Mit einem ATXmega, MSP430 etc. ist man da besser beraten, die haben
fraktionale Baudratenteiler.
Thread beobachten
Seitenaufteilung abschalten