Hallo Forum, ich habe vor nicht allzu langer Zeit eine Website gesehen, auf der jemand eine Zusammenstellung von Linux, Toolchain und Tools speziell für die Programmierung anbietet (Datenträger gegen 15,00 EUR oder so). Gedacht für Anfänger in der Entwicklung für Mikrocontroller. Leider finde ich die Website nicht mehr, würde mir die "Distribution" aber gerne mal angucken. rCOS LiveCD wird es nicht gewesen sein, denn die Website ist wohl "down". Irgendjemand, der mir da einen Hinweise geben kann? Danke und Gruß, Detlef
playground.boxtec.ch/doku.php/robox-live/start
Detlef R. schrieb: > Datenträger gegen 15,00 EUR oder so Hallo, evtl. reicht auch schon ein Artikel dieser Art zum Thema (nur als Beispiel) https://www.linuxjournal.com/article/7289?page=0,0 http://www.nongnu.org/avr-libc/ http://tuxgraphics.org/electronics/200904/avr-c-programming.shtml http://tuxgraphics.org/electronics/200901/avr-gcc-linux.shtml
Detlef R. schrieb: > Gedacht für Anfänger in der Entwicklung für Mikrocontroller. Dafür gibt's doch Arduino? Läuft auf Mac, Win und (*staun!*) Linux.
Ich wollte zurück zu den Basics. Abgesehen davon, dass ich die IDE von Arduiino nur mäßig finde. Mich nervt die Multi-Window GUI. :-( Aber danke für den Hinweis.
Ich würde von solchen "abgeleiteten", spezialisierten Linux-Distributionen die Finger lassen. Nach meiner Erfahrung gibt's davon jeden Tag drei neue und zwei verschwinden, weil die Erfinder den Aufwand dafür unterschätzen und nicht mehr tragen wollen.
Ich empfehle auch auf eine verbreitete Linux-Disti zu setzen. Ich bin grosser Fan von Mint (Cinnamon 64 Bit) - Ein vollständiges und stabile Distribution, gut geeignet für Windows Abkömmlinge... https://www.linuxmint.com/
Ich würde auch Mint empfehlen, allenfalls auch Ubuntu oder eine andere debian-basierte Distribution. Die ganzen cross compiler sind mit einer "apt install"-Zeile installiert, von avr über arm bis msp430...
Vielen Dank an alle Antwortenden! Vermutlich ist der Aufwand mit einer "normalen" Distribution wie mint dann doch nicht so groß, dort ins Programmieren zu kommen. Und ich habe keine "angepasste" Distri gefunden, die nicht schon ein paar Jährchen auf dem Buckel hat. Also werde ich mich einfach mal mit mint beschäftigen.
Mint installieren, dann apt-get install acc-avr avrdude avr-libc kate konsole dann hast Du alles was Du (zumindest für AVR) brauchst. Als Editor dann Kate und dort unter plugins die terminal tools aktivieren.
Andreas B. schrieb: > Mint installieren, dann > apt-get install acc-avr avrdude avr-libc kate konsole > dann hast Du alles was Du (zumindest für AVR) brauchst. Gelegentlich muss man mal nachsehen, ob die Tools in der Distribution halbwegs aktuell sind. Wenn nicht, kompiliert man sich bei Gelegenheit was neueres zusammen.
... wenn du aus Postleitzahlenregion 76xxx kommst, kannst du dich bei mir melden. Seit mehr als 3 Jahren werkel ich an eine Livedistribution, die eben Mikrocontrollerprogrammierung ermöglichen soll. Dieses Linux ist vom USB-Stick lauffähig oder auch von einer Festplatte startbar. Wer unbedingt unter einem Desktop arbeiten mag, hat als Editor / "IDE" Geany zur Verfügung, das wars dann aber schon. Dieses Linux arbeitet zur Mikrocontrollerprogrammierung grundsätzlich mit Makefiles, bei denen nur die hinzuzulinkenden Dateien sowie den zu verwendenden Programmer angegeben werden müssen. Die Makefiles werden mittels einem Generator erstellt (ähnlich dem mfile von Jörg Wunsch) Programme für Mikrocontroller können im Textmode mit einem Editor editiert werden, der aus der IDE von FreePascal abgeleitet ist (nein, die Controller werden nicht in Pascal programmiert, sondern standardmässig in C). Dieser Edior kann aus dem Programm heraus einen Make starten... und jedes Makefile hat auch die Option Flash. Installierte Compiler sind: - arm-none-eab-gcc - avr-gcc - sdcc Als Flasherprogramme stehen zur Verfügung: AVRDUDE ST-FLASH (auch in 2 modifizierten Varianten für Eigenbauelektronik) ST-LINK DFU-UTIL FLASH1114 FLASH51 PK2CMD ARDPICPROG Programmiert werden können: - nahezu alle AVR (Avrdude und AVR-GCC machen es möglich) - STM32: F030, F051, F103, F401, F411, F429 - STM8: STM8S103 / 003, STM8S105 - PIC16F: 16F887, 16F648, 16F630 - PIC18F: 18F52 - MCS51: AT89S51 / 52, AT89S8253, AT89S4051 Für die genannten Controller gibts es schon ewig viele Beispielcodes und Softwaremodule zu Display, SPI, UART, I2C, GPIO, Timer, Interrupts Aaaaaber der Pferdefuß ist: Ich komme einfach nicht dazu, das zu dokumentieren (das ist sicherlich mehr Aufwand wie das gesamte System und jedes mal wenn ich denke ich mache eine Doku und schreibe eine Installationsroutine ... kommen mir neue Ideen) Im Moment bin ich dabei, PIC-Controller in meinem System besser einzubinden ... bin hierbei etwas gefrustet und habe da eigentlich wichtigeres liegen lassen. Wie gesagt, wenn du aus dem PLZ-Bereich 76 bist, zeig ich dir das gerne und richte dir einen USB Stick gerne ein. Ralph
Ralph S. schrieb: > Wie gesagt, wenn du aus dem PLZ-Bereich 76 bist, zeig ich dir das gerne > und richte dir einen USB Stick gerne ein. Richte einen Stick ein, mache ein Image davon, lade es hoch?
Hallo Ralph, > Wie gesagt, wenn du aus dem PLZ-Bereich 76 bist, zeig ich dir das gerne > und richte dir einen USB Stick gerne ein. ich komme aus PLZ 38, Braunschweig. Also leider nicht um die Ecke. Außerdem will ich Dir nicht mehr Arbeit machen, als Du ohnehin schon hast. :-( ;-) Davon abgesehen, wenn Du Dr. Sommers (der Dr. Sommer aus dem Radio?) Vorschlag folgen magst, würde ich mich freuen, wenn Du mir ein iso zum Download bereitstellst. Ich würde mich gerne einmal daran versuchen. PM folgt. Gruß, Detlef
Gibt doch genügend Tools, um angepasste Linux-Live-Distris mit den gewünschten Tools zu erstellen. Z.B. Ubuntu Customization Kit, Linux Live USB Creator und Co. Wenn es also eine Live-Distri sein soll, einfach selber erstellen. Ist wirklich nicht schwer.
Das wichtigst ist imho die IDE - die Distributin ist da eher zweitrangig. Nachdem ich mich ein wenig mit Eclipse rumgequält habe bin ich bei Codeblocks gelandet. Das ist sozusagen der kleine Bruder von Eclipse und reicht für meine paar AVR-Progrämmchen.
Mark S. schrieb: > Das wichtigst ist imho die IDE Sehe ich anders: Das wichtigste ist ein guter Editor, z.B. Kate. Ein Makefile ist in 3min auf ein neues Projekt geändert. Aber das ist Geschmacksache. Eclipse finde ich grausam.
Hallo Forum, für den Anfang finde ich einen Editor mit Syntaxhighlighting ausreichend. Mit eclipse habe ich im Bereich Java viel gearbeitet und fand den sehr brauchbar, aber vermutlich geht das dann schnell in Glaubenskriege über. :-( Weswegen ich nach einer AVR-Distri gefragt hatte, war dass ich endlich mal von windoof weg will und mir die Gefahr nach der Installation eines z.B. Ubuntu-Derivats zu groß schien, keine funktionierende Toolchain installiert zu bekommen. Wenn man eigentlich "nur programmieren" will und sich erst damit auseinandersetzen muss, warum jetzt dieses oder jenes nicht funktioniert, das schien mir zu nervenaufreibend. Aber da hier einige schreiben, dass mit apt-get schnell eine Toolchain installiert ist, dann probiere ich das am Wochenende einfach mal aus. Solange ich nicht mit dem vi auf Kommandozeile arbeiten muss (ich weiß, das machen manche lieber) ist mir jeder Editor recht. Und Kate, kurz auf die Schnelle mal geguckt, bietet alles, was der geneigte Programmierer so (zunächst) braucht. Viele Grüße, Detlef
Detlef R. schrieb: > Hallo Forum, > > für den Anfang finde ich einen Editor mit Syntaxhighlighting > ausreichend. Mit eclipse habe ich im Bereich Java viel gearbeitet und > fand den sehr brauchbar, aber vermutlich geht das dann schnell in > Glaubenskriege über. :-( Ihh wo... einfach mit Emacs arbeiten, dann isses schon Richtig[TM]! ;-)
Gibt es dafür keine Docker Container mit dem nötigen Kram? Hier war das schon mal Thema: Beitrag "Docker mit gcc-avr" Habe mich damit selber noch nicht anfreunden können, aber das scheint ja der heisse Sch**ss zu sein.
Detlef R. schrieb: > Weswegen ich nach einer AVR-Distri gefragt hatte, war dass ich endlich > mal von windoof weg will und mir die Gefahr nach der Installation eines > z.B. Ubuntu-Derivats zu groß schien, keine funktionierende Toolchain > installiert zu bekommen. Ne, gerade die AVR sind ja dank Arduino dermaßen verbreitet, dass du auf jeden Fall eine funktionierende Toolchain bekommst. Das einzige was bei Debian, Ubuntu und Co leider manchmal ein bisschen doof ist, ist das die Pakete veraltet sind aber gerade bei Ubuntu/Mint gibt es bei beliebter Software meistens ein PPA und zur Not kann man es immer noch selber kompilieren, auch wenn das bei Compilern sicher nicht ganz trivial ist. Der GCC-ARM ist im aktuellen Ubuntu 18.04 z.B. nur in Version 6.3 enthalten, während der über ein PPA auch schon in Version 7.2 verfügbar ist. Wenn du eine Distri willst, die immer auf dem neuesten Stand ist, dann nimm Arch-Linux bzw. eines der Derivate von Arch, z.B. Antergos. Würde ich aber nur machen, wenn du schon ein bisschen Erfahrung mit Linux hast. Als ich von Windows auf Linux umgestiegen bin hatte ich auch ein Mint und war eigentlich sehr zufrieden damit. Eine "Spezial-Distribution für Embedded" braucht man auf keinen Fall. Als Editor würde ich mir auch mal Visual Studio Code anschauen. Der ist nicht ganz so schlank und schnell wie Kate, hat aber ein paar nette Features integriert.
Detlef R. schrieb: > Weswegen ich nach einer AVR-Distri gefragt hatte, war dass ich endlich > mal von windoof weg Und? Was gewinnt man mit diesem Schritt? Ich meine jetzt außer, dass man gleich mal auf Forenhilfe angewiesen ist .. Wo speziell liegt jetzt der Unterschied beim µC Proggen zw. Linux und "Windoof"?
Detlef R. schrieb: > für den Anfang finde ich einen Editor mit Syntaxhighlighting > ausreichend. das ist aber der Stand von vor 20 Jahren, IDE die auch die Quellen mit includes parsen und gutes Intellisense bieten möchte ich nicht mehr missen. Dazu Anbindung an Versionsverwaltung und Debugger, da ist der Editor doch nur ein Teil der Werkzeugkiste.
Wurscht schrieb: > Wo speziell liegt jetzt der Unterschied beim µC Proggen zw. Linux und > "Windoof"? 1. GCC läuft unter Linux wesentlich schneller (warum auch immer) 2. Linux hat komfortablere Multi-Desktop-Unterstützung 3. Man muss sich nicht erst umständlich eine Posix-Umgebung installieren um Make & Co nutzen zu können
Johannes S. schrieb: > Detlef R. schrieb: >> für den Anfang finde ich einen Editor mit Syntaxhighlighting >> ausreichend. > > das ist aber der Stand von vor 20 Jahren, IDE die auch die Quellen mit > includes parsen und gutes Intellisense bieten möchte ich nicht mehr > missen. Dazu Anbindung an Versionsverwaltung und Debugger, da ist der > Editor doch nur ein Teil der Werkzeugkiste. Der Mann schreibt doch, dass er zurück zu den Basics will.... und übrigens eine "gute" IDE macht aus einem noch lange keinen guten Programmierer, eher einen,der es hat gut mit einer IDE kann.
Johannes S. schrieb: > das ist aber der Stand von vor 20 Jahren, IDE die auch die Quellen mit > includes parsen und gutes Intellisense bieten möchte ich nicht mehr > missen. Codevervollständigung hat Kate auch. Was versteht man unter "includes parsen"? > Dazu Anbindung an Versionsverwaltung und Debugger, da ist der > Editor doch nur ein Teil der Werkzeugkiste. Warum muß die Versionsverwaltung Teil des Editors sein? Debuggen lohnt sich meiner Meinung nach bei uC nicht weil das meiste ja doch zeitkritisch ist. Im übrigen halte ich es da mit den Linux Prinzip: Für jede Aufgabe ein eigenes Tool. Man sieht: Ich bin kein Freund von IDEs. Das einzige, was ich bei Kate etwas vermisse, ist ein eingebautes RS232 Terminal.
Andreas B. schrieb: > Warum muß die Versionsverwaltung Teil des Editors sein? Weils super praktisch ist, wenn man direkt im Editor sieht, welche Zeilen oder Dateien gegenüber der letzten Version geändert wurden, und man bei "diff" Anzeigen auch das übliche Highlighting usw hat. Andreas B. schrieb: > Debuggen lohnt sich meiner Meinung nach bei uC nicht weil das meiste ja > doch zeitkritisch ist. Dann hast du es noch nie richtig genutzt... Es ist ungeheuer praktisch bei vertrackten Problemen, man kann Peripherie-Register beobachten, schauen wann sich Variablen ändern usw. Buffer-Overflow-Bugs in Dritt-Libraries würdest du sonst nie finden. Das zeitkritische ist gar nicht so oft ein Problem - viele (externe) Peripherie kann man beliebig lange anhalten. Dass der Debugger in der IDE integriert ist hat wieder den Vorteil dass man das gleiche Syntax Highlighting hat usw - halt alles im selben Editor Fenster, nicht drei verschiedene.
Andreas B. schrieb: > Was versteht man unter "includes > parsen"? das der Editor auch die defines, Typen, Klassen, Funktionen, Funktionsargumente kennt die zum Projekt gehören. Wenn ich den Anfang so eines Elements schreibe hilft mir der Editor wie es weitergeht. Ihr habt vielleicht alles selber geschrieben und noch alles im Kopf, ich bin aber schon alt und arbeite mit mehreren verschiedenen Systemen und kann mir nix mehr merken :) Debuggen wie Dr. Sommer sagt, dazu noch das man damit fremde SW besser (oder überhaupt erst) durchblicken kann.
Johannes S. schrieb: > das ist aber der Stand von vor 20 Jahren, IDE die auch die Quellen mit > includes parsen und gutes Intellisense bieten möchte ich nicht mehr > missen. Dazu Anbindung an Versionsverwaltung und Debugger, da ist der > Editor doch nur ein Teil der Werkzeugkiste. Was Du beschreibst, konnten Emacs und vi schon vor deutlich mehr als 20 Jahren, natürlich inklusive Autocompletion, SCM (damals meistens noch CVS) und natürlich Debugger. Nur so fancy Namen wie "Intellisense" hatten wir damals noch nicht dafür, leider. ;-)
Für den Notfall lässt sich hier https://build.opensuse.org mit etwas Durchklicken raus finden wie aktuelle avr-gcc, usw. kompiliert werden, oder einfach die bereits gebauten Pakete installieren. Gruß, Frank
Dr. Sommer schrieb: > Weils super praktisch ist, wenn man direkt im Editor sieht, welche > Zeilen oder Dateien gegenüber der letzten Version geändert wurden, und > man bei "diff" Anzeigen auch das übliche Highlighting usw hat. Wenn ich das Bedürfnis danach habe, öffne ich die csv Versionsverwaltung und schaue mir die Änderung im anderen Fenster oder einer anderen Arbeitsfläche an. Mir persönlich geht durch solche Gimmiks zu viel Platz auf den Bildschirm verloren, die ich lieber für den Editor habe. Ich sehe nämlich ganz gerne was ich 20 Zeilen vorher geschrieben habe. > Dann hast du es noch nie richtig genutzt Bei Programmen für den PC schon. Da sehe ich auch den Sinn darin. Dr. Sommer schrieb: > Das zeitkritische ist gar nicht so oft ein Problem Bei mir eigentlich fast immer. Jedenfalls bei den AVRs. Dr. Sommer schrieb: > viele (externe) > Peripherie kann man beliebig lange anhalten. Öhm, das erzähle mal irgendeinen Sensor oder einem Display daß es mal kurz stehenbleiben soll. ;-) Johannes S. schrieb: > das der Editor auch die defines, Typen, Klassen, Funktionen, > Funktionsargumente kennt die zum Projekt gehören. Das hat Kate teilweise. Zumindest kann man sich die Variablen und Funktionen anzeigen lassen. Mir hat es bis jetzt immer gereicht. Wie gesagt wir sprechen hier von uC Programmierung. Aber ich sehe schon, da kann man sich lange darüber streiten. Da hat wohl jeder seine besonderen Vorlieben.
Andreas B. schrieb: > Mir persönlich geht durch solche Gimmiks zu viel Platz auf den > Bildschirm verloren, die ich lieber für den Editor habe. Ich sehe > nämlich ganz gerne was ich 20 Zeilen vorher geschrieben habe Manche Leute haben halt Bildschirme mit mehr als 1024x768 Pixeln Auflösung :) Das Quick Diff von Eclipse ist einfach supi, man sieht immer sofort was man alles seit der letzten Known-Good Version vermurkst hat. So hat man auch automatisch sauberere Commits, weil man nicht ständig irgendwo Leerzeilen stehen lässt. Andreas B. schrieb: > Öhm, das erzähle mal irgendeinen Sensor oder einem Display daß es mal > kurz stehenbleiben soll. ;-) Dann gehen halt ein paar Werte verloren, oder das Display bleibt stehen... Na und? Bei Displays ist das nur bei solchen mit parallelem RGB-interface relevant (ohne eigenen Controller) - aber die entsprechenden RGB-Controller im Prozessor laufen natürlich beim Debuggen weiter. Daher bleibt sogar hier das Bild intakt.
Johannes S. schrieb: > Gibt es dafür keine Docker Container mit dem nötigen Kram? > > Hier war das schon mal Thema: > Beitrag "Docker mit gcc-avr" > > Habe mich damit selber noch nicht anfreunden können, aber das scheint ja > der heisse Sch**ss zu sein. Nach anfänglicher Skepsis bin ich zwar mittlerweile ein sehr großer Fan von Docker geworden. Aber erstens glaube ich nicht, daß man etwas benutzen muß, nur weil es gerade der heisze Sheisz ist, und zweitens glaub ich nicht, daß es sich lohnt, Docker alleine für diesen einen Anwendungsfall zu lernen und zu nutzen, da fehlt einfach der Benefit. Docker hat viele kleine und große Erleichterungen und Vereinfachungen der täglichen Entwickler-, QA-, Admin- und anderer Tätigkeitsfelder zu bieten, kann seine Stärken aber im Wesentlichen bei Arbeiten ausspielen, bei denen Automatisierung, Reproduzierbarkeit, und ein konsistenter Workflow wichtig sind. Um einen einzelnen Compiler auf einer einzelnen Maschine aufzusetzen, ist das sicher überdimensioniert. Um konsistente Buildumgebungen für Teams aus mehreren Leuten auszurollen, ist Docker hingegen eine feine Sache.
Dr. Sommer schrieb: > Andreas B. schrieb: >> Warum muß die Versionsverwaltung Teil des Editors sein? > > Weils super praktisch ist, wenn man direkt im Editor sieht, welche > Zeilen oder Dateien gegenüber der letzten Version geändert wurden, und > man bei "diff" Anzeigen auch das übliche Highlighting usw hat. Es ist genauso praktisch, dafür ein externes Werkzeug zu benutzen. Das hat allerdings den Vorteil, daß die Einzelkomponenten der Entwicklungsumgebung und sogar unterschiedliche Versionen der Werkzeuge nach Bedarf und Aufgabe frei miteinander kombiniert, erweitert oder geändert werden können.
Ich will Docker auch nicht schlecht reden, und warum ‚nur dafür‘? Ein Vorteil ist doch sicher das man zu einem Projekt die passenden Tools mit geringerem Aufwand als eine VM halten kann ? Bei neueren Tools hat man oft das Problem das alte Projekte oft nicht mehr 100% kompatibel sind und irgendwo irgendwelche Fehler werfen.
Johannes S. schrieb: > Ich will Docker auch nicht schlecht reden, und warum ‚nur dafür‘? Ein > Vorteil ist doch sicher das man zu einem Projekt die passenden Tools mit > geringerem Aufwand als eine VM halten kann? Eigentlich nicht. Eine VM kannst Du aktualisieren -- das geht mit einem Docker-Image zwar prinzipiell auch, aber die eigentliche Idee, ist, das Docker-Image stattdessen einfach neu zu bauen. Der Aufwand tut sich da allerdings nicht allzu viel. Die großen Stärken von Docker sehe ich primär in der Reproduzierbarkeit und der Vereinfachung des Deployment. Das lohnt sich aber, wie gesagt, IMO erst dann, wenn man mehrmals dieselbe Aufgabe erledigen, oder mehrere Maschinen bedienen muß. Aber mach's wie ich: probier's einfach mal aus. Vielleicht findest für Dich ja ganz andere Vor- oder Nachteile als ich? Docker hat, wie gesagt, nicht das eine Mörderfeature, nicht die eine Killerfunktion. Stattdessen sind Docker und Container überhaupt ein anderer Weg, um über Software, Prozesse, Prozeßmanagement und -Deployment zu denken. Das kann, je nach persönlichen Aufgaben und Vorlieben, nutz- und gewinnbringend sein, muß aber nicht.
Danke, das kommt auf meine ToDo Liste, aber erstmal nicht mit höchster Priorität.
Dr. Sommer schrieb: > Manche Leute haben halt Bildschirme mit mehr als 1024x768 Pixeln > Auflösung :) Habe ich auch (1900x1200). Das Problem ist nur daß mein Eizo nicht kaputtgeht und mich somit dran hindert mir einen 28" 4k Monitor zu kaufen. ;-) Und dann will ich 100 Zeilen auf den Schirm sehen und habe auch keinen Platz für Gimmiks. Dr. Sommer schrieb: > Dann gehen halt ein paar Werte verloren Das trifft vielleicht bei analogen Sensoren zu, die benutze ich aber kaum. Digitale lassen sich dann erst gar nicht auslesen. Und genau da habe ich zumindest, das meiste Bedürfnis irgendetwas zu debuggen. Ich lasse mir im Bedarfsfall mal ein paar Sachen über RS232 ausgeben, damit bin ich bis jetzt immer ausgekommen. Sheeva P. schrieb: > Es ist genauso praktisch, dafür ein externes Werkzeug zu benutzen. Das > hat allerdings den Vorteil, daß die Einzelkomponenten der > Entwicklungsumgebung und sogar unterschiedliche Versionen der Werkzeuge > nach Bedarf und Aufgabe frei miteinander kombiniert, erweitert oder > geändert werden können. Das ist eben die Linux Denke, die ich auch befürworte. Windows Nutzer sind da anders erzogen worden. (oh, jetzt wird es gefährlich ...)
Nun ja, wenn die IDE z.Bsp. Git unterstützt hat das beim Refactoring deutliche Vorteile. Wenn ich Dateien in der IDE verschiebe wird git mv gleich automatisch mit ausgeführt. Das ist sonst immer ein wenig kacke. Erst die Datei verschieben und das dann in der IDE nachziehen. Neu erzeugte Dateien werden auch gleich mit ins Repository aufgenommen, ohne das man diesen extra Schritt gehen muss.
Sheeva P. schrieb: > Das hat allerdings den Vorteil, daß die Einzelkomponenten der > Entwicklungsumgebung und sogar unterschiedliche Versionen der Werkzeuge > nach Bedarf und Aufgabe frei miteinander kombiniert, erweitert oder > geändert werden können. Das Eclipse Git Plug-in kann man auch einzeln Updaten... warum auch immer das nötig sein sollte. Andreas B. schrieb: > Digitale lassen sich dann erst gar nicht auslese Das hab ich ja noch nie gehört, bei welchem Sensor ist das denn so? Ich kenne das nur so dass höchstens ein Overflow Bit gesetzt wird... ich hab jedenfalls schon viel JTAG debuggt und Echtzeit Probleme waren kein großes Problem. Allein schon für die Initialisierung von Peripherie hilft das... Achja, z.B. der J-link hat extra eine Art Echtzeit Profiling, wo man sich wunderschön anschauen kann wo wie viel Zeit gebraucht wird. Andreas B. schrieb: > Ich lasse mir im Bedarfsfall mal ein paar Sachen über RS232 ausgeben, > damit bin ich bis jetzt immer ausgekommen. Was machst du wenn ein komplexes Programm irgendwo einfriert? Oder eine Library abstürzt? Erstmal alles voller printf packen? Das verlangsamt das Programm auch! Im Debugger sieht man im Idealfall direkt die Stelle wo eine Exception auftrat...
Dr. Sommer schrieb: > bei welchem Sensor ist das denn so? Lies mal z.B. onewire Sensoren aus. Letztens habe ich gerade einen Protokollumsetzer vom SHT3x zu onewire gemacht. Da ist nichts mit mal kurz anhalten. Klar kann man entsprechenden Testequipment solche Sensoren simulieren. Das ist aber außerhalb des Hobbybudgets. Dr. Sommer schrieb: > Was machst du wenn ein komplexes Programm irgendwo einfriert? Oder eine > Library abstürzt? Brain 2+ verwenden und nicht printf verwenden, das zieht zu viele Libraries mit rein. An den vermuteten Punkten verschiedenen Character ausgeben, dann sieht man wo er hängt. Ich mach da bestimmt kein seitenlanges Geschwafel mit printf rein. ;-) Und wenn es eine zeitkritische Stelle ist, lass ich einen Port wackeln. Außerdem kann man solches Durcheinander vermeiden wenn man die Komponenten nacheinander entwickelt und testet. Das macht die Fehlersuche erheblich übersichtlicher. Bei STM32 Entwicklung mag das insgesamt etwas anders ausehen, aber wir sind ja noch bei den AVRs (zumondest hört sich das so an).
Andreas B. schrieb: > Lies mal z.B. onewire Sensoren aus. Wer macht denn sowas... :) wenn man deren Protokoll mit UART oder Timer+DMA umsetzt könnte das auch gehen... Andreas B. schrieb: > An den vermuteten Punkten verschiedenen Character ausgeben, dann sieht > man wo er hängt. Je nach Programm Größe... Viel Spaß. Andreas B. schrieb: > Außerdem kann man solches Durcheinander vermeiden wenn man die > Komponenten nacheinander entwickelt und testet So die Theorie. Oft stört sich sowas aber gegenseitig, oder die "fertig entwickelte und getestete" Komponente hat Bugs die erst im Einsatz auftreten. Beispielsweise hat die STM32 USB Library einen Buffer Overflow. Der hat bei mir im Programm einen vtable Pointer überschrieben sodass das Programm bei einem schnöden Funktions Aufruf abgestürzt ist. Da habe ich einen Watchpoint auf den Pointer gesetzt und hab sofort die entsprechende Stelle gefunden. Ohne Debugger hätte das sehr, sehr lange gedauert. Andreas B. schrieb: > aber wir sind ja noch bei den AVRs Bei denen kann man doch auch komplexe Programme schreiben... die gibt's ja auch mit 256KB Programmspeicher, da passen viele Zehntausend LoC rein.
Ralph S. schrieb: > Seit mehr als 3 Jahren werkel ich an eine Livedistribution, die eben > Mikrocontrollerprogrammierung ermöglichen soll. Was ist der Zweck von sowas, das benutzt doch keiner und will auch niemand! Warum schreibst Du nicht stattdessen ein Script oder ein Meta-Paket das das ganze Zeug auf einer normalen üblichen Distribution installiert? Für jeden einzelnen Einsatzzweck eine separate Distribution zu haben ist doch an Umständlichkeit nicht mehr zu überbieten! Jede normale Distribution erlaubt es beliebige Software per Paket nachzuinstallieren und beliebig zu kombinieren. Das ist die Zukunft!
:
Bearbeitet durch User
Karl Käfer schrieb: > Was Du beschreibst, konnten Emacs und vi schon vor deutlich mehr als 20 > Jahren, natürlich inklusive Autocompletion Ja, und man braucht 20 Jahre um aus einem nackten vi oder Emacs mit hundertzwölfunddreißig Plugins, Hilfsprogrammen, Zusatzpaketen, Scripten und Konfigschnipseln überall verteilt so zu hinzufummeln daß es endlich 80% dessen kann was Eclipse out of the Box (!) schon kann! Und dann hat man immer noch keinen gescheiten Editor sondern irgendwas mit völlig inkompatiblen Tastenkürzeln die einen in den Wahnsinn treiben weil keiner je daran gedacht hat daß man mit dem Ding eigentlich auch vernünftig editieren können will. Hör mir auf. Wenn Du statt einer IDE lieber einen modularen Texteditor empfehlen willst der auch gut und angenehm zu benutzen und zu erweitern ist dann empfehle stattdessen vscode, das definiert den Stand der Technik in Sachen Editor momentan mit weitem Abstand.
:
Bearbeitet durch User
Bernd K. schrieb: > Ja, und man braucht 20 Jahre um aus einem nackten vi oder Emacs mit > hundertzwölfunddreißig Plugins, Hilfsprogrammen, Zusatzpaketen, Scripten > und Konfigschnipseln überall verteilt so zu hinzufummeln daß es endlich > 80% dessen kann was Eclipse out of the Box (!) schon kann! Nein, das hat man in der Zeit installiert, die Eclipse alleine zum starten braucht.
Andreas B. schrieb: > Nein, das hat man in der Zeit installiert, die Eclipse alleine zum > starten braucht. Jaja. Schon klar. Zeig doch mal wie Du das ganze Gedöns in 7 Sekunden installierst und konfigurierst. Ich bediene die Stoppuhr.
:
Bearbeitet durch User
Bernd K. schrieb: > empfehle stattdessen vscode da kann man übrigens super per Plugin die Funktionalität von Vim nachrüsten ;)
Bernd K. schrieb: > Ja, und man braucht 20 Jahre um aus einem nackten vi oder Emacs mit > hundertzwölfunddreißig Plugins, Hilfsprogrammen, Zusatzpaketen, Scripten > und Konfigschnipseln überall verteilt so zu hinzufummeln daß es endlich > 80% dessen kann was Eclipse out of the Box (!) schon kann! Ich kann nur für mich sprechen, aber bis auf die Installation der passenden Pakete und das Einschalten der betreffenden Funktionen über die GUI hab' ich noch nie was am Emacs "gefummelt", das funktioniert alles out-of-the-box.
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.