Hallo Miteinander, ich habe in Bascom angefangen zu programmieren und bin dann auf Arduino umgestiegen. Genutzt habe ich dort Atmega 8 328 2560 programmiert entweder über den Bootloader ( Arduino) oder über mysmartusb light (stk500) Nun möchte ich gerne auf eine anständige Entwicklungsumgebung umsteigen. Vorallem wegen den Debugging Möglichkeiten. Natürlich denke ich deshalb darüber nach gleich auf Controller umzusteigen die mehr Potential haben. Da ich mich selbst jedoch als Einsteiger sehe, will ich mir den Umstieg möglichst leicht machen. Folgende Möglichkeiten habe ich für mich gefunden: Samd21 Controller in Verbindung mit Atmel Studio 7 - Atmel Studio ist kostenlos und weit verbreitet, gefällt mir relativ gut. Funktioniert der Clone J-Link V8 einwandfrei in Verbindung mit Atmel Studio? STM32 Controller in Verbindung mit der STM32Cube IDE - Diese IDE finde ich ein wenig unübersichtlicher, jedoch sind die Controller richtig günstig zu kriegen. Was würdet ihr einem Anfänger, Umsteiger der weg von der Arduino IDE will raten? Anforderungen die ich an einen Controller habe: - Integrierte RTC - Viel Flash für grafik Displays - 3,3V
Nimm STM Nucleo Boards, gibts in allen möglichen Größenordnungen. Haben einen Debugger mit dabei. Läuft mit diversen IDEs und sind aktuelle Controller.
Zuerst einmal: Beide Controller sind um einiges komplexer als ein Atmega. Das Echtzeitverhalten ist weniger vorhersagbar, man muß sich im Zweifel mit DMA und ähnlichen Mechanismen auseinandersetzen, die der AVR einfach nicht hat. Die integrierte Peripherie ist deutlich komplexer. Oft werden Bibliotheken eingesetzt, um diese zu bedienen (Stichwort HAL), aber man kann auch jedes Register per Hand setzen, wenn man sich durch die sehr umfangreichen Datenblätter wühlt. Der Aufwand zur Einarbeitung ist erheblich. Ich denke, STM32 ist weiter verbreitet und hat die größere Entwicklergemeinde gegenüber SAMD21, komplex sind beide. STM32Cube ist eigentlich nur ein Konfigurationstool; es erstellt ein Grundgerüst, um dann z.B. mit "System Workbench for STM32" (basiert auf Eclipse) darauf ein eigenes Projekt aufzubauen.
Atmega 8 328 2560 und mysmartusb light (stk500)... und Atmel Studio sollte doch auch zusammenarbeiten oder ist das doch nicht STK500 kompatibel? Für erste Debuggversuche wahrscheinlich nicht schädlich wenn du den µC schon kennst.
Danke für die flotten Antworten! STM32 werde ich mir dann auf jedenfall mal anschauen. Die Nucleo Boards sind tatsächlich ziemlich interessant! Und preislich sogar so günstig das man nicht gleich zu billiger China Hardware greifen muss. Gibt es unter den Nucleo Boards eine spezielle Empfehlung oder ist das relativ egal mit welchem man sich beschäftigt? Die Auswahl ist ja recht groß und unübersichtlich. Ist es nicht so das STM32CubeIDE die IDE ist und STM32CubeMX das Tool zum Projekt erstellen? Kurz angeschaut hatte ich mir das schonmal. Das die ARM Controller generell ein gutes Stück komplexer sind gegenüber den AVR habe ich nach kurzer Recherche leider bereits feststellen müssen. Aber es hilft ja nichts, und mein Gedanke ist: Wenn ich mich schon in die "richtige" Programmierung mit Registern usw. einarbeiten will, dann doch gleich in eine Prozessorgeneration die etwas aktueller und leistungsstärker ist als die AVR. PlatformIO hatte ich mir bereits mal angeschaut, also Arduion IDE, hat mir jedoch überhaupt nicht zugesagt. Der Kendryte Chip scheint mir für meine Anwendungszwecke und meine Fähigkeiten doch etwas arg übertrieben zu sein. ( Nur kurz gegoogelt, habe ich vorher noch nie gehört) Das man sämtliche AVR´s auch in Atmel Studio nutzen kann ist mir durchaus bewusst, aber dann bin ich von den "Möglichkeiten" nicht unbedingt weiter als zuvor.
Ghostrider1911 schrieb: > Was würdet ihr einem Anfänger, Umsteiger der weg von der Arduino IDE > will raten? Für AVR Projekte mit Makefile (Vorlage: http://stefanfrings.de/avr_hello_world/index.html) in Kombination mit den dort genannten Tools: http://stefanfrings.de/avr_tools/index.html Momentan gefällt mit Qt Creator als IDE am besten. Für STM nutze ich inzwischen auch die die STM32 Cube IDE. Ja, die ist (wie alle auf Eclipse basierenden IDE) etwas sperrig, dafür aber kostenlos. Für drei STM32 Serien habe ich Informationen zusammen getragen: http://stefanfrings.de/stm32/index.html
Eclipse (CubeIde) ist ziemlich mächtig. Daher verstehe ich auch, dass es unübersichtlich wirkt. Das schöne ist aber, dass du 50% der kleinen Fenster schließen kannst weil sie eher in Ausnahmefällen interessant sind. Wenn du Hauptsächlich wegen Debugging wechseln willst, hol dir einen jlink Edu. Der kostet nicht die Welt und ist noch komfortabler und schneller als der in den nucleo-boards integrierte stlink. Außerdem empfehle ich dann möglichst "kleine" uCs zu verwenden da man bei denen z.B den clock-tree einfacher durchschaut. 73
Ghostrider1911 schrieb: > dann bin ich von den "Möglichkeiten" nicht > unbedingt weiter als zuvor. Doch. Ganz sicher. Die Arduino Bibliotheken beschraenken Vieles. wendelsberg
Wenn Du Dich wirklich mit dem Arduino beschäftigt hast, solltest Du wissen: "Was jetzt kommt hängt davon ab was Du BRAUCHST". Auch wenn Dein Nachfolger mehr Leistung, mehr Peripherie oder mehr Speicher bedienen soll, bleibt im Grunde genommen vieles gleich. Einzige Ausnahme: Du nimmst einen µC mit Betriebssystem (z.B. eine Himbeere). Da hast Du dann aber gleich das Problem, dass Du nur noch unter Schwierigkeiten an die Pins heran kommst und es auch oft mit der Echtzeit nicht weit her ist.
wendelsberg schrieb: > Doch. Ganz sicher. > Die Arduino Bibliotheken beschraenken Vieles. Man muß sie ja nicht benutzen. Was hindert einen daran, in C++ zu programmieren?
Frodo schrieb: > wendelsberg schrieb: >> Doch. Ganz sicher. >> Die Arduino Bibliotheken beschraenken Vieles. > > Man muß sie ja nicht benutzen. > Was hindert einen daran, in C++ zu programmieren? Nichts. Aber dann ist es kein Arduino mehr.
Frodo schrieb: > Was hindert einen daran, in C++ zu programmieren? Oder direkt in C. Nichts. Allerdings scheint der TO der Auffassung zu sein, dass Ghostrider1911 schrieb: > dann bin ich von den "Möglichkeiten" nicht > unbedingt weiter als zuvor. Beitrag "Re: Weg von Arduino - Beratung" Warum auch immer. wendelsberg
Cyblord -. schrieb: > Nichts. Aber dann ist es kein Arduino mehr. Was verändert sich an einem Arduino-Board, wenn man es in C++ programmiert? Wieso ist es dann kein Arduino mehr?
Frodo schrieb: > Was verändert sich an einem Arduino-Board, wenn man es in C++ > programmiert? Wieso ist es dann kein Arduino mehr? Ich denke, dass die allermeisten hier schon zwischen Hardware und Software differenzieren können. Wenn hier jemand von Arduino (ohne den Zusatz "Modul", "Board", "Shield" oder "IDE") schreibt, kannst du davon ausgehen, dass er das Software-Framework meint.
Stefan ⛄ F. schrieb: > kannst du davon > ausgehen, dass er das Software-Framework meint. Selbst darauf kann man vollständig verzichten, und dennoch IDE und Board beibehalten. Wahlweise in C, C++ oder Assembler programmieren.
Arduino Fanboy D. schrieb: > Stefan ⛄ F. schrieb: >> kannst du davon >> ausgehen, dass er das Software-Framework meint. > Selbst darauf kann man vollständig verzichten, und dennoch IDE und Board > beibehalten. > Wahlweise in C, C++ oder Assembler programmieren. Genau das Gleiche meinte ich ja auch.
Frodo schrieb: > Cyblord -. schrieb: >> Nichts. Aber dann ist es kein Arduino mehr. > > Was verändert sich an einem Arduino-Board, wenn man es in C++ > programmiert? > Wieso ist es dann kein Arduino mehr? Weil "Arduino" das Gesamtpaket aus Hardware, Framework und IDE ist. Alle drei Komponenten sind aufeinander abgestimmt. Lässt man einfach Teile weg, verliert es die wesentlichen Eigenschaften. "Arduino" ist also weder die HW, noch die SW sondern eben beides zusammen.
Übrigens: Theoretisch kann man in AVR-Studio auch ein Arduino-Scetch importieren und dann durch das Framework debuggen wenn man z.B. einen Atmel ICE anschließt.
Cyblord -. schrieb: > Lässt man einfach Teile weg, verliert es die wesentlichen Eigenschaften. Also du kannst es nicht beantworten, was sich am Board ändert. Arduino Fanboy hat es genau beschrieben. Man kann ein Arduino-Board in einer nahezu beliebigen Sprache und mit beliebiger IDE programmieren, es bleibt trotzdem Ein Arduino-Board. Zum Board gehört NICHT zwingend die Arduino-IDE!
Frodo schrieb: > Cyblord -. schrieb: >> Lässt man einfach Teile weg, verliert es die wesentlichen Eigenschaften. > > Also du kannst es nicht beantworten, was sich am Board ändert. Habe ich beantwortet. Ich habe allerdings auch nie behauptet dass sich etwas am Board ändert. Lies meine Behauptung einfach noch mal.
Franz schrieb: > Übrigens: Theoretisch kann man in AVR-Studio auch ein > Arduino-Scetch > importieren und dann durch das Framework debuggen wenn man z.B. einen > Atmel ICE anschließt. Durchaus! Wenn man sich auf Atmel Chips fixiert. Cyblord -. schrieb: > Weil "Arduino" das Gesamtpaket aus Hardware, Framework und IDE ist. Alle > drei Komponenten sind aufeinander abgestimmt. > Lässt man einfach Teile weg, verliert es die wesentlichen Eigenschaften. > "Arduino" ist also weder die HW, noch die SW sondern eben beides > zusammen. Eigentlich hat deine Bemerkung nur einen positiven Aspekt: --> Die Definitionshoheit liegt nicht in deinen Händen. <--
Arduino Fanboy D. schrieb: > Eigentlich hat deine Bemerkung nur einen positiven Aspekt: > --> Die Definitionshoheit liegt nicht in deinen Händen. <-- Mag sein. Jede andere Definition wäre allerdings Schwachsinn. Wer nicht zwischen Arduino-Board (=Arduino HW) und dem "Arduino" als System unterscheiden kann, der kann das natürlich nicht verstehen. Und die Popularität verdankt Arduino ausschließlich diesem Gesamtsystem. Nur HW würde keinem Anfänger was bringen. Nur die SW würde auch nichts bringen, weil die HW unbekannt wäre, und das automatische Mapping der Pins nicht gehen würde. Der Trick liegt also im Gesamtsystem.
:
Bearbeitet durch User
Ghostrider1911 schrieb: > Nun möchte ich gerne auf eine anständige Entwicklungsumgebung umsteigen. > Vorallem wegen den Debugging Möglichkeiten. Ghostrider1911 schrieb: > - Viel Flash für grafik Displays Deine Überschrift "weg von Arduino" suggeriert, daß du weg willst vom Basteln mit vorgefertigten Shields und Bibliotheken, kurz gesagt "weg von den Bauklötzchen". Aber warum fragst du als allererstes nach einer 'anständigen' Entwicklungsumgebung? .. und nach 'vor allem..debugging'? Du willst also doch nicht weg von all dem, was Arduino so ausmacht. Wenn es für dich nur ein Wechsel der IDE ist, dann lade dir alles was in Frage kommt herunter und probiere es aus. Das ist besser als hier nachzufragen, was andere dazu meinen. Die eigentlichen Fragen an dich wären: Was hast du denn bsher so entwickelt und was willst du künftig entwickeln? Ratschläge zu geben, ohne zu wissen, was der Ratsuchende denn EIGENTLICH beabsichtigt, ist albern und frustreich. Und deine Bemerkung "viel Flash für Grafik.." zeigt mir, daß es auch da bei dir Lernbedarf gibt. Für Grafik braucht man zu allererst ausreichend RAM. Also schreib mal was über deine bisherigen und künftigen Projektideen. Dann sieht man weiter. W.S.
Cyblord -. schrieb: > Und die Popularität verdankt Arduino ausschließlich diesem Gesamtsystem. > ... > Der Trick liegt also im Gesamtsystem. Klar, mag ein Anfänger mit dem Gesamtsystem starten... Ist auch richtig und gut so. Aber ein paar Projekte später..... Der Trick ist, dass man sich ganz nach belieben aussuchen kann, wie und was man davon verwendet. Existiert frischer Bedarf, z.B. an Copmiler, Libs oder (exotischen)Boards, wirds dran geklebt. Oder auch die IDE entfernt, und der Rest weiterverwendet. Dein Versuch das anzunageln, ist unzureichend/unangemessen. Und ja, der fehlende Debugger ist ein Manko. Aber auch dieses wird in den nächsten Versionen irgendwann gegessen sein.
Arduino Fanboy D. schrieb: > Der Trick ist, dass man sich ganz nach belieben aussuchen kann, wie und > was man davon verwendet. Ist ja auch ok. Ich sage nur, dass diese Einzelteile dann den Begriff "Arduino" (im Sinne des Gesamtsystems) nicht mehr verdienen. Davon unbeschadet kann man natürlich ein "Arduino-Board" verwenden welches auch genau das bleibt.
Obwohl es verständlich ist, daß man sich auf die obengenannten uC fokussiert finde ich es irgendwie schade, dam man oft nicht weit über den Zaun schaut. Vor Jahren verbrachte ich einige Zeit mit der Zilog Encore! Familie. Ich war positiv überrascht von den Ergebnissen. Ich baute mir einen Entwicklungsbord für den 64K Flash Typ. Der uC hat einen Songle wire debugger. Die komplette IDE und Compiler, Debugger waren frei. Der uC war eine Freude damit zu arbeiten. Und trotzdem kümmert sich scheinbar kein Schwein darum. Die ganze Entwicklungsumgebung funktionierte super, der Debugger war responsiv und die Dokus super. Dass ich trotzdem von Zilog abgekehrt bin hat andere externe Gründe. Irgendwie ist das schade. Naja, was solls... Mit dem STM32 kann man ja auch viel machen und das JTAG Debugging ist wirklich angenehm. Im Prinzip läßt sich mit allen uC viel machen sobald den Feind kennt. Ich arbeitete früher mit CooCox V1.74-175. Obwohl es da Gerüchte gibt, daß es heimtelefonieren soll, tritt das nicht auf wenn man nur den Compiler und den IDE installiert. Mit CC ließ sich damals auch sehr gut arbeiten und funktuonierte teilweise besser wie Atollic. Ich installierte am Dienstag CC V1.75 um ein altes Projekt zu pflegen und alles funktionierte auf Anhieb.
Stefan ⛄ F. schrieb: > Ich denke, dass die allermeisten hier schon zwischen Hardware und > Software differenzieren können. Wenn hier jemand von Arduino (ohne den > Zusatz "Modul", "Board", "Shield" oder "IDE") schreibt, kannst du davon > ausgehen, dass er das Software-Framework meint. Das Argument war doch aber das Debugging. Das hat nichts mit dem Arduino Framework zu tun, sondern mehr mit der IDE, i.e. hier geht es primär um die Arduino IDE.
Ghostrider1911 schrieb: > PlatformIO hatte ich mir bereits mal angeschaut, also Arduion IDE Eben nicht! Gruss Chregu
"Ghostrider1911 schrieb: > PlatformIO hatte ich mir bereits mal angeschaut, also Arduion IDE Eben nicht!" -> Das habe ich anders gemeint. Das PlatformIO und Arduino nicht das gleiche ist, weiß ich natürlich. Das hier so eine Diskussion über Arduino aus bricht, und was es eigentlich ist hätte ich nicht gedacht ;) Aber zurück zu meinem eigentlichen Anliegen: Was ich bereits gemacht habe? Ja eigentlich schon ein paar Sachen, alles werde ich jetzt nicht aufzählen, das letzte war eine Lötkolbensteuerung für die Weller RT spitze, mit ADS1115, kleinem OLED Display und einen Arduino Nano. Die Librarys die es für den ADS gibt sind alle nutzlos (weil zu langsam und sehr schlecht gemacht), deswegen hab ich das ganze gleich selbst geschrieben. Natürlich will ich mich auf einen µC festlegen der weit verbreitet ist, schon alleine weil die "einfachen" Probleme meist mit Google gelöst werden können. Ich werde mir die CUBE IDE mal anschauen.
Hallo, Ghostrider1911 schrieb: > Das hier so eine Diskussion über Arduino aus bricht, und was es > eigentlich ist hätte ich nicht gedacht ;) das gehört eben dazu. ;) Ich bin da sicher kein Maßstab, nur Hobbyprojekte, keinerlei berufliche o.ä. Berührungspunkte (Rentner). Bei der ArduinoIDE bin ich gelandet, weil ich keine andere IDE kenne, die mir so problemlos die Nutzung mehrerer CPU-Familien erlaubt. AVR, ESP8266, ESP32, W600, irgendein STM, auch mal ein nRF. Ein altes AVR-Studio ist noch installiert, ein ESP8266 SDK und ein ESP32 IDF ist auch noch drauf. Das z.B. unter einen gemeinsamen Hut zu bringen wäre für mich zuviel Aufwand bei Einarbeitung, Einrichtung und Pflege. Natürlich hat die ArduinoIDE Mankos, Debugger ist für mich da ein kleines Problem, ich bin zum Programmieren gekommen, als man von solchen Hilfen höchstens träumen konnte. Dafür kann ich eben in der ArduinoIDE nunt mischen, wenn ich darunter liegende Sachen brauche, z.B. alte AVR C-Sachen weiter nutzen will, ist da in wenigen Minuten eingebunden und angepasst. Zugriff auf die Systemfunktionen bei den ESPs macht man eben, wenn es keine Arduino Wrapperfunktion gibt. Ist doch egal, einbinden und Aufruf sieht am Ende doch auch nicht anders aus als in einer anderen IDE. Arduino ist, wie schon richtig geschreiben wurde, ein Konzept. Keine Boards (ein ESP8266 ist kein Arduino, ein China AVR Nano auch nicht, selbst wenn dasselbe drauf ist. Breakoutboards sind Löthilfen für ICS, die mir zu klein sind, steht eben meist Arduino-Kompatibel dran. Das alles ändert sich mit einer anderen IDE sowieso nicht. Ob der Umstieg für Dich konkret Vorteile bringst, wirst Du entscheiden müssen. Wenn Du Dich auf eine Prozessorfamilie einschießt, kann es das sicher. Wenn Du nehmen willst, was gerade passt oder nur interessant aussieht, gewinnt für mich immer die ArduinoIDE. Gruß aus Berlin Michael
Hallo, sehe ich ähnlich. Die Arduino IDE gewinnt bei mir durch ihre Einfachheit. Die bedient man blind. Für paar ganz wenige µC nehme ich Atmel Studio, geht auch wenn man es gewohnt ist, aber ansonsten immer wieder gern die Arduino IDE. Was ich hier noch vermisse und in AS toll finde ist mit Mausklick in den µC Header springen zur Implementation. Viel mehr brauche ich nicht zum programmieren. Und wegen debuggen Freunde. Ich weiß nicht was ihr alle so geil am Hardware Debugging findet. Das Programm bleibt doch bei jeden Breakpoint stehen. Das will ich nicht. Da lasse ich mir lieber Seitenweise Daten über die Serielle ausgeben und schau live zu was wann passiert und ziehe meine Schlüsse. Serieller Datalogger eben. Ich kann mir immer den gesamten Ablauf anschauen und zeitlich nachverfolgen nicht nur punktuell paar Bits die dann schon wieder anders und damit verschwunden sind.
Ich würde mir einen Wechsel der IDE auch genauestens überlegen. Ich benutze auch AVRs, als IDE hab ich aber was Richtung Eclipse am Start. Ich hab auch schon öfters mal überlegt mir auch andere Mikrocontroller und andere IDEs anzuschaun. Bisher konnte ich aber stets alle meine Mikrocontroller-Projekte mit irgendeinem AVR (von Attiny bis Atxmega) erschlagen. Und da ich dieses System gut kenne komme ich auch recht zügig voran. Switch auf eine andere IDE und/oder anderen Mikrocontroller wäre mit extremen Aufwand für mich verbunden und das lohnt sich einfach nicht in meinem Fall. Und das muss man sich IMO immer überlegen: Inwieweit lohnt sich ein Wechsel. Deshalb, finde ich, kann man da auch schlecht jemand anderen, den man ggf. nicht mal kennt, wirklich einen anderen Tipp geben außer "Schaus dir mal an und überlege es dir". Solche Frage haben IMO immer was von der Marke "Mag ich Schnitzel oder soll ich besser ein Spiegelei braten? Ein Salat ist ja auch ganz lecker."
Veit D. schrieb: > Und wegen debuggen Freunde. Ich weiß nicht was ihr alle so geil am > Hardware Debugging findet. Das Programm bleibt doch bei jeden Breakpoint > stehen. Das will ich nicht. Da lasse ich mir lieber Seitenweise Daten > über die Serielle ausgeben und schau live zu was wann passiert und ziehe > meine Schlüsse. Du bist halt ein Anfänger.
Du könntest auch damit Anfangen den Arduino erstmal von seinen Fesseln zu befreien. Jeder Arduino hat eigentlich gleich den passenden ISP Programmierstecker drauf. Damit kann man schonmal den Bootloader löschen und den Chip direkt programmieren. Je nach Typ von Arduino hat man dann auch in der Regel Debug Wire oder JTAG zur Verfügung und kann wirklich Debuggen. Die Arduino HW ist ja erstmal okay und erfüllt ihren Zweck, alles was es bräuchte wäre also Atmel Studio und ein passender Debugger als ICE oder MK3
Hallo, Unfassbar schrieb: > Veit D. schrieb: >> Und wegen debuggen Freunde. Ich weiß nicht was ihr alle so geil am >> Hardware Debugging findet. Das Programm bleibt doch bei jeden Breakpoint >> stehen. Das will ich nicht. Da lasse ich mir lieber Seitenweise Daten >> über die Serielle ausgeben und schau live zu was wann passiert und ziehe >> meine Schlüsse. > > Du bist halt ein Anfänger. mir ist bisher noch kein Debugger begegnet, der die Programmierfehler selber beseitigt hat. Dafür habe ich auch bei kommerzieller Software öfter den Eindruck, das hilflos probiert wurde, bis der Debugger das gewünschte Ergebnis ausgab. Gruß aus Berlin Michael
Unfassbar schrieb: > Du bist halt ein Anfänger. Ich stimme ihm zu. Ich programmiere beruflich seit 20 jahren.
Stefan ⛄ F. schrieb: > Unfassbar schrieb: >> Du bist halt ein Anfänger. > > Ich stimme ihm zu. Ich programmiere beruflich seit 20 jahren. Das heißt gar nichts. Man kann auch 20 Jahre frickeln. Ein ordentlicher Debugger gehört zum prof. Werkzeug dazu.
es gibt auch noch Mbed. Ist zwar nur für Cortex-M, aber bei der Bandbreite die die Abdecken habe ich schon seit vielen Jahren keinen AVR mehr vermisst. Das Mbed API ist in den letzten 2-3 Jahren enorm gewachsen, RTOS oder BareMetal, USB, Ethernet, einfache Sachen wie GPIO, Analog, serial, I2C, SPI usw. gibt es schon lange. Alles als eine getestete Einheit die auch mit dem eingebauten RTOS zusammenarbeitet. Über das mbed-cli lassen sich die Programme auch in der Kommandozeile einfach kompilieren, oder in einen Editor wie VSCode integrieren. Mit den 'Mbed enabled' Boards wie z.B. nahezu alle STM Nucleos oder Discos ist dann auch debuggen sehr einfach, USB Kabel reicht. Da ist Mbed-Studio mittlerweile eine 1-Klick Installation incl. ARM Toolchain. Als Hardware für grössere Projekte haben die STM32F4 im Moment sehr viel 'Bang for Bucks'. Die Chinaboards im Bluepill Format mit F401/F411 kosten <5€ , haben reichlich mehr Flash/RAM und noch Platz für ein SPI Flash, nur halt relativ wenige Pins rausgeführt. Für 2-3€ mehr gibts die F407 in verschiedenen Varianten, 168 MHz, 192 kB RAM, 512 oder 1024 kB Flash. Z.T. haben die Boards schon MicroSD Slot drauf, SPI Flash, RTC und Steckplatz für TFT Displays. Oder mit fast nix drauf, dafür alle Pins rausgeführt. Für diese low cost Boards muss man nur einen ext. STLink oder z.B. Bluepill mit BMP als Programmier/Debug Adapter anklemmen. Aber auch diese Einrichtung ist kein Hexenwerk mehr und wird mit ordentlicher Debugmöglichkeit belohnt.
Veit D. schrieb: > Da lasse ich mir lieber Seitenweise Daten > über die Serielle ausgeben und schau live zu was wann passiert und ziehe > meine Schlüsse. Serieller Datalogger eben. Ich kann mir immer den > gesamten Ablauf anschauen und zeitlich nachverfolgen nicht nur punktuell > paar Bits die dann schon wieder anders und damit verschwunden sind. Stefan ⛄ F. schrieb: > Ich stimme ihm zu. Ich programmiere beruflich seit 20 jahren. Michael U. schrieb: > mir ist bisher noch kein Debugger begegnet, der die Programmierfehler > selber beseitigt hat. Dafür habe ich auch bei kommerzieller Software > öfter den Eindruck, das hilflos probiert wurde, bis der Debugger das > gewünschte Ergebnis ausgab. Wer ernsthaft meint, sich zum debuggen über eine serielle Schnittstelle schöne bunte Texte ausgeben zu lassen, diese extra in die Software reinprogrammieren muss und mit Hilfe von hohen Interpretationsfähigkeiten sein Programm damit meint besser debuggen zu können, als mit einem Hardwaredebugger, der hat sich komplett, aber wirklich komplett disqualifiziert und als Frickler geoutet. Wer eben nicht weiß, wie man wirklich mit einem Hardwaredebugger effektiv debuggt, der greift halt zu solchen Mitteln. Und meint dann, dass ein Hardwaredebugger eh nur Spielerei ist. Totaler Bullshit. Wenn ich Chef wäre und mein Angestellter fängt mit sowas an, dann gibts zwei Möglichkeiten: Mach es richtig oder verschwinde. Auch wenn man seit 20 Jahren so arbeitet wird man deswegen nicht zum guten Softwareentwickler.
Unfassbar schrieb: > er ernsthaft meint, sich zum debuggen über eine serielle Schnittstelle > schöne bunte Texte ausgeben zu lassen Das was die Leute so unter Arduino schreiben oder eher zusammen copy pasten, dafür reicht auch so ein Speilzeugdebugger :) Das ganze wird später riesen Schaden verursachen, weil die Leute nicht wissen werden, wie man etwas richtig debuggen kann. Und dass man sowas überhaupt machen kann!
TippsUndTricks schrieb: > Das was die Leute so unter Arduino schreiben oder eher zusammen copy > pasten, dafür reicht auch so ein Speilzeugdebugger :) Nochmal: Texte über die serielle Schnittstelle ist kein Debugger. Das wolltest du aber vermutlch auch ausdrücken. So habe ich auch in den erste Monaten, als ich damals anfing gearbeitet. Aber da wusste ich es noch nicht besser. Eine uart zum debuggen führe ich grundsätzlich nicht mehr heraus - zumindest nicht für hier genannten Anwendungsfall.
Hallo, Unfassbar schrieb: > Auch wenn man seit 20 Jahren so arbeitet wird man deswegen nicht zum > guten Softwareentwickler. Du solltest vielleicht nicht von deinen Bedürfnissen auf die Bedürfnisse andere schließen. Es ist ein Unterschied ob ein Hobbyist im Jahr ein, zwei "Projekte" bearbeitet (und sich jedes mal wieder in eine Arbeitsumgebung eindenken muss), oder ob ein Profi Tag aus, Tag ein hochkomplexe, kommerzielle Software schreibt. Da stellt sich dann natürlich schon die Frage wie viel Aufwand man in die Beherrschung einer Entwicklungsumgebung steckt. rhf
Roland F. schrieb: > Du solltest vielleicht nicht von deinen Bedürfnissen [...] Man kann die Menschen aber an die Hand nehmen und den Leuten früh klarmachen, dass man so nicht debuggt. Wofür ist so ein Forum da? Möchte man nichts lernen? Wozu liest und schreibt man dann hier? Wenn jedoch alle auf dem selben Irrweg bestehen, wird dieser Umstand an die folgenden Generationen weitergegeben. Und ich glaube schon, dass einige der zitierten Authoren sich als Profis bezeichnen...
Unfassbar schrieb: > Wenn jedoch alle auf dem selben Irrweg bestehen, wird dieser > Umstand an die folgenden Generationen weitergegeben. In der Regel befinden sich gerade die Leute auf dem Irrweg, die meinen, es gäbe nur einen richtigen und das ist ihrer. Ich besitze Debugger und kann damit umgehen. Ich benutze sie täglich. Log-Meldungen benutze ich mit großem Abstand am häufigsten, weil sie mir am meisten nutzen bringen. Bei anderen Entwicklern und/oder Projekten mag das anders sein. Ich freue mich darüber, dass die SWD Schnittstellen aller (?) ARM Controller nach wie vor eine SWO Leitung haben. Spätestens wenn du als Softwareentwickler Fehler an Anlagen untersuchen musst, auf die du keinen Zugriff hast, wirst du über jede Protokolldatei froh sein, die du bekommen kannst.
Stefan ⛄ F. schrieb: > Spätestens wenn du als Softwareentwickler Fehler an Anlagen untersuchen > musst, auf die du keinen Zugriff hast, wirst du über jede Protokolldatei > froh sein, die du bekommen kannst. Unterscheide hier bitte zwischen geplanten Logausgaben komplexerer Systeme und "ich programmiere hier mal eine wirre pollende Textausgabe über die serielle Schnittstelle, um mir die Variable 'komischerName' ununterbrochen ausgeben zu lassen, aus 10 Milliarden Zeilen pro Sekunde". Logs sind geplant. Dann gibt es Schnittstellen, um diese auszulesen und ggf. sogar Tools, um diese darstellen zu können. Das hat dann aber in der Regel weniger mit Softwarefehlern zu tun, sondern mit äußeren Einflüssen die den Abauf stören können. Natürlich kann man damit auch Softwarefehler finden, ist dafür aber eigentlich nicht vorgesehen. Wenn ein Gerät rausgeht und beim Kunden steht, darf dieser nicht mehr das Versuchskanienchen sein und die Software muss vollumfänglich geprüft sein. Wenn dann ein offensichtlicher SOftwarefehler auftritt, dann ist das bei allen Geräten so. Das wird dann im Haus mit Debugger untersucht. Stefan ⛄ F. schrieb: > In der Regel befinden sich gerade die Leute auf dem Irrweg, die meinen, > es gäbe nur einen richtigen und das ist ihrer. Gewiss gibt es noch mehr Möglichkeiten. Aber im Bereich Mikrocontroller ist der Hardwaredebugger erste Wahl.
Unfassbar schrieb: > Wer eben nicht weiß, wie man wirklich mit einem Hardwaredebugger > effektiv debuggt, der greift halt zu solchen Mitteln. Und meint dann, > dass ein Hardwaredebugger eh nur Spielerei ist. Totaler Bullshit. Wenn du meinst, hier mit Ausdrücken wie "totaler Bullshit" herumwerfen zu müssen, dann disqualifizierst du dich selber. Merke: Lauter gebrüllt ist noch lange nicht richtiger gesagt. Mit den üblichen Debug-Möglichkeiten kann man eigentlich nur eines tun: Die eigenen Programmierfehler aufdecken, also die Stellen, wo man zu vergeßlich oder zu blöd war: Schusselfehler, Manual falsch verstanden, falsches Konzept gehabt, Compilerfehler, Klammer an der verkehrten Stelle, und so weiter. Für ganz gewöhnliche Projekte braucht man fast immer keinen Debugger, sofern man systematisch planen und programmieren kann. Für Leute hingegen, die drauflos programmieren (wie viele hier), ist jedoch der Debugger ein Segen, weil sie oftmals erstaut sind, was der Compiler aus dem gemacht hat, was sie in die Quelle hineingeschrieben haben. Diese Leute programmieren quasi mit dem Debugger und du gehörst offensichtlich genau zu dieser Sparte - was man aus deinen vehementen Worten ersehen kann. Nochwas: Manche Dinge kann man mit einem gewöhnlichen Debugger eher nicht debuggen - ich denke grad an sowas wie den USB-Treiber, wo man vom Host nach 3 ms bereits rausgeschmissen worden ist. In solchen Fällen ist tatsächlich ein gepuffertes Log die bessere Methode. Wie du erkennen kannst, ist die Wahl der Mittel fallabhängig und dein lautes Getöne zeugt nur von einem zu engen Horizont. Auch ohne Debugger kann man professionell arbeiten. Das kannst du dir mal als gesetzt merken. W.S.
Ghostrider1911 schrieb: > Das die ARM Controller generell ein gutes Stück komplexer sind gegenüber > den AVR habe ich nach kurzer Recherche leider bereits feststellen > müssen. Wobei man da auch keine "Angst" haben sollte. Die einzelnen Funktionsblöcke sind gut gekapselt und niemand zwingt einen, direkt alle einzuschalten und zu verwenden. Viele Möglichkeiten ergeben eben ein dickes Referenzhandbuch , von denen man dann aber für ein Modul (bspw. GPIO oder Zähler) nur einige wenige Seiten benötigt. Und das ist dann auch nicht mehr viel mehr als bei den AVRs. Man muss sich nur wenige wirklich neue Dinge angewöhnen, so bspw. das Freischalten der Taktversorgung der Module oder auch die komplexere Takterzeugung selbst. Aber dafür erstellt man sich einmal den Code und gut ist es. Wenn Du also schon AVRs außerhalb der Arduino-Umgebung programmiert hast, dann wirst Du wenig Umstellungsschwierigkeiten haben und Dir vieles bekannt vorkommen. > Aber es hilft ja nichts, und mein Gedanke ist: Wenn ich mich schon in > die "richtige" Programmierung mit Registern usw. einarbeiten will, dann > doch gleich in eine Prozessorgeneration die etwas aktueller und > leistungsstärker ist als die AVR. Genau. "Nichts muss, aber alles kann". Auch wir hier nutzen immer nur einen Bruchteil der Controllerhardware in einem Projekt. (Wir programmieren hier übrigens auch mit eigenen HAL-Bibliotheken und direkt auf den Registern. Es ist wirklich nicht schwer, sich das aufzubauen)
W.S. schrieb: > Für ganz gewöhnliche Projekte braucht man fast immer keinen Debugger, > sofern man systematisch planen und programmieren kann. Dann haben wir hier einen Überflieger der Kategorie "Ich mache keine Fehler". Kannst stolz auf dich sein, jedoch machen 99% der anderen Programmierer während der Umsetzung sogenannte Schusselfehler, die du selbstverständlich nicht machst. Und auch ich mache diese, obwohl ich gut plane (was ich zumindest von mir behaupte). W.S. schrieb: > Manche Dinge kann man mit einem gewöhnlichen Debugger eher nicht > debuggen - ich denke grad an sowas wie den USB-Treiber, wo man vom Host > nach 3 ms bereits rausgeschmissen worden ist. In solchen Fällen ist > tatsächlich ein gepuffertes Log die bessere Methode. Auch hier brauche ich keine Logs. Es gibt einen Punkt im Programmcode, an dem der USB versagt. Breakpoints setzen, abfangen, Variableninhalte anschauen und Schlüsse ziehen. Ggf. zweimal wiederholen und man hat den Problemmacher identifiziert. Logs als Ausgabe zum Finden von Softwarefehlern eignen sich nur, wenn man eine Anwendung mit wirklich großen Datenaufkommen hat. Damit meine ich keine Bildverarbeitung etc., sondern wirklich Gigabytes. Aber solche Geräte enthalten einen Mikrocontroller allenfalls als Vermittler, welcher dann widerum kein eigenes großes Datenvolumen hat. Daher steht dan ein Computer, Beaglebone, Linux, Pi, Banana, Beaglebone, phytec - was weiß ich.
W.S. schrieb: > Auch ohne Debugger kann man professionell arbeiten. Das kannst du dir > mal als gesetzt merken. > > W.S. Halte ich im Jahr 2020 für absoluten Quatsch. Die Zeiten von Assembler und mühsam ausgeklügelten Sprungplänen sind (eigentlich) vorbei. Leider gibt es zu viele Leute die meinen, daran fest halten zu müssen. Verstehe mich nicht falsch, mit Sicherheit hat Assemblercode auch seine Berechtigung aber mit Sicherheit nicht als einzige Sprache in einem Projekt. Und jetzt kommen gleich wieder Opa x bis y und erzählen mir, wie doll Assembler ja ist und wie effizient. Ja, das bestreite ich nicht aber für ein großes Projekt ist es nicht geeignet weil keine Sau ausser dem Autor diesen Wust schnell und einfach nachvollziehen kann. Um damit zum eigentlichen Thema zurück zu kommen: Hardwaredebugging bzw. Debugging allgemein ist einer der essentiellsten Teile heutiger Programmiermethoden. Allein schon durch den Einsatz vieler Frameworks oder Treibern von Anderen oder einem Hersteller hat man oft gar keine andere Chance, noch den Überblick zu behalten oder nach zu vollziehen, warum der Controller dieses oder jenes gerade tut. Das ist übrigens auch der Grund warum ich das mit Assembler angesprochen habe, denn dieses "man muss besser schauen was man macht und überlegen wo sein eigener Fehler liegt" hat eben noch ganz gut in Assemblerzeiten funktioniert, heute absolut veraltetete Sichtweise (meiner Meinung nach). Und zum Schluss noch eine Empfehlung an den TO: PIC Mikrocontroller von Microchip. IDE und Compiler gibt es gratis von der Firma. Die IDE ist sehr anfängerfreundlich, hat alles was man braucht und kostet wie bereits erwähnt nichts. Das All-in-One Gerät PICkit 3 (bzw. neuer 4) ist ein Hardwaredebugger und Flasher in einem. Die benötigten Pins hat jeder PIC und ausser diese richtig mit dem PICkit zu verbinden muss man hier quasi nichts tun. Das Gerät gibts schon ab 10-15€ als Chinaclone. Habe selbst einen Clone und hatte damit nie Probleme. Auch das Originale ist mit einem einmaligen Preis von 44,88€ (stand mouser 31.1) auch absolut in Ordnung. In diesem Sinne.
:
Bearbeitet durch User
habe mal in einem Code für ein Display einen Fehler gesucht weil da nicht alle Spalten angezeigt wurden. Mit dem Debugger war das ein Klacks den Fehler zu finden. Ja ja, wenn man nicht alles selber schreibt und Code von Fremden nimmt.
Vorname N. schrieb: > PIC Mikrocontroller von Microchip. IDE und Compiler gibt es gratis von > der Firma. Die IDE ist sehr anfängerfreundlich, hat alles was man > braucht und kostet wie bereits erwähnt nichts. Das All-in-One Gerät > PICkit 3 (bzw. neuer 4) ist ein Hardwaredebugger und Flasher in einem. > Die benötigten Pins hat jeder PIC und ausser diese richtig mit dem > PICkit zu verbinden muss man hier quasi nichts tun. Ich finde, der TO sollte eher mit kleinen ARMs anfangen. Ein STM32F0 ist nicht komplexer als ein PIC. Aber die Debugger von Microchip empfinde ich (meine Meinung) als Katastrophe. Compiler + IDE + Debugger sind auch richtig langsam. Dann lieber NXP, STM32 oder ATSAM. Die übliche Leier: Discoveryboard vn ST für < 10€.
Unfassbar schrieb: > Vorname N. schrieb: >> PIC Mikrocontroller von Microchip. IDE und Compiler gibt es gratis von >> der Firma. Die IDE ist sehr anfängerfreundlich, hat alles was man >> braucht und kostet wie bereits erwähnt nichts. Das All-in-One Gerät >> PICkit 3 (bzw. neuer 4) ist ein Hardwaredebugger und Flasher in einem. >> Die benötigten Pins hat jeder PIC und ausser diese richtig mit dem >> PICkit zu verbinden muss man hier quasi nichts tun. > > Ich finde, der TO sollte eher mit kleinen ARMs anfangen. Ein STM32F0 ist > nicht komplexer als ein PIC. Aber die Debugger von Microchip empfinde > ich (meine Meinung) als Katastrophe. Compiler + IDE + Debugger sind auch > richtig langsam. > > Dann lieber NXP, STM32 oder ATSAM. Die übliche Leier: Discoveryboard vn > ST für < 10€. Die Geschwindigkeit ist in der Tat im Vergleich zu anderen nicht so berauschend (obwohl das Debuggen durch das PICkit4 schon deutlich besser wurde). Allerdings muss man das Zeug nur runterladen und kann ohne großes Konfigurieren oder Toolchaingebastele direkt los legen. Zu den ST: Gibt ja auch die Bluepill -Boards für 2€ vom Chinamann :) Und den Cloneflasher /debugger gibts auch schon für 2€ vom selbigen (manchmal auch für 20cent mehr mit zu der Bluepill ;)). ST Mikrocontroller sind auch keine schlechte Wahl, man hat hier auch mehr Freiheiten was das individualisieren der IDE und allgemein der ganzen Tools betrifft. Der Nachteil ist, man muss sich dann definitiv damit Beschäftigen. Ausserdem ist es wirklich erstaunlich, für wie wenig Geld man mittlerweile eine 32bit ARM Architektur hinterher geworfen bekommt.
Unfassbar schrieb: > Dann haben wir hier einen Überflieger der Kategorie "Ich mache keine > Fehler". Kannst stolz auf dich sein, jedoch machen 99% der anderen > Programmierer während der Umsetzung sogenannte Schusselfehler, die du > selbstverständlich nicht machst. Und auch ich mache diese, obwohl ich > gut plane (was ich zumindest von mir behaupte). Schusselfehler macht jeder, mir wäre aber neu dass man die durch einen Debugger vermeidet. Schusselfehler erkennt man eigentlich immer am Ergebnis. Daher muss ich hier W.S. mal recht geben.
Hans schrieb: > und schneller als der in den nucleo-boards integrierte stlink. Den ST-Link auf den Nucleo-Boards kann man umflashen auf J-Link (offizieller Download auf der Segger Webseite), dann hat er damit quasi auch schon einen J-Link EDU und kann sich an dessen Vorteilen (keine Gesichtslähmung bei Einzelschritt, unlimited Breakpoints, etc.) erfreuen.
:
Bearbeitet durch User
Unfassbar schrieb: > ununterbrochen ausgeben zu lassen, aus 10 Milliarden Zeilen pro > Sekunde". Enorm schnell! Welche Hardware hast du denn? Will ich auch haben! Für Normalos würde ich zu STM32Fxxx mit SWD raten. Gut und günstig siehe Nucleo-Boards.
M. K. schrieb: > Schusselfehler macht jeder, mir wäre aber neu dass man die durch einen > Debugger vermeidet. Schusselfehler erkennt man eigentlich immer am > Ergebnis. Daher muss ich hier W.S. mal recht geben. Nö, mit dem Debugger findest du (unter anderem) deine Schusselfehler. Wo habe ich behauptet, dass man mit Debugger keine Fehler macht? Ein Debugger soll Fehler finden, nicht verhindern. Also ich sehe nicht, wenn ich mein Gerät anschalte und es hat eine Fehlfunktion: Oh, ich sehe sofort, dass ich da Variable X mit Y vertauscht und anschließt x++ statt --x geschrieben habe. Kommt vor, aber in der Regel muss man kurz reinschauen.
Speedy schrieb: > Unfassbar schrieb: >> ununterbrochen ausgeben zu lassen, aus 10 Milliarden Zeilen pro >> Sekunde". > > Enorm schnell! Welche Hardware hast du denn? Will ich auch haben! > > Für Normalos würde ich zu STM32Fxxx mit SWD raten. Gut und günstig siehe > Nucleo-Boards. Hardware aus der Zukunft. Da bin ich mit meiner Zeitmaschine hingereist, die ich natürlich mit einem STM32 gebaut habe, welche mit der seriellen Schnittstelle debuggt habe. Ok, eigentlich war die von Anfang an perfekt und hatte keine Fehler, also musste ich nichts debuggen.
Unfassbar schrieb: > Nö, mit dem Debugger findest du (unter anderem) deine Schusselfehler. Wer mit einem Debugger Schusselfehler findet sollte seine Arbeitsweise überdenken und das meinte W.S. und da pflichte ich ihm bei. Mit einem Debugger findet man die Ursachen für nicht erwartungsgemäßes Verhalten.
M. K. schrieb: > Unfassbar schrieb: >> Nö, mit dem Debugger findest du (unter anderem) deine Schusselfehler. > > Wer mit einem Debugger Schusselfehler findet sollte seine Arbeitsweise > überdenken und das meinte W.S. und da pflichte ich ihm bei. > > Mit einem Debugger findet man die Ursachen für nicht erwartungsgemäßes > Verhalten. Ein Debugger ermöglicht einem einfach, den Code StepByStep nachvollziehen zu können. Dabei kann man sowohl syntaktische (aka "Schusselfehler") als auch semantische Fehler finden. Unabhängig davon, welche Fehler man gezielt suchen will: Ohne Debugger wird es um einiges unangenehmer bis unmöglich. Darum sollte ein Debugger heute auch absoluter Standart sein.
M. K. schrieb: > Mit einem Debugger findet man die Ursachen für nicht erwartungsgemäßes > Verhalten. Das auch. Man kann sämtliche Arten von Fehler finden. Aber die serielle Schnittstelle ist dafür nur edingt geeignet und zusätzlich äußerst umständlich, langsam und selber Fehleranfällig.
Schönen Freitag Mittag miteinander! Gleich nach der Arduino Diskussion kommt die Debugger Diskussion ;) Naja ich sehe das so: Bis jetzt "debugge" ich so wie es hier bereits geschrieben wurde: Variablen einfach über die UART ausgeben und anzeigen lassen. Natürlich ist das ganze nicht so das gelbe vom Ei, zumindest für mich nicht. (Viele hier mögen das anders sehen, ich habe noch nie mit einem richtigen Debugger gearbeitet, und bin auf die neuen Möglichkeiten gespannt) Ich mache beim Programmieren viele Fehler, gebe ich auch gern zu, ich mache das nur Hobby mäßig und nicht beruflich. Jedoch denke ich mir, das gerade mir als Anfänger ein Debugger sehr gut helfen kann. Ich habe mir gerade einen Nucleo F103RB bestellt, dieser hat den (fast) gleichen µC als das Bluepill oder Maple Board drauf. Ich werde mir das in Verbindung mit der STM32Cube ansehen, bzw. mit der STM32 Workbench, auch die mBed Umgebung werde ich mir anschauen. Nach meinem aktuellen Wissensstand sind das die aktuell sinnvollsten IDE´s die für mich in Frage kommen. Ausserdem bieten sie alles was ich brauch in einer kompletten IDE, was für mich denke ich einfacher ist als ettliche Einzelprogramme. Ich möchte mich gleich in einen µC einarbeiten der mir auf jedenfall ausreicht und nicht wie vorher vom kleinsten zum größten. (attiny2313 - atmega8 - 88 - 168 - 328 - 32 - 2560) Vom preislichen her ist mir das egal, wenn ich die Preise vergleiche ist das kein Weltuntergang... Lieber mit Kanonen auf spatzen schießen, da tut sich der Anfänger auch leichter beim programmieren. (Meine Meinung) Ausserdem: Wie bereits erwähnt wurde muss man die gegebenen funktionen ja nicht nutzen. Klar, der Überblick ist schwieriger, aber da muss ich eben einmal durch, und wenn ich das kapiert habe wird das schon werden. Stefan Frings, der ja auch hier schreibt hat eine schöne Anleitung auf seiner Seite, an dieser werde ich mich entlanghangeln. kleines Beispiel: Ich habe eine Steuerung mit dem atmega328 gebaut, der flash ist komplett voll, 1-2 Funktionen müssen noch rein, also habe ich mehrere Stunden damit verbracht den Code zu optimieren. Mein Anspruch ist sicherlich einiges niedriger als der vieler Profis hier, ich hoffe das könnt ihr auch verstehen. Ich zähle mich als fortgeschrittenen Bastler, der gelegentliche Projekte verwirklichen will und aktuell mit den AVR´s an die Grenzen derjenigen kommt. Ob es sinnvoll ist von den AVR´s weg zu gehen, und ob ich das wirklich brauche, ist ein ganz anderes Thema, ich jedenfalls werde mir die STM32 jetzt anschauen, sollte es nichts werden sind die 20€ für das Nucleo eben für die Katz, damit kann ich ehrlich gesagt leben ;) Ich hätte einfach einen atmega2560 verwenden sollen, die paar Euro mehr sind mir sowas von egal, ich muss ja nichts in Serie fertigen.. Meine Projekte wurden bis jetzt alle nur in Einzelausfertigung erstellt. In diesem Sinne: Fröhliches Diskutieren und allen hier ein schönes Wochenende!! ;)
Unfassbar schrieb: > Ich finde, der TO sollte eher mit kleinen ARMs anfangen. Wenn schon ARM, dann würde ich auch dazu raten. Bei STM32 halte ich die Seriel L0, F0, F1 und F3 für den nächsten logischen Schritt nach ATmega328. Für den F1 findet man mehr Doku im Netz, aber der ist schon sehr alt. Der Nachfolger F3 ist sehr ähnlich, nur halt in vielen Punkten etwas verbessert. Wer gut englisch kann (um das Referenzhandbuch zu verstehen) wird auch damit klar kommen, denke ich. Bei mir hat das jedenfalls geklappt, und ich bin ausdrücklich kein Profi, was Mikrocontroller angeht.
Hallo, Vorname N. schrieb: > Ein Debugger ermöglicht einem einfach, den Code StepByStep > nachvollziehen zu können. Dabei kann man sowohl syntaktische (aka > "Schusselfehler") als auch semantische Fehler finden. vorweg, ich habe meine Ansicht und den Bereich Hobby ja bereits erwähnt. Keiner kann ein Programm StepByStep durchgehen, um einen Fehler zu finden. Macht auch niemand. Erstmal grenzt man doch die Problemecke ein, um zu schauen, wo man überhaupt ansetzen muß. Da ist doch eher die Unterscheidung "gute und weniger gute Programmierer". Der gute kennt soviel vom Programmablauf, daß er schnell an der kritischen Stelle ansetzen kann, der weniger gute stochert mehr rum. Natürlich kann dann ein Hardwaredebugger das Leben leichter machen, Breakpoiunts, Variablentracing usw. usw. geht dann schneller als per serieller Ausgabe Variablenwerte beim Funktionsaufruf auszugeben und Zwischen ergebnisse. Letztlich muß man doch selber aus den Prgrammlauf erwartete und falsche Werte auswerten und die Ursache weiter eingrenzen. Mir hilft es da meist mehr, den Breich im Sourcecode in Ruhe durchzuschauen, 50% der Fehler finde ich da bereits. Die anderen 50% sind dann Fehler bei der Nutzung von Programmteilen anderer, Doku nicht richtig gelesen, Anmerkungen speziell in Datenblättern übersehen usw. Mich stört es da etwas, daß sowas an einer Debugger-Version festgemacht wird. Ich kenne auch genug Leute, die einen tollen Meßgerätepark haben und nicht in der Lage sind, das richtig zu bedienen, die Ergebnisse zu interpretieren und vor allem die Grenzen der jeweiligen Technik zu kennen. Gruß aus Berlin Michael
Unfassbar schrieb: > Wenn > ein Gerät rausgeht und beim Kunden steht, darf dieser nicht mehr das > Versuchskanienchen sein und die Software muss vollumfänglich geprüft > sein. Na wer das glaubt, den kann man nicht ernst nehmen. Das gibt es nicht mal mehr im Flugzeugbau, wie letztes Jahr ans Licht kam. wendelsberg
wendelsberg schrieb: > Na wer das glaubt, den kann man nicht ernst nehmen. > Das gibt es nicht mal mehr im Flugzeugbau, wie letztes Jahr ans Licht > kam. Du vertehst ganz genau, was ich damit meine.
Unfassbar schrieb: > Du vertehst ganz genau, was ich damit meine. s/vertehst/verstehst/ Nein, erklaer es bitte. wendelsberg
wendelsberg schrieb: > Nein, erklaer es bitte. Nain, dass ersparr ech mier. Auf diesen Kinderkram habe ich keine Lust.
Michael U. schrieb: > Hallo, > > Vorname N. schrieb: >> Ein Debugger ermöglicht einem einfach, den Code StepByStep >> nachvollziehen zu können. Dabei kann man sowohl syntaktische (aka >> "Schusselfehler") als auch semantische Fehler finden. > > Keiner kann ein Programm StepByStep durchgehen, um einen Fehler zu > finden. Macht auch niemand. Erstmal grenzt man doch die Problemecke ein, > um zu schauen, wo man überhaupt ansetzen muß. > Da ist doch eher die Unterscheidung "gute und weniger gute > Programmierer". > > Michael Vielleicht habe ich mich ein wenig unklar ausgedrückt. Natürlich wird i.d.R. der zu debuggende Bereich eingegrenzt, logisch. Aber: Die generelle Funktion eines Debuggers ist es eben, gezielt in jede Zeile eingreifen zu können und das Ergebnis direkt zu erkennen und nach verfolgen zu können. Und selbst wenn das keiner macht, theoretisch könnte ich mit meinem Debugger durch hunderte Zeilen von Code steppen, einfach nur weil er es eben kann :)
Beim Code analysieren geht man meist vom richtigen Ergebnis aus oder glaubt zu wissen was in einer Codezeile passiert. Im Debugger sieht man aber was tatsächlich passiert. Und da gibt es sehr oft Unterschiede. Habe gerade einen 1 qm Papier entsorgt, da waren noch Unterlagen von Windriver und QNX drin. Da hat man noch für jeden Handschlag extra bezahlen müssen. Heute bekomme ich das alles für Lau, da kann ich nicht verstehen warum sich dagegen wehren muss. Es ist nur Faulheit da mal ein Tutorial durchzuarbeiten.
Man muss halt auch wissen WIE man mit einem Debugger sinnvoll arbeitet. Und es ist wie mit so vielem: Was man nicht kennt, braucht man nicht. Kennt man es, will man nicht mehr ohne. Man denke nur an Conditional Breakpoints, Task/OS awareness, Tracing. Das sind Dinge die einfach praktisch sind. Die will ich nicht missen.
Gestern sollte ich eine Änderung kontrollieren, wo die Spezifikation zwar korrekt aber von der Form her ziemlich verwirrend geschrieben war. Mit dem Debugger habe ich den Code für alle geforderten Szenarien Zeile für Zeile ausgeführt, so bekam ich einen klaren Endruck davon, was da eigentlich abläuft. Das könnte einen auf die Idee bringen, dass man nicht mehr ordentlich dokumentieren muss, weil man ja bequem debuggen kann. (Duck mich weg)
Stefan ⛄ F. schrieb: > Das könnte einen auf die Idee bringen, dass man nicht mehr ordentlich > dokumentieren muss, weil man ja bequem debuggen kann. > > (Duck mich weg) Du brauchst dich nicht ducken. Du hast völlig recht damit. Viele planen ihre Software überhaupt nicht mehr, also wirklich gar nicht. Dann wird einfach wild drauflos programmiert. Wenn die Spezifikation ziemlich "verwirrend" geschrieben ist, da geht die zur Überarbeitung an den Author zurück, basta. Wenn die dann ausgebessert wurde, würde ich erst mit der Arbeit beginnen.
Ja, das scheinen die wichtigsten Pragmas beim Programmieren zu sein: - mit dem Debugger wird man zu faul zum Nachdenken, ist überflüssig - Doku ist immer veraltet, also auch überflüssig - Tests sind aufwändig und decken keine 100 % ab, lassen wir das - Versionsverwaltung ist zu kompliziert, zip mit Datum Uhrzeit reicht. Ich finde es gut das es andere Ansichten und Projekte gibt von denen man wirklich was lernen kann.
Stefan ⛄ F. schrieb: > Das könnte einen auf die Idee bringen, dass man nicht mehr ordentlich > dokumentieren muss, weil man ja bequem debuggen kann. Also ehrlich, diesen gedanklichen Bogen von Debugging zu "braucht keine Doku" kann ich nicht nachvollziehen. Das sind komplett unterschiedliche Dinge. Es ist trivial dass man jede Software Reengineeren kann (mit oder ohne Debugger). Eine Doku erstellt man, damit das eben nicht jedes mal muss, sondern am besten gar nie und schlimmstenfalls einmal.
:
Bearbeitet durch User
Hallo, Johannes S. schrieb: > - mit dem Debugger wird man zu faul zum Nachdenken, ist überflüssig > - Doku ist immer veraltet, also auch überflüssig > - Tests sind aufwändig und decken keine 100 % ab, lassen wir das > - Versionsverwaltung ist zu kompliziert, zip mit Datum Uhrzeit reicht. Obige Punkte sind sicherlich sehr sinnvoll, aber soll jetzt jeder, der ein BASCOM-Programm mit 20 Zeilen Code auf einem ATtiny schreibt - einen Debugger benutzen, - eine umfangreiche Dokumentation anlegen, - Testsoftware schreibe, - und das Ergebnis dann in eine Versionsverwaltung einpflegen? Konkret: ab welcher Projektgröße ist das alles sinnvoll und ab wann darf es auch mal ein bisschen einfacher gehandhabt werden? rhf
Roland F. schrieb: > Obige Punkte sind sicherlich sehr sinnvoll, aber soll jetzt jeder, der > ein BASCOM-Programm mit 20 Zeilen Code auf einem ATtiny schreibt > - einen Debugger benutzen, > - eine umfangreiche Dokumentation anlegen, > - Testsoftware schreibe, > - und das Ergebnis dann in eine Versionsverwaltung einpflegen? Dokumentation: definitiv ja, für genau den Dödel selber. Der weiß nämlich nach spätestens einem halben Jahr nicht mehr, was er sich dabei gedacht hat, was er da geschrieben hat... Der Rest ist für Kleinkram unter 10000 Zeilen Code aber mehr oder weniger verzichtbar. > Konkret: ab welcher Projektgröße ist das alles sinnvoll und ab wann darf > es auch mal ein bisschen einfacher gehandhabt werden? Also eine Versionsverwaltung betreibe ich sogar privat. Sprich: mit nur einem einzigen Entwickler. Ist unwahrscheinlich hilfreich und nimmt nebenbei wesentliche Teile der Doku auf. Die besteht nämlich darin, wie ich beim Einchecken Änderungen begründe. Aber OK, selbst meine privaten Projekte gehen doch immer ganz signifikant über 20 Zeilen hinaus... Sobald mehr als ein Entwickler beteiligt ist, halte ich aber eine Versionsverwaltung für absolut unverzichtbar. Schon um die Schuld ordnungsgemäß zuweisen zu können... Tests hingegen... Naja. Viel Aufwand, relativ wenig Nutzen. So meine Meinung. Das Blöde bei Tests ist: es wird immer nur das getestet, woran der Programmierer gedacht hat. Aber klar: mit zunehmender Zahl von Entwicklern gewinnen Tests immer mehr an Sinn. Sie fangen nämlich dann wenigstens das auf, woran der eine Programmierer noch gedacht hat, der andere aber nicht, weil er nur die Hälfte des Problems wirklich verstanden hatte und garnix vom Code gelesen hat, bevor er seinen "Beitrag" zum Gesamtwerk eingecheckt hat. Die typischen YT-Tutorial und C&P-Coder halt... Mit zunehmender Entwicklerzahl wird natürlich auch die Doku immer wichtiger. Wobei ich "Doku" im Stil der heute üblichen halb- oder vollatomatischen Annotationen verschiedener Coleur für vollkommen verzichtbar halte. Das was da drin steht, steht doch schon in der Deklaration im Quelltext. Ordentliche Doku ist eine Darstellung des Konzeptes, nicht eine Auflistung dessen, was ohnehin im Quelltext steht, nur in einer anderen Metasprache... Und was nun Debugger betrifft: ja, die können manchmal hilfreich sein. Das Problem ist (besonders in Echtzeit-Systemen): wenn im Debugger das Problem sichtbar wird, liegt die eigentliche Ursache oft schon weit in der Vergangenheit. Hier sind mit Echtdaten gefütterte Simulatoren viel hilfreicher. Da kann man nämlich dieselbe Situation beliebig oft abspielen und sich sozusagen rückwärts zur Wurzel des Übels durchkämpfen... Der typische blöde Debugger-Benutzer baut aber hingegen oft bloß ein try-catch an der Stelle ein, wo's dann wirklich knallt... Das ist in meinen Augen eine Perversion. Sowas sollte verboten werden.
Roland F. schrieb: > - einen Debugger benutzen, > - eine umfangreiche Dokumentation anlegen, > - Testsoftware schreibe, > - und das Ergebnis dann in eine Versionsverwaltung einpflegen? Einen Debugger, wenn er sein Programm nicht zum laufen bekommt, ja. Es reichen hier Kommentare im Quellcode. Testsoftware, Blödsinn. Versionsverwaltung auch blödsinn. c-hater schrieb: > Der Rest ist für Kleinkram unter 10000 Zeilen Code aber mehr oder > weniger verzichtbar. Auch in Quellcode unter 10.000 Zeilen kann eine Menge arbeit drin stecken. Das merkt man dann, wenn man das erste mal aus versehen diesen löscht, was mir anfangs einmal passiert ist. Mensch habe ich mich geärgert. c-hater schrieb: > Also eine Versionsverwaltung betreibe ich sogar privat. Das hat ja auch absolut nichts mit der Anzahl der Entwickler zu tun.
Roland F. schrieb: > Obige Punkte sind sicherlich sehr sinnvoll, aber soll jetzt jeder, der > ein BASCOM-Programm mit 20 Zeilen Code auf einem ATtiny schreibt Der TO hat schon mit Arduino 'gespielt' und wollte jetzt mehr, es geht also nicht um den kleinsten Tiny. Trotzdem wird man, wenn man sich z.B. in git eingearbeitet hat, nicht mehr ohne diese Hosenträger arbeiten wollen. Ich jedenfalls nicht, habe vor kurzem noch versehentlich Dateien überschrieben. Ein Klick auf den Angelhaken (Revert) im VSCode, und schon war alles wieder repariert. Also nur eine Frage wie gut man sich selber organisieren kann/will, das hat nix mit Hobby zu tun. Da darf man soviel Chaos veranstalten wie man will, man ist König auf seiner eigenen Insel. Aber man kann das auch als Übung und Weiterbildung betrachten. Gilt genauso für die anderen Punkte. Kostet natürlich alles Einarbeitung, aber es ging ja um besser machen. Mit einem großen µC und Fortsetzen meterlanger Sketche kann man das Chaos zum Quadrat weiterleben. Tests überlasse ich gerne anderen :) Zum Glück gibt es Leute die auch daran Spaß haben, noch ein Grund warum ich github genial finde.
Unfassbar schrieb: > Testsoftware, Blödsinn. > Versionsverwaltung auch blödsinn. In den Firmen wo ich bisher gearbeitet habe, würdest du nach so einer Äußerung zum persönlich Gespräch geladen werden. Wenn du dabei bleibst: Kündigung. Unfassbar schrieb: > Auch in Quellcode unter 10.000 Zeilen kann eine Menge arbeit drin > stecken. Das merkt man dann, wenn man das erste mal aus versehen diesen > löscht, was mir anfangs einmal passiert ist. Mensch habe ich mich > geärgert. Den Fehler hätte TestSoftware frühzeitig gemeldet und mit Hilfe der Versionsverwaltung hättest du genau nachvollziehen (und reverten) können, was verändert wurde. Johannes S. schrieb: > Trotzdem wird man, wenn man sich z.B. > in git eingearbeitet hat, nicht mehr ohne diese Hosenträger arbeiten > wollen. Für Einzelkämpfer empfehle ich Subversion anstelle von GIT, weil man da ein paar Bedienschritte weniger hat. Subversion geht auch ohne Server, wenn man möchte.
Stefan ⛄ F. schrieb: > In den Firmen wo ich bisher gearbeitet habe, würdest du nach so einer > Äußerung zum persönlich Gespräch geladen werden. Wenn du dabei bleibst: > Kündigung. Wenn das bei einem 20 Zeilen Programm gefordert wird - dann kündige ich gerne. Man muss die Verhältnismäßigkeit bewahren. Aber ja, vermutlich waren deine Firmen im ISO9001 Sumpf versunken und es wären wirklich Dokumentation + Testfälle erforderlich gewesen... Stefan ⛄ F. schrieb: > Den Fehler hätte TestSoftware frühzeitig gemeldet und mit Hilfe der > Versionsverwaltung hättest du genau nachvollziehen (und reverten) > können, was verändert wurde. Nein. Ich habe aus Versehen in eclipse ein Projekt in einem bereits bestehenden eclipse Projekt erstellt. Das habe ich dann wieder gelöscht, dabei hat eclipse aber ALLES unwideruflich entfernt, ohne es in den Windoof Papierkorb zu packen. Es hat also auch das andere rojekt als Projektdateien betrachtet und vernichtet. Selbst ein .git Ordner wäre dann vernichtet worden. Auch recuva etc. konnte nichts retten. Aber wie gesagt, das war ein Anfängerfehler damals...
Stefan ⛄ F. schrieb: > Wenn du dabei bleibst: > Kündigung. Achja, eine Kündigung wäre hier natürlich unwirksam.
Unfassbar schrieb: > Aber ja, vermutlich > waren deine Firmen im ISO9001 Sumpf versunken und es wären wirklich > Dokumentation + Testfälle erforderlich gewesen... Ohne diesen "Sumpf" dürften wir nicht Daten von Personalausweisen, Biometrische Informationen und Finanz-Transaktionen verarbeiten. Und das ist gut so, ein gewisses Maß an Vorgaben muss sein, auch wenn diese ab und zu mal übertrieben erscheinen. Die Daten-Lecks, die in den letzten 12 Monaten durch die Medien gingen, zeigen die Notwendigkeit allzu deutlich.
Unfassbar schrieb: > Selbst ein .git Ordner wäre dann vernichtet worden. Nein, wäre er nicht. Wenn du damit richtig arbeitest, liegt das Source Repository ganz woanders. > Achja, eine Kündigung wäre hier natürlich unwirksam. Ein Arbeitgeber kann seine Angestellten kündigen, wann es ihm beliebt. Innerhalb der Probezeit sogar fristlos. Und wenn du nicht tust, was dein Chef von Dir verlangt, dann auch fristlos. Daran kannst du mit deiner arroganten Einstellung nichts ändern.
Stefan ⛄ F. schrieb: > Ein Arbeitgeber kann seine Angestellten kündigen, wann es ihm beliebt. Nur bei Winz-Buden mit weniger als 10 Beschäftigten. Bei allem was größer ist, greifen mehr und mehr die Zügelungen des reinen Kapitalismus in Form des staatlich verordnete Abeitsrechts und darin inbegriffen die Mitbestimmungsrechte der "Arbeitnehmer". (Euphemismus: eigentlich sind die das, die die Arbeit geben, der "Arbeitgeber" krallt nur die Erträge der Arbeit ein und gibt denen, die dieses Arbeit leisten, ein wenig davon ab, wenn er halbwegs clever ist, nicht zu wenig...)
c-hater schrieb: > und darin inbegriffen die > Mitbestimmungsrechte der "Arbeitnehmer". Mitbestimmungsrechte? Das geht in etwas so: Ein erfahrenes Team bekommt recht schnell mit, ob ein Neuling kompatibel ist, bzw. sein können wird. Der Arbeitgeber wird, im eigenen Interesse, der Teamempfehlung folgen.
Stefan ⛄ F. schrieb: > Ohne diesen "Sumpf" dürften wir nicht Daten von Personalausweisen, > Biometrische Informationen und Finanz-Transaktionen verarbeiten. Und das > ist gut so, ein gewisses Maß an Vorgaben muss sein, auch wenn diese ab > und zu mal übertrieben erscheinen. Ja, aber häufig holen sich vor allem Klitschen dieses "Ziertifikat", um gut organisiert zu wirken. Und weil andere Firmen es verlangen. Dabei ist die Realität dann aber, dass zwei Wochen vorm Audit alle Mitarbeiter etwas geschult werden und danach wieder alles aus dieser Zertifizierung ignoriert wird. Stefan ⛄ F. schrieb: > Nein, wäre er nicht. Wenn du damit richtig arbeitest, liegt das Source > Repository ganz woanders. Soll ich mir jetzt einen Server hinstellen oder meine gits irgendwo im Internet hochladen? Ich habe ja nie behauptet, dass ich richtig mit git umgehe ;). Aber privat habe ich tatsächlich keinen Server, so ein Nerd bin ich nicht. Einmal pro Woche Backup reicht aus (samt allen Git Repos im Umkehrschluss). Stefan ⛄ F. schrieb: > Ein Arbeitgeber kann seine Angestellten kündigen, wann es ihm beliebt. Woah, gewagte These.
Arduino Fanboy D. schrieb: > Ein erfahrenes Team bekommt recht schnell mit, ob ein Neuling kompatibel > ist, bzw. sein können wird. Das ist dann in der Probezeit. Aber danach kannst du nicht mal eben so jemand kündigen... da musst du größere Geschütze aufziehen.
Stefan ⛄ F. schrieb: > In den Firmen wo ich bisher gearbeitet habe, würdest du nach so einer > Äußerung zum persönlich Gespräch geladen werden. Wenn du dabei bleibst: > Kündigung. Wenn er in einer Firma in diesem Bereich arbeiten würde, würde er sich nicht zu so einer Aussage hinreissen lassen sondern wüsste um die unschätzbaren Vorteile dieser Werkzeuge eines Entwicklers ;)
Arduino Fanboy D. schrieb: > Mitbestimmungsrechte? > > Das geht in etwas so: > Ein erfahrenes Team bekommt recht schnell mit, ob ein Neuling kompatibel > ist, bzw. sein können wird. Ja. Das sollte dann aber in der Probezeit passieren, denn genau dafür ist die da. Danach wird's schwierig. Und das ist gut so!
Gerhard O. schrieb: > Im Prinzip läßt sich mit allen uC viel machen sobald den Feind kennt. Moin Gerhard! So ist es. Alle springen auf Cortex, aber wozu? Sicher brauchen nur die wenigsten diese Leistung. In irgendeinem Forum las ich über Roboter auf ATtiny85 Basis. Ich persönlich finde es viel spannender zunächst alles aus einem Controller raus zu holen und dann evtl. mehrere kleine Controller als System zusammen arbeiten zu lassen. Vielleicht sogar mit einem eigenes entwickelten Datenaustausch. Das hatte ich schon einmal vor und vielleicht spielt mein Kopf doch wieder irgendwann komplett mit. Dann würde ich so etwas einmal versuchen. Aus 1000 PS 100 PS zu nutzen ist leicht, aus einem PS gefühlte 5 PS zu machen (früher beim Frisieren war das so; mein Mokick lief 100 km/h), macht für mich den größeren Reiz aus.
F. F. schrieb: > evtl. mehrere kleine Controller als > System zusammen arbeiten zu lassen. Vielleicht sogar mit einem eigenes > entwickelten Datenaustausch. Das ist aber eine Fehlerquelle zusätzlich. Ein ARM M4 kostet genausoviel wie ein Xmega oder Atmega. Da stellt sich mir die Frage nicht mehr, was ich nutze..
F. F. schrieb: > So ist es. Alle springen auf Cortex, aber wozu? > Sicher brauchen nur die wenigsten diese Leistung. Doch, sie brauchen die, um ihre programmiererische Unfähigkeit aufzufangen. Mit genug Hardwarepower kann man fast jede Inkompetenz wegretuschieren... > Ich persönlich finde es viel spannender zunächst alles aus einem > Controller raus zu holen Privat habe ich da auch sehr viel Spaß dran. Kommerziell funktioniert das aber nicht. Leistungsfähige Hardware ist einfach viel zu billig geworden. Und gute Programmierer wachsen halt nicht auf Bäumen... Naja, dadurch gibt allerdings auch genug C&P-ler, die auch diese Hardware mit ihrer Inkompetenz zum Ächzen bringen. Es ist ein Geschäftsfeld meines Brötchengebers, solche aus dem Ruder gelaufene Projekte doch noch zu retten. Das darf ich dann tun. Und ich finde das richtig geil. Da gibt es immer sehr viel zu lachen... Darf ich meinem Cheffe natürlich nicht verraten. Sonst kommt der auf die Idee, dass er mir kein Gehalt zahlen müsste, sondern im Gegenteil Eintrittsgeld oder sowas fordert, weil ich ja so viel Spaß an der Arbeit habe...
Ja klar, im Geschäftsleben gelten andere Regeln. Ich meinte natürlich nur den privaten Bereich. Und zum Display, den absoluten Blödsinn in dieser Richtung habe ich bei einer Taschenlampe (hier im Forum) gesehen. Für mich ist eine perfekte Lösung die, die ich nicht sehe und sogar nach einiger Zeit vordergründig vergesse, weil alles klaglos und so gut seine Arbeit verrichtet, dass mir auch keine Verbesserung einfällt.
Unfassbar schrieb: > Soll ich mir jetzt einen Server hinstellen oder meine gits irgendwo im > Internet hochladen Wie gesagt geht das mindestens bei SVN auch ohne Server. Ein Verzeichnis irgendwo auf irgendeinem Speichermedium genügt.
F. F. schrieb: > Ich persönlich finde es viel spannender zunächst alles aus einem > Controller raus zu holen und dann evtl. mehrere kleine Controller als > System zusammen arbeiten zu lassen. Du bindest dir lieber freiwillig einen Klotz ans Bein? Früher hat man so etwas gemacht weils da einfach ein Leistung fehlte aber heute wo es Leistung ohne Ende gibt, warum sollte man einen µC benutzen, der kaum mit kommt wenn es zum gleichen Preis, ja nicht selten sogar noch preiswerter, deutlich potentere µCs gibt?
c-hater schrieb: > Tests hingegen... Naja. Viel Aufwand, relativ wenig Nutzen. So meine > Meinung. Das Blöde bei Tests ist: es wird immer nur das getestet, woran > der Programmierer gedacht hat. Endlich mal einer der das genauso sieht wie ich - speziell das nach dem Doppelpunkt. Leider glauben nach wie vor viele das nach einen erfolgreichen Testlauf alles in Ordnung ist. Leider ist dem nicht so, wenn ich mit meinen Testfällen die Realität nicht korrekt abbilde. Die Crux dabei ist, wenn ich die Realtät nicht richtig kenne kann ich sie auch nicht abbilden. Merke ich gerade beruflich - da will einer meine Software neu implementieren und frickelt da seit 6 Jahren dran rum. Die Tests laufen halt durch, dennoch ist Software an vielen Stellen nicht praxistauglich.
Zeno schrieb: > und frickelt da seit 6 Jahren dran rum Seit 6 Jahren? Da wäre ich schon lange in der Irrenanstalt gelandet..
Zeno schrieb: > Merke ich gerade beruflich - da will einer meine > Software neu implementieren und frickelt da seit 6 Jahren dran rum. Seit 6 Jahren? Hochschulbereich? In der freien Wirtschaft kann man sich das doch nicht erlauben 6 Jahre an einer Neuimplementierung rumzufrickeln. Und ja, Test durchzuführen, die nicht die Realität abbilden, sind ziemlich sinnbefreit.
Unfassbar schrieb: > Seit 6 Jahren? Da wäre ich schon lange in der Irrenanstalt gelandet.. Ach der darf meinetwegen auch noch länger daran rum frickeln, wenn man ihn läßt. Man hat ihm jetzt noch einen an die Seite gestellt. Das Problem hierbei der hat noch weniger Ahnung davon worum es geht und was Ende herauskommen sollte. Fairerweise muß man sagen programmieren können beide, wahrscheinlich sogar besser als ich, aber sie haben halt keinerlei Ahnung von dem was sie programmieren sollen.
M. K. schrieb: > In der freien Wirtschaft kann man sich > das doch nicht erlauben 6 Jahre an einer Neuimplementierung > rumzufrickeln. Doch kann man - sehe ich ja gerade. Man muß sich nur entsprechend verkaufen. Ist in größeren Konzernen auch kein Problem.
Zeno schrieb: > Doch kann man - sehe ich ja gerade. Man muß sich nur entsprechend > verkaufen. Ist in größeren Konzernen auch kein Problem. Ist dann aber doch sicher ne wesentlich größere Sache. Ansonsten könnte ich mir das bei weitem nicht vorstellen. Ich bin nur beim Mittelstand aber bei uns, rund 1000 Mitarbeiter, wäre das ein absolutes NoGo an einer Neuimplementierung 6 Jahre lang dran rumzufrickeln.
Mahlzeit miteinander! Ich habe gestern schonmal ein wenig mit dem Nucleo 103RB rumgespielt, leider komme ich schon bei den ersten Schritten nicht wirklich weiter. Das Programm lässt sich auf den µC spielen (Download verified successfully) , aber wenn ich zur Debug perspetive wechsle und Resume (F8) drücke, kann er sich scheinbar nicht verbinden. Target is not responding... (10 mal ca) Target is not responding, retrying... Error! Failed to read target status Debugger connection lost. Shutting down... Hatte das schonmal jemand so? Der ST-Link kann sich ja scheinbar verbinden, sonst würde er das Programm ja nicht drauf gespielt kriegen, also kann ich das ganze nicht so wirklich nachvollziehen.
Hast du im Programm die Pin Config von PA13/PA14 verändert? Das sind die Pins der SWD (Debug) Schnittstelle und wenn du die umkonfgurierst, dann is aus mit Verbinden bis zum Reset.
Angehängte Dateien:
-
Unbenannt.PNG
24 KB
Danke für die Antwort! Das Pinout von PA13/14 habe ich nicht geändert. Leider habe ich keinen Schimmer woran das liegen könnte.
M. K. schrieb: > Ist dann aber doch sicher ne wesentlich größere Sache. Ach, wenn man's durch die Mitarbeiterzahl dividiert, sieht es garnicht so schlimm aus ..hehehe ;-) Ich kenne das auch, daß der Chef Leute rausgeworfen hatte, nachdem sie ihn mehr als 2 Jahre lang Geld gekostet hatten und kein Ergebnis rumkam. Und das in einer weitaus kleineren Firma als bei deinen rund 1000 MA. Versuche mal, dir vorzustellen, wie sowas bei Firmengrößen unter 30 MA aussieht. Aber Fälle solcher Art gibt's immer wieder und offenbar überall. Allerdings sehe ich es durchaus, daß Backpfeifen es in größeren Unternehmen leichter haben, sich durchzumogeln, als in kleineren Firmen. Dort gibt es nämlich weniger Leute, auf die man die Schuld abwälzen kann und die Gesamt-Rückkopplung (Entwickeln->Fertigen->Verkaufen->Gehaltszahlung) ist weitaus kürzer und direkter. und hier schreibt so ein Überflieger zum Thema USB: Unfassbar schrieb: > Auch hier brauche ich keine Logs. Es gibt einen Punkt im Programmcode, > an dem der USB versagt. Breakpoints setzen, abfangen, Variableninhalte > anschauen und Schlüsse ziehen. Ggf. zweimal wiederholen und man hat den > Problemmacher identifiziert. Kopfschütteln meinerseits über solche Worte. Aber du Unfassbarer hast ja schon weiter oben mit "Bullshit" und dergleichen herumgeworfen. Aber vielleicht bist du ja der Superguru. Also schreib doch mal meinen USB-VCP-Treiber für die STM32F103xx oder dessen von anderen gemachte Version für die STM32F3xx um auf den STM32F105. Das sollte für so einen großartigen Kerl wie dich doch ein Klacks sein. Breakpoints setzen, abfangen, zweimal wiederholen - und der Rest des Forums wird dir DANKBAR sein für einen weiteren gut benutzbaren USB-VCP Treiber. Mach mal. W.S.
W.S. schrieb: > Also schreib doch mal meinen > USB-VCP-Treiber für die STM32F103xx oder dessen von anderen gemachte > Version für die STM32F3xx um auf den STM32F105. Du bist immer noch so lernresistent wie eh und je. Der F105 hat einen völlig anderen USB als der F103. Das habe ich dir in einem anderen Thread aber schon geschrieben! Für den USB OTG darf man den komplett neu schreiben.
Ghostrider1911 schrieb: > Leider habe ich keinen Schimmer woran das liegen könnte. Ja. Soviel zum Thema Debuggen. Du hat also einen ST-Link, über den du zwar (wie du annimmst) den Maschinencode in den µC hineinbekommst, aber den Debugger kriegst du trotzdem nicht gestartet. Unschöne Situation, gelle? Hast du einen Oszi? Wenn ja, dann schau dir damit die diversen Signale an: also Takt, Portpins usw. - vielleicht kann man dort ja etwa Wichtiges sehen. Ich würde an deiner Stelle zuerst mal den Systemtakt an ein Portpin herausführen. Bei den STM32 gibt es mE dafür das Signal MCO. Damit kannst du wenigstens sehen, ob du überhaupt einen Systemtakt hast. Oder vielleicht klebt dein µC in irgend einem Fault und kommt da trotz SWD nicht heraus? Vermutungen solcher Art gibt es zuhauf. Wenn garnichts geht, dann kommt leicht Panik auf - bis hin zu der Überlegung, ob man den Chip demoliert haben könnte... W.S.
Mw E. schrieb: > Für den USB OTG darf man den komplett neu schreiben. Exakt. Und genau DAS war mein obiger Vorschlag. Du solltest verstehendes lesen lernen, mein Lieber. Einen Vorteil hat das Ganze: Es reicht aus, ein Manual zu lesen und nicht zwei lesen zu müssen. Sollte dir entgegen kommen. W.S.
Ghostrider1911 schrieb: > Der ST-Link kann sich ja scheinbar verbinden, sonst würde er das > Programm ja nicht drauf gespielt kriegen, also kann ich das ganze nicht > so wirklich nachvollziehen. Eventuell ist die STLink Firmware veraltet, hast du mal ein Update im STUtility probiert?
W.S. schrieb: > Exakt. > Und genau DAS war mein obiger Vorschlag. > Du solltest verstehendes lesen lernen, mein Lieber. Ich hab dich schon verstanden. Du willst ihm was schwereres aufzwingen als du geschafft hast.
@Johannes S. Ja ein Update der Firmware habe ich bereits gemacht, das war laut der CubeIDE auch notwendig. Dennoch tut sich jetzt nicht mehr als vorher. Gibt es irgendwelche wichtigen Einstellungen die ich noch machen muss?
Ghostrider1911 schrieb: > Danke für die Antwort! Das Pinout von PA13/14 habe ich nicht geändert. Cube MX deaktiviert SWD standardmäßig. Für den Anfang würde ich empfehlen, auf Cube MX und HAL zu verzichten, um die Hardware und das Referenzhandbuch besser kennen zu lernen. Danach wird es Dir sehr viel leichter fallen, die HAL richtig zu benutzen. Wir vertiefen dieses Thema besser in einem neuen Thread, dann müssen wir uns nicht ständig unter den Hitzköpfen weg ducken.
Ich konnte mich nicht mal dazu durchdringen HAL zu lernen. Immer wieder mal angeschaut und jedes mal einfach nur den Kopf geschüttelt. Viel zu komplex, viel zu wenig Lernmaterial bzw. Lernmaterial dass sich an Experten richtet. Und dann soll man damit rechnen dass das Zeug in paar Jahren durch eine andere lib ersetzt werden kann. Boa ne... wenn man nicht gezwungen ist bloß weg damit :D Man sollte das wirklich nicht unterschätzen, es kostet recht viel Lebenszeit sich in diesen Zeug einzuarbeiten. Und es kann in paar Jahren auch schon im Müll landen. Und ich glaube das machen nur wenige Menschen aus Spaß und Hobby. Wer so was annehmbar findet der hat schon eine Grundlage von Jahren sich erarbeitet. Das ist meiner Meinung nach nichts für den typischen Arduino Entwickler.
Danke an Stefan frings für den Tipp das man zuerst das Debuggen aktivieren muss! Für alle hier die das durch google finden: Ihr müsste in der STM32CubeMX ansicht (in der .ioc Datei im Project Explorer) unter Pinout & Configuration bei System Core unter SYS , Debug auf Serial Wire umstellen, dann klappt das! Für mich ein absolutes Rätsel warum das nicht standartmäßig auf den Wert gestellt ist, vorallem weil in den Tutorials die ich bis jetzt gelesen habe, das nie in einem Wort erwähnt wird. (Ich habe ein neues Projekt erstellt und da direkt das Nucleo Board ausgewählt) Naja, Einsteigerfreundlich ist das ganze überhaupt nicht, soviel hab ich schon gemerkt mittlerweile. Ich hoffe nur das wird besser wenn ich mich ein bisschen damit beschäftigt habe. Ob ich das HAL nun nutzen werde oder nicht? Puh, die Meinungen diesbezüglich sind ja sehr verschieden. Muss ich mir noch genauer anschauen. Für den Anfang werde ich mich durch ein paar Tutorials hangeln. Was ich auch probiert habe: So flashen wie Stefan Frings in seiner Anleitung "Einblick in die moderne Elektronik ohne viel Theorie" geschrieben hat, sprich über Serial. Aber das ist so umständlich und dauert ewig, da finde ich im Vergleich das Programmieren über ISP bei den 8bit Atmel Controllern, oder auch den Arduino Bootloader über UART wesentlich besser. So kommt für mich eigentlich nur flashen und debuggen per ST-Link in Frage, oder eventuell auch J-Link (später). Aber das ist denke ich für den Anfang egal. Ich denke die jenigen die hier schreiben "Das ist nix für Arduino Bastler" haben warscheinlich Recht, dennoch werde ich das ganze jetzt nicht so schnell wieder verwerfen und mich trotzdem damit beschäftigen.
Ghostrider1911 schrieb: > Für mich ein absolutes Rätsel warum das nicht standartmäßig auf den Wert > gestellt ist In Hardware nach dem Reset ist der SWD auch aktiv. Das ist in den Defaultwerten der PORTA GPIO Register so vorgesehen. Also die HAL (der vom MX erzeugte Code) schaltet das dann aktiv aus. Da warten bei der HAL noch mehr solche Fallstricke ;) Daher stimme ich da stefans Vorschlag voll zu. Er hat da auch auf seiner Webseite viel dazu geschrieben: http://stefanfrings.de/stm32/ Aber die haste ja eh schon gefunden ;) Den CubeMX kannste dazu nutzen um zu gucken welche Peripherie an welchen Pins rausguckt. Denn da gibts durchaus mehrere Möglichkeiten. Wenn Fragen aufkommen zur Peripherie auf Registerebene biste bei mir richtig. Mit einem UART und Hello World kannste ja mal anfangen und dann gehts weiter. Erst Polling, dann IRQ und wenn du willst DMA.
Ghostrider1911 schrieb: > Naja, Einsteigerfreundlich ist das ganze überhaupt nicht, soviel hab ich > schon gemerkt mittlerweile. Na immerhin ;) Man muss das auch nicht direkt in der .ioc abändern, sondern kann das direkt im Pinout konfigurieren. Was die Programmierer von ST sich dabei gedacht haben weiß kein Mensch. Ich schließe mich daher Stefan und fritzler an und schlage vor, erstmal ohne HAL einzusteigen. Grundsätzlich würde ich einem Einsteiger ein F072-Nucleo empfehlen und dann dazu dieses Tutorial (was auch auf Stefans Seite verlinkt ist): http://www.pomad.fr/node/5 Wenn du das Schritt für Schritt durcharbeitest (und nebenbei immer wieder mal ins Reference Manual schaust), weißt du nachher schon ziemlich gut über die STM32 Bescheid. Für die F0- und die L0-Serie gibt es direkt von ST auch die sogenannten "Snippets". Das ist ordentlich kommentierter Beispielcode für die jeweilige Peripherie, der nur mit den Registern arbeitet. Wenn du jetzt keine Lust hast gleich das nächste Board zu bestellen und das F103 in die Ecke zu werfen, dann kannst du natürlich auch versuchen das Tutorial mit Hilfe des Refman mit dem F103 durchzuarbeiten aber da musst du dann halt aufpassen, weil sich die Peripherie des F103 in mancherlei Hinsicht eben doch vom F072 unterscheidet. Genauer gesagt ist die Peripherie der F0-Serie besser, weil neuer, d.h. alte Hardwarebugs wurden behoben (z.B. I2C beim F1). Wünsche dir wie auch immer viel Erfolg.
:
Bearbeitet durch User
W.S. schrieb: > Mach mal. Um dir irgendwas zu beweisen? Kein Interesse. Vielleicht, wenn ichs mal benötige.
Ghostrider1911 schrieb: > Ich denke die jenigen die hier schreiben "Das ist nix für Arduino > Bastler" haben warscheinlich Recht, dennoch werde ich das ganze jetzt > nicht so schnell wieder verwerfen und mich trotzdem damit beschäftigen Ich denke, das ist nicht verkehrt sich so etwas auch mal anzusehen. Diejenigen, die schreiben, dass das nix für Arduino-Baster ist, pauschalisieren mir ja zu viel, es kommt halt immer auf den Bastler an.
Guten Morgen miteinander! Scheinbar war es ein Irrglaube, das die HAL ähnlich zu den Libraries beim Arduino funktioniert und einiges erleichtert. Ich werde mir nun auch noch die Atollic True Studio IDE besorgen und nach dem Tutorial von PoMAD vorgehen. (Oder die STM32Cube ohne MX nutzen, was ja auch funktionieren sollte). Ich werds nun mal mit dem 103RB probieren, für Projekte würde ich schließlich auch gerne die F103 nutzen, weil die eben sehr günstig zu bekommen sind. (Blackpill z.B.)
Ghostrider1911 schrieb: > Guten Morgen miteinander! > > Scheinbar war es ein Irrglaube, das die HAL ähnlich zu den Libraries > beim Arduino funktioniert und einiges erleichtert. Natürlich erleichtern HAL (und auch StdPeriphLib) bestimmte Dinge. Nur das ganze mit Arduino zu vergleichen ist halt Unsinn. Es scheint Arduino Nutzer sind bereits zu verdorben um nochmal die Kurve hin zu irgendwas zu bekommen. > Ich werde mir nun auch noch die Atollic True Studio IDE besorgen und > nach dem Tutorial von PoMAD vorgehen. (Oder die STM32Cube ohne MX > nutzen, was ja auch funktionieren sollte). Als ob die IDE irgendwas damit zu tun hat.
Cyblord -. schrieb: > Es scheint Arduino Nutzer sind bereits zu verdorben um nochmal die Kurve > hin zu irgendwas zu bekommen. Sei doch nicht so hart! Manche brauchen einige Zeit (daher auch oft die teils so naiv anmutenden Kommentare) und anderen reicht es eben was sie damit erreichen können. So viele Menschen fahren Auto, aber außer Ölstand checken (nicht einmal das können alle) fahren sie eben nur. Hand hoch, wer schon mal eine Kopfdichtung an seinem Auto gemacht hat. Gut, mache ich auch nicht gerne, aber wenn es sein musste, dann schon. Beruflich habe ich das schon oft gemacht. Genau wie du "in den Eingeweiden des Controllers" rum gräbst. Es müssen doch nicht alle Profis werden. Und schön, dass sie überhaupt die Möglichkeiten haben, im gewissen Rahmen, mit Arduino ihre eigenen Projekte umzusetzen.
Unfassbar schrieb: > W.S. schrieb: >> Für ganz gewöhnliche Projekte braucht man fast immer keinen Debugger, >> sofern man systematisch planen und programmieren kann. > > Dann haben wir hier einen Überflieger der Kategorie "Ich mache keine > Fehler". Kannst stolz auf dich sein, jedoch machen 99% der anderen > Programmierer während der Umsetzung sogenannte Schusselfehler, die du > selbstverständlich nicht machst. Und auch ich mache diese, obwohl ich > gut plane (was ich zumindest von mir behaupte). Offensichtlich hast du noch nie von Unit Tests gehört. 70% der Schusselfehler werfen mir damit einen Fehler in der IDE, bevor ich das Programm einmal aufs Board laden musste. 25% werden über Datenlogs gefunden. Natürlich nicht über manuell interpretierte 2 Millionen Zeilen UART-Ausgabe, sondern logischerweise per Script aufgezeichnet und ausgewertet, über UART, USB oder Ethernet, was halt am Board verfügbar ist. Werte lassen sich dann auch toll als zeitlicher Verlauf darstellen (z.B. interessant für regelungstechnische Systeme). Für 5% muss tatsächlich der Debugger herhalten. das ist üblicherweise die Kategorie "Datenblatt falsch interpretiert". Aber manche glauben in ihrer Hybris halt, die Welt erfunden zu haben.
Beitrag #6130489 wurde von einem Moderator gelöscht.
Beitrag #6130499 wurde von einem Moderator gelöscht.
Beitrag #6130507 wurde von einem Moderator gelöscht.
Mw E. schrieb: > Du willst ihm was schwereres aufzwingen als du geschafft hast. Aufzwingen??? Nee. Hier wird niemand gezwungen. Aber wenn jemand meint, einen Chip verwenden zu wollen, für den es eben noch keinen Treiber von mir gibt, dann muß er eben sich selbst hinsetzen und es tun. Das ist die eigene Wahl desjenigen, der es haben will. Und ob das schwerer wird, einen OTG nur als Device verwenden zu wollen als ein reines Device, sei mal dahingestellt. Ich brauch's bislang nicht und hab mich deshalb auch nicht damit befaßt. W.S.
Beitrag #6130516 wurde von einem Moderator gelöscht.
Sicherlich werde ich einige Zeit brauchen um die Controller auch nur ansatzweise zu beherrschen, wenn es so einfach währe gäbe es keine Leute die das den ganzen Tag beruflich machen... Für mich wird es immer nur ein Hobby bleiben. Ausdauer ist schon eine meiner Stärken, daher bin ich da guter Dinge. Das die IDE an sich nichts mit HAL, PSL etc. zu tun hat ist mir schon bewusst. Dennoch werde ich einige IDE´s testen bevor ich mich festlege. Generell schadet es warscheinlich nicht die gleiche IDE wie im Tutorial zu nutzen. Auch wenn ich schon gemerkt habe das sich die IDE´s sehr ähneln, da sie alle auf Eclipse basieren ( zumindest die IDE´s für den STM32) Atmel Studio ist ja an Visual Studio angelehnt. Meiner Meinung nach sollten einige Leute hier eher auf privater Ebene diskutieren anstatt das hier öffentlich zu tun. Leider ist genau das der Grund warum man durch "googeln" nur sehr zäh an Informationen kommt, vorallem in Foren. In diesem Sinne einen schönen Tag! ;)
vn nn schrieb im Beitrag #6130516: > Meinst du nicht, ein konstruktives, themenbezogenes Posting wäre > sinnvoller als irgendwelche stumpfsinnigen, inhaltsleeren > Unterstellungen, weil du sonst nix beitragen kannst? Ich habe meine Meinung kund getan, reicht das nicht? Auch mit unitTests etc. kannst du nicht alles abfangen und simulieren und am Ende musst du einfach mal reinschauen - wie du schon geschrieben hast meinetwegen nur in 5% der Fälle - mit dem Debugger. Aber zu behaupten, dass man für ganz gewöhnliche Projekte keinen Hardwaredebugger benötigt stimmt einfach nicht. Stattdessen wird dazu geraten, sich riesige Datenmengen über eine Uart augeben zu lassen facepalm. Noch mehr Retro geht kaum. Während er dann noch seine Debugausgabe programmiert, habe ich den Fehler schopn gefunden und beseitigt. W.S. schrieb: > Für ganz gewöhnliche Projekte braucht man fast immer keinen Debugger, > sofern man systematisch planen und programmieren kann.
Unfassbar schrieb: > Ich habe meine Meinung kund getan, reicht das nicht? Nein, das ändert nämlich nix daran, dass du den Thread mit deinen billigen Unterstellungen (die du dann ja ohnehin nicht näher ausführen kannst) zumüllst. Unfassbar schrieb: > uch mit unitTests > etc. kannst du nicht alles abfangen und simulieren und am Ende musst du > einfach mal reinschauen - wie du schon geschrieben hast meinetwegen nur > in 5% der Fälle - mit dem Debugger. Eh. Und nu? Unfassbar schrieb: > Aber zu behaupten, dass man für ganz gewöhnliche Projekte keinen > Hardwaredebugger benötigt stimmt einfach nicht. Für 99% der eher simplen Hobbyprojekte stimmt es definitiv. Aber du kannst sicher Beispiele für die unmengen an Fehlern aufzählen, die man nur als Hobbyist findet. Abgesehen davon hat er geschrieben "fast nicht". Aber du unterstellst halt gern Dinge, was? Unfassbar schrieb: > Stattdessen wird dazu > geraten, sich riesige Datenmengen über eine Uart augeben zu lassen > facepalm. Noch mehr Retro geht kaum. Während er dann noch seine > Debugausgabe programmiert, habe ich den Fehler schopn gefunden und > beseitigt. Während du noch verzweifelt durchstepst, hat jeder andere schon 5 Unittests geschrieben. Allein in der Zeit, die das Binary in den Chip geladen wird, ist der Test schon durch. Und eine Debugausgabe ist nun wirklich kein Hexenwerk. Aber klar, wenn du für jede Lapalie den Debugger anwerfen musst, weil dir vernünftige Prozesse zum finden von Fehlern unbekannt sind... Tu der Welt einen Gefallen, und lass den Thread in Ruhe. Lad deinen Müll anderswo ab.
vn nn schrieb: > die man nur als Hobbyist findet. Die man nur per Debugger findet, soll das natürlich heißen.
Ghostrider1911 schrieb: > Naja, Einsteigerfreundlich ist das ganze überhaupt nicht, soviel hab ich > schon gemerkt mittlerweile. Ich hoffe nur das wird besser wenn ich mich > ein bisschen damit beschäftigt habe. Das alles hängt sehr davon ab, mit was für einer Erwartung du dich einem Verwenden von Mikrocontrollern ohne Arduino zuwendest. Obendrein hängt es auch von deinen Vorkenntnissen und Fertigkeiten ab. Im Grunde hast du die Entscheidung zwischen zwei Wegen: a) wie Arduino, wo du also eine vorgefertigte Infrastruktur benutzen willst, dabei aber dann eben beschränkt bist auf das, was du an Infrastruktur vorfindest. b) deinen eigenen Weg gehen, den du dir aber selbst bahnen mußt. Dabei bist du dann nicht beschränkt auf irgend etwas Vorgefertigtes, aber es macht am Anfang eben ein wenig mehr Mühe. Später dann nicht mehr, da hat man dann sowohl Erfahrungen als auch einen Sack voll eigener Software, die (wenn man's richtig gemacht hat) zu großen Teilen plattformunabhängig ist und einem das Anwerfen eines neuen Chips gar sehr erleichtert. W.S.
Beitrag #6130589 wurde von einem Moderator gelöscht.
Ghostrider1911 schrieb: > Scheinbar war es ein Irrglaube, das die HAL ähnlich zu den Libraries > beim Arduino funktioniert und einiges erleichtert. Aus meiner Sicht vereinfacht die HAL nicht viel mehr als die Taktkonfiguration. Aber die kann man sich auch schnell aus einer Kopiervorlage ableiten. Die HAL macht aber richtig Sinn, wenn du den gleichen Stück Code auf unterschiedlichen STM Controller benutzen willst. Denn sie abstrahier die kleinen feinen Unterschiede soweit es geht. Das Arduino Framework ist einfacher, weil es die Anwendungsmöglichkeiten der Peripherie einschränkt. Weniger Flexibilität = weniger Doku = weniger Dinge die man missverstehen kann. Mit Arduino kannst du zum Beispiel keinen BLDC Motor ansteuern (jedenfalls nicht ohne Klimmzüge am Framework vorbei). Die Nutzung der HAL entbindet einen jedenfalls nicht davon, das Referenzhandbuch zu verstehen. Du hast dann also zwei dicke Bücher zu lesen: erst das Referenzhandbuch, dann die Doku zur HAL, denn die Doku der HAL baut darauf auf. Bei Arduino ist das anders, da hat man sich sehr darum bemüht, dass die Anwender meistens ausschließlich mit der Arduino Doku arbeiten können. Sogar einige Grundlagen von C/C++ sind dort erneut dokumentiert worden. Aber wenn es mal nicht wie erwartet klappt (z.B. 3,3V mit 20 MHz), dann kommt üblicherweise und zurecht die Antwort: RTFM.
Für den Anfang werde ich versuchen mich auf einen µC zu beschränken, und zwar den STM32F103RB (bzw. STM32F103C8) Ich denke den Controller kann ich nicht an seine Grenzen bringen, der dürfte weitaus reichen für meine Zwecke. Ausserdem gibt es aus China genügend Boards die diesen nutzen, was natürlich von Vorteil ist. Ich baue mir gerne immer kleine Testboards zum einfacheren Basteln. Ich denke das werde ich hier auch machen. Erstmal werde ich mich ein wenig durch die verschiedenen IDE´s probieren und schauen welche mir am besten zusagt. Danach werde ich ein paar Beispiele testen und dann nach der Anleitung anfangen zu basteln ;) Tatsächlich findet man viele Sachen in Google über die STM32, auf jedenfall viel mehr als über die SAMD Controller von Atmel. Ich sag hier mal danke an Stefan Frings der wie es mir scheint vielen STM32 Anfängern ein bisschen auf die Füße hilft. (Ich habe andere Beiträge hier von ihm gelesen)
Ghostrider1911 schrieb: > Ausserdem gibt es aus China genügend Boards die diesen nutzen, was > natürlich von Vorteil ist. Ich baue mir gerne immer kleine Testboards > zum einfacheren Basteln. Ich denke das werde ich hier auch machen. Ich nutze gerne STM32 im LQFP32 Gehäuse. Grund: Von Hand noch gut lötbar. Ich setze die Controller nämlich gerne auf eigenen Boards ein, die genau für die jeweilige Anwendung erstellt wurden. Mit Eval, Test oder sonstigen Boards kann ich nichts anfangen. Leider gibt es nicht gar so viele in diesem Gehäuse. Momentan setze ich da auf STM32F04 und F05. Zwar eine Kategorie unter den F1, aber für vieles ausreichend.
M. K. schrieb: > Ist dann aber doch sicher ne wesentlich größere Sache. Ansonsten könnte > ich mir das bei weitem nicht vorstellen. Ich bin nur beim Mittelstand > aber bei uns, rund 1000 Mitarbeiter, wäre das ein absolutes NoGo an > einer Neuimplementierung 6 Jahre lang dran rumzufrickeln. Naja es ist nicht trivial, aber wenn man sich mit der Problematik beschäftigt, dann ist es eigentlich nicht so schwer. Ich habe an dem Programm ca. 3 Mannjahre gearbeitet. Das komplette Programmpaket hat ca. 400000 Zeilen Code die ich geschrieben habe. Damit decke ich 100% der gegenwärtigen Anforderungen ab. Mein Vorteil ist halt das ich das Programm selbst anwende und daher weis was gebraucht wird. Mit anderen Worten ich weis genau worum es geht. Ich habe auch auf die User des Programms gehört und mich bemüht es so anwenderfreundlich zu gestalten. Das neue Programm hat nur ca. 15% der Funktionalitäten von meinem Programm und wird halt von den meisten Anwendern abgelehnt, weil die Bedienung nicht zu unserem Arbeitsworkflow passt. Mein Programm ist mit Delphi geschrieben, aber unsere Chefs sind halt der Meinung das es in C# sein müsse.
von Ghostrider1911 (Gast) 03.02.2020 10:16 >Guten Morgen miteinander! >Scheinbar war es ein Irrglaube, das die HAL ähnlich zu den Libraries >beim Arduino funktioniert und einiges erleichtert. >Ich werde mir nun auch noch die Atollic True Studio IDE besorgen und >nach dem Tutorial von PoMAD vorgehen. (Oder die STM32Cube ohne MX >nutzen, was ja auch funktionieren sollte). Wenn Du etwas Erfahrung mit STM32Cube gesammelt hast, kannst Du eventuell zum STM32 Repository beitragen: https://github.com/stm32duino/Arduino_Core_STM32 Die erste Schwierigkeit dürfte sein, das ganze Repository in STM-Cube zu importieren. Ich gehe davon aus, dass Frederik Pilon von STM, der die Entwicklung dort voran treibt mit STM-Cube entwickelt.
Ghostrider1911 schrieb: > Für den Anfang werde ich versuchen mich auf einen µC zu beschränken, und > zwar den STM32F103RB (bzw. STM32F103C8) > > Ich denke den Controller kann ich nicht an seine Grenzen bringen, der > dürfte weitaus reichen für meine Zwecke. Naja, das Schöne an den CM ist ja das die eine große Bandbreite abdecken. Wenn man Ethernet oder Grafik haben möchte ist der F103 nicht ideal, für ein paar € mehr gibts dann aber einen F407. Nochmal 5 € drauf für einen Ethernet PHY und 11 Dupont Strippen und du hast einen schnellen Ethernet Controller.
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.