Hallo Community, ich bin absoluter Neuling auf dem Gebiet der Microcontroller. Ich komme aus der SPS Programmierung. Habe mich seit ein paar Tagen in die Welt eingelesen und verstehe noch nicht viel. Welche Typen und welche Programmiersysteme würdet Ihr denn empfehlen AVR,PIC? Bis jetzt interessant finde ich LunaAVR verstehe aber bis jetzt überhaupt nicht, wie man Debugging auf der Hochsprachenebene macht ?? Man muß doch sehen was in dem Teil passiert. Muß ich andere IDE’s benutzen oder geht das mit Microcontroller überhaupt ?? Für jeden Hinweis wäre ich sehr dankbar. Vielen Dank im Voraus. Carlo
Herr Fahrlehrer. Ich habe noch nie am Steuer gesessen. Bitte zeigen Sie mir, die man das Auto in Bewegung setzt und dann den Nürburgring durchfährt. Andere Leute bevorzugen das Schritt-für-Schritt-Verfahren. Es hat ein paar gravierende Vorteile, gegenüber dem Alles-auf-Einmal-Verfahren. Trotzdem ein Tip: Schau mal oben, links unter AVR nach oder unter https://www.mikrocontroller.net/articles/AVR Für den Anfang sollte das ausreichend Beschäftigung liefern.
Sebastian S. schrieb: > Herr Fahrlehrer. Ich habe noch nie am Steuer gesessen. Bitte zeigen Sie > mir, die man das Auto in Bewegung setzt und dann den Nürburgring > durchfährt. Was ist Dir denn über die Leber gekrochen? Seine Frage ist doch völlig legitim und nicht zu hoch gegriffen! Grüsse, René
Carlo S. schrieb: > Welche Typen und welche Programmiersysteme würdet Ihr denn empfehlen > AVR,PIC? Jehowa! SCNR
Hallo Sebastian und „Hinz“ Ich verstehe nicht wirklich , warum Ihr euch auf den „Schlips“ getreten fühlt. Die Frage war doch nur, ob es Systeme mit Hochsprachendebugging gibt, da ich nicht die Absicht habe ein paar LED’s blinken zu lassen, wenn ich mein Projekt mit Microcontroller realisieren sollte. Ich kann mir nicht vorstellen dass man komplexe Aufgaben ohne Fehler programmiert und Somit ohne sinnvollen Debugger zeitnah zu einem Ergebnis kommt. Eine sinnvolle Antwort würde mich erfreuen. Vielen Dank im Voraus. Carlo
Man programmiert die Aufgabe nicht in eines durch, insbesondere nicht wenns komplexer wird. Man zerlegt die Aufgabe in Funktionen, Prozeduren und Klassen. Ferner kommt man mit Debugmeldungen (z.B. Textausgaben auf den Seriellport) schon sehr weit. Debugger ist erstmal nicht wirklich wichtig, aber natürlich trotzdem ein gutes Werkzeug. Mein Tipp, Arduino fur 2,50€ kaufen und erstmal irgendwas machen.
Natürlich gibts das! z.B. für AVR und SAM das Atmel Studio So gibts für eigentlich jeden µC sein eigenes und Eclipse+gdb für alle. Naja... Aber irgendwie macht ein Hardwaredebugger wenig Spaß auf µC. Die ganze Peripherie, und das Zeitverhalten, spielt einem gern Streiche. Carlo S. schrieb: > Ich kann mir nicht vorstellen dass man komplexe Aufgaben ohne Fehler > programmiert und > Somit ohne sinnvollen Debugger zeitnah zu einem Ergebnis kommt. Tja... Dann steht dir ja noch eine Einsicht bevor....
Carlo S. schrieb: > Bis jetzt interessant finde ich LunaAVR Davon habe ich keine Ahnung. Ich verwende an der Arbeit Keil Microvision zum Programmieren von STM32-Controllern in C, und privat MPLAB X zum Programmieren von kleinen PICs. In beiden IDEs kann man natürlich die C-Programme auf Quelltextebene debuggen und Variablen und Registerinhalte anschauen und ggf. auch ändern. Mit AVR-Studio habe ich auch schon gearbeitet, auch da geht das Debuggen natürlich auf "Hochsprachen-Ebene". Beim MPLAB debugge ich meist zunächst mit dem Simulator. Die Hardware der PICs wird zum größten Teil auch vom Sim unterstützt, und inzwischen kann man da auch im "Logic Analyzer" Fenster mit zwei Cursorn Zeiten abmessen.
Auch wenn oft geschriehen wird wie "unsauber" das Programmieren mit Arduino sein kann, möchte ich jetzt trotzdem mutig Arduino vorschlagen. Für die ersten Schritte bekommt man ohne große Kosten ein vollständig funktionales uC "Entwicklungssystem". Die IDE installiert in der Regel ohne besondere Probleme, jeder PC oder Mac kann verwendet werden und die Arduino AVR Bords sind erschwinglich. Trotz des kontroversen Rufs wird mit dem C/C++ GCC Compiler gearbeitet und Umsteigen ist später nicht so schwer. Dazu kommt, daß es unzählige funktionierende Beispiele gibt, die am Anfang vermeiden mit frustrierenden Problemen stecken zu bleiben. Erst wenn man ein genügend Maß Erfahrung hat, lernt man bei der Fehlersuche. Am Anfang sollen zumindest die bekannten Sachen anstandslos funktionieren. Da alle Bibliotheken in C/C++ geschrieben sind kann man die gesammten Quellen studieren. Zuletzt existiert eine gewaltige User Community. Probiers aus um Dir ein Bild zu machen und ich glaube Du wirst es nicht bereuen. Da Arduino Bords auf AVR aufbauen lassen sie sich generell auch anderweitig einsetzen und sind kein rausgeschmissenes Geld. Arduino ist ähnlich wie ein Hersteller "Referenz Design". Die mitgegebenen Beispielsprogramme und Bords funktionieren in der Regel auf Anhieb. Am Anfang ist das ein nicht zu unterschätzender Vorteil. STM32 ist für den Anfang einfach im Detail viel zu kompliziert. Nicht schwer, aber zu viele Bäume um den Wald zu empfinden. Das sollte man sich nicht antun. Man kann auch mit Arduino sauber programmieren. Registerzugriffe, Interruptbetrieb u.v.a. sind genauso wie woanders möglich. Das wäre halt mein möglicher Vorschlag. Grüße, Gerhard
:
Bearbeitet durch User
Hallo „nur zufällig hier“, Arduino Fanboy, Thomas Elger und Gerhard O. Nachdem ich am Anfang über die ersten Reaktionen enttäuscht war bedanke ich mich bei euch über eure Hinweise. Ich muss mich noch weiter einarbeiten und werde eure Meinungen in meine Entscheidung einfließen lassen. Ich komme halt aus einer anderen Welt (SPS) wo ich seit 25 Jahren professionell arbeite. Bei der SPS Programmierung sehe ich halt in jeden Moment im Ablauf des Programm’s was das Teil gerade macht. Deshalb habe ich mir vorgestellt das auf Microcontroller portieren zu können. Ob da meine Ansätze richtig sind, wird sich zeigen. Carlo
Hi, Meine Meinung: Für alles ohne (RT)OS braucht man keinen Debugger. Der Chip soll ja was machen mit den Interfaces. Und ein Scope und Mulimeter und serielle Konsole hilft Dir da mehr... Weil die Aufgabe eher lautet: Wie konfiguriere ich meine Hardware richtig ? Da hilft kein Debugger, sondern nur Verständnis Deines uC. Was ist ein Stack Overflow? Warum springt das Ding x mal in den Interrupt ? Warum sind die ADC Werte so bescheiden? Wieso macht der jetzt wieder nen Reset ? Die Programme sind nicht so komplex. Wenn doch: Am PC den Algo testen... Wenn Du programmieren kannst und den uC kennst, kannst Du 90% funktionierenden Code nur anhand der Datenblätter der Aktuatoren/Sensoren schreiben. Gruß B2
Carlo S. schrieb: > wie man Debugging auf der Hochsprachenebene macht Mit einem Hardware-Debugger. Am günstigsten ist ein Mikrocontroller-Board mit integriertem Debugger. Wie schon ausgeführt ist es mit einem 8-bit Mikrocontroller einfacher einzusteigen. Hier mal als Beispiel günstige Boards für 8-bit und 32-bit, beide mit demselben Debugger. Keine weitere Ausstattung erforderlich. https://de.rs-online.com/web/p/products/9140107/ https://de.rs-online.com/web/p/products/8725700/ Du kannst Dir auch vorab die Software ansehen. Wenn Du auf dem PC Visual Studio oder Eclipse kennst, ist es sehr ähnlich. https://www.silabs.com/products/development-tools/software/simplicity-studio Wie auch schon ausgeführt, gibt es beim Debuggen von Mikrocontroller ähnliche Probleme wie auch bei PC Programmen. Der Debugger lässt das Programm langsamer laufen, somit wird das Timing anders. Wenn Du Kommunikation wie UART oder USB verwendest, wird es zum Timeout kommen. Also nach dem Debuggen immer noch das Release ausführlich testen. nur zufällig hier schrieb: > Arduino fur 2,50€ kaufen und erstmal irgendwas machen Das geht natürlich auch :-)
Hallo Lothar, wenn das Debuggen das Timing verändert ist es nicht gut. In meiner Welt (SPS) werden die Daten in Echtzeit in der SPS gespeichert oder über Ethernet „weggeschoben“ aber vielleicht ist ne SPS auch „langsamer“ . Auf alle Fälle kann ich bei UART oder TCP/IP - Kommunikation sehen , was passiert. Einen kleinen AVR oder PIC habe ich schon vor 20 Jahren programmiert und somit kann ich die 2,5 € sparen. Ich habe halt jetzt ein Projekt wo aus der Stückzahl der Geräte ein Microcontroller wahrscheinlich angebracht wäre anstatt eine SPS zu nehmen. Carlo
Carlo S. schrieb: > wenn das Debuggen das Timing verändert ist es nicht gut Das lässt sich gar nicht vermeiden. Wenn der Mikrocontroller im Release mit 100 MHz läuft, kann er im Debug vielleicht mit 4 MHz laufen. Das ist halt entsprechend zu berücksichtigen und zu Testen, indem im Release Testdaten über Terminal rausgeschrieben werden. Die einzige sehr teure Alternative ist Trace. Aber wenn Du bei der SPS Debugging Step-by-Step machst, dann hängt doch auch das Timing? Abgesehen davon sind doch die meisten SPS Mikrocontroller. > über Ethernet weggeschoben Das gibt doch Latenz. Wir sind vor einiger Zeit von einer RS485 PC-Karte mit FPGA auf einen (teuren) industriellen Ethernet/RS485 Wandler umgestiegen. Latenz ging von 2us auf 200us hoch.
Hallo Lothar, eine SPS hat eine völlig andere Philosophie, da wird das Programm zyklisch durchlaufen, von Anfang bis Ende. Bis das Programm das nächste mal abgearbeitet wird, hat der heute sehr leistungsfähige Prozessor Zeit die im Hintergrund „geloggten“ Daten über TCP an das Programmiergerät z.Teil auch über Hilfs-CPU’s zu senden . Da kann man zu jedem Zeitpunkt im Programm den Wert der Variablen sehen. Carlo
Lothar schrieb: > Das lässt sich gar nicht vermeiden. Wenn der Mikrocontroller im Release > mit 100 MHz läuft, kann er im Debug vielleicht mit 4 MHz laufen. Das ist nicht richtig! Solange das Programm läuft, läuft es auch mit Debugger in original-Geschwindigkeit (jedenfalls kenne ich es so!). Erst, wenn das Programm z.B. durch Erreichen eines Breakpoints abgebrochen wird oder wenn man es im Einzelschritt durchsteppt, ist das Timing natürlich dahin. Im übrigen verstehe ich die Aversion gegen Debugger hier von manchen Leuten nicht. Es ist ein Werkzeug, das natürlich auch seine Grenzen hat. Nicht alles muss immer in Echtzeit ablaufen, oder es ist schon oft sehr hilfreich, wenn man ein Programm an einer gewissen Stelle abbrechen und in die Variablen und Register (auch der Peripherie) schauen kann. Von pauschalen Aussagen wie "...braucht man keinen Debugger" halte ich gar nichts. N2 schrieb: > Da hilft kein Debugger, sondern nur Verständnis Deines uC. Was ist ein > Stack Overflow? Warum springt das Ding x mal in den Interrupt ? Warum > sind die ADC Werte so bescheiden? Wieso macht der jetzt wieder nen Reset > ? Tja, genau um solche Fragen zu ergründen, ist ein Debugger meist recht nützlich!
:
Bearbeitet durch User
Carlo S. schrieb: > eine SPS hat eine völlig andere Philosophie Wenn ich z.B. das hier lese, dann scheint das nicht so zu sein: Das "Sampling trace" ist dasselbe wie das Mikrocontroller Trace. Und beim "Debugging" kannst Du einen Breakpoint im Programm setzen oder "Single step" machen. Dann steht das Programm und damit auch das Timing. Dann läuft der Tank über :-) https://infosys.beckhoff.de/english.php?content=../content/1033/tcplccontrol/html/tcplcctrl_onlinedebug.htm&id= > da wird das Programm zyklisch durchlaufen, von Anfang bis Ende Nur im "Single cycle debug". Das geht beim Mikrocontroller Debug auch. Oder siehst Du das anders? Du kannst übrigens Mikrocontroller auch SPS-mäßig programmieren: mit LabVIEW oder Simulink. Das ist für einen Mikrocontroller Experten aber ganz furchtbar.
Carlo S. schrieb: > eine SPS hat eine völlig andere Philosophie, Ja. <seufz> > da wird das Programm zyklisch durchlaufen, von Anfang > bis Ende. Bis das Programm das nächste mal abgearbeitet > wird, hat der heute sehr leistungsfähige Prozessor Zeit > die im Hintergrund „geloggten“ Daten über TCP an das > Programmiergerät z.Teil auch über Hilfs-CPU’s zu > senden . > Da kann man zu jedem Zeitpunkt im Programm den Wert der > Variablen sehen. Gibt's im Großen und Ganzen alles nicht. Vergiss den gesamten Komfort, den Du von der SPS kennst. Das einzige, was GANZ UNGEFÄHR vergleichbar ist, ist das Lesen von Eingängen und Setzen von Ausgängen, aber schon bei der Pufferung, die die SPS macht (Prozessabbild der Eingänge/Ausgänge) ist Schluss. Timer gibt es zwar, aber nicht in dem Sinne, in dem die SPS das kennt. Da das Prinzip der zyklischen Abarbeitung im Sinne der SPS nicht bekannt ist, gibt es auch keine Unterstützung für das gleichzeitige Steuern unabhängiger äußerer Abläufe. Fortgeschrittene Programmierer beherrschen dies zwar trotzdem, aber die Verwaltung dafür muss man i.d.R. komplett von Hand bauen ("state machines"). Aktualisierung von des Programmes bei laufender Programmausführung geht selbstverständlich auch nicht. Dass während der Zeit, in der das Programm eingespielt wird, alle Ausgänge auf ungefährliche Werte gesetzt sind, liegt selbstverständlich vollständig in der Verantwortung des Programmierers. Debugging-Schnittstellen gibt es, die sind aber m.W. hersteller- und baureihenspezifisch. Das absurde an der Situation ist, dass der durchschnittliche Mikrocontroller-Programmierer die SPS-Leute belächelt, weil sie etwas derart rückständiges wie AWL verwenden müssen... Ach ja, apropos: Wenn Du AWL gemacht hast, wird Dir die Programmiersprache C gefallen -- die ist genauso unlesbar... Der Fairness halber: Ein "nackter" Mikrocontroller ist schneller. 10 Mio Maschinenbefehle je Sekunde sind auch für kleine, stomsparende µC nicht exotisch. Alles, was mit "normalem Zahlenrechnen" zu tun hat, geht im µC viel einfacher.
Lothar schrieb: > Carlo S. schrieb: >> eine SPS hat eine völlig andere Philosophie > > Wenn ich z.B. das hier lese, dann scheint das nicht > so zu sein: Oh doch. >> da wird das Programm zyklisch durchlaufen, von >> Anfang bis Ende > > Nur im "Single cycle debug". Du verstehst es nicht: Das SPS-Programm wird (normalerweise) STÄNDIG KOMPLETT zyklisch durchlaufen, OHNE UNTERBRECHUNG. Da man (zumindest in AWL) m.W. nicht rückwärts springen kann, können PRINZIPBEDINGT keine Blockierungszustände auftreten. "Warten" gibt es PRINZIPBEDINGT nicht -- es gibt nur den Fall, dass ein "Timer" noch nicht abgelaufen ist. Und -- ja, eine SPS kennt DUTZENDE Timer (wenn nicht noch mehr). Da das Ganze letztlich eine spezielle Interpretersprache ist, gibt es auch keine "Abstürze" im herkömmlichen Sinne. Der logische Ablauf in bestimmten Funktionsbausteinen kann falsch sein, dann macht ein Teil der Maschine etwas Falsches, aber die anderen Teile der Maschine arbeiten trotzdem korrekt. Infolge des Interpretercharakters lassen sich Teile des Programmes austauschen, WÄHREND DIE SPS ARBEITET und WÄHREND DIE VON DER SPS GESTEUERTE MASCHINE LÄUFT! Im einen Durchlauf des Zyklus wird halt der alte Funktionsbaustein benutzt, dann wird intern irgendein Pointer umgestellt, und im nächsten Zyklus wird der neue, geänderte FB ausgeführt. Kein Problem. Die Abschätzigkeit, mit der auf die SPS-Leute herabgesehen wird, ist (wenigstens was das Steuern externer Prozesse angeht) VÖLLIG unberechtigt. Die µC-Fritzen lösen zu 80% der Zeit Probleme, die eine SPS prinzipbedingt nicht hat.
nur zufällig hier schrieb: > Man programmiert die Aufgabe nicht in eines durch, insbesondere nicht > wenns komplexer wird. > Man zerlegt die Aufgabe in Funktionen, Prozeduren und Klassen. Ein anschauliches Modell für objektorirntiere Programmierung ist die Großbaustelle BER. Man zerlegt die Aufgaben, Kapselt die Dinge - und irgendwann verliert man den Kontrollfluss
Possetitjel schrieb: > mit der auf die SPS-Leute herabgesehen wird Kenne ich so nicht. Gab doch sogar mal eine AVR Soft SPS: http://www.microsps.com/ Aber Fakt ist, das komplexe Industrieanlagen z.B. in der Verfahrenstechnik, die statt nur PID-Regler auch MPC o.ä. brauchen mit einer SPS nicht zu realisieren sind. > gibt es auch keine Unterstützung für das gleichzeitige Steuern > unabhängiger äußerer Abläufe Parallax Propeller, Multicore-Mikrocontroller z.B. LPC4370 > Aktualisierung des Programms bei laufender Programmausführung Bei Multicore-Mikrocontroller geht das.
Lothar schrieb: > Possetitjel schrieb: >> mit der auf die SPS-Leute herabgesehen wird > > Kenne ich so nicht. Gab doch sogar mal eine > AVR Soft SPS: Ja, ich weiss. Es gab immer mal wieder Anläufe; etabliert hat sich m.W. keiner. (Leider.) > Aber Fakt ist, das komplexe Industrieanlagen z.B. in der > Verfahrenstechnik, die statt nur PID-Regler auch MPC o.ä. > brauchen mit einer SPS nicht zu realisieren sind. Eine SPS ist auch nicht primär ein (klassischer) Regler, sondern ein Ding, mit dem man Ablaufsteuerungen realisiert. Das schließt das Zusammenwirken mit (unterlagerten) Reglern und mit übergeordneter Prozessleittechnik ein. >> gibt es auch keine Unterstützung für das gleichzeitige >> Steuern unabhängiger äußerer Abläufe > > Parallax Propeller, Multicore-Mikrocontroller z.B. LPC4370 Also bitte... bleib' doch ausnahmsweise mal ernsthaft. Der prototypische Mikrocontroller ist auf µC.net ein AVR, der in C programmiert wird. Weder der AVR noch C haben IRGEND EINE Unterstützung für das Steuern paralleler externer Prozesse. Es geht natürlich, wenn man weiss, wie man einen endlichen Automaten programmiert, aber ich sprach von UNTERSTÜTZUNG, nicht von "ist prinzipiell machbar". >> Aktualisierung des Programms bei laufender Programmaus- >> führung > > Bei Multicore-Mikrocontroller geht das. ...die natürlich der Standard sind. Meine Güte.
Neben einem guten Debugger würde ich auf eine Entwicklungsumgebung achten, welche effizientes Kompilieren und Downloaden ermöglicht. Stichwort: In-system programming Je nach Problemstellung helfen: Logic Analyzer Protokoll Analyzer Oszilloskop Multimeter
Eine Frage aus Kanada: Seid ihr Frühaufsteher oder kommt das von Schlaflosigkeit. Meine Güte, bei mir ist es 21 Uhr und man hört immer noch von Euch:-)
Beitrag #5358278 wurde vom Autor gelöscht.
Hallo Harlekin, Deine Aussagen gefallen mir sehr gut. So würde ich es angehen wollen. Aber an welche Technik (Debugger, Entwicklungsumgebung) denkst du da ?? Sollte man „alles“ in C machen ?? Carlo
> Leuten nicht. Es ist ein Werkzeug, das natürlich auch seine Grenzen hat.
Nicht alles muss immer in Echtzeit ablaufen, oder es ist schon oft sehr
hilfreich, wenn man ein Programm an einer gewissen Stelle abbrechen und
in die Variablen und Register (auch der Peripherie) schauen kann. Von
pauschalen Aussagen wie "...braucht man keinen Debugger" halte ich gar
nichts.
Man sollte sich das Arbeiten ohne Debugger angewoehnen. Es gibt
Funktionalitaeten, die nicht in echtzeit ablaufen muessen. Wie zB
Displayansteuerung. Das macht man jeweils einmal und verwendet sie in
jedem Projekt gleich.
Echzeitprozess sollte man nicht anhalten muessen, und sollte auch so
planen dass sie durchlaufen, auch im Fehlerfall. Denn bei einem
Programmstop ist der Kontext kaputt. Im schlechteren Fall wird etwas
zerstoert. Man stelle sich eine Liftsteuerung vor..
Es gibt viele Moeglichkeiten, wie man Echtzeitdebugging macht. Alle
bedingen aber schon beim Design eingeplant worden zu sein.
Wenn ich Regelungsprozesse, die in einer Minutenzeitskala ablaufen,
anschauen will, verwende ich Kommunikation zum PC. Im Sinne von, der PC,
als Master darf Werte abfragen, die vorhanden sind. Oder schnell
gerechnet werden koennen. Eine Kommunikationsschnittstelle sollte man
sowieso eingeplant haben.
Wenn die Zeitskala kuerzer ist, plane ich einen SPI Stecker, wo ich im
Bedarfsfall einen 8x8bit DAC aufstecken kann. Das Programm schreibt die
Werte, die mich interessieren in den DAC, und ich kann mehrere Kanaele
parallel mit dem Oszilloskop anschauen.
Carlo S. schrieb: > Hallo Sebastian und „Hinz“ > > Ich verstehe nicht wirklich , warum Ihr euch auf den „Schlips“ getreten > fühlt. Elitäres Standesdünkel. Iiiiiiih, Anfänger mit Fragen. Ist hier normal, leider... Ich würde dir empfehlen, mit AVR oder PIC anzufangen. Grund ist, dass die einfach sind. Aus persönlicher Anschauung kann ich PIC24 empfehlen, hierfür benötigt man ein PICkit und MPLABX, sowie ein Steckbrett. MPLABX und Compiler ist frei verfügbar - die Einschränkungen des freien Compilers sind für Privatnutzer wenig problematisch. Debuggen kann man damit einfach, indem man in C einen Breakpoint auf die entsprechende Zeile setzt, der PIC bleibt dann stehen, und du kannst dir die einzelnen Variablen ansehen. Du kannst ein Programm dann schrittweise fortführen, wenn du willst. Wie am PC halt auch. Ich persönlich empfehle den PIC24FV32KA301 als Einstieg. Code-Examples für PIC24 findest du hier: https://www.microchip.com/doclisting/TechDoc.aspx?type=CodeExamples Ich kam aus der gleichen Ecke, also SPS. Hässliche IDEs mit seltsamen Bedienkonzepten bist du als SPS-Programmierer ja gewöhnt, eine gute Voraussetzung für µC-Programmierung, egal ob PIC, AVR oder STM32 ;-) PS: Damit will ich AVRs nicht abwerten - wie schon geschrieben habe ich halt mit den PIC angefangen.
Carlo S. schrieb: > Sollte man „alles“ in C machen ?? Ich würde auf jeden Fall erstmal in und mit C beginnen. Man kann nämlich ganz einfach mit wenigen Befehlen und Funktionen ganz einfach und durchschaubar in C programmieren. Natürlich kann ich mit Pointern komplexen Strukturen und wirren Funktionen aus komischen Inkludierungen C anfängerfeindlich, wie undurchschaubar machen. Davon darf man sich aber nicht abschrecken lassen. Ein paar Basics anlesen - und dann einfache Dinge mit wenigen Schlüsselwörtern und Funktionen machen. Die Bibel ist noch immer : Brian W. Kernighan, Dennis M. Ritchie Programmieren in C ( ANSI Standard ) Mit dem C-Reference Manual in deutscher Sprache Übersetzt aus dem Englischen von den Professoren Axel-Tobias Schreiner, Ernst Janich hervorragend und beispielhaft übersetzt! Wie schon jemand hier schrieb, wenn Dir AWL nicht fremd ist - dann kommst Du recht schnell in C ( möglicherweise auch in Assembler ) rein. letztendlich wirst Du alle Dinge die Du aus der SPS kennst hier in der Mikro-Prozessor-Programmierung wiederfinden - und wirst auch SPS Eigenheiten besser verstehen lernen.
Walter K schrieb: > objektorirntiere Wsa für Tiere? Walter K schrieb: > Man zerlegt die Aufgaben, Kapselt die Dinge - und irgendwann verliert > man den Kontrollfluss Ich bezweifele, dass Deine Analyse des Problems korrekt ist aber selbst wenn: Ein schlechtes Design kann man mit JEDER Methode hinlegen, wenn man unbedingt will... Zum BER: Irgend ein Kabarettist sagte einmal sinngemäß: Die Berliner kommen billiger zu einem Großflughafen, indem sie ihr Berlin abreißen und 1:1 am Flughafen Frankfurt Main wieder aufbauen. Naja... Ist wohl die verdiente Rache für damals, als die ganzen Bonner sich schwergetan haben mit dem Umzug nach Berlin und wir gefrotzelt haben: "...dabei haben wir Ihnen extra ihr Bonn 1:1 am Spreebogen nachgebaut."
:
Bearbeitet durch User
Sabberalot W. schrieb: > Das macht man jeweils einmal und verwendet sie in > jedem Projekt gleich. Aber einmal muss man es halt auch mal schreiben. Wenn Ihr alle so perfekte Programmierer seid, die von vornherein keine Fehler machen, braucht Ihr da natürlich auch keinen Debugger für (und auch sonst nicht). Sabberalot W. schrieb: > Im schlechteren Fall wird etwas > zerstoert. Man stelle sich eine Liftsteuerung vor.. Wenn da der "echte" Lift dranhängt, ist die Phase, wo man mit dem Debugger am JTAG- oder SW-Anschluss des µC hängt, hoffentlich schon vorbei...
:
Bearbeitet durch User
Carlo S. schrieb: > Aber an welche Technik (Debugger, Entwicklungsumgebung) denkst du da ?? Leider kann ich keine konkrete Vorschläge machen, da ich nicht auf dem aktuellen Stand bin. Carlo S. schrieb: > Ich habe halt jetzt ein Projekt wo aus der Stückzahl der Geräte > ein Microcontroller wahrscheinlich angebracht wäre anstatt eine SPS zu > nehmen. SPS und Microcontroller kann man nicht so einfach miteinander vergleichen. Im Gegensatz zur SPS hat man beim Microcontroller keine fertige Hardware zur Verfügung. Deren Entwicklungskosten, Tests und Zertifizierungen müssen eingerechnet werden. Auch der Softwareentwicklungsaufwand wird höher sein. Darum empfehle ich, ein Lastenheft zu erstellen und damit bei einigen Spezialisten eine Offerte einzuholen. Das liefert eine gute Entscheidungsgrundlage.
M.A. S. schrieb: > Irgend ein Kabarettist sagte einmal sinngemäß: > Die Berliner kommen billiger zu einem Großflughafen, indem sie ihr > Berlin abreißen und 1:1 am Flughafen Frankfurt Main wieder aufbauen. > Naja... Lach! Ich wohne in der Nähe einer Strasse, die eine Länge von 140km hat, die von Koblenz quer übern den Hunsrück nach Saarburg geht ... und die vor ungefähr 80 Jahren in exakt 100 Tagen gebaut wurde (auch wenn interessierte Kreise nicht müde werden, zu betonen - sie sei ja nach 100 Tagen noch nicht ganz fertig gewesen! - was auch stimmt, der einzige ( und für damalige Verhältnisse, fast schon revolutionäre) Kreisel war noch nicht bepflanzt!
>Sabberalot W. schrieb: >> Im schlechteren Fall wird etwas >> zerstoert. Man stelle sich eine Liftsteuerung vor.. > >Wenn da der "echte" Lift dranhängt, ist die Phase, wo man mit dem Debugger am JTAG- oder SW-Anschluss des µC hängt, hoffentlich schon vorbei... Es gibt aber immer ein Debuggen an der tatsaechlichen Hardware, am tatsaechlichen Prozess. Und das sollte man einplanen, dass dann eben nichts schieflaeuft.
Hallo Carlo Ich würde dir empfehlen mit einem Atmega oder Attiny das Assembler Tutorial hier durchzuarbeiten und vll. ein eigenes kleines Projekt (nichts großartiges) damit machen. So bekommt man ein Gefühl wie ein Mikrocontroller intern funktioniert. Dann würde ich relativ schnell auf C umsteigen. Damit kann man dann angenehmer übersichtlichere und größere Programme entwickeln. Wenn du dann noch nicht genug hast wäre auf C++ aufzusatteln keine schlechte Idee. Die Sprache bringt viele angenehme Features mit sich. Allerdings sollte man dann schon eine Ahnung haben welches Feature wann Sinn macht und welches nicht (vor allem bei Mikrocontroller). Als IDE kann ich AVR Studio empfehlen.
Hallo, fange mit dem Arduino Board an und verlasse es nach 14 Tagen schnellst möglich wieder.
Werner S. schrieb: > fange mit dem Arduino Board an und verlasse es nach 14 Tagen schnellst > möglich wieder. genau ... und gewöhne Dich nicht an dieses Pseudo-C und die Pseudo-IDE Linux oder FreeBSD, avr-gcc, avrdude usw. ..und später kannst Du den Arduino als ISP für andere mP nutzen
Hallo Ich kann nicht so recht verstehen , warum hier einige meinen, das man keinen Debugger braucht. Bei meinen vielen (auch sehr großen) SPS-Projekten hat sich nicht das eigentliche Programm sondern das dynamische Zusammenspiel von externer Hardware mit den mechanischen Komponenten (Pneumatik,Hydraulik,Achsen usw.) als Problem und Herausforderung dargestellt. Carlo
Carlo S. schrieb: > wie man Debugging auf der Hochsprachenebene macht ?? Man muß doch sehen > was in dem Teil passiert. Carlo S. schrieb: > Ich kann nicht so recht verstehen , warum hier einige meinen, das man > keinen Debugger braucht. Kann es sein, dass Du etwas anderes meinst mit "Debugger"? Nimm doch als Anfänger ruhig so einen kleinen fertigen Arduino und schreib ein "Programm", was meinetwegen einen Pin umschaltet und dazu auf der seriellen Schnittstelle etwas ausgibt, was Du dir dann am PC während der Laufzeit anschaust. Den Port (Umschaltung) kannst Du messen oder mit LED sichtbar machen. Was würde Dein Debugger in deiner Vorstellung und in diesem Beispiel tun?
Hallo Rainer, Wenn dein „Umschaltpin“ ein Eingang sein soll müsste der Debugger zur Laufzeit zeigen , dass A der Eingang auch wirklich von der Software als 1 erkannt wird (nicht das der Eingang def. Ist) B ich würde dann gerne sehen wohin das Programm verzweigt C das er den Ausgang (LED) ansteuert D was er intern an die UART übergibt Ich möchte nicht das der Debugger irgend welche Breakpoint’s setzt oder nur eine Schrittabarbeitung Macht. Carlo
Mal meine persönliche Einschätzung zur Wahl eines Mikrocontrollers: In den 90ern und Anfang der 0er Jahre waren PIC-Mikrocontroller offenbar sehr beliebt. Dann traten die AVRs (ATmega & Co.) ihren Siegeszug an und verdrängten die PICs weitgehend. Jahrelang waren dann die AVRs quasi DIE Standard-Mikrocontroller schlechthin, zumindest für im privaten/Hobby-Bereich. In diese Zeit fällt auch die Entstehung der Arduino-Boards, weshalb die Arduino-Boards ursprünglich allesamt AVRs benutzten. Die AVRs sind immer noch sehr populär, in den letzten Jahren sind jedoch 2-3 neue Konkurrenten hinzugekommen, die eine vglw. grosse Anhängerschar gewonnen haben: - Die STM32. Im Vergleich zu AVR-Mikrocontrollern der gleichen Preislage bieten diese offenbar deutlich mehr Features und Power. Allerdings sollen sie wohl auch etwas komplexer/komplizierter sein, und der Einstieg damit etwas schwerer. - Die ESPs - der ESP8266 und dessen Nachfolger ESP32. Sind so schnell und besitzen so viel RAM, dass man darauf auch komplette Interpreter für Hochsprachen laufen lassen kann, z.B. (Micro)Python oder LUA. Neben diesem Umstand dürfte ihre grosse Popularität vor Allem daher kommen, dass sie bereits WLAN an Board haben, und man für entsprechende Module (mit satten 4MB Flash-Speicher) bei Bestellung in China nur ca. 1,60 Euro bezahlt. Nachdem bereits der ESP8266 ein Riesenerfolg wurde, kam dann vor 1-2 Jahren der in fast allen Belangen nochmal MASSIV verbesserte Nachfolger ESP32 auf den Markt, der bspw. noch Bluetooth an Board und nochmal ca. 10mal soviel RAM hat, dafür aber auch erst ab ca. 3 Euro zu haben ist. Auch ich würde für den Einstieg Arduino empfehlen. Viele hier im Forum, gerade diejenigen mit jahrzehntelanger Mikrocontroller-Erfahrung, schauen auf Arduino ein wenig herab, aber lass Dich davon nicht abschrecken: Zumindest für den Einstieg in die Mikrocontroller-Welt ist Arduino wirklich hervorragend geeignet, weil es den Einstieg besonders leicht macht und man Unmengen Ressourcen/Tutorials/Informationen dazu findet. Praktisch dabei ist auch: Mittlerweile kann man (mit entsprechenden Plugins) ganz viele Mikrocontroller über die Arduino-IDE programmieren, neben den von Anfang an unterstützten AVRs auch z.B. die oben erwähnten STM32, ESP8266 und ESP32. Du musst Dich also kaum auf eine bestimmten Mikrocontroller-Familie festlegen. Meine konkrete Hardware-Empfehlung für den Einstieg wäre: Ein beliebiges Arduino-Board mit AVR (z.B. der sehr gut für Steckboards geeignete Arduino Nano; wenn man in China bestellt, ist man da teilweise schon mit zwei Euro dabei), ein NodeMCU-DevKit (ESP8266) (ab ca. 3 Euro bei Bestellung in China) oder ein ESP32-DevKit (ab ca. 6 Euro bei Bestellung in China). Dazu noch ein Steckboard und ein paar Sensoren/Aktoren/LEDs, falls Du sowas noch nicht hast. Programmierung mit der Arduino-IDE. Zum Thema Debugger: Ich schäme mich zwar ein wenig dafür, aber ich habe mich bislang noch niemals nennenswert mit Debuggern beschäftigt, obwohl ich seit Jahrzehnten programmiere. Wenn ich irgendwas debuggen muss, füge ich bislang einfach immer einfach eine print()-Anweisung (bzw. etwas Vergleichbares) ein.
Dacht' ich's mir doch. Programmieren ist bischen anders als SPS. Ich
meinte zwar einen Ausgabepin aber sei's drum.
Also A erschlägst Du z.B. mit einer Abfrageschleife plus Verzweigung
(oder später mit einem Interrupt:
do
if Eingang = 1
then verzweige hierhin
else print "war nix"
loop
hierhin:
print "hier gehts weiter bei 1"
Ist zwar kein Arduino, aber Prinzip ist gleich.
Also A) wenn er nicht erkannt wird, verzweigt er nicht. B) legst Du
selbst fest ("hierhin"). C) kannst Du sehen und D) ebenfalls
:
Bearbeitet durch User
Hallo Rainer, sicherlich kann man A für Testfälle so erledigen aber man kann doch nicht für alle Test’s noch 10x Testprogramme schreiben dann wird man ja nie fertig . Außerdem müßte man ja zu Schluss Alles wieder entfernen was ja auch fehleranfällig ist . „war nix“ würde ja dann auch permanent Geschrieben. Zu B : Ich will ja prüfen ob des Programm dahin verzweigt. ZU C: was ist wenn an der seriellen eben nichts „rauskommt“ ?? Was versteht du denn unter einem Debugger ?? Carlo
Carlo S. schrieb: > Was versteht du denn unter einem Debugger ?? So ungefähr das hier: https://de.wikipedia.org/wiki/Debugger Carlo S. schrieb: > u B : Ich will ja prüfen ob des Programm dahin verzweigt. Da geht man als Programmierer davon aus. wenn ich einen Funktionsaufruf "machdies();" notiere, und das Programm kommt da an, dann verzweigt er auch dahin. Carlo S. schrieb: > ZU C: was ist wenn an der seriellen eben nichts „rauskommt“ ?? dito B: wenn ich "Print ..." schreibe, dann kommt da auch was, sonst habe ich die Parameter der SChnittstelle falsch angegeben oder die Hardware ist kaputt. Carlo S. schrieb: > „war nix“ würde ja dann auch permanent Geschrieben. sicher, war ja auch nur ein Beispiel. Carlo S. schrieb: > sicherlich kann man A für Testfälle so erledigen aber man kann doch > nicht für alle Test’s noch 10x Testprogramme schreiben dann wird man ja nie fertig Wieso nicht? do if (EingangA==1) {machA();} if (EingangB==1) {machB();} if (EingangC==1) {machC();} if (EingangD==1) {machD();} if (EingangE==1) {machE();} ... loop Das ging jetzt schnell :-) Ich würde Dir empfehlen, die Arduino-Anfänger-Beispielprogramme mal durchzulesen und "nachzumachen"
:
Bearbeitet durch User
Carlo S. schrieb: > Hallo Lothar, > > wenn das Debuggen das Timing verändert ist es nicht gut. In meiner Welt > (SPS) werden > die Daten in Echtzeit in der SPS gespeichert oder über Ethernet > „weggeschoben“ aber > vielleicht ist ne SPS auch „langsamer“ . Auf alle Fälle kann ich bei > UART oder TCP/IP - > Kommunikation sehen , was passiert. > Einen kleinen AVR oder PIC habe ich schon vor 20 Jahren programmiert und > somit kann ich die 2,5 € > sparen. Ich habe halt jetzt ein Projekt wo aus der Stückzahl der Geräte > ein Microcontroller wahrscheinlich angebracht wäre anstatt eine SPS zu > nehmen. > > Carlo Wenn Du ein kommerzielles Projekt daraus machen möchtest, spare Dir die Mühe und gehe zu einem der unzähligen Embedded-Ingenieurbüros, die wie Unkraut aus dem Boden schießen. Du sagst, was Du haben willst und die machen Dir das sogar, vorausgesetzt Du bringst das Geld für die Party mit. Mit 60€ zzgl. Märchensteuer bist Du dabei. Nicht billig, aber in anbetracht dessen, dass Du keine Ahnung von der Entwicklung von Microcomputer-Systemen hast, wäre das die beste Lösung. Hier geht es nicht nur ums Programmieren, sondern auch um das Bauen von HW und vor allem ums qualifizieren der Geräte, da Du ja sicherlich weißt, dass man nicht alles einfach so in Umlauf bringen darf. Ob sich der Aufwand löhnt, kannst nur Du selbst wissen.
Angehängte Dateien:
-
Debugger_.png
46 KB
Carlo S. schrieb: > Was versteht du denn unter einem Debugger ?? Hi, der ATMEL-Studio4-Programm-"Simulator" kann über Button "Debug" aufgerufen werden und liefert mir "visualisiert" z.B. Informationen über den tatsächlichen PC Stand, die Registerinhalte, die Flags, die Portzustände usw. usf. ciao gustav
Hallo SachMal, ich will es natürlich nicht kommerzielles machen, da wäre der Aufwand den du schilterst natürlich zu groß. Carlo
Joachim S. schrieb: > Mal meine persönliche Einschätzung zur Wahl eines > Mikrocontrollers: > > In den 90ern und Anfang der 0er Jahre waren PIC-Mikrocontroller offenbar > sehr beliebt. Dann traten die AVRs (ATmega & Co.) ihren Siegeszug an und > verdrängten die PICs weitgehend. Jahrelang waren dann die AVRs quasi DIE > Standard-Mikrocontroller schlechthin, zumindest für im > privaten/Hobby-Bereich. > In diese Zeit fällt auch die Entstehung der Arduino-Boards, weshalb die > Arduino-Boards ursprünglich allesamt AVRs benutzten. Du wirfst du alle PICs in einen Topf, denn dein Wissen bezieht sich auf Urgestein aus den späten 70ern. Dass ein PIC32MZ-derivat im Leben nicht mit einem mieselsüchtigem AVR nicht vergleichbar ist, ist dir offensichtlich nicht klar. Das ist aber eh irrelevant: Nummer1 bei den Microcontrollern ist Renesas, und nicht Microchip. Der Einsatz in der Industrie dürfte >99,97% der verbauten PICs und AVRs ausmachen. Der kleine Nebenschauplatz hier im Forum ist weder repräsentativ, noch relevant. --> Ein Brett vorm Kopf ist kein Horizont
Brrzzt schrieb: > Du wirfst du alle PICs in einen Topf, denn dein Wissen bezieht sich auf > Urgestein aus den späten 70ern. Dass ein PIC32MZ-derivat im Leben nicht > mit einem mieselsüchtigem AVR nicht vergleichbar ist, ist dir > offensichtlich nicht klar. > > Das ist aber eh irrelevant: > Nummer1 bei den Microcontrollern ist Renesas, und nicht Microchip. > Der Einsatz in der Industrie dürfte >99,97% der verbauten PICs und AVRs > ausmachen. Der kleine Nebenschauplatz hier im Forum ist weder > repräsentativ, noch relevant. Ich kann aufgrund Deiner Antwort jetzt nur vermuten, dass sich da ein PIC-Fan auf den Schlips getreten fühlt oder so. Wir reden hier doch von Mikrocontrollern für den Hobby-/Privat-Bereich, und meine Aussagen waren demnach auch ausschliesslich auf diesen Bereich bezogen. Was in der Industrie o.Ä. verwendet wird, dürfte für den Threadstarter eher irrelevant sein. Was die PICs betrifft: Vielleicht irre ich mich da ja, aber mein persönlicher Eindruck ist eben, dass die PICs im Hobby-/privaten Bereich, um den es hier geht, eher wenig verbreitet sind, und AVR/STM32/ESPs da derzeit um ein Vielfaches populärer sind. Wenn Du klare Belege für das Gegenteil hast, lasse ich mich natürlich gerne eines Besseren belehren. Laut diesem Artikel aus dem letzten Jahr: http://oiger.de/2017/04/28/nxp-nun-fuehrender-mikrocontroller-anbieter/163462 liegt Renesas übrigens nur noch auf Platz 2 bei den Mikrocontrollern - mit nicht 99,97 sondern ca. 16 Prozent Marktanteil. > --> Ein Brett vorm Kopf ist kein Horizont Und Tourette ist kein Glücksspiel mit einer rollenden Kugel.
:
Bearbeitet durch User
Sebastian S. schrieb: > Herr Fahrlehrer. Ich habe noch nie am Steuer gesessen. Bitte zeigen Sie > mir, die man das Auto in Bewegung setzt Genau dafür habe ich den bezahlt. > und dann den Nürburgring durchfährt. Gegen entsprechendes Entgelt hätte er auch das getan. Joachim S. schrieb: > Viele hier im Forum, gerade diejenigen mit jahrzehntelanger Mikrocontroller-Erfahrung, > schauen auf Arduino ein wenig herab, Weil sie nicht akzeptieren können, dass es genug unkritische Anwendungen gibt, wo dessen IDE mehr als ausreichend ist! > Zum Thema Debugger: > Ich schäme mich zwar ein wenig dafür, aber ich habe mich bislang noch > niemals nennenswert mit Debuggern beschäftigt, obwohl ich seit > Jahrzehnten programmiere. Als ich 6502 beruflich eingesetzt habe, hatte ich einen ic-circuit-emulator: CPU raus, Kabel drauf und PC dran. Tolle Sache, aber bannig teuer gewesen. > Wenn ich irgendwas debuggen muss, füge ich > bislang einfach immer einfach eine print()-Anweisung (bzw. etwas > Vergleichbares) ein. So mache ich das mit dem Arduino: Lasse mir Meßwerte seriell ausgeben, um zu kalibrieren oder auch mal 'nur' Portzustände, wenn etwas nicht laufen will. Das braucht zwar Zeit, aber so zeitkritische Anwendungen, dass diese dadurch gestört werden, hat man eher selten.
Auch beim Arduino kann man ganz normal in Visual Studio debuggen, wenn man sich von der Arduino IDE löst und das Visual Micro Plugin einsetzt.
Joachim S. schrieb: > Brrzzt schrieb: >> Du wirfst du alle PICs in einen Topf, denn dein Wissen bezieht sich auf >> Urgestein aus den späten 70ern. Dass ein PIC32MZ-derivat im Leben nicht >> mit einem mieselsüchtigem AVR nicht vergleichbar ist, ist dir >> offensichtlich nicht klar. >> >> Das ist aber eh irrelevant: >> Nummer1 bei den Microcontrollern ist Renesas, und nicht Microchip. >> Der Einsatz in der Industrie dürfte >99,97% der verbauten PICs und AVRs >> ausmachen. Der kleine Nebenschauplatz hier im Forum ist weder >> repräsentativ, noch relevant. > > Ich kann aufgrund Deiner Antwort jetzt nur vermuten, dass sich da ein > PIC-Fan auf den Schlips getreten fühlt oder so. Aha, und warum nicht Renesas-Fan? Momentan bearbeite ich übrigens gar keinen PIC, sondern einen STM32F303ZE. Aber der ist nicht Anfängertauglich, denke ich. Ich mag einfach nur keine dummen Vergleiche, die aus Engstirnigkeit resultieren. Wenn PIC<>AVR müsstest du PIC16/PIC18 <> ATMEGA vergleichen. Und PIC12, PIC16 mit ATTINY. Selbst das ist schwierig, denn es gibt steinalte PICs, und nagelneue, schlechte AVRs und gute. Weder AVR noch PIC16/18 sind veraltet. Es zwar ältere Produktlinien, aber sie bekommen beide noch Zuwachs. Aber allgemein "PIC" gegen AVR impliziert auch PIC32MZ gegen ATTINY. Das ist dumm, die bedienen ganz andere Segmente... Beide sind übrigens vom gleichen (relativ unbedeutenden) Hersteller. Soviel zu Krieg ;-)
Brrzzt schrieb: >> Ich kann aufgrund Deiner Antwort jetzt nur vermuten, dass sich da ein >> PIC-Fan auf den Schlips getreten fühlt oder so. > > Aha, und warum nicht Renesas-Fan? Weil ca. 80% Deiner Postings in diesem Thread eben Monologe über PIC-Mikrocontroller sind, Du Renesas hingegen nur kurz erwähnt hast. Mittlerweile habe ich übrigens gesehen, dass Du weiter oben bereits ein anderes Posting verfasst hast, in dem Du ebenfalls einen PIC-Mikrocontroller empfohlen hast. Das verstärkt den Eindruck noch, dass Deine offensichtliche Verärgerung über mein früheres Posting vermutlich vor Allem daher kommt, dass ich von PIC-Mikrocontrollern tendenziell eher abgeraten habe, während Du sie halt explizit empfohlen hast. > Ich mag einfach nur keine dummen Vergleiche, die aus Engstirnigkeit > resultieren. Und ich mag nicht, wenn Leute (völlig unnötig) beleidigend und unhöflich werden, nur weil Jemand bzgl. irgendeiner Mikrocontroller-Familie eine andere Meinung hat. > Wenn PIC<>AVR müsstest du PIC16/PIC18 <> ATMEGA vergleichen. > Und PIC12, PIC16 mit ATTINY. Selbst das ist schwierig, denn es gibt > steinalte PICs, und nagelneue, schlechte AVRs und gute. > Weder AVR noch PIC16/18 sind veraltet. Es zwar ältere Produktlinien, > aber sie bekommen beide noch Zuwachs. Ich weiss gar nicht, was Du eigentlich willst - wo habe ich denn überhaupt irgendwo AVR mit PIC-µCs verglichen? Ich habe von PIC-µCs überhaupt keine Ahnung, habe mich nie auch nur mit ihnen beschäftigt, und würde daher gar nicht auf die Idee kommen, die (was Features etc. betrifft) mit irgendwelchen anderen Mikrocontrollern zu vergleichen. Das mögen wirklich ganz ganz tolle Mikrocontroller sein, gut möglich! Der Grund, warum ich für den Einstieg eher von PIC abrate, hat damit überhaupt nichts damit zu tun, was nun die bessere Mikrocontroller-Familie ist - sondern einfach damit, dass mir die PICs im privaten/Hobbybereich derzeit deutlich weniger populär zu sein scheinen als andere Mikrocontroller-Familien. Und das halte ich halt für einen viel wichtigeren Faktor, wenn es beim Einstieg in die Mikrocontroller-Welt um die Wahl der Mikrocontroller-Familie geht: Etwas nehmen, was derzeit halt populär ist, weil man dann viel leichter Tutorials, Infos, Software und im Bedarfsfall Hilfe findet.
Wolfgang schrieb: > Auch beim Arduino kann man ganz normal in Visual Studio debuggen, > wenn man sich von der Arduino IDE löst und das Visual Micro Plugin > einsetzt. Es soll aber auch noch Techniker geben, die sich noch nicht der kollektiven Windows-Verblödung ergeben haben
Walter K schrieb: > nur zufällig hier schrieb: >> Man programmiert die Aufgabe nicht in eines durch, insbesondere nicht >> wenns komplexer wird. >> Man zerlegt die Aufgabe in Funktionen, Prozeduren und Klassen. > > Ein anschauliches Modell für objektorirntiere Programmierung ist die > Großbaustelle BER. > Man zerlegt die Aufgaben, Kapselt die Dinge - und irgendwann verliert > man den Kontrollfluss Eigentlich ist das Gegenteil der Fall. Wenn ein Objekt defekt ist, tauscht man es gegen ein funktionierendes aus. Im Falle von BER wäre das dann ein brauchbarer und vorschriftskonformer Brandschutz gewesen, aber Immobilien sind halt keine Software und da kann man Teile nicht einfach durch welche austauschen, die lediglich dieselbe Schnittstelle haben. In der OO klappt sowas prima, das ist ja gerade der große Vorteil.
Manfred schrieb: > Sebastian S. schrieb: >> und dann den Nürburgring durchfährt. > > Gegen entsprechendes Entgelt hätte er auch das getan. Ja, aber es hätte keinen Spaß gemacht. Wenn Du dabei Spaß haben willst, fragst Du ausdrücklich nach Sabine oder Claudia, und wenn Du 'drin sitzt fragst Du ausdrücklich danach, ob das nicht auch schneller geht. Nur ein Tipp: dabei solltest Du mehrere Kotztüten mitführen.
Beitrag #5360931 wurde von einem Moderator gelöscht.
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.