Hallo, Ich bin, wie so viele in letzter Zeit, vor allem durch Arduino & co. auf die Mikroprozessorprogrammierung gestoßen. Das ist zwar alles ganz schön und gut, allerdings sind die Möglichkeiten des Arduino etwas eingeschränkt und vor allem sehr sehr langsam. Das liegt wohl vor allem daran dass der Arduino eher einfach als effizient seien soll. Deshalb habe ich mich in letzter Zeit mehr und mehr mit AVR's im allgemeinen beschäftigt und daher den Arduino als ISP verwendet. Nun ist die mitgelieferte IDE und bootloader des Arduino allerdings sehr schwärfällig und kaum mehr als ein Texteditor mit Buttons zum kompilieren und hochladen. Daher wollte ich hier einmal fragen welche Alternativen es gibt die ich nutzen kann ohne dass ich mir weitere Hardware dazukaufen muss. Ich habe mit dem Arduino in letzter Zeit vor allem AtTiny's programmiert und würde das gerne weiterhin machen. Vielen Dank für eure Hilfe, - Busti
:
Bearbeitet durch User
Hallo Moritz, Moritz Bust schrieb: > Ich bin, wie so viele in letzter Zeit, vor allem durch Arduino & co. auf > die Mikroprozessorprogrammierung gestoßen. Das ist zwar alles ganz schön > und gut, allerdings sind die Möglichkeiten des Arduino etwas > eingeschränkt und vor allem sehr sehr langsam. Das liegt wohl vor allem > daran dass der Arduino eher einfach als effizient seien soll. > > Deshalb habe ich mich in letzter Zeit mehr und mehr mit AVR's im > allgemeinen beschäftigt und daher den Arduino als ISP verwendet. Nun ist > die mitgelieferte IDE und bootloader des Arduino allerdings sehr > schwärfällig und kaum mehr als ein Texteditor mit Buttons zum > kompilieren und hochladen. > > Daher wollte ich hier einmal fragen welche Alternativen es gibt die ich > nutzen kann ohne dass ich mir weitere Hardware dazukaufen muss. Ich habe > mit dem Arduino in letzter Zeit vor allem AtTiny's programmiert und > würde das gerne weiterhin machen. Nun, um einen Mikrocontroller zu programmieren, muß man natürlich erstmal etwas haben, um Quellcode zu erstellen und zu bearbeiten. Dazu kann jeder beliebige Texteditor genutzt werden, auch Windows' Notepad; mehr Spaß und Vergnügen machen allerdings Editoren, die zumindest Syntax-Highlighting (also das Einfärben bestimmter Schlüsselworte und Elemente im Quellcode) beherrschen. Da kannst Du unter Windows Geany, UltraEdit oder Notepad++ benutzen, oder aber auch eine integrierte Entwicklungsumgebung wie Atmel Studio oder Eclipse, wobei diese zwar einen großen Funktionsumfang haben aber ähnlich schwerfällig sind wie die Arduino-"IDE". Alte UNIX-Hasen wie ich benutzen Editoren Emacs und / oder vi, die man entweder als extrem mächtige Editoren oder etwas schlankere IDEs ansehen kann. ;-) Dann brauchst Du natürlich einen Crosscompiler für die Zielplattform, oft und gerne wird hier der avr-gcc aus der GNU Compiler Collection benutzt. Außerdem brauchst Du eine Programmer-Software wie avrdude, um Deine Programme über den Arduino-ISP auf Deinen Zielprozessor zu bringen. Je nach Präferenz können noch ein Debugger und / oder eine Software zur Simulation sinnvoll sein. HTH und liebe Grüße, Karl
vim gcc make avrdude und n terminal, mehr braucht man eh nicht wenn man nicht debuggen kann.
Ich komme aus der java Ecke und bin daher schon mit Eclipse & co. vertraut...
:
Bearbeitet durch User
Moritz Bust schrieb: > Ich komme aus der java Ecke und bin daher schon mit Eclipse & co. > vertraut... Dann würd ich auch bei Eclipse bleiben. Eclipse ist hinreichend flexibel um damit alle möglichen Prozessoren in allen möglichen Sprachen zu programmieren. Immerhin kannst du frei bestimmen, welche Compiler/Tools von Eclipse aufgerufen werden. Nur eines finde ich wichtig: Bei allem Komfort, man sollte wissen was unter der Haube werkelt. Also vielleicht mal, nur zu Übungszwecken, ein kleines Projekt aus 3-4 C-Dateien mittels Konsole und im nächsten Schritt mittels eigenem Makefile übersetzen. Das bringt dich ungemein weiter und du lernst die Tools mit denen du arbeitest kennen. Danach würd ich aber wieder zum Editor (oder IDE) greifen.
Wo kann ich dann die ganzen Einstellungen vornehmen? Fusebits etc.
Schau Dir mal LunaAVR an. Ist relativ simpel, aufgeräumt und einfach zu erlernen ohne Leistungseinbussen.
Moritz Bust schrieb: > Wo kann ich dann die ganzen Einstellungen vornehmen? Fusebits etc. Mit avrdude...
Klaus I. schrieb: > Schau Dir mal LunaAVR an. Ist relativ simpel, aufgeräumt und > einfach zu > erlernen ohne Leistungseinbussen. Bitte den Threadtitel beachten ...
Moritz Bust schrieb: > Wo kann ich dann die ganzen Einstellungen vornehmen? Fusebits etc. Eclipse Plugin. Dazu Atmel Toolchain und AVRdue. http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin Ich bevorzuge eigentlich auch Eclipse, verwende aber für die AVRs, AVRStudio, da on Chip Debugging dort wesentlich komfortabler abläuft. Ohne Debugger ist das aber nicht nötig. Zum Thema "professineller Arbeiten" würde ich aber auch zur Anschaffung eines Debuggers, z.B. dem AVR Dragon raten. Kostet zwar um die 50€ aber (da sind die Debugger für die Cortex-Mx ARMs von LPC und STM um eine Größenordnung billiger), aber die Möglichkeit während des Programablaufs in deinen Chip hineinzusehen, ist imho ein riesen Komfort-/Effizienzgewinn gegenüber printf/blinky Debug.
Ich benutze auf der Arbeit Eclipse mit GCC für Arms.. Geht alles... Ist aber imho nicht toll. Eclipse als Java-Software ist einfach sauig, die Toolchain für meinen Debugger ist nicht ganz sauber, es gibt ständig Probleme mit der IDE, alles Käse.. Nutze nebenher für Desktops noch VisualStudio für .Net Krams, das ist alles deutlich toller, integrierter, Nutzerfreundlicher. Allerdings ist GCC mitm VS dann wieder nicht so doll.. Für AVRs habe ich früher mit AVR-Studio gearbeitet.. Schlimmer als Eclipse isses nicht, aber man kanns imho deutlich besser bedienen, die integration ist einfach da, und man muss sie nicht selbst frickeln.
Peter schrieb: > Klaus I. schrieb: >> Schau Dir mal LunaAVR an. Ist relativ simpel, aufgeräumt und >> einfach zu >> erlernen ohne Leistungseinbussen. > > Bitte den Threadtitel beachten ... Ja, der passt aber absolut nicht. Aber vielleicht hast Du hier Bedenken, dass meine Antwort nicht zum Titel des Unterforums passt? Der TO hat jetzt Arduino als erste Plattform genannt und wünscht Verbesserungen wegen der schlechten Performance. Wie gesagt ist LunaAVR geeignet schnell eine gute und einfache Entwicklungsumgebung für den genannten Anwendungsbereich bereitzustellen. Das BASCOM könnte man jetzt auch noch nennen. Hängt halt davon ab was der TO eigentlich machen möchte, eine bessere "Effizienz" als Arduino sollten beide bieten.
@ Scelumbro (Gast) >Zum Thema "professineller Arbeiten" würde ich aber auch zur Anschaffung >eines Debuggers, z.B. dem AVR Dragon raten. Kostet zwar um die 50€ aber Heute nicht mehr. Das Atmel-ICE ist unwesentlich teurer, kommt aber mit komplettem Gehäuse und und kann deutlich mehr!
Falk Brunner schrieb: > @ Scelumbro (Gast) > >>Zum Thema "professineller Arbeiten" würde ich aber auch zur Anschaffung >>eines Debuggers, z.B. dem AVR Dragon raten. Kostet zwar um die 50€ aber > > Heute nicht mehr. Das Atmel-ICE ist unwesentlich teurer, kommt aber mit > komplettem Gehäuse und und kann deutlich mehr! Zumindest stimmst du mir zu, dass ein Debugger sinnvoll ist, oder?
Falk Brunner schrieb: > Ja. Auch wenn "richtige" Männer ohne ihn überleben können ;-) Danke Falk, das sehe ich auch so !
Falk Brunner schrieb: > Ja. Auch wenn "richtige" Männer ohne ihn überleben können ;-) Man gewöhnt sich schnell dran :-/ Bei AVR hab ich eigentlich nie einen Debugger vermisst (weil keiner da war und weils auch ohne geht wenn man will [und ich wollte, also gings, und zwar immer]). Seit einiger Zeit mach ich ARM und hab nen J-Link, ruck-zuck hab ich mich an das Vorhandensein eines Debuggers gewöhnt. Zum Glück weiß ich aber immer noch wie man zur Not¹ auch ohne auskommt. ________ ¹ Jetzt schreib ich schon "Not", früher wars normal...
:
Bearbeitet durch User
Bernd K. schrieb: > Seit einiger Zeit mach ich ARM und hab nen J-Link, ruck-zuck hab ich > mich an das Vorhandensein eines Debuggers gewöhnt. Zum Glück weiß ich > aber immer noch wie man zur Not¹ auch ohne auskommt. Mir gings ähnlich. Nachdem ich früher gedacht habe, mit printf Debug und einem UART-USB Kabel löst man jedes Problem schnell und einfach, hatte ich dann mal ein LPCXPresso Board mit Debugger. Und war überrascht wie schnell das ging - auch ohne den Code mit printf Anweisungen vollzuklatschen. Das tolle in der neuen ARM Welt ist, dass es sogar noch als Bonus Semihosting gibt - also printf-Debug direkt über den Debugger. Von den Möglichkeiten war ich so verwöhnt, das ich mir vor dem nächsten AVR Projekt (Restbestände müssen ja aufgebraucht werden) einen Dragon besorgt hatte. Leider ohne Semihosting :(
Klaus I. schrieb: > Schau Dir mal LunaAVR an. Ist relativ simpel, aufgeräumt und einfach zu > erlernen ohne Leistungseinbussen. Würde Dir auch LunaAVR empfehlen, insbesondere wenn die Aktivitäten im Hobbybereich bleiben sollen. Da würde ich mir das C Gerümpel, Make Files usw. nicht antun. http://avr.myluna.de/doku.php?id=de:about
Bernd K. schrieb: > hab ich mich an das Vorhandensein eines Debuggers gewöhnt Glaub' mir, das wäre dir beim AVR genauso gegangen, wenn du ihn nur gehabt hättest. ;-)
Moritz Bust schrieb: > Deshalb habe ich mich in letzter Zeit mehr und mehr mit AVR's im > allgemeinen beschäftigt und daher den Arduino als ISP verwendet. Du weisst aber schon, aus welchen Bauteilen ein Arduino besteht? Wenn Du professioneller arbeiten möchtest, würde ich bei der Sourcecode-Verwaltung anfangen (z.B. SVN, GIT)
:
Bearbeitet durch User
Pete K. schrieb: > Du weisst aber schon, aus welchen Bauteilen ein Arduino besteht? Klar... Ich meinte auch eher die für Hobbybastler gemachte Arduino IDE. SVN und GIT haben für mich auch mit java immer eine Rolle gespielt. Lunatic schrieb: > Würde Dir auch LunaAVR empfehlen, insbesondere wenn die Aktivitäten im > Hobbybereich bleiben sollen. Da würde ich mir das C Gerümpel, Make Files > usw. nicht antun Ich habe nach den ersten Antworten erstmal versucht mir Eclipse einzurichten nachdem ich etwas mit AVR-GCC und Avrdude herumgespielt habe. Ich denke ich habe das Grundprinzip verstanden. Dennoch scheint LunaAVR im Moment die bessere Wahl da ich zz. eher im Hobbybereich aktiv bin und nicht gleich übertreiben möchte. Allerdings werde ich versuchen mich schrittweise an Eclipse oder Atmel Studio heranzutasten, sobald ich etwas mehr Zeit dafür finde. Außerdem habe ich mit Java ein kleines Fable für Micro-Benchmarking entwickelt und würde deshalb irgendwann auch gerne AVR-ASM lernen. (Wozu den größeren Chip kaufen wenn der kleine es auch kann)
> Wo kann ich dann die ganzen Einstellungen vornehmen? Fusebits etc. Moritz, schau Dir mal diese Anleitung an, ich glaube, die bringt dich weiter: http://stefanfrings.de/avr_hello_world/index.html Außerdem google nach "Fusebit Calculator", wegen der Umrechnung in hexadezimal-zahlen für das Makefile.
@ Stefan Us (stefanus) >> Wo kann ich dann die ganzen Einstellungen vornehmen? Fusebits etc. In der IDE deiner Wahl, direkt menschenlesbar. >Außerdem google nach "Fusebit Calculator", wegen der Umrechnung in >hexadezimal-zahlen für das Makefile. OMG! Es lebe die Steinzeit!
Moritz Bust schrieb: > Außerdem habe ich mit Java ein kleines Fable für Micro-Benchmarking > entwickelt und würde deshalb irgendwann auch gerne AVR-ASM lernen. (Wozu > den größeren Chip kaufen wenn der kleine es auch kann) dafür wird dir der in der IDE enthaltene Editor für die Luna-Bibliotheken sicher gefallen, die werden in Assembler programmiert. Schön aufgeräumt. Ich habe mit einem Interface angefangen.
Moritz Bust schrieb: > Ich habe nach den ersten Antworten erstmal versucht mir Eclipse > einzurichten nachdem ich etwas mit AVR-GCC und Avrdude herumgespielt > habe. Ich denke ich habe das Grundprinzip verstanden. Dann bleib dabei! Denn damit kannst du später auch abseits von AVR weiter arbeiten.
Falk Brunner schrieb: > hexadezimal-zahlen für das Makefile. > > OMG! Es lebe die Steinzeit! Buullshit! Glaubst Du jemand will jedes mal umständlich und fehlerbehaftet in ner GUI rumklicken wenn er die selbe hex mit den selben Einstellungen auf den gleichen Controller brennen will wie letzte Woche? Das wird einmal schriftlich niedergelegt in einer Datei die für Menschen wie Maschinen gleicherlei lesbar ist und ich wüsste nicht welches Format für Fusebits universeller und praktischer wäre als ihre Hexadezimale Darstellung und was für das Brennen ergonomischer wäre als ein Batch oder Makefile. Und da man ein Makefile sowieso schon hat ist das der beste Platz um auch die Anweisungen fürs Brennen abzulegen.
:
Bearbeitet durch User
Bernd K. schrieb: > und ich wüsste nicht welches Format > für Fusebits universeller und praktischer wäre als ihre Hexadezimale > Darstellung und was für das Brennen ergonomischer wäre als ein Batch > oder Makefile. Schrieb schon oben einer: Steinzeit.
@ Bernd K. (prof7bit) >> OMG! Es lebe die Steinzeit! >Buullshit! Glaubst Du jemand will jedes mal umständlich und >fehlerbehaftet in ner GUI rumklicken wenn er die selbe hex mit den >selben Einstellungen auf den gleichen Controller brennen will wie letzte >Woche? Das macht man mit einem ELF-File, dort steckt ALLES drin. Ausserdem reden wir von Entwicklung, wo man immer was lesen, anzeigen und ändern will. Da will ich DIREKT im KLARTEXT sehen, welche Fuse-Einstellungen aktiv sind! >Das wird einmal schriftlich niedergelegt in einer Datei die für Menschen >wie Maschinen gleicherlei lesbar ist und ich wüsste nicht welches Format >für Fusebits universeller und praktischer wäre als ihre Hexadezimale >Darstellung Jaja, da kannst du dich dem Josefsorden anschießen ;-) Beitrag "wer kann sich noch an den hex-zeichensatz erinnern?" > und was für das Brennen ergonomischer wäre als ein Batch >oder Makefile. Auch eine IDE kann man konfigurieren und sie macht dann all das auf Knopfdruck. Nur ist die (einmalige) Einstellung per IDE um Welten einfacher als per kryptischen makefile. > Und da man ein Makefile sowieso schon hat ist das der >beste Platz um auch die Anweisungen fürs Brennen abzulegen. Jaja, für Unix-Neanderthaler.
Falk Brunner schrieb: > Da will ich DIREKT im KLARTEXT sehen, welche Fuse-Einstellungen aktiv > sind! Leider sind die Dinger zuweilen so miteinander verwoben, dass ich auch dem Ergebnis eines Atmel Studio da nicht übern Weg trauen würde, ohne die tatsächlichen Bits selbst nochmal verifiziert zu haben. Die Variante, die Dinger im ELF-File zu deklarieren, ist was anderes, die finde ich durchaus sinnvoll (deshalb habe ich das ja auch ins AVRDUDE aufgenommen). Allerdings muss ich nicht zwanghaft jedesmal an den Fuses rumfummeln. Klar braucht man das zur Massenprogrammierung bei einem Produkt, aber während der Entwicklung stell ich die Fuses eh' nur einmal am Anfang ein.
Falk Brunner schrieb: > Auch eine IDE kann man konfigurieren und sie macht dann all das auf > Knopfdruck. Glaubst Du ich installier Eclipse oder Atmelstudio auf nen Automaten der zum Flashen da ist und erklär dann den Leuten wie und wo sie erst umständlich im GUI rumklicken sollen? Computer wurden erfunden um programmiert zu werden und dann für die Menschen zu arbeiten. Sie wurden nicht erfunden um die Menschen für die Computer arbeiten zu lassen.
Computer helfen uns, in kürzester Zeit Probleme zu lösen, die wir ohne sie gar nicht hätten. ;-)
@ Bernd K. (prof7bit) >Glaubst Du ich installier Eclipse oder Atmelstudio auf nen Automaten der >zum Flashen da ist und erklär dann den Leuten wie und wo sie erst >umständlich im GUI rumklicken sollen? War davon auch nur EINE SEKUNDE die Rede? Automatisierung in der Produktion war hier gar nicht gefragt!
@ Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >> Da will ich DIREKT im KLARTEXT sehen, welche Fuse-Einstellungen aktiv >> sind! >Leider sind die Dinger zuweilen so miteinander verwoben, dass ich >auch dem Ergebnis eines Atmel Studio da nicht übern Weg trauen würde, >ohne die tatsächlichen Bits selbst nochmal verifiziert zu haben. Wenn es nicht mal Atmel selber schafft, eine fehlerfreie GUI für die Fuseeinstellungen hinzubekommen, dann ist wohl alles zu spät. Ausserdem zeigt es die Fuses als HEX-Wert ZUSÄTZLICH an. >Allerdings muss ich nicht zwanghaft jedesmal an den Fuses rumfummeln. >Klar braucht man das zur Massenprogrammierung bei einem Produkt, aber >während der Entwicklung stell ich die Fuses eh' nur einmal am Anfang >ein. Ja, aber dazu will ich sie weder per Hand zusammenfriemeln noch über irgendwelche Fuse-Calculators im Netz herausfinden. Machbar ist vieles, sinnvoll schon deutlich weniger.
Falk Brunner schrieb: > Wenn es nicht mal Atmel selber schafft, eine fehlerfreie GUI für die > Fuseeinstellungen hinzubekommen, dann ist wohl alles zu spät. Naja, die Übersetzung in verbalen Text finde ich nicht immer wirklich gelungen. > Ausserdem zeigt es die Fuses als HEX-Wert ZUSÄTZLICH an. Mittlerweile, zum Glück. Das war noch nicht immer so, und da es früher nicht so war (und da der Studio-Salat eh' bloß auf Windows läuft :), habe ich das nie benutzt und benutze es auch heute noch nicht.
@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >Naja, die Übersetzung in verbalen Text finde ich nicht immer wirklich >gelungen. Na dann mach doch einen Verbesserungsvorschlag an Atmel, dort noch Piktogramme anzuzeigen ;-)
Falk Brunner schrieb: > Na dann mach doch einen Verbesserungsvorschlag an Atmel, dort noch > Piktogramme anzuzeigen ;-) Das wäre dann zumindest Windows-passfähig. ;-) Nein, die haben eigentlich zu viele verschiedene Dinge auf zu viele Bits verteilt seinerzeit. CKSEL0 entscheidet zuweilen mit über die Taktquelle, während es bei einigen Kombinationen von CKSEL[3:1] dann eine Erweiterung von SUT[1:0] ist. Ich geh' deshalb dafür lieber durchs Datenblatt, lese mir die Anmerkungen zu den einzelnen Bits durch, überlege mir, welche Takteinstellungen ich nun konkret brauche und wie dafür die Bits dargestellt werden. Dann habe ich irgendwann das Lowfuse-Byte zusammen, da kann ich dann auch gleich den Hexwert eingeben (mache ich übrigens auch in den Fällen, wo ich das Studio wirklich mal benutze). Nur mal so, das ist (aus den XML-Daten rausgezogen) das, was da als Auswahl steht:
1 | Ext. Clock; Start-up time PWRDWN/RESET: 6 CK/14 CK + 0 ms |
2 | Ext. Clock; Start-up time PWRDWN/RESET: 6 CK/14 CK + 4.1 ms |
3 | Ext. Clock; Start-up time PWRDWN/RESET: 6 CK/14 CK + 65 ms |
4 | Int. RC Osc. 8 MHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 0 ms |
5 | Int. RC Osc. 8 MHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 4.1 ms |
6 | Int. RC Osc. 8 MHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 65 ms |
7 | Int. RC Osc. 128kHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 0 ms |
8 | Int. RC Osc. 128kHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 4.1 ms |
9 | Int. RC Osc. 128kHz; Start-up time PWRDWN/RESET: 6 CK/14 CK + 65 ms |
10 | Ext. Low-Freq. Crystal; Start-up time PWRDWN/RESET: 1K CK/14 CK + 0 ms |
11 | Ext. Low-Freq. Crystal; Start-up time PWRDWN/RESET: 1K CK/14 CK + 4.1 ms |
12 | Ext. Low-Freq. Crystal; Start-up time PWRDWN/RESET: 1K CK/14 CK + 65 ms |
13 | Ext. Low-Freq. Crystal; Start-up time PWRDWN/RESET: 32K CK/14 CK + 0 ms |
14 | Ext. Low-Freq. Crystal; Start-up time PWRDWN/RESET: 32K CK/14 CK + 4.1 ms |
15 | Ext. Low-Freq. Crystal; Start-up time PWRDWN/RESET: 32K CK/14 CK + 65 ms |
16 | Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 258 CK/14 CK + 4.1 ms |
17 | Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 258 CK/14 CK + 65 ms |
18 | Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 1K CK /14 CK + 0 ms |
19 | Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 1K CK /14 CK + 4.1 ms |
20 | Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 1K CK /14 CK + 65 ms |
21 | Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 16K CK/14 CK + 0 ms |
22 | Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 16K CK/14 CK + 4.1 ms |
23 | Ext. Full-swing Crystal; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms |
24 | Ext. Crystal Osc. 0.4-0.9 MHz; Start-up time PWRDWN/RESET: 258 CK/14 CK + 4.1 ms |
25 | Ext. Crystal Osc. 0.4-0.9 MHz; Start-up time PWRDWN/RESET: 258 CK/14 CK + 65 ms |
26 | Ext. Crystal Osc. 0.4-0.9 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 0 ms |
27 | Ext. Crystal Osc. 0.4-0.9 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 4.1 ms |
28 | Ext. Crystal Osc. 0.4-0.9 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 65 ms |
29 | Ext. Crystal Osc. 0.4-0.9 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 0 ms |
30 | Ext. Crystal Osc. 0.4-0.9 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 4.1 ms |
31 | Ext. Crystal Osc. 0.4-0.9 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms |
32 | Ext. Crystal Osc. 0.9-3.0 MHz; Start-up time PWRDWN/RESET: 258 CK/14 CK + 4.1 ms |
33 | Ext. Crystal Osc. 0.9-3.0 MHz; Start-up time PWRDWN/RESET: 258 CK/14 CK + 65 ms |
34 | Ext. Crystal Osc. 0.9-3.0 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 0 ms |
35 | Ext. Crystal Osc. 0.9-3.0 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 4.1 ms |
36 | Ext. Crystal Osc. 0.9-3.0 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 65 ms |
37 | Ext. Crystal Osc. 0.9-3.0 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 0 ms |
38 | Ext. Crystal Osc. 0.9-3.0 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 4.1 ms |
39 | Ext. Crystal Osc. 0.9-3.0 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms |
40 | Ext. Crystal Osc. 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 258 CK/14 CK + 4.1 ms |
41 | Ext. Crystal Osc. 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 258 CK/14 CK + 65 ms |
42 | Ext. Crystal Osc. 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 0 ms |
43 | Ext. Crystal Osc. 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 4.1 ms |
44 | Ext. Crystal Osc. 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 65 ms |
45 | Ext. Crystal Osc. 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 0 ms |
46 | Ext. Crystal Osc. 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 4.1 ms |
47 | Ext. Crystal Osc. 3.0-8.0 MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms |
48 | Ext. Crystal Osc. 8.0- MHz; Start-up time PWRDWN/RESET: 258 CK/14 CK + 4.1 ms |
49 | Ext. Crystal Osc. 8.0- MHz; Start-up time PWRDWN/RESET: 258 CK/14 CK + 65 ms |
50 | Ext. Crystal Osc. 8.0- MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 0 ms |
51 | Ext. Crystal Osc. 8.0- MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 4.1 ms |
52 | Ext. Crystal Osc. 8.0- MHz; Start-up time PWRDWN/RESET: 1K CK /14 CK + 65 ms |
53 | Ext. Crystal Osc. 8.0- MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 0 ms |
54 | Ext. Crystal Osc. 8.0- MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 4.1 ms |
55 | Ext. Crystal Osc. 8.0- MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + 65 ms |
Das ist einerseits erschlagend viel, andererseits schon so stark mit Abkürzungen verwurschtelt, dass man es ohnehin nicht versteht, ohne parallel die exakte Bedeutung im Datenblatt nachzulesen. Wenn ich aber schon im Datenblatt bin, dann habe ich von dort meine Bits schneller zusammen, als ich in dieser fetten Liste meine gewünschte Einstellung gefunden habe ;), bei der ich am Ende ohnehin nochmal verifizieren müsste, ob sie tatsächlich auch so passt … gerade eine schräg eingestellte Fuse kann einem ja mächtig Ärger einhandeln.
@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >Nein, die haben eigentlich zu viele verschiedene Dinge auf zu viele >Bits verteilt seinerzeit. CKSEL0 entscheidet zuweilen mit über die >Taktquelle, während es bei einigen Kombinationen von CKSEL[3:1] dann >eine Erweiterung von SUT[1:0] ist. Mag ja sein, aber es sollte für die Informatik des Jahres 2015 im Rahmen des Möglichen liegen, das gescheit zu dekodieren und darzustellen! >Nur mal so, das ist (aus den XML-Daten rausgezogen) das, was da als >Auswahl steht: >Ext. Clock; Start-up time PWRDWN/RESET: 6 CK/14 CK + 0 ms . . . . . >Ext. Crystal Osc. 8.0- MHz; Start-up time PWRDWN/RESET: 16K CK/14 CK + >65 ms >Das ist einerseits erschlagend viel, andererseits schon so stark mit >Abkürzungen verwurschtelt, dass man es ohnehin nicht versteht, ohne >parallel die exakte Bedeutung im Datenblatt nachzulesen. Ja, das ist Müll. Kann es sein, dass bei Atmel so viele schlechte Praktikanten programmieren? Oder nur Unix-Freaks, die keine Ahnung von intuitiven GUIs haben? > Wenn ich >aber schon im Datenblatt bin, dann habe ich von dort meine Bits >schneller zusammen, als ich in dieser fetten Liste meine gewünschte >Einstellung gefunden habe ;), Du kompilierst auch dein Betriebssystem selber. Das machen viele andere Leute, mich eingeschlossen, nie ;-) > bei der ich am Ende ohnehin nochmal >verifizieren müsste, ob sie tatsächlich auch so passt … gerade eine >schräg eingestellte Fuse kann einem ja mächtig Ärger einhandeln. Und eben weil das so ist, ist so ein manuelle Bitfummeln nicht sonderlich anfängertauglich!
Falk Brunner schrieb: > Auch eine IDE kann man konfigurieren und sie macht dann all das auf > Knopfdruck. Nur ist die (einmalige) Einstellung per IDE um Welten > einfacher als per kryptischen makefile. Das sehe ich auch so. Vorab. Ich habe mich schon mal mit dem Makefile beschäftigt und erst dank Jörg und seinem schönen Programm (Dank an dieser Stelle) bekam ich es überhaupt zum laufen. Später habe ich das auch einigermaßen verstanden. Wir hatten das zu zweit versucht und mein Mitstreiter ist ein Ing mit Doktortitel, nur falls ihr meint ich wäre zu doof. Aber er hatte das auch nicht hin bekommen. Insgesamt habe ich bestimmt 10 Stunden (mit Unterbrechungen) gebraucht das ans laufen zu bekommen. Was ist, wenn ich einen anderen Controller programmieren will? Genau, ich brauche wieder ein Makefile. Ich nehme das Studio und damit klappt alles. Wenn es neue Produkte gibt, dann wird mein Programmer gleich automatisch abgedatet. Was will man mehr? Und dann zu den Unkenrufern, das würde alles viel schneller klappen, als mit dem Studio. Die Zeit fürs lernen des kryptischen Zeugs, die rechne mal aufs Studio. Ich wette man ist dann mit dem Studio immer noch schneller. Das erinnert mich so an den Schallplattenhändler: "CD setzt sich niiiiemals durch!" Ungefähr ein Jahr später gab es seinen Schallplattenladen nicht mehr.^^
Falk Brunner schrieb: > Wenn es nicht mal Atmel selber schafft, eine fehlerfreie GUI für die > Fuseeinstellungen hinzubekommen, dann ist wohl alles zu spät. > Ausserdem zeigt es die Fuses als HEX-Wert ZUSÄTZLICH an. Das ist, glaube ich, wieder ein Zeichen dafür, dass die Leute übers Studio reden, aber schon ewig nicht mehr mit gearbeitet haben und die neuste Version nicht mal kennen.
Jörg Wunsch schrieb: > Nein, die haben eigentlich zu viele verschiedene Dinge auf zu viele > Bits verteilt seinerzeit. CKSEL0 entscheidet zuweilen mit über die > Taktquelle, während es bei einigen Kombinationen von CKSEL[3:1] dann > eine Erweiterung von SUT[1:0] ist. Das ist ein tolles Beispiel. Diese Einstellungen stehen doch so gar nicht mehr im Studio. Da ist das alles viel einfacher und knapper gehalten. Wenn ich mich nicht übers Studio ran getastet hätte, hätte ich sicher mehr Probleme gehabt das zu kapieren. Mit dem Studio habe ich die Änderungen gemacht und mit dem Minipro habe ich dann die mir damals kryptischen Einstellungen angeschaut und dann auch, nach nochmaligem lesen des Datenblattes, verstanden.
Falk Brunner schrieb: > Du kompilierst auch dein Betriebssystem selber. Das machen viele andere > Leute, mich eingeschlossen, nie ;-) Habe ich auch alles hinter mir und das ist schon klasse, wenn ich meinen eigenen perfekten Kernel habe. Immer wird vom Zeitvorteil geredet. Wenn man das erlernen und das Ausführen dazu zählt, dann möchte ich mal sehen wie viel vom Zeitvorteil noch übrig bleibt. Ich möchte behaupten, dass es unterm Strich mehr Zeit braucht.
Falk Brunner schrieb: > Oder nur Unix-Freaks, die keine Ahnung von intuitiven GUIs haben? Unix-Freaks? Kannste doch dort vergessen. Bis auf die AVR32-Hanseln sind die doch alle Windows-gestählt. Man hätte den Kram wohl besser gar nicht so schräg in die Fuses setzen sollen. Hat man ja beim Xmega dann auch korrigiert. In die GUI selbst willst du den Kram ja auch nicht direkt reinprogrammieren. Das gab's ja bei AVR Studio 3, da brauchte man dann für jeden neuen Controller eine neue Binärversion … F. Fo schrieb: > die neuste Version nicht mal kennen. Ich muss sie mir hin und wieder dienstlich ansehen. Das genügt mir, sie möglichst schnell wieder abzuschalten und mich effektiveren Zeitvertreiben zuzuwenden. :-) Nein, an das Ding werde ich mich wohl für den Rest meines Lebens nicht mehr gewöhnen.
@ F. Fo (foldi) >> Ausserdem zeigt es die Fuses als HEX-Wert ZUSÄTZLICH an. >Das ist, glaube ich, wieder ein Zeichen dafür, dass die Leute übers >Studio reden, aber schon ewig nicht mehr mit gearbeitet haben und die >neuste Version nicht mal kennen. Die HEX-Anzeige gab es schon in 4.x, und die ist schon mindestens 5 Jahre alt!
@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >Unix-Freaks? >Kannste doch dort vergessen. Bis auf die AVR32-Hanseln sind die doch >alle Windows-gestählt. War ja nur eine Vermutung. >Man hätte den Kram wohl besser gar nicht so schräg in die Fuses >setzen sollen. Hat man ja beim Xmega dann auch korrigiert. Was lässt sich HEUTE wohle einfacher korrigieren? Das Silizium (vor allem das verkaufte) oder die Software? >In die GUI selbst willst du den Kram ja auch nicht direkt >reinprogrammieren. Das gab's ja bei AVR Studio 3, da brauchte man >dann für jeden neuen Controller eine neue Binärversion … Das meinte ich ja nicht so. Sondern dass man die Informationen aus dem XML-files sinnvoll auf der GUI ANZEIGEN und auswählen kann. Also ein Drop Down Box für Oszillatortyp (RC int, RC ext, XO, Crystal) und eine für Startup time. Dass man da ein wenig dekodieren und gegenprüfen muss, ist halt die Aufgabe für die Programmierer. Dass dazui natürlich auch passende Infos in den XML-Files stehen müssen, ist auch klar. (Ich vermute mal, das hat man versäumt und hatte keinen Bock, das zu korrigieren, damit war eine eindeutig Dekodierung nicht mehr sinnvoll möglich).
Jörg Wunsch schrieb: > Nein, an das Ding werde ich mich wohl für den Rest meines Lebens nicht > mehr gewöhnen. Das ist ja auch ok, wenn man das andere beherrscht, aber wenn du noch mal Anfänger wärst, würdest du nicht auch lieber zunächst zum Studio greifen, als alles zu Fuß zu machen?
Falk Brunner schrieb: > Die HEX-Anzeige gab es schon in 4.x Anzeige ja, aber die Möglichkeit der hexadezimalen Eingabe (und damit das Herstellen eines "known good state" ohne aufwändiges und fehlerträchtiges Geklicker) erst ganz am Ende der Studio-4-Ära.
Ich habe seit ca 5 Jahren eine Firmware veröffentlicht, die auch kommerziell genutzt wird. Anfangs hatte ich in Text-form hingeschrieben, wie die Fuses im AVR Studio einzustellen sind. Ich hatte exakt die Wortlaute vom AVR Studio verwendet. Damals bekam ich jede Woche Rückfragen von Leuten, die damit nicht klar kamen. Dann schrieb ich die Hexadezimal-Werte für alle möglichen Controller ins Makefile. Seit dem hat nie wieder jemand nachgefragt. Nachdem die initiale Entwicklung abgeschlossen ist, halte ich es für absolut sinnvoll, die Fuses (bzw den ganzen Compilier+Flash Vorgang) durch ein wie auch immer geartetes Script zu automatisieren. Ich nutze jedoch während der Entwicklung gerne die Fuses GUI vom AVR Studio. Beides hat seine Existenz-Berechtigung. Beides ist sinnvoll. Wer ich was von Steinzeit und so von sich gibt, irritiert mich.
Stefan Us schrieb: > Wer ich was von Steinzeit und so von sich gibt, irritiert mich. Deine Irritation merkt man deutlich ;-) Zu professionell und Debugger: mit dem Dragon hatte ich vor längerer Zeit gespielt. Was an Debugging mit einem ATmega32 möglich war fand ich recht bescheiden. Um die Interna des µC einsehen zu können, mußte das Programm gestoppt werden bzw. auf einen Breakpoint laufen. Für Echtzeitanwendungen war das richtig schlecht! Gibt es denn aktuell Möglichkeiten, beim laufenden Programm interne Variablen anzusehen, ohne das Programm anzuhalten? Habe ich etwas verpaßt?
> Gibt es denn aktuell Möglichkeiten, beim > laufenden Programm interne Variablen anzusehen Nicht dass ich wüsste.
Stefan Us schrieb: >> Gibt es denn aktuell Möglichkeiten, beim >> laufenden Programm interne Variablen anzusehen > > Nicht dass ich wüsste. Danke für die Info! Dann weiß ich allerdings nicht, was am Debugging so zündend sein soll. Sicher ist es interessant für einen Anfänger, der zuvor noch nie einen µC von innen gesehen hat und im Einzelschritt Änderungen von Registern oder Statusflag sehen möchte. Gut zum Lernen, aber wenn es knifflig wird, ist es recht mühsam, sich zum vermeintlichen Fehler durchzuhangeln. Anders sieht es bei neueren µCs aus wie z.B. den Cortex-Mx oder diversen Teilen von Renesas. Da kann man im laufenden Programm Variable oder IO-Register ansehen/ändern. Da ist es eine sehr große Hilfe, wenn dies von der verwendeten IDE unterstützt wird (z.B. KEIL, IAR, Renesas).
@ Stefan Us (stefanus) >Anfangs hatte ich in Text-form hingeschrieben, wie die Fuses im AVR >Studio einzustellen sind. Ich hatte exakt die Wortlaute vom AVR Studio >verwendet. Damals bekam ich jede Woche Rückfragen von Leuten, die damit >nicht klar kamen. Logisch. Wenn, denn hätte ich eher einen Screenshot gemacht. Aber auch das ist nicht so optimal. >Dann schrieb ich die Hexadezimal-Werte für alle möglichen Controller ins >Makefile. Seit dem hat nie wieder jemand nachgefragt. Ein ELF-File wäre noch einfacher. >Nachdem die initiale Entwicklung abgeschlossen ist, halte ich es für >absolut sinnvoll, die Fuses (bzw den ganzen Compilier+Flash Vorgang) >durch ein wie auch immer geartetes Script zu automatisieren. Das hat auch keiner bestritten. >Ich nutze jedoch während der Entwicklung gerne die Fuses GUI vom AVR >Studio. AHA!!!! >Wer ich was von Steinzeit und so von sich gibt, irritiert mich. ??? Satzbau? Wort vergessen?
m.n. schrieb: > Sicher ist es interessant für einen Anfänger, der zuvor noch nie einen > µC von innen gesehen hat und im Einzelschritt Änderungen von Registern > oder Statusflag sehen möchte. Gut zum Lernen, Dazu fand ich das auch gut und habe sehen können, dass ich das was ich zuvor angelesen hatte auch so funktionierte. Ich weiß nicht, ob in komplexen Programmen ein Debugger hilft, aber wenn ich wissen will, ob ich zu einem gewissen Punkt komme, lasse ich eine Led leuchten.
m.n. schrieb: > Gibt es denn aktuell Möglichkeiten, beim laufenden Programm interne > Variablen anzusehen, ohne das Programm anzuhalten? Wie sollte das denn gehen, außer vielleicht durch eine echte Emulation und Dualport-RAM, bei der der Debugger unabhängig vom Prozessor auf den RAM zugreift (was schweineteuer ist)?
Jörg Wunsch schrieb: > Wie sollte das denn gehen, außer vielleicht durch eine echte > Emulation und Dualport-RAM, bei der der Debugger unabhängig vom > Prozessor auf den RAM zugreift (was schweineteuer ist)? Bei ARM-Cortexen ist das standardmäßig immer mit eingebaut. > schweineteuer J-Link EDU: 50€
:
Bearbeitet durch User
@ Bernd K. (prof7bit) >> Wie sollte das denn gehen, außer vielleicht durch eine echte >> Emulation und Dualport-RAM, bei der der Debugger unabhängig vom >> Prozessor auf den RAM zugreift (was schweineteuer ist)? >Bei ARM-Cortexen ist das standardmäßig immer mit eingebaut. Dann hat man aber bestenfalls die CPU-Register, aber nicht alle Variablen! >> schweineteuer >J-Link EDU: 50€ Er meint die Kosten für das Silizium, denn eine Registerbank als Dual Port ist hat aufwändiger als Single Port (Wobei viele CPUs sowieso mit DualPort Registern arbeiten, um mehr Operationen zu parallelisieren.
Jörg Wunsch schrieb: > Wie sollte das denn gehen, außer vielleicht durch eine echte > Emulation und Dualport-RAM, bei der der Debugger unabhängig vom > Prozessor auf den RAM zugreift (was schweineteuer ist)? Einfach ausgedrückt muß das Debug-Interface µC-intern als weiterer Busmaster auf den Prozessor selbst, Speicher und IO-Bereich zugreifen können. Bei Renesas geht das ab HSX- und SH-Controllern mit JTAG-Interface. Die neuesten RXe können dies auch über die FINE-Schnittstelle erledigen, ähnlich wie die Cortexe per SWD. Das geht schon mit ST-Link und der IAR-Kickstarter Version. Eine feine Sache! Entscheidend dabei ist, daß die IDE diese Funktionen ünterstützt. Bei IAR heißt das Schlüsselwort dafür 'Live Watch'. Am besten hat mir das bei HEW von Renesas gefallen, da man dort auch eigene Gruppen von anzuzeigenden Registern vorgeben kann und ganz gezielt und übersichtlich mal Timer, DMAC oder eine UART untersuchen kann. Will beispielsweise ein Timer nicht laufen, ändert man die Konfigurationsbits solange, bis er 'anspringt' - während das Programm läuft. EM:Blocks unterstützt dies ein wenig, indem man Werte von Variablen angezeigt bekommt, wenn man bei laufendem Programm den Cursor im Editor entsprechend positioniert - auf die Variable schiebt. Hierzu muß die Variable allerdings einen festen Speicherplatz haben und somit global oder static sein. Damit kann man leben. Beim Abfragen von Touch-Koordinaten per Interrupt hat mir das sehr geholfen, da man aktuelle Roh- und Endwerte anzeigen kann. Bewegt man den Finger, kann man die Änderung direkt verfolgen. Verwendet man zur Skalierung Variable, so kann man auch diese zur Laufzeit anpassen. Damit ist man sehr produktiv.
Falk Brunner schrieb: >>Bei ARM-Cortexen ist das standardmäßig immer mit eingebaut. > > Dann hat man aber bestenfalls die CPU-Register, aber nicht alle > Variablen! Doch, das greift bei laufender CPU aufs RAM zu. Kannst live beliebigen globalen und statischen Variablen im RAM zuschauen ohne daß das laufende Programm in irgendeiner Weise abgebremst oder anderweitig beeinträchtigt wird. Mit der passenden Software auf dem PC https://www.segger.com/j-link-j-scope.html kann mans sogar schön in Echtzeit plotten. Beste Erfindung seit geschnitten Brot.
:
Bearbeitet durch User
@ Bernd K. (prof7bit) >wird. Mit der passenden Software auf dem PC >https://www.segger.com/j-link-j-scope.html kann mans sogar schön in >Echtzeit plotten. Beste Erfindung seit geschnitten Brot. WOW! Das sieht ja wirklich gut aus! Und mit dem zusätzlichen Busmaster klingt das auch logisch.
Bernd K. schrieb: > ohne daß das laufende Programm in irgendeiner Weise abgebremst oder > anderweitig beeinträchtigt wird. Das wiederum wage ich zu bezweifeln. Man sollte nie „nie“ sagen (oder eben hier „in irgendeiner Weise“). Ohne Dualport-RAM geht es einfach nicht ohne Ausbremsen. Kann allerdings sein, dass sich (je nach Anwendungsfall) das Ausbremsen in einem Bereich bewegt, wo es dich wenig stört. Aber manchmal sind auch zwei oder drei zusätzliche Takte nicht tolerierbar, und oft genug sind Variablen ohehin nicht an definierten Speicherplätzen abgelegt, sondern mal in diesem, mal in jenem Register. Dann hilft es auch nicht viel, wenn der Debugger zwischenzeitlich auf den RAM zugreifen kann.
@Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >> ohne daß das laufende Programm in irgendeiner Weise abgebremst oder >> anderweitig beeinträchtigt wird. >Das wiederum wage ich zu bezweifeln. Man sollte nie „nie“ sagen >(oder eben hier „in irgendeiner Weise“). Ohne Dualport-RAM geht >es einfach nicht ohne Ausbremsen. Stimmt! > Kann allerdings sein, dass sich >(je nach Anwendungsfall) das Ausbremsen in einem Bereich bewegt, wo >es dich wenig stört. Darauf wird es hinauslaufen. Das Debugmodul darf den anderen Busteilnehmern halt nicht dazwischen funken. Vielleicht steckt ausreichend Intelligenz drin, um sichere Lücken im Buszugriff ausnutzen zu können. > Aber manchmal sind auch zwei oder drei >zusätzliche Takte nicht tolerierbar, und oft genug sind Variablen >ohehin nicht an definierten Speicherplätzen abgelegt, sondern mal >in diesem, mal in jenem Register. Naja, globale Variablen eher nicht. Nichtstatische lokale Variablen sind in diesem Fall sowieso nicht gefragt. > Dann hilft es auch nicht viel, >wenn der Debugger zwischenzeitlich auf den RAM zugreifen kann. Doch doch. Ausserdem geht auch auch um das Monitoring von IO-Registern. Wobei dort bestimmte "heiße" Register eher nicht überwacht werden können, wenn ein Zugriff von denen Hardwareaktionen auslöst (UART Daten etc.) Trotzdem sieht das schon recht nett aus!
Jörg Wunsch schrieb: > Bernd K. schrieb: >> ohne daß das laufende Programm in irgendeiner Weise abgebremst oder >> anderweitig beeinträchtigt wird. > > Das wiederum wage ich zu bezweifeln. Man sollte nie „nie“ sagen Vermutlich werden je nach Zugriff (und µC) 10 - 50 ns benötigt. Dies aber nur für die ausgewählten Variablen ein paar Mal pro Sekunde und auch nur dann, wenn ein gleichzeitiger Zugriff über den betreffenden Bus stattfindet. So bremst ein Zugriff aufs RAM nicht die Zugriffe aufs Flash-ROM oder die Peripherie aus und umgekehrt. Aber das ist doch Alles Kleinkram im Gegensatz zu einem Debugger, der auf einen Breakpoint läuft und den µC komplett stoppt. In einer realen Anwendung kann dann ein Antrieb ungebremst auf den Anschlag fahren oder ein geöffnetes Luftdruckventil die Meßvorrichtung zum Platzen bringen. Ein Knackpunkt sind allerdings IO-Register, die allein durchs Lesen ggf. ein Interrupt-Flag löschen, wie zum Beispiel beim STM32F4 der Zugriff auf ein Capture-Register eines Timers. Wenn so etwas passieren kann, muß man das entsprechend beachten.
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.