Weg von Arduino - Beratung

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.

PlatformIO

> - Viel Flash für grafik Displays
kendryte k210 ?

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

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:
> 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.

Ü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!

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. <--

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.

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.

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

Unfassbar schrieb:
> Du bist halt ein Anfänger.

Ich stimme ihm zu. Ich programmiere beruflich seit 20 jahren.

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.

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.

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.

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:
> 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.

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.

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.

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.

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.

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.

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!

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..

Display ansteuern mit tiny Cluster? Nein Danke.

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...

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.

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..

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.

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.

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.

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?

@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.

W.S. schrieb:
> Mach mal.

Um dir irgendwas zu beweisen? Kein Interesse. Vielleicht, wenn ichs mal 
benötige.

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.)

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.

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.

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.

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)

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.