Hi, ich möchte ein Projekt mit einem Arduino Board realisieren und auch die Arduino Software verwenden. Ich müsste aber wissen, welche Ressourcen von der Software verwendet werden, zB Timer oder ähnliches. Es gibt ja zB die Funktion micros(). Die muss ja im Hintergrund irgendwie mitlaufen, also schätze ich, dass ein Timer belegt wird. Wo finde ich Infos darüber? Gruß und schönen Sonntag Markus
Markus B. schrieb: > Ich müsste aber wissen, welche Ressourcen von der Software verwendet > werden, Da die Software auf dem PC läuft, RAM. Je nach Zusatztools auch mehr oder weniger Festplattenspeicher. Soweit ich weis ist sie nicht Multiprozessorfähig, nutzt also nur 1 Kern.
Markus B. schrieb: > Wo finde ich Infos darüber? Ich habe Goolge benutzt - 7ter Treffer: https://www.heise.de/developer/artikel/Timer-Counter-und-Interrupts-3273309.html
Plim schrieb: > > Da die Software auf dem PC läuft, RAM. Je nach Zusatztools auch mehr > oder weniger Festplattenspeicher. Soweit ich weis ist sie nicht > Multiprozessorfähig, nutzt also nur 1 Kern. Du hast mich missverstanden. Ich meine die Software auf dem Controller
Markus B. schrieb: > Wo finde ich Infos darüber? Die reine nackte Wahrheit findest du in den Quellen, des Arduino Core, auf deinem Rechner. Oder auch hier: https://github.com/arduino/Arduino/tree/master/hardware/arduino/avr/cores/arduino
Markus B. schrieb: > Du hast mich missverstanden. Ich meine die Software auf dem Controller Das nennt sich Firmware
Plim schrieb: > Markus B. schrieb: >> Du hast mich missverstanden. Ich meine die Software auf dem Controller > > Das nennt sich Firmware Firmware ist auch Software...
Plim schrieb: > Markus B. schrieb: >> Du hast mich missverstanden. Ich meine die Software auf dem Controller > > Das nennt sich Firmware Allein aus dem Kontext (Timer, micros()) sollte sich erkennen lassen, dass nicht die PC Software gemeint ist. Vielen Dank für die anderen Antworten. Damit komme ich weiter.
Markus B. schrieb: > Allein aus dem Kontext (Timer, micros()) sollte sich erkennen lassen, > dass nicht die PC Software gemeint ist. Weil beim PC keine Timer und micros() benutzt werden?
Plim schrieb: > Markus B. schrieb: >> Allein aus dem Kontext (Timer, micros()) sollte sich erkennen lassen, >> dass nicht die PC Software gemeint ist. > > Weil beim PC keine Timer und micros() benutzt werden? Alle haben geschnallt, worum es geht. Nur du stellst dich dumm. Oder ist das gar keine Verstellung?
Markus B. schrieb: > Ich müsste aber wissen, welche Ressourcen von der Software verwendet > werden, zB Timer oder ähnliches. Es gibt ja zB die Funktion micros(). > Die muss ja im Hintergrund irgendwie mitlaufen, also schätze ich, dass > ein Timer belegt wird. > > Wo finde ich Infos darüber? Im File "wiring.c" befindet sich folgender Abschnitt:
1 | unsigned long micros() { |
2 | unsigned long m; |
3 | uint8_t oldSREG = SREG, t; |
4 | |
5 | cli(); |
6 | m = timer0_overflow_count; |
7 | #if defined(TCNT0)
|
8 | t = TCNT0; |
9 | #elif defined(TCNT0L)
|
10 | t = TCNT0L; |
11 | #else
|
12 | #error TIMER 0 not defined
|
13 | #endif
|
14 | |
15 | #ifdef TIFR0
|
16 | if ((TIFR0 & _BV(TOV0)) && (t < 255)) |
17 | m++; |
18 | #else
|
19 | if ((TIFR & _BV(TOV0)) && (t < 255)) |
20 | m++; |
21 | #endif
|
22 | |
23 | SREG = oldSREG; |
24 | |
25 | return ((m << 8) + t) * (64 / clockCyclesPerMicrosecond()); |
26 | }
|
Calli schrieb: > Alle haben geschnallt, worum es geht. Nur du stellst dich dumm. > Oder ist das gar keine Verstellung? Ist angeboren...
Markus B. schrieb: > ich möchte ein Projekt mit einem Arduino Board realisieren und auch die > Arduino Software verwenden. > > Ich müsste aber wissen, welche Ressourcen von der Software verwendet > werden, zB Timer oder ähnliches. Ich halte diese Fragestellung für ziemlich abwegig: Wer Hochsprache programmiert, will sich eigentlich nicht mit diesen Details befassen. Wenn man es dennoch weiß, was kann man ändern? Ich habe hier ein Projekt in Arbeit, wo ich den Programmspeicherbedarf mit Argwohn betrachte. Ändern kann ich ihn aber nicht, außer, anständig zu programmieren und zu versuchen, bestimmte fertige Funktionen zu meiden.
Manfred schrieb: > Ich halte diese Fragestellung für ziemlich abwegig: Wer Hochsprache > programmiert, will sich eigentlich nicht mit diesen Details befassen. C und C++ sind doch keine Hochsprachen. Das Wissen darüber was bereits belegt ist, nützt einem jedenfalls zu vermeiden, dass man ausversehen wo dazwischen funkt.
Manfred schrieb: > Ich halte diese Fragestellung für ziemlich abwegig: Wer Hochsprache > programmiert, will sich eigentlich nicht mit diesen Details befassen. Wie kommst du drauf, dass man sich beim Programmieren in einer Hochsprache, nicht mit der Hardware des uC befassen muss? Meinst du, die Libraries dafür fallen vom Himmel?
Manfred schrieb: > will sich eigentlich nicht mit diesen Details befassen. Man muss allerdings manchmal Sachen machen die man eigentlich nicht will. > Wenn man es dennoch weiß, was kann man ändern? .... > außer, anständig zu programmieren und zu versuchen, bestimmte fertige Funktionen zu meiden. Eben, dazu muss man aber dann doch einige Details kennen.
Manfred schrieb: > Ich halte diese Fragestellung für ziemlich abwegig: Wer Hochsprache > programmiert, will sich eigentlich nicht mit diesen Details befassen. Bei embedded gibt's halt auch schnell mal "für Erwachsene"(tm).
Manfred schrieb: > Ich halte diese Fragestellung für ziemlich abwegig: Wer Hochsprache > programmiert, will sich eigentlich nicht mit diesen Details befassen. muss man aber manchmal, ich habe viel mit dem Arduino nano328p gearbeitet, aber als mir der zu eng wurde war ich froh das es den Arduino mighty mini 1284p gab. Ich installierte nach Anleitung und fast alles klappte, dann irgendwo klemmte es, es lag an der Timerbelegung, also passte ich die Timer und die ISR Aufrufe an, manchmal muss ich beim 1284p von TIMER1 auf TIMER2 oder TIMER3 ausweichen.
1 | #if defined(__AVR_ATmega328P__)
|
2 | #define TIMSKx TIMSK1
|
3 | #define OCIExA OCIE1A
|
4 | #define TIMERx_COMPA_vect TIMER1_COMPA_vect // ATmega
|
5 | #define TCCRxA TCCR1A
|
6 | #define COMxA0 COM1A0
|
7 | #define OCRxA OCR1A
|
8 | #define TCCRxB TCCR1B
|
9 | #define WGMx2 WGM12
|
10 | #define CSx0 CS10
|
11 | |
12 | #define LED_ARDUINO 5
|
13 | #define LED_ARDUINO_DDR DDRB
|
14 | #define LED_ARDUINO_PORT PORTB
|
15 | |
16 | #elif defined(__AVR_ATmega1284P__) // --------- m1284p ------------
|
17 | |
18 | #define TIMER1
|
19 | |
20 | #ifdef defined(TIMER1)
|
21 | #define TIMSKx TIMSK1
|
22 | #define OCIExA OCIE1A
|
23 | #define TIMERx_COMPA_vect TIMER1_COMPA_vect // ATmega
|
24 | #define TCCRxA TCCR1A
|
25 | #define COMxA0 COM1A0
|
26 | #define OCRxA OCR1A
|
27 | #define TCCRxB TCCR1B
|
28 | #define WGMx2 WGM12
|
29 | #define CSx0 CS10
|
30 | #elif defined(TIMER2)
|
31 | #define TIMSKx TIMSK2
|
32 | #define OCIExA OCIE2A
|
33 | #define TIMERx_COMPA_vect TIMER2_COMPA_vect // ATmega
|
34 | #define TCCRxA TCCR2A
|
35 | #define COMxA0 COM2A0
|
36 | #define OCRxA OCR2A
|
37 | #define TCCRxB TCCR2B
|
38 | #define WGMx2 WGM22
|
39 | #define CSx0 CS20
|
40 | #elif defined(TIMER3)
|
41 | #define TIMSKx TIMSK3
|
42 | #define OCIExA OCIE3A
|
43 | #define TIMERx_COMPA_vect TIMER3_COMPA_vect // ATmega
|
44 | #define TCCRxA TCCR3A
|
45 | #define COMxA0 COM3A0
|
46 | #define OCRxA OCR3A
|
47 | #define TCCRxB TCCR3B
|
48 | #define WGMx2 WGM32
|
49 | #define CSx0 CS30
|
50 | |
51 | #define LED_ARDUINO 7
|
52 | #define LED_ARDUINO_DDR DDRB
|
53 | #define LED_ARDUINO_PORT PORTB
|
54 | |
55 | #else
|
56 | #error TIMER fehlt
|
57 | #endif
|
58 | #ifdef LED_ARDUINO
|
59 | #ifdef LED_ARDUINO_DDR
|
60 | #ifdef LED_ARDUINO_PORT
|
61 | #define LED_ARDUINO_ON LED_ARDUINO_PORT |= (1<<LED_ARDUINO)
|
62 | #define LED_ARDUINO_OFF LED_ARDUINO_PORT &= ~(1<<LED_ARDUINO)
|
63 | #define LED_ARDUINO_START 5
|
64 | #define LED_ARDUINO_ONOFF_TIME 2 // x10ms
|
65 | #endif // #ifdef LED_ARDUINO_DDR
|
66 | #endif // #ifdef LED_ARDUINO_PORT
|
67 | #endif // #ifdef LED_ARDUINO
|
die FastLED Lib ergab bei Nutzung vom 1284p das die Zeit für eine LED 10% langsamer ist, https://www.mikrocontroller.net/attachment/244099/m1284p_timing.jpg statt 30µs für 24 Bit werden 33 µs gebraucht, da musste ich die fastLED LIB anpassen auf F_CPU 9L/10L, somit wurde das Timing für den ATmega 1284p um 10% langsamer. delay.h
1 | #if F_CPU < 96000000
|
2 | #if defined(__AVR_ATmega1284P__)
|
3 | #define NS(_NS) ( (_NS * ( (F_CPU*9L/10L) / 1000000L))) / 1000
|
4 | #define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / ((F_CPU*9L/10L) / 1000000L)
|
5 | #else
|
6 | #define NS(_NS) ( (_NS * (F_CPU / 1000000L))) / 1000
|
7 | #define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / (F_CPU / 1000000L)
|
8 | #endif
|
Wolfgang schrieb: > Manfred schrieb: >> Ich halte diese Fragestellung für ziemlich abwegig: Wer Hochsprache >> programmiert, will sich eigentlich nicht mit diesen Details befassen. > > Wie kommst du drauf, dass man sich beim Programmieren in einer > Hochsprache, nicht mit der Hardware des uC befassen muss? Wenn es bei "Hochsprache" um das Arduino-Framework geht, dann ist das definitiv so. Denn das ist genau die Stoßrichtung von Arduino: die Hardware des µC so weit zu abstrahieren, daß der Programmierer sich nicht mehr damit befassen muß. Das geht so weit, daß sogar die Architektur (AVR vs. STM32 vs. $YOU_NAME_IT) des µC wegabstrahiert wird. > Meinst du, die Libraries dafür fallen vom Himmel? Für den Arduino-Anwender tun sie das. Mein Rat an den TO wäre, daß er sich entscheiden soll. Entweder er verwendet das Arduino-Framework, dann soll er das durchgängig tun und nicht daran vorbei auf die Hardware zugreifen. Oder er macht es anders herum und wirft das Arduino-Framework raus.
Axel S. schrieb: > dann soll er das durchgängig tun und > nicht daran vorbei auf die Hardware zugreifen. Sorry, aber das funktioniert nicht! Klar, bei kleinen einfachen Sachen ja, aber in der harten Realität, no.
Arduino F. schrieb: > Axel S. schrieb: >> dann soll er das durchgängig tun und >> nicht daran vorbei auf die Hardware zugreifen. > > Sorry, aber das funktioniert nicht! > Klar, bei kleinen einfachen Sachen ja, aber in der harten Realität, no. Keine Ahnung, wo du die Grenze zur "harten Realität" ziehst, aber in der Realität der allermeisten Arduino-Benutzer ist das so. Wenn sich irgendwo die Notwendigkeit(!) ergibt, low-level am Framework vorbei programmieren zu müssen(!), dann wäre meine Schlußfolgerung eher, daß man gerade dem Arduino-Denken entwachsen ist und jetzt auch ohne Stützräder fahren kann.
Axel S. schrieb: > Wenn sich > irgendwo die Notwendigkeit(!) ergibt, low-level am Framework vorbei > programmieren zu müssen(!), dann wäre meine Schlußfolgerung eher, daß > man gerade dem Arduino-Denken entwachsen ist und jetzt auch ohne > Stützräder fahren kann. Du machst ein "Entweder Oder" dahin, wo sich ein recht langwieriger Prozess befindet. Eine solche Erwartungshaltung ist vollkommen unrealistisch. Für dich, ist eine solche "Entweder Oder" Haltung vielleicht möglich. Aber ein Anfänger, mitten im Lernprozess, der ist damit überfordert. Bedenke: Ein 3 Jähriges Kind kann laufen, aber bis es einen Marathon gewinnen kann, vergehen noch Jahre.
Arduino F. schrieb: > Du machst ein "Entweder Oder" dahin, wo sich ein recht langwieriger > Prozess befindet. Eine solche Erwartungshaltung ist vollkommen > unrealistisch. > Für dich, ist eine solche "Entweder Oder" Haltung vielleicht möglich. > Aber ein Anfänger, mitten im Lernprozess, der ist damit überfordert. Der Anfänger bleibt doch einfach beim Arduino Framework. Man kann mit dem nunmal sehr viele Dinge machen.
Ich bin nicht unbedingt ein Anfänger. Ich bin nur faul xD. So lang ich weiß was von Arduino selbst verwendet wird kann ich das ja entweder mit nutzen oder drum herum arbeiten. Wenn mir etwas nicht in den Kram passt schreibe ich es halt selbst
Btw. hab mit einw enig googlen dieses Dokument gefunden: https://code.google.com/archive/p/arduino/wikis/HardwareResourceMap.wiki Wurde aber in einem Beitrag von 2010 gelinkt, also womöglich nicht aktuell.
Markus B. schrieb: > So lang ich weiß was von Arduino selbst verwendet wird kann ich das > ja entweder mit nutzen oder drum herum arbeiten. Wenn mir etwas > nicht in den Kram passt schreibe ich es halt selbst Wenn hier nicht nur allgemeines Geblubber stehen soll, stelle eine konkrete Frage. Welche Resourcen von Arduino genutzt werden, hängt u.a. davon ab, welche Libraries du in deinem Projekt nutzt. Solange du bspw. die Servo-Lib nicht benutzt ist der Timer1 frei. Oder solange du die Wire-Lib nicht nutzt ist das I²C Interface frei.
Wolfgang schrieb: > Wenn hier nicht nur allgemeines Geblubber stehen soll, stelle eine > konkrete Frage. Welche Resourcen von Arduino genutzt werden, hängt u.a. > davon ab, welche Libraries du in deinem Projekt nutzt. Solange du bspw. > die Servo-Lib nicht benutzt ist der Timer1 frei. Oder solange du die > Wire-Lib nicht nutzt ist das I²C Interface frei. Wer genau wissen möchte was Arduino in den Code rein stellt hat die Möglichkeit den LIST file und MAP files z.B. vom Debug File zu erzeugen. Das geht ganz leicht. Kopier den objdump.exe in den Arduino Build Folder. Der Build Folder ist nach dem kompilieren bei W7-10 in: C:\Users\yourusername\AppData\Local\Temp\arduino_build_963314>avr-objdum p -S MyProgram.ino.elf > list.txt Die Build Nummer ist natürlich anders bei jeden neuen Projekt. Für den Map File: avr-objdump -t MyProgram.ino.elf > map.txt Damit bewaffnet weiß man genau was gespielt wird und welche Interrupts vom System benützt werden. Ich finde es jedenfalls ganz nützlich. Für die meisten Sachen verwende ich nur die Serial Lib. und den Rest mache ich mir selber in gewohnter uC Weise. Man muss ja die Arduino Bibliotheken nicht unbedingt verwenden. Abgesehen davon hat Arduino Fanboy schon früher aufgezeigt wie man ganz normal in C mit dem Arduino IDE Projekte bauen kann. Man hat schon Möglichkeiten und für Vieles reicht mir zumindest das. Und sonst habe ich ja noch CodeVision AVR oder andere Tools zur Verfügung. Aber wie schon so viele bestätigt haben, mit Arduino kann man Vieles machen und kann viel Zeit ersparen. Man muss ja nicht immer das Rad neu erfinden. Und die Arduino Bibliotheken müssen nicht unbedingt schlecht sein. Kommt halt darauf an. Für professionelle Anwendungen gelten sowieso ganz andere Randbedingungen und Anforderungen. Was mich betrifft, bin ich dankbar, dass es Arduino und die ganze HW dazu gibt.
Wolfgang schrieb: > Welche Resourcen von Arduino genutzt werden, hängt u.a. > davon ab, welche Libraries du in deinem Projekt nutzt. Es ging mir nur darum, was standardmäßig für alle Projekte verwendet wird. Im Endeffekt ist es nur Timer 0, um den es geht. Der Rest wie UART ist klar
Gerhard O. schrieb: > Die Build Nummer ist natürlich anders bei jeden neuen Projekt. Das habe ich bei mir automatisiert. Eine *.asm und *.map wird damit bei jeder Kompilierung erzeugt. (kann ich gerne mal zeigen, wenn gewünscht) Gerhard O. schrieb: > Abgesehen davon hat Arduino Fanboy schon früher aufgezeigt wie man ganz > normal in C mit dem Arduino IDE Projekte bauen kann. Nicht C, sondern C++, auch wenn es wie C aussieht. Die Hauptdatei *.ino ist immer C++ *.h, *.cpp und *.c kann man in Tabs und Libraries verwenden. und *.S nur in Libraries.
1 | int main() |
2 | {
|
3 | for(;;); |
4 | }
|
Wohl das kleinstmögliche Arduino Programm. Es wird keine Hardware vorbereitet, keine ISR etabliert. Damit funktioniert die Systemzeit nicht mehr. Also millies(), delay() und alle davon abhängigen/Verwandten.
Arduino F. schrieb: > Das habe ich bei mir automatisiert. > Eine *.asm und *.map wird damit bei jeder Kompilierung erzeugt. > (kann ich gerne mal zeigen, wenn gewünscht) Ja, bitte, bitte!:-) Da bin ich noch nicht von mir aus selber drauf gekommen. Geht das permanent? Habe gestern in einer VM MINT-X32 und das Arduino IDE installiert. War schockiert wie viel schneller die Projekte gebaut werden. Da ist mindestens ein Faktor 1-2 Unterschied. Hatte nur am Anfang Schwierigkeiten mit den USB Serial Port Permissions. Gruss, Gerhard
Arduino F. schrieb: > Wohl das kleinstmögliche Arduino Programm. > Es wird keine Hardware vorbereitet, keine ISR etabliert. > Damit funktioniert die Systemzeit nicht mehr. > Also millies(), delay() und alle davon abhängigen/Verwandten. Das macht nichts. Ich bin gewohnt das selber zu machen. Es ist übrigens interessant wie viel Platz die einfache pinmode braucht. Beim ersten Mal über 28 Bytes und dann jeder weitere Gebrauch 6 Bytes. Wenn man bedenkt, dass bei direktem Register Zugriff nur 4 Bytes für den ganzen Port verbraucht werden, merkt man schon wie viel effizienter es so geht. 8 mal pinmode gebraucht ist also 28+56=84bytes, gegenüber 4 Bytes für DDRx und PORTx.
Gerhard O. schrieb: > Ja, bitte, bitte!:-) > Da bin ich noch nicht von mir aus selber drauf gekommen. Geht das > permanent? Permanent! Wird auch nicht bei einem Board Update überschrieben. Die Inbetriebnahme ist etwas fummelig, da man in der Konfigurationsdatei keine Ausgabeumleitungen per > etablieren kann Ich zeige hier meine Pfade. Arduino steckt bei mir in E:\Programme\arduino In E:\bin stecken meine ganzen kleinen selbst geschriebenen Werkzeuge Die Pfade wirst du natürlich anpassen müssen. Es müssen 3 Dateien erstellt werden: ---- E:\Programme\arduino\hardware\arduino\avr\platform.local.txt (in dem Ordner sollte schon eine platform.txt liegen)
1 | recipe.hooks.linking.postlink.1.pattern=E:\bin\avr_asm_dump.bat "{compiler.path}avr-objdump" "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.asm" |
2 | recipe.hooks.linking.postlink.2.pattern=E:\bin\avr_map_dump.bat "{compiler.path}avr-objdump" "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.map" |
---- E:\bin\avr_asm_dump.bat
1 | @Echo OFF |
2 | %1 -h -S %2 > %3 |
---- E:\bin\avr_map_dump.bat
1 | @Echo OFF |
2 | %1 -t %2 > %3 |
Arduino F. schrieb: > Axel S. schrieb: >> Wenn sich >> irgendwo die Notwendigkeit(!) ergibt, low-level am Framework vorbei >> programmieren zu müssen(!), dann wäre meine Schlußfolgerung eher, daß >> man gerade dem Arduino-Denken entwachsen ist und jetzt auch ohne >> Stützräder fahren kann. > > Du machst ein "Entweder Oder" dahin, wo sich ein recht langwieriger > Prozess befindet. Eine solche Erwartungshaltung ist vollkommen > unrealistisch. Nein, ist es nicht. Am Ende ist es aufwendiger, am Arduino Framework vorbei auf die Hardware zuzugreifen, wenn man sich dabei nicht in den Fuß schießen will. Für Trivialitäten wie das direkte Schreiben auf einen PORT mag es ja noch gehen, aber spätestens wenn Timer oder der ADC ins Spiel kommen, gerät man schnell in Teufels Küche. Da kriegt man dann subtile Fehler, die ohne Debugger auch der Profi kaum findet. Viel weniger der Anfänger. Eigentlich es doch ganz einfach: wenn man direkt auf die Hardware zugreift, muß man keine Arduino-Interna kennen. Das ist einfach. Wenn man rein bei der Arduino API bleibt, muß man keine Interna der Hardware kennen. Das ist noch einfacher. Warum sollte man den Aufwand maximieren, indem man beides kennen muß und dazu noch die nichttrivialen Verschränkungen der beiden Layer? > Für dich, ist eine solche "Entweder Oder" Haltung vielleicht möglich. > Aber ein Anfänger, mitten im Lernprozess, der ist damit überfordert. Mit dieser Einstellung lernt der Anfänger niemals laufen. Das ist auch mein Haupt-Kritikpunkt an Arduino: es gibt keinen vernünftigen Upgrade-Pfad von Arduino hin zur direkten Programmierung der Hardware per Register. Alles, was man für Arduino gelernt hat, braucht man für den zweiten Schritt nicht. > Ein 3 Jähriges Kind kann laufen, aber bis es einen Marathon gewinnen > kann, vergehen noch Jahre. Ja. Und wenn es darauf besteht, die von Mutti gehäkelten Babyschuhe immer weiter tragen zu wollen, wird es nie einen Marathon laufen.
Axel S. schrieb: > wenn es darauf besteht, Wer "besteht" denn darauf? Du versuchst in die Ecke zu drängen.... Aber dadurch wird das nicht wahr. Es ist nur deine Projektion. Dumm nur, dass sich die Arduino Jünger nicht deiner Projektion gemäß verhalten. Sie nutzen, was fertig ist, und bei Bedarf wird dazu gebaut. Das ist das übliche Verhalten.
Autor: Axel Schwenke (a-za-z0-9) >Nein, ist es nicht. Am Ende ist es aufwendiger, am Arduino Framework >vorbei auf die Hardware zuzugreifen, wenn man sich dabei nicht in den >Fuß schießen will. Wenn man sich damit auskennt und ein wenig Code lesen kann, ist das eher kein Problem. Und soweit ich aus den Fragen von Markus erkennen kann, ist er ziemlich gut dazu in der Lage. Deine Antworten klingen für mich eher so: Ich weiß nicht recht, wie das Framework funktioniert, will's auch nicht wissen, muss es aber allen anderen ausreden. >Mit dieser Einstellung lernt der Anfänger niemals laufen. Meine Empfehlung: mit Deiner Expertise den Ball lieber mal ein wenig flacher halten.
Arduino F. schrieb: > Permanent! > Wird auch nicht bei einem Board Update überschrieben. Vielen Dank für die Hinweise. Werde es gleich heute Abend ausprobieren. Darauf wäre ich selber nicht gekommen. Gruss, Gerhard
Gerhard O. schrieb: > Vielen Dank für die Hinweise. Gerne doch. Gerhard O. schrieb: > Darauf wäre ich selber nicht gekommen. Danke für die Blumen! Nachtrag: Über eine Rückmeldung würde ich mich sehr freuen.
Arduino F. schrieb: > Gerhard O. schrieb: >> Vielen Dank für die Hinweise. > Gerne doch. > > Gerhard O. schrieb: >> Darauf wäre ich selber nicht gekommen. > Danke für die Blumen! > > Nachtrag: > Über eine Rückmeldung würde ich mich sehr freuen. Gute Nachricht: Ich habe Deine Instruktionen mit den nötigen Anpassungen aufs Wort befolgt und es hat auf Anhieb funktioniert. Nochmals vielen Dank für dieses kleine Juwel. Gruss, Gerhard
Angehängte Dateien:
-
Preferences_Json.jpg
44 KB
Die mir von Arduino Fanboy D. im April 2018 zur Verfügung gestellten Instruktionen zur Erstellung von MAP und ASM Dateien für Arduino bedürfen einer kleinen Änderung wenn Board Packages via dem Board Manager (json) (in PREFERENCES menu) installiert werden. Siehe auch: Beitrag "Re: Welche Ressourcen nutzt die Arduino Software?" Nach etwas Fehlersuche stellte sich heraus, daß die neue Datei "platform.local.txt" in diesem Fall nicht mehr in AFDs angegebene Pfad plaziert werden darf, sondern jetzt in die jeweilig erstellten durch json generierten Datei Pfade fuer die jeweilig installierten Pakete. Z.B. habe ich bei mir den Mighty Core für den ATMEGA1284 mittels installiert: https://mcudude.github.io/MightyCore/package_MCUdude_MightyCore_index.json Anstatt in dem von AFD ursprünglich angegebenen Pfad muß die Datei "platform.local.txt" nun hier in dem versteckten Pfad plaziert werden: C:\Users\GJO\AppData\Local\Arduino15\packages\MightyCore\hardware\avr\2. 0.3 (Aufpassen, daß Windows Explorer Appdata nicht versteckt und Hide wegklicken)) Dasselbe gilt für: https://github.com/watterott/ATmega328PB-Testing/raw/master/package_m328pb_index.json Alternativ kann der Inhalt von platform.local.txt auch direkt an der richtigen Stelle in die Datei platform.txt eingefügt werden. Gleich nach: (Um Zeile 74 herum) ## Create output files (.eep and .hex) recipe.objcopy.eep.pattern="{compiler.path... ... ## Create output files (.asm and .map) recipe.hooks.linking.postlink.1.pattern=c:\bin\avr_asm_dump.bat... recipe.hooks.linking.postlink.2.pattern=c:\bin\avr_map_dump.bat... Besser ist es mit "platform.local.txt" zu arbeiten Jedenfalls funktioniert es nun wieder. Vielleicht hilft es jemand von Euch. Falls es eh ein alter Hut und Schnee von gestern sein sollte, bitte ich den Beitrag zu ignorieren. Gerhard
Alles gut...! Ein Tipp am Rande: Wenn man die portable Installation verwendet, liegen alle Dateien in einem Ordner. Und werden nicht üer die Platte verteilt.
Arduino Fanboy D. schrieb: > Alles gut...! > > Ein Tipp am Rande: > Wenn man die portable Installation verwendet, liegen alle Dateien in > einem Ordner. Und werden nicht üer die Platte verteilt. Das stimmt nur teilweise. Meine Probleme hatte ich ja mit der portablen installation von V1.82 und später. Ich installiere neuere Versionen nur noch portable. Nur die erste IDE Installation müßte wegen der USB Treiber normal erfolgen. Es scheint tatsächlich der Fall zu sein, daß alles was über den Board Manager geht, vom Inhalt des json Pakets bestimmt wird. Ich sollte mal die json Datei examiniren um zu sehen ob der Pfad der installierten Ordner dort angegeben ist oder nur (intern) vom Board Manager fest gelegt wird. Das Ungute an dieser Pfad Örtlichkeit ist, daß er normalerweise versteckt angelegt wurde und man in den Einstellungen vom W-Explorer das dort erst ändern muß um Appdata zu finden. Damals, bevor ich den Board Manager verwendete, funktionierten Deine Angaben ja noch einwandfrei. Was mir auch aufgefallen ist, daß der "preferences.txt" von jeder Version kommunal benutzt wird und jede IDE dieselben Einstellungen hat.
Gerhard O. schrieb: > Nur die erste IDE Installation müßte wegen der USB > Treiber normal erfolgen. Das ist vielleicht ein Weg, aber notwendig ist er nicht. Das "müsste" ist also falsch. Im Arduino Ordner befindet sich ein Ordner namens drivers. Dort findet sich ein Installer für die Treiber. Den kann man jederzeit aufrufen. z.B. wenn man die portable Installation auf einer USB Disk hat, und an einen fremden Rechner steckt, ist das das Mittel der Wahl. Es gibt also keinerlei Notwendigkeit einer vorhergehenden normalen Installation.
Hallo, Gerhard O. schrieb: > Was mir auch aufgefallen ist, daß der "preferences.txt" von jeder > Version kommunal benutzt wird und jede IDE dieselben Einstellungen hat. kann ich nicht bestätigen, ich habe hier teilweise etliche portable-IDE drauf, jede nutzt die preferences.txt aus ihrem Ordner. Ist auch sinnvoll, weil sich der Inhalt der preferences.txt zwischen den Versionen durchaus ändert. Gruß aus Berlin Michael
Arduino Fanboy D. schrieb: > Gerhard O. schrieb: >> Nur die erste IDE Installation müßte wegen der USB >> Treiber normal erfolgen. > > Das ist vielleicht ein Weg, aber notwendig ist er nicht. > Das "müsste" ist also falsch. > > Im Arduino Ordner befindet sich ein Ordner namens drivers. > Dort findet sich ein Installer für die Treiber. > Den kann man jederzeit aufrufen. > > z.B. wenn man die portable Installation auf einer USB Disk hat, und an > einen fremden Rechner steckt, ist das das Mittel der Wahl. > > Es gibt also keinerlei Notwendigkeit einer vorhergehenden normalen > Installation. Ah, danke! Da hatte ich nie reingeschaut. Das ist gut zu wissen. ...
Michael U. schrieb: > Hallo, > > Gerhard O. schrieb: >> Was mir auch aufgefallen ist, daß der "preferences.txt" von jeder >> Version kommunal benutzt wird und jede IDE dieselben Einstellungen hat. > > kann ich nicht bestätigen, ich habe hier teilweise etliche portable-IDE > drauf, jede nutzt die preferences.txt aus ihrem Ordner. Ist auch > sinnvoll, weil sich der Inhalt der preferences.txt zwischen den > Versionen durchaus ändert. > > Gruß aus Berlin > Michael Hallo Berlin:-) Es ist gut zu wissen, daß die Installationen sich nicht unbedingt alle gleich verhalten. wenn ich den PC später anhabe, muß ich mir die Pfade noch einmal ansehen. Aber, wie kommt es dann, daß jede Version bei mir mit dem gleichen Projekt startet? Wenn ich mich recht erinnere bezieht sich der Pfad im jeweiligen Preferences Einstellfenster auf ...Arduino15 im versteckten Appdata In Local. Na, dann werde ich mir das nochmals zu Gemüte führen wenn der PC an ist und den jeweiligen Pfad checken. Ich werde wenn es soweit berichten und genau aufpassen. Gruß, Gerhard
Gerhard O. schrieb: > Wenn ich mich recht erinnere bezieht sich der > Pfad im jeweiligen Preferences Einstellfenster auf ...Arduino15 im > versteckten Appdata In Local. Das die portablen Versionen gar nicht in Arduino15 rum buddeln, ist das eher unwahrscheinlich.
Markus B. schrieb: > Ich müsste aber wissen, welche Ressourcen von der Software verwendet > werden, zB Timer oder ähnliches. Es gibt ja zB die Funktion micros(). > Die muss ja im Hintergrund irgendwie mitlaufen, also schätze ich, dass > ein Timer belegt wird. In diesem Fall würde ich (unter Windows) den Taskmanager öffnen und nachschauen. Bei mir ist das z.B. Hauptspeicher, Prozessoren (4 Kerne) und Festplattenplatz. Beim Compillieren und Übertragen an das Arduino-Board kommt noch USB hinzu, dass als Ressource verwendet wird.
Andrea schrieb: > In diesem Fall würde ich (unter Windows) den Taskmanager öffnen und > nachschauen. Das hilft in "diesem Fall" leider nicht weiter, da die Ressourcen des Zielsystems gemeint sind.
Arduino Fanboy D. schrieb: > Gerhard O. schrieb: >> Wenn ich mich recht erinnere bezieht sich der >> Pfad im jeweiligen Preferences Einstellfenster auf ...Arduino15 im >> versteckten Appdata In Local. > > Das die portablen Versionen gar nicht in Arduino15 rum buddeln, ist das > eher unwahrscheinlich. Jetzt werde ich immer unsicherer. Gut, ich werde das nach dem Frühstück noch einmal nachprüfen um zu sehen ob ich unabsichtlich was geraucht habe:-) Ich habe bei mir noch einige Versionen im V1.6. Bereich laufen obwohl ich zur Zeit noch V1.8.2 gerne verwende. (Bei älteren Projekten wechsle ich meine Tools ohne besonderen Grund nicht gerne)
Andrea schrieb: > Er schreibt aber "Software" und nicht "Firmware" Das stimmt, da hast du Wahr. Ich weiß jetzt allerdings nicht, warum eine Firmware keine Software sein soll. Scheint mir eher ein Unterschied in der Projektion zu sein, als einer in der Realen Welt.
Gerhard O. schrieb: > (Bei älteren Projekten wechsle > ich meine Tools ohne besonderen Grund nicht gerne) Dem stimme ich zu. Die portable Version ist gut für ein ProjektBackup geeignet, weil man so den ganzen Kram in einer getesteten Version speichern kann, IDE inclusive aller Libs, und Projektverzeichnissen.
OT. Bei mir machte ich die Erfahrung, daß Serial in der V1.8.9 RX seitig nicht mehr funktioniert. TX ist in Ordnung. In allen Versionen bevor und in V1.8.10 funktioniert allerdings derselbe (zeitgetesterter) Code. Hatte allerdings noch keine Zeit mir V1.8.9 deswegen näher anzusehen. Vielleicht hilft das jemanden de sich in V1.8.9 die Haare ausrauft. Irgendwas ist in der Version verschieden.
Leider kompiliert dein problembehaftetes Programm nicht bei mir. Somit kann ich deine Aussage nicht verifizieren.
Michael U. schrieb: > Hallo, > > Gerhard O. schrieb: >> Was mir auch aufgefallen ist, daß der "preferences.txt" von jeder >> Version kommunal benutzt wird und jede IDE dieselben Einstellungen hat. > > kann ich nicht bestätigen, ich habe hier teilweise etliche portable-IDE > drauf, jede nutzt die preferences.txt aus ihrem Ordner. Ist auch > sinnvoll, weil sich der Inhalt der preferences.txt zwischen den > Versionen durchaus ändert. > > Gruß aus Berlin > Michael Hallo Michael, ich habe mal alle IDEs gestartet. Der angegebene Pfad ist vom PREFERENCES Dialog. Die preferences.txt Datei ist bei mir bei allen Installationen dort gespeichert: V1.8.10: C:\Users\GJO\AppData\Local\Arduino15 (Portable) V1.8.9: C:\Users\GJO\AppData\Local\Arduino15 (Portable) V1.8.6: C:\Users\GJO\AppData\Local\Arduino15 (Portable) V1.8.5: C:\Users\GJO\AppData\Local\Arduino15 (Portable) V1.8.2: C:\Users\GJO\AppData\Local\Arduino15 (Portable) V1.6.13: C:\Users\GJO\AppData\Local\Arduino15 (Portable) V1.6.10: C:\Users\GJO\AppData\Local\Arduino15 (Portable) V1.6.5: C:\Users\GJO\AppData\Local\Arduino15 (Portable) V1.8.2: C:\Users\GJO\AppData\Local\Arduino15 (Admin) Es gibt zwischen Installationen auf verschiedenen PC aus irgendeinen Grund scheinbar doch Unterschiede. Auch bei der Admin Installation ist der Pfad gleich. Was meinst Du dazu? Könntest Du mal bei Dir ähnlich nachsehen? Gruß, Gerhard
Gerhard O. schrieb: > Könntest Du mal bei Dir ähnlich > nachsehen? Nachgesehen! Klarer Fall! Bei mir wird C:\Users\abc\AppData\Local\Arduino15 nicht verwendet, weil ein solcher Ordner schlicht nicht existiert. Den habe ich vor geraumer Zeit gelöscht und nicht mehr hinterhergetrauert.
Arduino Fanboy D. schrieb: > Leider kompiliert dein problembehaftetes Programm nicht bei mir. > Somit kann ich deine Aussage nicht verifizieren. Arduino Fanboy D. schrieb: > Leider kompiliert dein problembehaftetes Programm nicht bei mir. > Somit kann ich deine Aussage nicht verifizieren. Wenn Du Dir die Arbeit machen willst, kann ich Dir das besagte Programm zukommen lassen. Allerdings ist es fuer eine 1284P Bord mit diesem Bord Package beabsichtigt: https://mcudude.github.io/MightyCore/package_MCUdude_MightyCore_index.json Wenn ich V1.8.9 verwende gibt es bei Empfang eines Zeichen jedesmal einen CPU RESET. Auf allen anderen IDE Versionen funktioniert es einwandfrei. Ich muesste mir mal die MAP Datei durchsehen. Sieht moeglicherweise nach einen unbelegten oder falschen ISR Vektor aus. Ich habe gerade das Programm auf einem normalen Pro-Mini mit V189 ausprobiert und damit funktioniert es. Das Problem tritt nur beim 1284P und V1.8.9 auf.
Arduino Fanboy D. schrieb: > Gerhard O. schrieb: >> Könntest Du mal bei Dir ähnlich >> nachsehen? > > Nachgesehen! > > Klarer Fall! > > Bei mir wird C:\Users\abc\AppData\Local\Arduino15 nicht verwendet, weil > ein solcher Ordner schlicht nicht existiert. > Den habe ich vor geraumer Zeit gelöscht und nicht mehr > hinterhergetrauert. Das erklärt viel. Mich hat es aber bis jetzt nicht gestört weil ich ja wußte wo es abgelegt wurde. Normalerweise bevorzuge ich die Installations Defaults. Aber das ist halt Geschmackssache.
Gerhard O. schrieb: > Die preferences.txt Datei ist bei mir bei allen > Installationen dort gespeichert: Bei mir nicht, sie findet sich im Ordner \portable\ unterhalb des Programmverzeichnisses der IDE - für die 1.7.4 und 1.8.9 getrennt. Hast Du nach dem Auspacken der IDE-zip manuell das Verzeichnis 'portable' angelegt? Wenn es fehlt, fingert die IDE im Benutzerbereich unter Arduino15 herum.
Angehängte Dateien:
-
Arduino_Portable.jpg
30 KB -
Arduino15.jpg
52 KB
Manfred schrieb: > Gerhard O. schrieb: >> Die preferences.txt Datei ist bei mir bei allen >> Installationen dort gespeichert: > > Bei mir nicht, sie findet sich im Ordner \portable\ unterhalb des > Programmverzeichnisses der IDE - für die 1.7.4 und 1.8.9 getrennt. > > Hast Du nach dem Auspacken der IDE-zip manuell das Verzeichnis > 'portable' angelegt? Wenn es fehlt, fingert die IDE im Benutzerbereich > unter Arduino15 herum. Das habe ich auch so gemacht. Alle meine portablen IDEs sind dort abgelegt. Ich vermute der Bord Manager macht das, da alle meine IDEs zusaetzliche Bord packages (json) installiert haben. Ich werde das naeher untersuchen. Normalerweise lade ich mir die ZIP Datei herunter, packe sie aus und dann deponiere ich sie bei den anderen ab. Siehe beiliegendes Bild.
Manfred schrieb: > Gerhard O. schrieb: >> Die preferences.txt Datei ist bei mir bei allen >> Installationen dort gespeichert: > > Bei mir nicht, sie findet sich im Ordner \portable\ unterhalb des > Programmverzeichnisses der IDE - für die 1.7.4 und 1.8.9 getrennt. > > Hast Du nach dem Auspacken der IDE-zip manuell das Verzeichnis > 'portable' angelegt? Wenn es fehlt, fingert die IDE im Benutzerbereich > unter Arduino15 herum. Ich habe wie von Dir vorgeschlagen ein Unterverzeichnis angelegt und fest gestellt, dass das gleich vom IDE beanschlagt wird. Das ist also der Grund fuer den Arduin15 Default. Das wusste ich nicht. Danke! Ja. Jetzt wird alles dort abgelegt. Muss natuerlich die Bord Packages neu installieren. Nachtrag: Ich haette mir wahrscheinlich besser die Erlaeuterungen auf der Arduino Seite zu Gemuete fuehren sollen. Da steht alles wie man es machen soll. Asche auf mein Haupt:-(((
Gerhard O. schrieb: > kann ich Dir das besagte Programm > zukommen lassen. Allerdings ist es fuer eine 1284P Bord Dann kann ich es nicht testen, also wenig sinnvoll. Aber du hast ja min. eine laufende Variante. Gerhard O. schrieb: > Ich haette mir wahrscheinlich besser die Erlaeuterungen auf > der Arduino Seite zu Gemuete fuehren sollen. Ja! Wenn du von der portablen IDE Variante sprichst, dann komme ich niemals auf die Idee, dass du den portable Ordner weggelassen haben könntest. Denn dieser ist ja das Kernstück des portabilisierens.
Arduino Fanboy D. schrieb: > Gerhard O. schrieb: >> kann ich Dir das besagte Programm >> zukommen lassen. Allerdings ist es fuer eine 1284P Bord > Dann kann ich es nicht testen, also wenig sinnvoll. > Aber du hast ja min. eine laufende Variante. > > Gerhard O. schrieb: >> Ich haette mir wahrscheinlich besser die Erlaeuterungen auf >> der Arduino Seite zu Gemuete fuehren sollen. > Ja! > Wenn du von der portablen IDE Variante sprichst, dann komme ich niemals > auf die Idee, dass du den portable Ordner weggelassen haben könntest. > Denn dieser ist ja das Kernstück des portabilisierens. Gerade aufgewacht bei Neuschnee... Irgendwie kam ich nie auf die Idee nach den Erläuterungen der portablen Seite zu suchen von deren Existenz mir überhaupt nichts bekannt war. Ich kannte nur die kurzen Bemerkungen auf der Download Seite und dachte das wars. Auf den Gedanken, daß dazu ein extra Verzeichnis notwendig wäre, kam ich folglich nicht weil ja alles mittels der Alternativ Verzeichnis Anordnung im Arduino15 Verzeichnis bestens funktionierte. Natürlich ist es möglich, daß es gerade dadurch bei der Kombination 1284 und V189 zu irgendeinen Konflikt kam. Wenn ich also getrennt vorgehe muß ich alles (Bord Manager) wiederholt installieren. Allerdings eliminiert man so die Möglichkeit eines unerkannten Installationskonflikt und wäre folglich der korrekte weitere Schritt. Das wird jetzt eine Zeit brauchen bis ich das alles geändert habe. Da ich hauptsächlich mit eigener HW arbeite sind Default Installationen für mich noch nicht direkt gebrauchsfähig. Jedenfalls bedanke ich mich für Eure bisherige Unterstützung. Es gibt immer welche die viel mehr wissen und konnte gestern wieder etwas dazu lernen. Alleine gestellt irrt man manchmal ab und zu in den Gefilden der Ignoranz:-) Ich habe übrigens die Seite über die Erstellung von Custom Core Packages gelesen. Ganz interessante Sache. Allerdings müsste man zweckmäßigerweise in Linux operieren. Ich habe mir übrigens unter Linux einige modifizierte 328er Optiboot Bootloader für niedrige Quarzfrequenzen angefertigt. Getestet habe ich bis jetzt mangels Quarze im 1-2Mhz Bereich nur die 4MHz Version. Das ist ganz nützlich für stromsparende Projekte. Muß allerdings noch die 1 und 2 Mhz Versionen testen sobald ich die Quarze habe. OK. Zeit für Frühstück und Schneeschippen...
Gerhard O. schrieb: > Wenn ich also getrennt vorgehe muß ich alles (Bord Manager) wiederholt > installieren. Alternativ: Statt den portable Ordner von Hand anzulegen, und von Arduino füllen zu lassen, kopierst du diesen portable Ordner von der vorhergehenden Installation da rein. So wie es auch in dem Artikel empfohlen wird. Dann kommen alle deine installierten Boards/Sketches/Libraries mit.
Gerhard O. schrieb: > Ja. Jetzt wird alles dort abgelegt. Schön, dass ich helfen konnte. Arduino Fanboy D. schrieb: > Wenn du von der portablen IDE Variante sprichst, dann komme ich niemals > auf die Idee, dass du den portable Ordner weggelassen haben könntest. Wieso? Die IDE-Version ohne Installer bringt den Ordner \portable\ nicht mit - das könnte man den A*-Entwicklern als Fehler anlasten. Arduino Fanboy D. schrieb: > Dann kommen alle deine installierten Boards/Sketches/Libraries mit. Da habe ich auch so die eine oder andere Unklarheit, welche Library von welchem Speicherort die IDE gerade verwendet.
Manfred schrieb: > Gerhard O. schrieb: >> Ja. Jetzt wird alles dort abgelegt. > > Schön, dass ich helfen konnte. > > Arduino Fanboy D. schrieb: >> Wenn du von der portablen IDE Variante sprichst, dann komme ich niemals >> auf die Idee, dass du den portable Ordner weggelassen haben könntest. > > Wieso? Die IDE-Version ohne Installer bringt den Ordner \portable\ > nicht mit - das könnte man den A*-Entwicklern als Fehler anlasten. Eine gute Frage die ich mir auch stellte. > > Arduino Fanboy D. schrieb: >> Dann kommen alle deine installierten Boards/Sketches/Libraries mit. > > Da habe ich auch so die eine oder andere Unklarheit, welche Library von > welchem Speicherort die IDE gerade verwendet. Das finde ich auch so. ...
Gerhard O. schrieb: >> Da habe ich auch so die eine oder andere Unklarheit, welche Library von >> welchem Speicherort die IDE gerade verwendet. > Das finde ich auch so. Vielleicht sollte man/ihr die ausführlichen Ausgaben der IDE aktivieren. Dann sagen euch die Meldungen, ganz klar, und auf Deutsch, welche Libraries verwendet werden. Also: Augen auf, und die Einstellungen, mach weit. Gerhard O. schrieb: >> Arduino Fanboy D. schrieb: >>> Wenn du von der portablen IDE Variante sprichst, dann komme ich niemals >>> auf die Idee, dass du den portable Ordner weggelassen haben könntest. >> >> Wieso? Die IDE-Version ohne Installer bringt den Ordner \portable\ >> nicht mit - das könnte man den A*-Entwicklern als Fehler anlasten. > Eine gute Frage die ich mir auch stellte. 3 Varianten es gibt! 1. Ide per Installer, oder aus dem Win App Store 2. Die Zip selber auspacken. 3. Die Portable! Zip auspacken und portable Ordner anlegen. OK, wenn euch 3 Varianten überfordern.... Wer soll das heilen? Nicht jeder Zip Auspacker, will auch portable. Vorschlag: Doku lesen, und sich dann entscheiden, was man will. 1, 2 oder 3
Thread beobachten
Seitenaufteilung abschalten
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.