Hi, ich beschäftige mich seit ca. einem Jahr mit uC und frage mich welche Systeme die besten Aussichten für die Zukunft haben. Ich würde mich später gerne in dem Bereich selbstständig machen (oder zumindest arbeiten) und kleinere Anwendungen entwickeln. (Wunschvorstellung... mal gucken ob es klappt). Bisher habe ich hauptsächlich mit Atmel Studio i.V.m. 8 Bit Controllern gearbeitet. Am effektivsten ist es natürlich direkt mit der richtigen Hard- und Software zu arbeiten um später aufwendige Umstellungen zu vermeiden. 1. Welche IDE´s empfehlt ihr? Atmel Studio ist ja zum Beispiel nur für Atmel Controller. Ich würde mich aber gerne etwas breiter Aufstellen was die IDE angeht und mich nicht nur auf Atmel konzentrieren. Was ist zum Beispiel mit Eclipse? TrueStudio basiert ja zum Beispiel darauf. Gibt es dazu dann auch entsprechende Debugger die mit vielen uC zurecht kommen? 2. Macht es überhaupt noch Sinn mit kleine leistungsschwache 8bit Controllern zu arbeiten? Der Preisunterschied ist ja nicht mehr so groß. Ob mein Produkt später 4 EUR mehr kostet, weil ich einen 32 bit anstatt einen 16 oder 8 bit Controller verwendet habe, interessiert ja nicht wirklich. In dem Beitrag habe ich gelesen das manche Aufgaben mit 8 bit Controllern einfacher sind als mit 32 bit. Beitrag "Vorteile 32 Bit Controller" Das kann ich aber nicht wirklich nachvollziehen. Je mehr Rechenleistung ich habe um so einfacher wird das Ganze doch, oder? Vor allem bei Berechnungen. 3. Welche Hersteller für uC empfehlt ihr? Welche Hersteller bieten die meisten Tools an? Also mit welchem lässt sich am schnellsten und am besten arbeiten. Bei ST Controllern kann man zum Beispiel über CubeMx einfach die Register konfigurieren. Mir ist zumindest nicht bekannt das es sowas auch für Atmel Controller gibt. 4. Für welches System gibt es die besser Community? Auch im Hinblick auf Bibliotheken und Co. Vermutlich kann man bei keiner Frage direkt sagen das der eine oder der andere Hersteller besser ist, aber mich würde eure Meinung einfach interessieren. Vielen Dank!
Steffen schrieb: > Ich würde mich später gerne in dem Bereich selbstständig machen (oder > zumindest arbeiten) und kleinere Anwendungen entwickeln. > (Wunschvorstellung... mal gucken ob es klappt). Dann solltest du insbesondere eine gute Flexibilität an den Tag legen und dich eben nicht auf einen konkreten Controller „einschießen“. Erfolgreich wird man dadurch, dass man in der Lage ist, sich den Aufgaben zu stellen, die gerade anfallen. > 1. Welche IDE´s empfehlt ihr? Herstellerunabhängige IDEs sind natürlich prinzpiell von Vorteil, weil du keinen Vendor lock-in hast. Der Nachteil ist, dass du auf diesen oder jenen Komfort verzichten musst, den die Hersteller halt in ihre IDEs reinpacken. > Gibt es dazu dann auch entsprechende Debugger die mit vielen uC zurecht > kommen? GDB ist vermutlich der Debugger, der das breiteste Spektrum unterstützt. Ich habe bislang damit m88100 (kennt heute keiner mehr :), i386 ff., Atmel AVR und ARMs diverser Hersteller debuggt. > 2. Macht es überhaupt noch Sinn mit kleine leistungsschwache 8bit > Controllern zu arbeiten? Das hängt von deiner Aufgabe ab. Wenn es gar keinen Sinn mehr hätte, würde Microchip wohl kaum noch neue Produkte in diesem Bereich entwickeln – auch wenn diese sich mittlerweile doch in einigen Punkten vom Ursprung der AVRs entfernt haben (bspw. indem man den Flash in den normalen Adressraum gemappt hat). > Der Preisunterschied ist ja nicht mehr so groß. Der spielt ohnehin erst bei sehr großen Stückzahlen eine Rolle, und dann wiederum gibt es diverse Fernost-Produkte, die nochmal deutlich billiger sind als die großen gängigen Familien. > Das kann ich aber nicht wirklich nachvollziehen. Je mehr Rechenleistung > ich habe um so einfacher wird das Ganze doch, oder? Wenn deine Rechenleistung ohnehin überdimensioniert ist, spielt es keine Rolle, ob sie nun 10000fach überdimensioniert ist oder „nur“ 100fach. Dann können andere Kriterien interessant sein, bspw. wie schnell man aus dem Schlaf aufwachen kann, auf einen Interrupt reagieren, oder wie schnell das Projekt insgesamt zum Laufen gekommen ist. > 3. Welche Hersteller für uC empfehlt ihr? Den jeweils passenden. :-) > Welche Hersteller bieten die meisten Tools an? Quantität über Qualität? > Bei ST Controllern kann man zum Beispiel über CubeMx einfach die > Register konfigurieren. Mir ist zumindest nicht bekannt das es sowas > auch für Atmel Controller gibt. ASF, Atmel Start Ob man sowas aber wirklich dauerhaft haben will, da scheiden sich die Geister … mein Fall ist es jedenfalls nicht (also nicht nur Atmel, generell).
Steffen schrieb: > aber mich würde eure Meinung einfach > interessieren. Bei der Projektplanung sollte sich herausstellen, welchen Ressourcen Bedarf du hast. Danach wählt man den µC aus. Zusätzlich schlägt die natürliche Trägheit zu Buche, die einen verführt, bei einer µC Familie und einer IDE zu bleiben. Schlussendlich: Egal, worauf du dich jetzt fixierst.... Es ist sowieso (mit hoher Wahrscheinlichkeit) auf Dauer die falsche Wahl.
Die besten Aussichten haben die Arduinos, die an Heliumballonen in die Stratossphäre aufsteigen. Georg
Steffen schrieb: > Hi, > > ich beschäftige mich seit ca. einem Jahr mit uC und frage mich welche > Systeme die besten Aussichten für die Zukunft haben. > > Ich würde mich später gerne in dem Bereich selbstständig machen (oder > zumindest arbeiten) und kleinere Anwendungen entwickeln. > (Wunschvorstellung... mal gucken ob es klappt). Nicht gucken ob es klappt, machen! > Am effektivsten ist es natürlich direkt mit der richtigen Hard- und > Software zu arbeiten um später aufwendige Umstellungen zu vermeiden. Das dürfte nahezu nie klappen, dafür gibt es viel zuviele verschiedene Systeme und Ökosysteme > 2. Macht es überhaupt noch Sinn mit kleine leistungsschwache 8bit > Controllern zu arbeiten? > Alleine diese Frage wird jetzt wieder Popcornwürdig ausarten. Ich bin erklärter Gegner davon für jeden Fliegenschiß gleich einen ARM auszupacken, nur weil die Dinger mittlerweile nahezu nix kosten. > Der Preisunterschied ist ja nicht mehr so groß. Ob mein Produkt später 4 > EUR mehr kostet, weil ich einen 32 bit anstatt einen 16 oder 8 bit > Controller verwendet habe, interessiert ja nicht wirklich. DAS erklär mal dem Kunden bzw dem internen Controller. Beide werden da sicherlich GANZ anderer Meinung sein. Bei Volumenelektronik wird oftmals auch noch die letzte 5cent Diode eingespart... > > Das kann ich aber nicht wirklich nachvollziehen. Je mehr Rechenleistung > ich habe um so einfacher wird das Ganze doch, oder? Vor allem bei > Berechnungen. > Das ist wie mit Autos.. 450PS unterm Hintern zu haben bringt dir im Stadtverkehr null, außer mehr Sprit zu verbrauchen als alle anderen. > Vermutlich kann man bei keiner Frage direkt sagen das der eine oder der > andere Hersteller besser ist, Eben, es gibt zuviele und manche können manches besser als andere und bei vvielen ist es einfach nur Geschmacks-oder Preissache. > aber mich würde eure Meinung einfach > interessieren. Ich hoffe du bist auf den Krieg der gleich losbricht vorbereitet ;) Ich hol schonmal Popcorn.
Das Wort "leistungsschwach" ist großer Unsinn. Es gibt eine Aufgabe zu lösen, welche sich je nach Kenntnis des Entwicklers (der eine schafft auf nem Tiny das, was ein anderere nichtmal auf nem Mega32 hinbekommt) mit mehr oder weniger Rechenleistung lösen lässt. Jeder uC hat seine Spezialbereiche. Es gibt Low Power MCUs, welche idR. etwas weniger Rechenleistung haben, und andere, bei denen die Stromaufnahme egal ist. Ich denke, eine Einarbeitung in die ARM basierten Devices ist auf jeden Fall sinnvoll.
Das erinnert an die sich ständig wiederholende Frage: "Welches ist der beste/schnellste Mikrocontroller". Für einen Bastler ist das ja auch das Naheliegendste, aber auch das am Meisten vom eigenen Geschmack abhängige, Problem. Der Profi entscheidet nach den Bedürfnissen und weniger nach dem Geschmack. Also ganz einfach: Was wird gebraucht? Welche Rechenleistung, wie viele und welche Anschlüsse usw.? Erst wenn das entschieden ist, schaut man sich um, welcher Prozessor zu diesem Profil passt. Natürlich wird auch der Profi nachrechnen müssen wie sinnvoll das Einarbeiten in eine völlig neue Prozessorlinie ist. Aber spätestens wenn es aber um Stückzahlen oder größere (teurere) Mikrokontroller geht, wird der eigene Geschmack unter dem Tisch liegen.
Steffen schrieb: > Ich würde mich später gerne in dem Bereich selbstständig machen (oder > zumindest arbeiten) und kleinere Anwendungen entwickeln. > ... > Steffen schrieb: > 4. Für welches System gibt es die besser Community? > > Auch im Hinblick auf Bibliotheken und Co. ...na dann viel Spaß bei der rechtlichen Recherche zu den verschiedenen Lizenzmodellen. Alles andere ist grob fahrlässig und wird, bei Nichtbeachtung, recht teuer werden!
Steffen schrieb: > ich beschäftige mich seit ca. einem Jahr mit uC Also bist Du noch ein Anfänger. > Ich würde mich später gerne in dem Bereich selbstständig machen Dafür fehlt Dir noch einiges an konkreten Projekterfahrungen aus dem industrielen Umfeld. > Am effektivsten ist es natürlich direkt mit der richtigen Hard- und > Software zu arbeiten um später aufwendige Umstellungen zu vermeiden. Als kompletter Anfänger auf ein einzelnes Pferd zu setzen und dann davon auszugehen, bis zur Rente niemals mehr umsatteln zu müssen, ist nicht nur äußerst verbohrt und riskant, sondern ganz klar zum Scheitern verurteilt. > 1. Welche IDE´s empfehlt ihr? Die zum jeweiligen Projekt passende. Oder je nach Erfordernissen auch keine IDE, sondern ein sehr guter Editor (z.B. Ultraedit/UE Studio) und eine separate Build-Umgebung. > Was ist zum Beispiel mit Eclipse? TrueStudio basiert ja zum Beispiel > darauf. Es gibt mittlerweile Unmengen von Eclipse-basierten IDEs und sonstigen Anwendungen. Selbst Lotus Notes basiert(e) auf Eclipse. Wenn alles gut zusammenpasst, ist Eclipse gut. Aber wehe, man muss Anpassungen vornehmen, die nicht ins Konzept passen... Dann schießt man sich sehr schnell ins eigene Knie. > Gibt es dazu dann auch entsprechende Debugger die mit vielen uC zurecht > kommen? GDB, Lauterbach TRACE32. Für Low-Level-Debugging ist Lauterbach ganz klar die allererste Wahl. > 2. Macht es überhaupt noch Sinn mit kleine leistungsschwache 8bit > Controllern zu arbeiten? Ja. Das hängt vom Projekt ab. > Der Preisunterschied ist ja nicht mehr so groß. Ob mein Produkt später 4 > EUR mehr kostet, weil ich einen 32 bit anstatt einen 16 oder 8 bit > Controller verwendet habe, interessiert ja nicht wirklich. Da werden dir ggf. die Kaufleute Deines Kunden mit dem Arsch ins Gesicht springen. Bei der Auswahl geht es aber nicht nur um den Preis, sondern auch noch um sehr viele andere Aspekte aus den Bereichen Logistik, Qualität, Herstellbarkeit. > 3. Welche Hersteller für uC empfehlt ihr? Diejenigen, der die für das konkrete Projekt passenden Bauelemente anbietet. > Welche Hersteller bieten die meisten Tools an? Was interessiert die Anzahl an Tools? Nichts. > Also mit welchem lässt sich am schnellsten und am besten arbeiten. Das ist eine komplett andere Fragestellung! Was nützt es, die tollste Entwicklungsumgebung und die meisten Werkzeuge zu haben, wenn der Controller so wirklich überhaupt nicht zum Projekt passt? > 4. Für welches System gibt es die besser Community? > > Auch im Hinblick auf Bibliotheken und Co. Es nützt nichts, wenn es zwar Unmengen an tollen Bibliotheken gibt, diese aber z.B. aus rechtlichen Gründen nicht im konkreten Projekt eingesetzt werden können. Von einem selbstständigen Entwickler, der nicht nur als Programmierknecht beauftragt wird, wird häufig völlig zu recht erwartet, dass er den Kunden ganzheitlich bezüglich aller Aspekte (technisch, fertigungstechnisch, logistisch, juristisch) fachkundig beraten kann bzw. die Stellen aufzeigen kann, in denen ggf. noch Beratungsbedarf besteht. Dafür fehlt Dir derzeit komplett der Überblick. Diesen wirst Du nicht (nur) durch ein paar Fragen und Antworten in Internetforen erwerben. Suche dir also lieber einen ordentlichen Arbeitgeber, bei dem Du in so viele Bereiche hineinschnuppern kannst, dass du irgendwann den Überblick gewinnst. Die meisten Großunternehmen ermöglichen es einem üblicherweise nicht, sich fachübergreifend aufzuschlauen, sondern verlangen eher Scheuklappen und die Spezialisierung auf ein möglichst kleines Aufgabengebiet. Es ist zwar wichtig, auch solche Strukturen einmal kennengelernt zu haben, um deren Entscheidungsprozesse zu verstehen, aber auf technischer Ebene ist das eine Sackgasse.
Vielen Dank für eure Beiträge. Jörg W. schrieb: > Dann solltest du insbesondere eine gute Flexibilität an den Tag legen > und dich eben nicht auf einen konkreten Controller „einschießen“. Genau das ist mein Ziel. Jörg W. schrieb: > GDB ist vermutlich der Debugger, der das breiteste Spektrum unterstützt. > Ich habe bislang damit m88100 (kennt heute keiner mehr :), i386 ff., > Atmel AVR und ARMs diverser Hersteller debuggt. Vielen Dank! Teste ich aus :). Jörg W. schrieb: > Das hängt von deiner Aufgabe ab. > > Wenn es gar keinen Sinn mehr hätte, würde Microchip wohl kaum noch neue > Produkte in diesem Bereich entwickeln – auch wenn diese sich > mittlerweile doch in einigen Punkten vom Ursprung der AVRs entfernt > haben (bspw. indem man den Flash in den normalen Adressraum gemappt > hat). Genau das ist mir kurz nach dem Beitrag dann auch mal in den Sinn gekommen :D. Ich habe in der Zwischenzeit auch noch recherchiert und auch hier gute Artikel gefunden. Tatsächlich ist der Marktanteil von 8 Bit Controllern noch relativ groß. Das hätte ich so auch nicht erwartet. Natürlich verbrauchen 32 Bit mehr Saft und ist etwas teurer. Aber unabhängig davon: Welche Sachen kann ein 32Bit Controller sonst schlechter als ein 8 Bit Controller. Jörg W. schrieb: > Der spielt ohnehin erst bei sehr großen Stückzahlen eine Rolle, und dann > wiederum gibt es diverse Fernost-Produkte Genau so sehe ich das auch. Außerdem habe ich auch nicht vor in den nächsten 3 Jahren irgendwas auf den Markt zu bringen. So wie ich manche Beiträge verstanden habe wurde das ein wenig missverstanden. Jörg W. schrieb: > Dann können andere Kriterien interessant sein, bspw. wie schnell man aus > dem Schlaf aufwachen kann, auf einen Interrupt reagieren, oder wie > schnell das Projekt insgesamt zum Laufen gekommen ist. Genau solche Informationen interessieren mich. Wann ist der 32 Bit im Nachteil. Hat dafür vielleicht jemand ne gute Quelle? Jörg W. schrieb: >> 3. Welche Hersteller für uC empfehlt ihr? > > Den jeweils passenden. :-) Und was kann welcher Hersteller am besten? Gibt es dazu vielleicht auch gescheite Quellen? Der Artikel "Mikrocontroller-Vergleich" auf dieser Seite hier hat mich da leider nicht wirklich weitergebracht. Jörg W. schrieb: >> Welche Hersteller bieten die meisten Tools an? > > Quantität über Qualität? Damit meinte ich wie anwenderfreundlich die IDE ist. Also die Qualität der gesamten Tools. Jörg W. schrieb: > ASF, Atmel Start Oh das ist mir durch die Lappen gegangen. Danke! Arduino Fanboy D. schrieb: > Bei der Projektplanung sollte sich herausstellen, welchen Ressourcen > Bedarf du hast. Danach wählt man den µC aus. Genau das fällt einem Anfänger natürlich ziemlich schwer. Mit wenig Erfahrung kann man vorher nur schlecht voraussagen was man alles benötigt. georg schrieb: > Die besten Aussichten haben die Arduinos, die an Heliumballonen in die > Stratossphäre aufsteigen. Ich finde Arduino nicht so gut. Alleine das man nicht gescheit Debuggen kann finde ich ziemlich bescheiden. Als Anfänger sucht man sich da immer n Wolf. aso schrieb: > Ich hoffe du bist auf den Krieg der gleich losbricht vorbereitet ;) Ich > hol schonmal Popcorn. Ne war ich nicht :D. War schon erstaunt das es so viele Beiträge gab. Aber finde ich natürlich gut :). Random .. schrieb: > Jeder uC hat seine Spezialbereiche. Es gibt Low Power MCUs, welche idR. > etwas weniger Rechenleistung haben, und andere, bei denen die > Stromaufnahme egal ist. Die man als Anfänger nicht kennt. Oder zumindest ich nicht. Bis auf natürlich den Verbrauch. Random .. schrieb: > Ich denke, eine Einarbeitung in die ARM basierten Devices ist auf jeden > Fall sinnvoll. Genau das habe ich mir auch nach ein paar Stunden Recherche jetzt vorgenommen. Ich wollte mich erstmal in den STM32 einarbeiten. Gleichzeitig bekomme ich durch TrueStudio auch ein Einblick in Eclipse. HIER ABER AUCH GLEICH NOCH NE NEUE FRAGE: Brauche ich wirklich nur ein ST-Link und Truestudio um zu debuggen? Kann ich gar nicht richtig klauben wenn man bedenkt was Atmel für einen Debugger nimmt. Ein ST-Link kostet nur 20 EUR. Die Trace Funktion kann ich aber nur mit ST-Link und entsprechender Software nutzen oder ? https://www.mikrocontroller.net/articles/STM32#Trace_Funktionen Zumindest bei TrueStudio geht das nur in der Pro Version https://atollic.com/pricing/ 50c schrieb: > ...na dann viel Spaß bei der rechtlichen Recherche zu den verschiedenen > Lizenzmodellen. Alles andere ist grob fahrlässig und wird, bei > Nichtbeachtung, recht teuer werden! War nie meine Absicht irgendwas zu kopieren. Trotzdem sind Bibliotheken für Anfänger oft sehr hilfreich um einen Anreiz für die Umsetzung zu bekommen. MIT ANREIZ MEINE ICH NICHT KOPIEREN. Andreas S. schrieb: > Also bist Du noch ein Anfänger. Habe nie was anderes behauptet :). Andreas S. schrieb: >> Ich würde mich später gerne in dem Bereich selbstständig machen > > Dafür fehlt Dir noch einiges an konkreten Projekterfahrungen aus dem > industrielen Umfeld. Dessen bin ich mir bewusst. Deswegen ja auch später. Ist ja wie gesagt auch nur eine Wunschvorstellung. Andreas S. schrieb: > Als kompletter Anfänger auf ein einzelnes Pferd zu setzen und dann davon > auszugehen, bis zur Rente niemals mehr umsatteln zu müssen, ist nicht > nur äußerst verbohrt und riskant, sondern ganz klar zum Scheitern > verurteilt. Habe ich nie behauptet. Momentan reicht es mir schon wenn ich nicht auf dem Pferd sitzen das in die falsche Richtung läuft oder stehen bleibt. Andreas S. schrieb: >> 1. Welche IDE´s empfehlt ihr? > > Die zum jeweiligen Projekt passende. Oder je nach Erfordernissen auch > keine IDE, sondern ein sehr guter Editor (z.B. Ultraedit/UE Studio) und > eine separate Build-Umgebung. Danke :). Schaue ich mir mal an :). In welchem Fall hat ein guter Editor mit separater Build Umgebung denn Vorteile? Andreas S. schrieb: >> Was ist zum Beispiel mit Eclipse? TrueStudio basiert ja zum Beispiel >> darauf. > > Es gibt mittlerweile Unmengen von Eclipse-basierten IDEs und sonstigen > Anwendungen. Selbst Lotus Notes basiert(e) auf Eclipse. Wenn alles gut > zusammenpasst, ist Eclipse gut. Aber wehe, man muss Anpassungen > vornehmen, die nicht ins Konzept passen... Dann schießt man sich sehr > schnell ins eigene Knie. Was meinst du mit Anpassungen die nicht ins Konzept passen? Andreas S. schrieb: > Von einem selbstständigen Entwickler, der nicht nur als > Programmierknecht beauftragt wird, wird häufig völlig zu recht erwartet, > dass er den Kunden ganzheitlich bezüglich aller Aspekte (technisch, > fertigungstechnisch, logistisch, juristisch) fachkundig beraten kann > bzw. die Stellen aufzeigen kann, in denen ggf. noch Beratungsbedarf > besteht. Dafür fehlt Dir derzeit komplett der Überblick. Diesen wirst Du > nicht (nur) durch ein paar Fragen und Antworten in Internetforen > erwerben. Da stimme ich dir zu 100% zu. > Suche dir also lieber einen ordentlichen Arbeitgeber, bei dem > Du in so viele Bereiche hineinschnuppern kannst, dass du irgendwann den > Überblick gewinnst. Die meisten Großunternehmen ermöglichen es einem > üblicherweise nicht, sich fachübergreifend aufzuschlauen, sondern > verlangen eher Scheuklappen und die Spezialisierung auf ein möglichst > kleines Aufgabengebiet. Es ist zwar wichtig, auch solche Strukturen > einmal kennengelernt zu haben, um deren Entscheidungsprozesse zu > verstehen, aber auf technischer Ebene ist das eine Sackgasse. Genau das ist leider ein großes Problem. Solche Arbeitgeber sind sehr schwer zu finden. Jedes halbwegs große Unternehmen will einen zum Fachidioten, in einem bestimmten Bereich, erziehen. Das ist halt auch absolut nicht das was ich will. Ich bin mir auch noch gar nicht sicher bei welchen Unternehmen ich mich nach meinem Master bewerbe. Vielen Dank für eure Beiträge !!!!!!!!!
Steffen schrieb: >>> Welche Hersteller bieten die meisten Tools an? >> >> Quantität über Qualität? > > Damit meinte ich wie anwenderfreundlich die IDE ist. Versteif' dich nicht auf eine IDE eines Herstellers. Damit stellt sich die Frage gar nicht. > georg schrieb: >> Die besten Aussichten haben die Arduinos, die an Heliumballonen in die >> Stratossphäre aufsteigen. > > Ich finde Arduino nicht so gut. Auch wenn Georg keinen Smiley dran gemalt hat: das war'n Scherz. Irgendwas, was in der Stratosphäre herumfliegt, hat natürlich eine gute Aussicht, und danach hattest du gefragt … > Brauche ich wirklich nur ein ST-Link und Truestudio um zu debuggen? Du brauchst eigentlich nur einen FT2232 zum Debuggen – für alle Cortex-M, egal ob von ST, Atmel, NXP, … Ich habe auch schon mit einem Atmel-ICE einen STM32 debuggt (ICE lag gerade herum, außerdem gestaltete sich die Verkabelung einfacher). Andersrum könnte man sicher auch einen SAMxxx mit einem ST-Link debuggen. Beides geht natürlich nicht mit den Tools der jeweiligen Hersteller, aber siehe oben, wenn man sich nicht auf deren IDEs versteift, eröffnen sich mehr Möglichkeiten. > 50c schrieb: >> ...na dann viel Spaß bei der rechtlichen Recherche zu den verschiedenen >> Lizenzmodellen. Alles andere ist grob fahrlässig und wird, bei >> Nichtbeachtung, recht teuer werden! > > War nie meine Absicht irgendwas zu kopieren. Es fängt bei der Systembibliothek an. Selbstverständlich will keiner jedesmal das Fahrrad von Neuem erfinden, also benutzt man, wo es geht, fertige Bibliotheken. Aber man muss natürlich auf deren Lizenzmodelle achten. GPLed Libs möchte sicher kein Kunde in seinen Embedded-Produkten verwenden, BSD oder MIT oder Apache dagegen schon eher (die komplette newlib, die häufig bei Cortex-M benutzt wird, ist mit solchen Lizenzen versehen). > Danke :). Schaue ich mir mal an :). In welchem Fall hat ein guter Editor > mit separater Build Umgebung denn Vorteile? Für mich: ich muss mich nicht umgewöhnen, nur weil ich mal einen anderen Controller benutze. :)
Ein sehr guter Vergleich der Mikrocontroller ist z.B. hier zu finden: https://jaycarlson.net/microcontrollers/ In diesem Artikel werden auch Fragen geklärt wie Vorteile von 32bittern vs 8bitter und umgekehrt, verschiedene IDEs, Code Gen Tools etc. Meine Empfehlung zu den Mikrocontrollerfamilien (Achtung, könnte nicht objektiv sein) wäre einmal STM8 (die kleinen der Familie sind äußerst günstig für das, was sie können) und EFM8 (sehr schnell, sehr flexibel und manche haben eine Pin Matrix integriert).
Steffen schrieb: > ich beschäftige mich seit ca. einem Jahr mit uC und frage mich welche > Systeme die besten Aussichten für die Zukunft haben. Die Frage ist eigentlich, ob damit auch wirklich arbeiten willst. Nach meiner Erfahrung, sind die IDE's immer unhandlicher und aufgeblähter geworden, ein vernünftiger Editor wie boxer, emacs oder auch vim mit Schnittstellen zur Shell resp, scripten/Batches/Makefiles reicht völlig und läuft auch auf Uralt-Rechnern bestens. Man muss halt nur den Arsch in der Hose haben, das gegen die ganzen Horden von KlickiKacki Fan-trollen und "Mode-Püppchen" argumentativ durchzustehen und sich ein Wochenende Zeit nehmen das an die eigenen Vorlieben anzupassen. bspw: http://www.edm2.com/index.php/File:Boxerscr.gif
Ich kann gar nicht mehr aufzählen mit wievielen IDEs und Prozessoren ich schon gearbeitet habe. Ein Dutzend Programmiersprachen habe ich auch schon durch. Aber: kennt man eine IDE, kennt man auch die anderen. Letztendlich brauch ich nur den Hammer bei Eclipse, F5 bei VisualStudio, und das Ding compiliert. Die Prozessoren sind egal, mit C und C++ gehen alle. Assembler habe ich dieses Jahrtausend nicht mehr gemacht. Bibliotheken kommen und gehen. Einarbeiten schön und gut, aber in 3 Jahren hast du etwas komplett anderes. Wichtig ist, dass du schnell wechseln kannst. Du mußt dich schnell in das Wesentliche einarbeiten können. Und dann mit den vorhandenen Mitteln die Aufgabe erledigen. Bei der nächsten Aufgabe wird eh wieder alles ganz anders sein. Mach einfach IRGENDWAS. Spiele mit einer Architektur herum, dass du die Konzepte verstehst. Die Konzepte kannst du in 20 Jahren noch anwenden. Dann wird du aber einen anderen Arbeitgeber und eine andere IDE haben.
Steffen schrieb: > Natürlich verbrauchen 32 Bit mehr Saft und ist etwas teurer. Das ist keineswegs so natürlich und trifft vielfach auch überhaupt nicht zu. Bei rechenintensiven Anwendungen kommt es auf die benötigten Datentypen an. Eine 32*32 Bit²-Multiplikation, die ein aktueller 32 Bit-Controller ein sehr wenigen Taktzyklen erledigt, kosten auf einem 8 Bit-Controller - womöglich ohne Hardwaremultiplizierer - nicht nur wesentlich mehr Taktzyklen, sondern auch Energie. Bei ICs mit kleiner aktiver Chipfläche wird die Gesamtfläche hauptsächlich durch die Bonding-Pads und nicht die Transistorzahl bestimmt. Nur große Speicher kosten viel Fläche. Ein 32-Bit-Controller in einem modernen Halbleiterprozess (inkl. Packaging) ist ggf. viel billiger herzustellen als ein 8-Bit-Controller in einem älteren Prozess. > Genau solche Informationen interessieren mich. Wann ist der 32 Bit im > Nachteil. Hat dafür vielleicht jemand ne gute Quelle? Die wird es nicht geben. Man findet natürlich Unmengen an Publikationen, deren Kernaussage darin besteht, dass das Produkt X (Hardware, Software, Methode, ...) viel besser als alle anderen ist. > Und was kann welcher Hersteller am besten? Gibt es dazu vielleicht auch > gescheite Quellen? Das ändert sich mit jeder Bauelementegeneration. Außerdem hat in den letzten ca. zehn Jahren eine unglaubliche Konzentration auf dem Markt stattgefunden, d.h. die allermeisten Unternehmen sind nach außen hin verschwunden und existieren jetzt unter dem Deckmantel einiger weniger sehr großer Marken: Texas Instruments: Burr-Brown, National Semiconductor, Luminary Micro, usw. Analog Devices: Linear Technology, Precision Monolithics, usw. NXP: Philips, VLSI, Valvo, Signetics, usw. Vishay: sehr, sehr, sehr viele > Damit meinte ich wie anwenderfreundlich die IDE ist. Also die Qualität > der gesamten Tools. Das sind doch völlig unterschiedliche Aussagen! Was nützt einem die tollsten Klicki-Bunti-Oberfläche, die alle erdenklichen GUI-Preise und -Auszeichnungen gewinnen würde, wenn die darunter befindliche Toolchain komplette Kacke ist? Und so ist es leider ziemlich häufig. Je schicker die IDE, desto schlechter ist meist auch die Automatisierbarkeit, z.B. auf einem Buildserver für Regressionstests. > Ich finde Arduino nicht so gut. Alleine das man nicht gescheit Debuggen > kann finde ich ziemlich bescheiden. Als Anfänger sucht man sich da immer > n Wolf. Arduinos sind ganz normale AVR- und/oder ARM-Controller, die in C++ programmiert werden. Da hat man das gesamte Füllhorn an Debuggingmöglichkeiten. > Die man als Anfänger nicht kennt. Oder zumindest ich nicht. Bis auf > natürlich den Verbrauch. Dann lies Dir Fachartikel, Datenblätter, Projektbeschreibungen usw. durch. Und zwar immer wieder und immer wieder. > Brauche ich wirklich nur ein ST-Link und Truestudio um zu debuggen? Kann > ich gar nicht richtig klauben wenn man bedenkt was Atmel für einen > Debugger nimmt. Ein ST-Link kostet nur 20 EUR. Die Debugger von Atmel sind doch auch ziemlich günstig, d.h. maximal wenige hundert Euro. Das entspricht nur wenigen Stunden Arbeitszeit als Entwickler. Lauterbach TRACE32 ist "etwas" teurer, lohnt sich aber sehr schnell, weil es wie geschnitten Brot läuft und für jedes Zielsystem gleich aussieht. Die Oberfläche sieht zwar ziemlich nach 1990er Jahren aus, ist aber hochgradig effizient. > War nie meine Absicht irgendwas zu kopieren. Trotzdem sind Bibliotheken > für Anfänger oft sehr hilfreich um einen Anreiz für die Umsetzung zu > bekommen. MIT ANREIZ MEINE ICH NICHT KOPIEREN. Wie bitte? Als Programmierübung mag es zwar ganz nett sein, alle Bibliotheken selbst zu schreiben, aber ansonsten verwendet man natürlich fertige Bibliotheken, WENN sie für den ganz konkreten Fall geeignet sind. Die Tatsache, dass man sich eingehend mit den Lizenzbestimmungen befassen muss, bedeutet nicht zwangsweise den Ausschluss für kommerzielle Projekte. > Danke :). Schaue ich mir mal an :). In welchem Fall hat ein guter Editor > mit separater Build Umgebung denn Vorteile? Naja, spätestens dann, wenn während des Buildvorganges Schritte durchgeführt werden müssen, die nicht durch die IDE abgedeckt werden oder nur sehr mühsam oder fehlerträchtig möglich sind. Insbesondere wenn man ein Embedded-Linux-System von vorne bis hinten durchkompilieren und alle vor- und nachgelagerten Schritte automatisieren will, ist es nicht sinnvoll, dies aus einer IDE heraus zu machen. Und wenn man das ganze dann auch noch auf einen Buildserver (Jenkins o.ä.) auslagern will, muss man sich an dessen Anforderungen halten. Das verträgt sich nicht mit IDEs. > Was meinst du mit Anpassungen die nicht ins Konzept passen? Naja, eben Anpassungen, die nicht ins Konzept passen, siehe oben. > Genau das ist leider ein großes Problem. Solche Arbeitgeber sind sehr > schwer zu finden. Jedes halbwegs große Unternehmen will einen zum > Fachidioten, in einem bestimmten Bereich, erziehen. Das ist halt auch > absolut nicht das was ich will. Dann ist die Sache doch klar: suche dir einen Arbeitgeber, der eben kein halbwegs großes Unternehmen ist. Davon gibt es sehr viele. Aber "die heutige Jugend" ist einfach auf ein paar große Marken fixiert und übersieht den allergrößten Teil der Unternehmen. > Ich bin mir auch noch gar nicht sicher bei welchen Unternehmen ich mich > nach meinem Master bewerbe. Und im Zweifelsfall werden dann doch einfach wieder aus Verlegenheit die Bewerbungen an die angeblichen "Top-10-Arbeitgeber" verschickt... Man beachte, dass sich sehr viele der im Internet befindlichen Übersichten über die "Top-X-Arbeitgeber" nicht auf Bewertungen der Mitarbeiter beziehen, sondern auf die Erwartungen von Bewerbern, also Personen, die nur den Außenauftritt und das Markenimage kennen, aber dort noch nie gearbeitet haben.
Andreas S. schrieb: >> Was meinst du mit Anpassungen die nicht ins Konzept passen? > > Naja, eben Anpassungen, die nicht ins Konzept passen, siehe oben. Noch ein Nachtrag: Sobald ein Projekt mehrere Bauelemente enthält, für die Code aus einem Guss erstellt werden muss, gibt es Probleme, spätestens dann, wenn es sich z.B. um Microcontroller unterschiedlicher Hersteller handelt. Oder man muss die Codegenerierung aus irgendeinem CASE-Werkzeug in den eigenen Buildvorgang einbinden. Oder man hat Konfigurationsdateien, die nicht von der IDE unterstützt werden, aber wichtige Bestandteile für die Codegenerierung enthalten. Beispiele: CORBA, ASN.1, XML, SDL, TTCN, JSON.
Jörg W. schrieb: >> Ich finde Arduino nicht so gut. > > Auch wenn Georg keinen Smiley dran gemalt hat: das war'n Scherz. > Irgendwas, was in der Stratosphäre herumfliegt, hat natürlich eine gute > Aussicht, und danach hattest du gefragt … Jetzt stehe ich aber mal dumm da :D. Arduino erfährt ja schon ziemlich Aufwind. Deswegen hatte ich das missverstanden.... Jörg W. schrieb: > Es fängt bei der Systembibliothek an. > > Selbstverständlich will keiner jedesmal das Fahrrad von Neuem erfinden, > also benutzt man, wo es geht, fertige Bibliotheken. Aber man muss > natürlich auf deren Lizenzmodelle achten. GPLed Libs möchte sicher kein > Kunde in seinen Embedded-Produkten verwenden, BSD oder MIT oder Apache > dagegen schon eher (die komplette newlib, die häufig bei Cortex-M > benutzt wird, ist mit solchen Lizenzen versehen). Bezüglich Bibliotheken und Tools hab ich auch schon die nächste Frage. Ich habe mich mal ein bisschen bei ST umgesehen und da hat mich schon fast der schlag getroffen. Die haben ja eine riesige Menge an Bibliotheken und Tools. Beispielsweise sowas hier: https://www.st.com/content/st_com/en/stm32-graphic-user-interface.html Das sieht ja schon sehr vielversprechend aus und so wie ich das gesehen habe alles kostenlos. Wie sieht es hier dann zum Beispiel mit Lizenzen aus? Man wird das dann ja nicht einfach so auch kommerziell nutzen können oder? Microchip bietet sowas aber in dem Umfang nicht an oder? Nicht das ich wieder was verpasst habe. Viktor B. schrieb: > Ein sehr guter Vergleich der Mikrocontroller ist z.B. hier zu finden: > https://jaycarlson.net/microcontrollers/ Das sieht sehr vielversprechend aus. Führe ich mir später mal zu Gemüte. PittyJ schrieb: > Aber: kennt man eine IDE, kennt man auch die anderen. Letztendlich > brauch ich nur den Hammer bei Eclipse, F5 bei VisualStudio, und das Ding > compiliert Ja das ist mir eben auch aufgefallen als ich mir ein paar Videos angeschaut habe. Es kommt einem schon viel bekannt vor. Andreas S. schrieb: > Wie bitte? Als Programmierübung mag es zwar ganz nett sein, alle > Bibliotheken selbst zu schreiben, aber ansonsten verwendet man natürlich > fertige Bibliotheken, WENN sie für den ganz konkreten Fall geeignet > sind. Mit kopieren meinte klauen also einfach ohne Lizenz verwenden. Andreas S. schrieb: > Dann ist die Sache doch klar: suche dir einen Arbeitgeber, der eben kein > halbwegs großes Unternehmen ist. Davon gibt es sehr viele. Aber "die > heutige Jugend" ist einfach auf ein paar große Marken fixiert und > übersieht den allergrößten Teil der Unternehmen. Das mag sein. Man hat einfach oft das Gefühl das es besser ankommt wenn man vorher bei Bosch gearbeitet hat als in einem Unternehmen welches der zukünftige Arbeitgeber nicht kennt. Natürlich macht es keinen Sinn aber den Eindruck bekommt man an den Unis. Andreas S. schrieb: > Und im Zweifelsfall werden dann doch einfach wieder aus Verlegenheit die > Bewerbungen an die angeblichen "Top-10-Arbeitgeber" verschickt... Eher aus dem Grund den ich eben genannt habe. Vielen vielen Dank für eure Beiträge!
Steffen schrieb: > Autor: > > Steffen (Gast) > > > > > > > > Datum: 26.06.2019 19:34 Du bist der beste Troll aller Zeiten! Gratuliere. Geil gemacht :-)
Steffen schrieb: > Man wird das dann ja nicht einfach so auch kommerziell nutzen können > oder? > Man wird das dann ja nicht einfach so auch kommerziell nutzen können > oder? > Microchip bietet sowas aber in dem Umfang nicht an oder? Nicht das ich > wieder was verpasst habe. Ich denke, dass du die Lizenz-Hinweise selber lesen kannst. Gerade bei ST sind diese Dokumente einfach formuliert und nicht übermäßig groß. Langer Rede, kurzer Sinn: Das meiste ist kostenlos, damit du deren Chips kaufst. Ansonsten ist deine Frage nach dem "besten" Mikrocontroller in den vergangenen 12 Monaten oft genug durchgekaut worden. Den bisherigen Diskussionen kann man nichts hilfreiches hinzufügen. Benutze daher bitte die Suchfunktion!
Stefanus F. schrieb: > Ansonsten ist deine Frage nach dem "besten" Mikrocontroller in den > vergangenen 12 Monaten oft genug durchgekaut worden. Den bisherigen > Diskussionen kann man nichts hilfreiches hinzufügen. Benutze daher bitte > die Suchfunktion! Wenn es kein Troll wäre - die beste Antwort. (Punkt)
Steffen schrieb: > Das sieht ja schon sehr vielversprechend aus und so wie ich das gesehen > habe alles kostenlos. Wie sieht es hier dann zum Beispiel mit Lizenzen > aus? Dann musst Du eben selbst in die zugehörigen Lizenztexte schauen. > Man wird das dann ja nicht einfach so auch kommerziell nutzen können > oder? Doch, natürlich kann man solche Bibliotheken in kommerziellen Projekten nutzen! Genau für diesen Zweck werden sie ja meist kostenlos angeboten. Der Hersteller würde solche teuren Entwicklungen doch niemals nur für ein paar hausinterne Demos durchführen bzw. beauftragen. Allerdings gibt es meist ein paar Pferdefüße: 1. Der Einsatz solch einer Bibliothek darf nur mit den zugehörigen Bauteilen des Herstellers erfolgen, d.h. man darf nicht einfach die Bibliothek von ST auf einem LPC von NXP einsetzen. Hierdurch erreicht der Hersteller eine sehr starke Kundenbindung. Dies ist in vielen Fällen völlig akzeptabel, kann aber auch zum Ausschlusskriterium werden, falls absehbar sein sollte, dass die eigene Software samt Bibliotheken auf einem "fremden" Microcontroller o.ä. zum Einsatz kommen sollte. 2. Wenn die Bibliothek von einem Drittanbieter stammt und durch einen Halbleiterhersteller o.ä. angeboten wird, handelt es sich eventuell nur um eine Evaluierungsversion, mit der man munter im eigenen Labor herumbasteln kann, was das Zeug hält. Auch darf man ggf. munter Demonstratoren vorzeigen. Sobald man jedoch Serienprodukte in den Verkehr bringen will, muss man entweder Lizenzbedingungen wie unter 1. akzeptieren oder eine entsprechende kostenpflichtige Lizenz erwerben. 3. Mittlerweile sehr gebräuchlich sind auch Mischformen. Beispiel: der Halbleiterhersteller bietet eine Fremdbibliothek wie bei 2. an, jedoch unter den Lizenzbedingungen wie 1.. Der Hersteller der Bibliothek bietet zusätzlich auch noch die Möglichkeit an, bei ihm direkt eine Lizenz auch für andere Plattformen oder eine Bibliothek mit mehr Funktionalität zu erwerben. Das ganze gibt es auch bei Hardwareprodukten. Der von ST Microelectronics vertriebene Programmier- und Debugschniepel ST-LINK stammt in Wirklichkeit von Segger, ist jedoch auf Prozessoren von ST beschränkt. Kauft man ihn jedoch als J-Link direkt von Segger, gibt es keine Herstellerbindung, und er unterstützt viel mehr Prozessoren bzw. Kerne. > Das mag sein. Man hat einfach oft das Gefühl das es besser ankommt wenn > man vorher bei Bosch gearbeitet hat als in einem Unternehmen welches der > zukünftige Arbeitgeber nicht kennt. Natürlich macht es keinen Sinn aber > den Eindruck bekommt man an den Unis. Wer ist "man"? An den Unis findet man vorrangig zwei Personengruppen: 1. Anfänger ohne bzw. mit minimaler Berufserfahrung, 2. Mitarbeiter des Öffentlichen Dienstes, von denen der Großteil noch nie in einem Unternehmen gearbeitet hat und dort auch niemals eine Anstellung bekäme. Dennoch haben beide Gruppen sehr konkrete Vorstellungen, wie es "in der freien Wirtschaft" zugehe. Die Mitarbeiter des ÖD favorisieren dabei natürlich Großunternehmen, weil deren bürokratische Prozesse denen des ÖD am ähnlichsten sind. Viele dieser Mitarbeiter stammen aus Familien, in denen schon seit mehreren Generationen ein Großteil der Vorfahren auch im ÖD gearbeitet hat und es daher als der Normalfall angesehen wird. Falls es überhaupt Kontakte zwischen Hochschulen und Unternehmen gibt, sind das entweder Großunternehmen oder Start-Ups, die aus der Hochschule heraus gegründet werden. Natürlich scheitern viel, viel mehr dieser Start-Ups als Großunternehmen. Auch das trägt zu dem Bild bei, das Hochschulangehörige von der "freien Wirtschaft" haben.
Steffen schrieb: > Brauche ich wirklich nur ein ST-Link und Truestudio um zu debuggen? Jein. Das TrueStudio heißt inzwischen aber STM32 Cube IDE und die Ausprobier-Boards (Discovery und Nucleo) enthalten bereits einen ST-Link Adapter, den man später auch für eigene Boards verwenden kann. Es gibt auch andere Programmieradapter, der ST-Link ist für STM8 und STM32 Controller die Standardoption und sehr preisgünstig. > ich gar nicht richtig klauben wenn man bedenkt was Atmel > für einen Debugger nimmt. Ja, das ist dort viel billiger, als bei Atmel. Die meisten Nucleo Boards kosten ca. 15€ inklusive ST-Link. > Die Trace Funktion kann ich aber nur mit ST-Link und entsprechender > Software nutzen oder ? Ja, bzw. jedem anderen SWD oder JTAG kompatiblen Programmieradapter mit der zugehörigen Software. Wenn du mit kostenloser Software anfangen willst, nimm einen ST-Link. Der wird von allen mir bekannten IDEs out-of-the-box unterstützt. Wenn der dir dann irgendwann zu lahm ist oder die (auf Eclipse basierte) IDE zu doof wird, wechsle auf Keil MDK und einen Segger J-Link. Aber setzt dich erstmal hin, bevor du in die Preislisten schaust. > Zumindest bei TrueStudio geht das nur in der Pro Version Nein, seit ST die IDE aufgekauft hat, ist es komplett kostenlos, dafür aber leider auf STM32 Controller beschränkt. > Wann ist der 32 Bit im Nachteil? Da es sehr viele 32 Bit Controller mit sehr unterschiedlichen Eigenschaften gibt, kann man die Frage nicht vernünftig beantworten. Selbst "der STM32" wie du ihn weiter oben genannt ist, ist eine Produktreihe mit mehr als 1000 Modellen. Schau Dir meine Homepage für den Anfang an: http://stefanfrings.de/mikrocontroller_buch2/index.html http://stefanfrings.de/stm32/index.html
Steffen schrieb: > Jetzt stehe ich aber mal dumm da :D. Arduino erfährt ja schon ziemlich > Aufwind. Arduino ist wie Lego Duplo: gut und beliebt bei Anfängern. Aber keiner baut damit echte Häuser - obwohl man es tun könnte.
Steffen schrieb: > Was ist zum Beispiel mit Eclipse? Obwohl für uC völlig überfrachtet setzt sich Eclipse immer mehr durch von: 8-Bit 8051 z.B. https://www.silabs.com/support/getting-started/microcontrollers/efm8-mcu bis: 32-Bit Cortex-M und teilweise auch Cortex-A z.B. https://www.nxp.com/support/developer-resources/software-development-tools/mcuxpresso-software-and-tools/mcuxpresso-integrated-development-environment-ide:MCUXpresso-IDE
Stefanus F. schrieb: > Arduino ist wie Lego Duplo: gut und beliebt bei Anfängern. Aber keiner > baut damit echte Häuser - obwohl man es tun könnte. Von dir hätte ich eine solch unsinnige Pauschalisierung eigentlich nicht erwartet, Stefan. Natürlich baut man damit auch echte Häuser. Wenn das Haus die gestellten Anforderungen erfüllt, warum nicht? Stefanus F. schrieb: > Ja, das ist dort viel billiger, als bei Atmel. Die meisten Nucleo Boards > kosten ca. 15€ inklusive ST-Link. Die Atmel/Microchip-Pendants dazu sind deren Xplained bzw. XplainedPro-Boards, auch diese haben einen Onboard-Debugger dabei. Die Preisspanne ist je nach Ausführung breiter, es gibt auch ganz billige, aber auch recht umfassend ausgestattete Development-Boards. Allerdings hat der Preis der Atmel-ICE seit der Übernahme durch Microchip doch ganz schön angezogen, leider.
Stefanus F. schrieb: > Ich denke, dass du die Lizenz-Hinweise selber lesen kannst. Gerade bei > ST sind diese Dokumente einfach formuliert und nicht übermäßig groß. > Langer Rede, kurzer Sinn: Das meiste ist kostenlos, damit du deren Chips > kaufst. Hab ich auch. Habe dem Braten aber nicht richtig getraut, da ich sowas von ATMEL Controllern nicht gewohnt bin. Das ist für mich dann schon ein riesen Plus! Johann J. schrieb: > Du bist der beste Troll aller Zeiten! Gratuliere. Geil gemacht :-) Was ist damit jetzt gemeint? Stefanus F. schrieb: > Ansonsten ist deine Frage nach dem "besten" Mikrocontroller in den > vergangenen 12 Monaten oft genug durchgekaut worden. Den bisherigen > Diskussionen kann man nichts hilfreiches hinzufügen. Benutze daher bitte > die Suchfunktion! Ich weiß das es dazu schon viele Beiträge gab. Die haben mich aber alle nicht wirklich weiter gebracht. Der Beitrag hier war für mich hingegen wirklich sehr aufschlussreich. Andreas S. schrieb: > Allerdings gibt es meist ein paar Pferdefüße: > > 1. Der Einsatz solch einer Bibliothek darf nur mit den zugehörigen > Bauteilen des Herstellers erfolgen, d.h. man darf nicht einfach die > Bibliothek von ST auf einem LPC von NXP einsetzen. Hierdurch erreicht > der Hersteller eine sehr starke Kundenbindung. Dies ist in vielen Fällen > völlig akzeptabel, kann aber auch zum Ausschlusskriterium werden, falls > absehbar sein sollte, dass die eigene Software samt Bibliotheken auf > einem "fremden" Microcontroller o.ä. zum Einsatz kommen sollte. > > 2. Wenn die Bibliothek von einem Drittanbieter stammt und durch einen > Halbleiterhersteller o.ä. angeboten wird, handelt es sich eventuell nur > um eine Evaluierungsversion, mit der man munter im eigenen Labor > herumbasteln kann, was das Zeug hält. Auch darf man ggf. munter > Demonstratoren vorzeigen. Sobald man jedoch Serienprodukte in den > Verkehr bringen will, muss man entweder Lizenzbedingungen wie unter 1. > akzeptieren oder eine entsprechende kostenpflichtige Lizenz erwerben. > > 3. Mittlerweile sehr gebräuchlich sind auch Mischformen. Beispiel: der > Halbleiterhersteller bietet eine Fremdbibliothek wie bei 2. an, jedoch > unter den Lizenzbedingungen wie 1.. Der Hersteller der Bibliothek bietet > zusätzlich auch noch die Möglichkeit an, bei ihm direkt eine Lizenz auch > für andere Plattformen oder eine Bibliothek mit mehr Funktionalität zu > erwerben. > > Das ganze gibt es auch bei Hardwareprodukten. Der von ST > Microelectronics vertriebene Programmier- und Debugschniepel ST-LINK > stammt in Wirklichkeit von Segger, ist jedoch auf Prozessoren von ST > beschränkt. Kauft man ihn jedoch als J-Link direkt von Segger, gibt es > keine Herstellerbindung, und er unterstützt viel mehr Prozessoren bzw. > Kerne. DANKE! Gut zu wissen! Stefanus F. schrieb: > Ja, das ist dort viel billiger, als bei Atmel. Die meisten Nucleo Boards > kosten ca. 15€ inklusive ST-Link. Ebenfalls ein riesiges Plus für ST. Vor allem für Anfänger (besonders arme Studenten) die oft keinen eigenen Debugger haben. Meiner ist auch nur eine Leihgabe. Stefanus F. schrieb: >> Zumindest bei TrueStudio geht das nur in der Pro Version > > Nein, seit ST die IDE aufgekauft hat, ist es komplett kostenlos, dafür > aber leider auf STM32 Controller beschränkt. Oh das sind natürlich gute Nachrichten für mich :). Stefanus F. schrieb: > Schau Dir meine Homepage für den Anfang an: > http://stefanfrings.de/mikrocontroller_buch2/index.html > http://stefanfrings.de/stm32/index.html Das sieht gut aus :). Damit sind bei mir auch erstmal alle Fragen geklärt. Für mich macht es den Anschein das ich mit ST für den Anfang nichts falsch machen kann. Ich werde mir jetzt ein STM32 Eval Board und einen ST Link besorgen. Dann werde ich mal etwas in die 32 Bit Welt eintauchen. Ihr habt mir sehr weiter geholfen! Vielen vielen Dank für eure Beiträge. Ist nicht selbstverständlich das sich die Leute in Foren so ins Zeug legen. Spitzen Truppe hier :).
St Link brauche ich bei den Evals natürlich nicht :P ... Vertan
Steffen schrieb: > da ich sowas von ATMEL Controllern nicht gewohnt bin Die verstecken sowas komplett in ASF. Die Lizenzbedingungen sind aber auch eher so, wie oben beschrieben, also keine allgemeine BSD-, MIT- oder Apache-Lizenz, sondern rechtliche Bindung an deren Hardware. Allerdings ist ASF ein heftiges Konglomerat, es gibt da auch Subsysteme mit anderen (liberaleren) Bedingungen. Man muss sich das wirklich alles im Detail selbst ansehen, und auch die Kunden über sowas informieren.
Noch ein Punkt: Hier wird (logischerweise, da viele hobbymässig am Werk sind) meisstens auf kostenlose Lösungen verwiesen, wie z.B. gdb. Allerdings sollte man bedenken, dass solche AllRounder meisst wenig Möglichkeiten zum Debuggen mit sich bringen. Spezialisierte IDEs (z.B. auf ARM) bringen Tools zur zeitlichen grafischen Auswertung des eigenen Systems mit, was oftmals sehr hilfreich ist. So habe ich z.B. in einer Ethernet Anwendung die Timings, Timeouts und Data-loss mit einem SWO basierten grafischen Analyzer ausgewertet, und ein seltenes, kritisches Problem anhand der Interrupt-/RTOS Timeslotanalyse gefunden. Die verwendete Debugunit mus dafür aber auch entsprechende Frequenzen (84MHz bei mir) unterstützen, um die Daten aus dem Chip zu bekommen.
:
Bearbeitet durch User
Random .. schrieb: > Noch ein Punkt: > Hier wird (logischerweise, da viele hobbymässig am Werk sind) meisstens > auf kostenlose Lösungen verwiesen, wie z.B. gdb. Ich benutze ihn seit mehr als 25 Jahren professionell. Zählt das? Dabei war es übrigens kein Kriterium, dass er kostenlos ist. Natürlich gibt der Chef auch Geld für Werkzeuge aus, wenn sie uns massiv Arbeitsstunden sparen, denn die werden schnell teurer. > Allerdings sollte man bedenken, dass solche AllRounder meisst wenig > Möglichkeiten zum Debuggen mit sich bringen. Das ist, mit Verlaub, Quark. Ich habe ausreichend viele kommerzielle Debugger gesehen, bei denen ich mir den Featureset eines GDB herzlichst gewünscht hätte. > Spezialisierte IDEs (z.B. auf ARM) bringen Tools zur zeitlichen > grafischen Auswertung des eigenen Systems mit, was oftmals sehr > hilfreich ist. Timing-Analysen sind immer hilfreich, keine Frage. Die erledigen wir hier seit Jahren in erster Linie mit dem Logic Analyzer. Ein paar GPIOs für das Debuggen, und man ist völlig flexibel, welches Timing man gerade analysieren möchte – ganz ohne spezialisierte Debugger.
Jörg W. schrieb: >> Das kann ich aber nicht wirklich nachvollziehen. Je mehr Rechenleistung >> ich habe um so einfacher wird das Ganze doch, oder? Im Prinzip ja, im Hobby Bereich arbeitet man auch so. In industriellen Anwendungen hast Du aber Kosten, die Du möglich klein halten musst. Man wählt das Produkt das am besten zur Anwendung passt. Exemplarisch: Auch ein Intel I7 Multicore könnte eine LED blinken lassen.
Jörg W. schrieb: >> Das kann ich aber nicht wirklich nachvollziehen. Je mehr Rechenleistung >> ich habe um so einfacher wird das Ganze doch, oder? Welche Berechnungen denn ? Eine Temperaturumrechnung ? In double, mit Gleitkommaeinheit? Zum Einen genuegen Single, zum Anderen muss man auch keine 10000 Temperaturen pro sekunde umrechnen, sondern vielleicht 2.
Bonzz schrieb: > zum Anderen muss man auch > keine 10000 Temperaturen pro sekunde umrechnen, sondern vielleicht 2. Grundsätzlich stimme ich Dir zu, allerdings kenne ich keinen Mikrocontroller, der so extrem langsam ist, dass er nur 2 Temperaturen pro Sekunde umrechnen kann.
Steffen schrieb: > Ich würde mich später gerne in dem Bereich selbstständig machen (oder > zumindest arbeiten) und kleinere Anwendungen entwickeln. > (Wunschvorstellung... mal gucken ob es klappt). Wenn es um den Bereich Microcontroller geht, kannst du das vergessen. Da gibt es Betriebe die das sein 20 Jahren mit etlichen Leuten mit entsprechender Erfahrung. Du könntest aber durchaus in einem Nischenbereich Erfolg haben. Beispiel: Arbeitskollege hier ist Hobby Imker. Der hat für seine Völker (so nennt man den Bestand der Bienen) Waagen gebaut. Das Gewicht der Völker wird mittels Arduino und co überwacht und lässt sich per Remote über eine App abrufen (Gewicht, Temp., Luftfeuchte, Winkel). Natürlich reicht das nciht sich selbständig zu machen, aber er kann die Dinger verkaufen. Um gleich beim Beispiel zu bleiben: Wenn das ganze kommerzialisiert werden soll, wählt man die CPU die am billigsten ist und die Aufgabe zu 100% übernehmen kann. Entwirft den PCB, das Layout und lässt das in China produzieren. Siehst du, worauf es hinausläuft? Es ist völlig schnuppe welche CPU oder welche IDE. Die Anwendung bestimmt die cpu.
:
Bearbeitet durch User
PittyJ schrieb: > Aber: kennt man eine IDE, kennt man auch die anderen. Letztendlich > brauch ich nur den Hammer bei Eclipse, F5 bei VisualStudio, und das Ding > compiliert. Den Hammer lol war das nicht eine Schildkröte oder eine Schnecke? Wenn man etwas unter die Haube schauen will (und das soltte man) gehts mit GCC und Kommandozeile los. Eclipse-basierte IDE muss man mögen... (mehr Diplomatie geht nicht ;-)) Ich bin im Moment mit VisualGDB sehr zufrieden. (stabil und schnell) Habe aber auch schon viel mit Keil und Konsorten gemacht. Grüße Runout
Steffen schrieb: > 1. Welche IDE´s empfehlt ihr? Atmel Studio ist ja zum Beispiel nur für > Atmel Controller. Ich würde mich aber gerne etwas breiter Aufstellen was > die IDE angeht und mich nicht nur auf Atmel konzentrieren. Probiere mal die PSoCs von Cypress aus. Die Dinger sind echt eine gute Alternative zu den STM32 Controllern. Die IDE "PSoC Creator" bekommst du auch umsonst. Funktioniert mit einem Keil Compiler. Steffen schrieb: > . Macht es überhaupt noch Sinn mit kleine leistungsschwache 8bit > Controllern zu arbeiten? Wenn du einmal einen 32-Bitter programmiert und verstanden hast, dann machen 8-Bitter im Hobbybereich keinen Sinn mehr. Ein Atmega kostet meistens genauso viel wie ein STM32 Controller und hat dabei weniger Leistung und Peripherie. MfG
Steffen schrieb: > ich beschäftige mich seit ca. einem Jahr mit uC und frage mich welche > Systeme die besten Aussichten für die Zukunft haben. Nichts ist so beständig wie der stetige Wandel.
AVR schrieb im Beitrag #5888776: > Wenn du einmal einen 32-Bitter programmiert und verstanden hast, dann > machen 8-Bitter im Hobbybereich keinen Sinn mehr Für mich schon. Ich nutze zum Beispiel kleine ATtinies im 8 poligen DIP Gehäuse häufiger, als alle anderen Mikrocontroller. Ich kenne keinen 32bit Controller, den ich ohne zusätzliche Aufwände auf Lochraster bekomme. Preislicht mithalten kann da nur das Bluepill Board, das ist aber größer und nimmt wesentlich mehr Strom auf. Programmiertechnisch sehe ich zwischen 8bit und 32bit keinen wesentlichen Unterschied. Die 32bit COntroller sind meistens größer breiter schneller und dementsprechend auch komplizierter. Wenn ich deren Leistung nicht brauche, bevorzuge ich die Einfacheren 8bit Modelle. Zudem sind die Datenblätter aller mir bekannten 8bit Controller klarer formuliert, so dass ich mit wesentlich weniger Fehlschlägen zum Ziel komme.
Stefanus F. schrieb: > Ich kenne keinen 32bit Controller, den ich ohne zusätzliche Aufwände auf > Lochraster bekomme. Das ist allerdings für eine kommerzielle Anwendung als Kriterium ziemlich uninteressant. 8-Pinner insgesamt dagegen können kommerziell als „08/15-Logik-Ersatz“ an vielen Stellen sinnvoll sein, und da wird bei den 32-Bittern die Luft schnell dünn, während man bei 8-Bittern doch noch Auswahl hat. > Programmiertechnisch sehe ich zwischen 8bit und 32bit keinen > wesentlichen Unterschied. Naja, bis ich mir für einen Cortex-M überlegt habe, wie ich das Taktsystem überhaupt organisiere, habe ich eine simple Aufgabe (wenn sie nicht viel mehr umfasst als den typischen LED-Blinker) auf einem AVR bereits fix und fertig. ;-) Die größere Leistungsfähigkeit und Flexibilität hat an dieser Stelle halt ihren Preis (in Form von Gehirnschmalz).
:
Bearbeitet durch Moderator
AVR schrieb im Beitrag #5888776: > Wenn du einmal einen 32-Bitter programmiert und verstanden hast, dann > machen 8-Bitter im Hobbybereich keinen Sinn mehr Stefanus F. schrieb: > Ich kenne keinen 32bit Controller, den ich ohne zusätzliche > Aufwände auf Lochraster bekomme. Jörg W. schrieb: > Das ist allerdings für eine kommerzielle Anwendung als Kriterium > ziemlich uninteressant. Es geht um den Hobbybereich.
Stefanus F. schrieb: > Es geht um den Hobbybereich. Sehe ich nicht so! Steffen schrieb: > in dem Bereich selbstständig machen Womit dann der Hobbybereich verlassen wird.
Arduino Fanboy D. schrieb: >> Es geht um den Hobbybereich. > Sehe ich nicht so! Ich hab's doch oben zitiert! AVR hat seine Meinung für den Hobbybereich geäußert und meiner einer hat dazu geantwortet. Wenn du woanders unterwegs bist, ist das deine Sache. Hätte ich ihm mit Argumenten für den Profi Bereich geantwortet, dann wäre meine Antwort unpassend gewesen. Herr Doktor, soll ich im Freibad Sonnenschutz-Creme auftragen? Nein, im Keller ist es dunkel genug.
Stefanus F. schrieb: > Wenn du woanders unterwegs bist, ist das deine Sache. Nein. Wenn man in diesem Thread unterwegs ist, sollte man sich schon primär danach richten, was der TE für Absichten hat(te). Nur, weil dann einer mit irgendwelchen abweichenden Dingen daher kommt, ist das kein Grund, nun den halben Thread wegdriften zu lassen, und erst recht kein Grund, dass du Leute, die dich auf das eigentliche Thema des Threads hinweisen, schräg anmachst, Stefan.
Ich denke alleine die Tatsache, dass diese Frage hier im Forum in der vorliegenden Art gestellt wurde deutet darauf hin, dass es sich um "Hobby" handelt. Im Profi-Bereich werden solche Fragen einfach nicht gestellt. Zum Thema: Nimm den uC zu dem es die meisten Einträge in Foren gibt. Bei 32bit ist das stm32. Dazu findest du tonnenweise Hilfe und Beispiele und IDEs gibts auch genug. Nimm nur dann etwas weniger Bekanntes, wenn die Anforderungen es nötig machen. Mach dir nicht zu viele Gedanken. Besorge dir ein 5 Euro Evaluation Board, da ist alles drinn (debugger, programmer). Und lade dir irgendeine IDE runter und mach einfach mal. Der Rest kommt von selbst. Wenn eine kostenpflichtige IDE, dann nimm KEIL. Das ist im Industriesektor verbreitet und etabliert. Fuer Hobby nimm irgendwas.
Stefanus F. schrieb: > Langer Rede, kurzer Sinn: Ahem. Deutsch ist zwar nicht meine Muttersprache, benutze es kaum noch, außer hier im Forum, aber entweder: Lange Rede, kurzer Sinn oder: Langer Rede kurzer Sinn Nennt sich Grammatik, wenn ich mich richtig erinnere...
Also ich glaube ja das es die größte Community bei PIC und AVR Microcontrollern gibt. Da beide von Microchip hergestellt werden hat man da auch einen direkten Ansprechpartner in beiden Fällen. Ich weiß natürlich nicht was du genau damit machen möchtest, aber mit den 8bit Controllern von ATMEL kann man schon einen PC bauen (schau mal hier im Forum nach)... Für noch schwerere Aufgaben kannst du dann immernoch die Atxmegas verwenden. Also ich bin der Meinung das eine Idee meistens nicht daran scheitert dass der Controller zu wenig kann, sondern dass der Mensch, der das Programm schreibt zu wenig kann. ? Zumindest ich merke immer wieder wie oft man einen Programmcode zu ineffizient schreibt und ihn dann noch einmal überarbeitet. Und die AVRs haben mich bisher in keinem meiner Projekte hängengelassen. ?
Von Grammatik habe ich in der Tat keine Ahnung, eben so wenig von Rechtschreibung.
Jörg W. schrieb: > Stefanus F. schrieb: >> Arduino ist wie Lego Duplo: gut und beliebt bei Anfängern. Aber keiner >> baut damit echte Häuser - obwohl man es tun könnte. > > Von dir hätte ich eine solch unsinnige Pauschalisierung eigentlich nicht > erwartet, Stefan. > > Natürlich baut man damit auch echte Häuser. Wenn das Haus die gestellten > Anforderungen erfüllt, warum nicht? Ja - warum nicht. Jörg W. schrieb: > Für mich: ich muss mich nicht umgewöhnen, nur weil ich mal einen anderen > Controller benutze. :) Spannend - wie machst Du das? Von 8-Bit AVR auf STM... ohne "Umgewöhnung"? Für mich liegen da Welten dazwischen. Stefanus F. schrieb: > Jörg W. schrieb: >> Das ist allerdings für eine kommerzielle Anwendung als Kriterium >> ziemlich uninteressant. > > Es geht um den Hobbybereich. Ja - das sehe ich auch so. Jörg W. schrieb: > Stefanus F. schrieb: >> Wenn du woanders unterwegs bist, ist das deine Sache. > > Nein. Wenn man in diesem Thread unterwegs ist, sollte man sich schon > primär danach richten, was der TE für Absichten hat(te). Na, welche denn bitte (außer zu trollen). Schon mal aufgefallen, dass er sich nur bedingt meldet?
Stefanus F. schrieb: > Von Grammatik habe ich in der Tat keine Ahnung, eben so wenig von > Rechtschreibung. Stimme ich zu. ebenso wenig
hibbi schrieb: > Nimm nur dann etwas weniger Bekanntes, wenn die Anforderungen es nötig > machen. Er kann auch etwas weniger bekanntes nehmen. Ich hatte oben ja schon die PSoCs genannt. Die Teile sind genial einfach. Er muss in der IDE die Datenblätter der einzelnen Komponenten lesen und verstehen. Zu Funktionsweise ist auch die passende API der Komponenten in den Datenblätter enthalten. Hier zwei Kits für relativ wenig Geld: https://www.mouser.de/ProductDetail/Cypress-Semiconductor/CY8CKIT-059?qs=sGAEpiMZZMuo%252BmZx5g6tFKhundMNZurhvz2tw2jO%2Fk8%3D Oder sogar mit einem BLE 5.0 Modul https://www.mouser.de/ProductDetail/Cypress-Semiconductor/CY8CPROTO-063-BLE?qs=sGAEpiMZZMve4%2FbfQkoj%252BADQD2pyyYPWkc4N8EztMLQ%3D So viel Hardware für wenig Geld. Die Teile sind nicht schwer zu verstehen. MfG
Jörg W. schrieb: > Naja, bis ich mir für einen Cortex-M überlegt habe, wie ich das > Taktsystem überhaupt organisiere, habe ich eine simple Aufgabe (wenn sie > nicht viel mehr umfasst als den typischen LED-Blinker) auf einem AVR > bereits fix und fertig. ;-) Ja, viele Sachen gehen auf den 8-Bittern bedeutend einfacher. Man muß nicht für jeden Interrupt 2 Pending-Flags in der richtigen Reihenfolge löschen, sondern das Flag wird oft beim Eintritt automatisch gelöscht. Auch um spurious Interrupts muß man sich nicht kümmern, weil es die nicht gibt. Mit Ausnahme der asynchronen Timer werden auch alle Aktionen sofort gültig ohne versteckte Nebeneffekte. Die geringere Komplexität verringert auch die Fehlerquellen, d.h. das Debugging wird einfacher.
Peter D. schrieb: > Ja, viele Sachen gehen auf den 8-Bittern bedeutend einfacher. Sie bieten das beste Verhältnis von Komplexität zu Nutzen. > sondern das Flag wird oft beim Eintritt automatisch gelöscht. Leider nicht mehr bei den neueren AVR Series-0/1 Typen. Da wird manches leider komplizierter.
Zu Deiner Aussage:"Ich würde mich später gerne in dem Bereich selbstständig machen (oder zumindest arbeiten) und kleinere Anwendungen entwickeln". Man darf nichts elektronisch Selbstgebasteltes verkaufen oder verschenken. Das macht leider auch Sinn. Die Welt ist mit Rohstoffen (Konfliktrohstoff), Vergiftung der Umwelt (Rohs) und Elektronikmüll schon an einem Limit angekommen. Stichwort: Elektronikgerätegesetz.
Beitrag #5890615 wurde von einem Moderator gelöscht.
Beitrag #5890755 wurde von einem Moderator gelöscht.
Beitrag #5890928 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.