Guten Tag zusammen, Ich möchte mich beruflich im Bereich mikrocontroller orientieren, da ich meine Ausbildung zum Softwareentwickler abgeschlossen habe und in der Zeit schon viel mit einem Arduino gearbeitet habe. Da ich noch relativ unberührt bin, was AVR/ARM angeht wollte ich mir hier input holen. Was gibt es für Bücher und gibt es Kits wo bereits alles vorhanden ist? Tutorials hatte ich mir hier angeguckt, allerdings wirken mir diese (ohne jemanden angreifen zu wollen) doch etwas veraltet oder verwirrend. Speziell im Bereich Hardwarebeschaffung finde ich dort leider keinen roten Faden, weshalb eine entsprechende Lektüre oder andere Tutorials sehr lobenswert wären. Wichtig wäre mir noch, dass ich auch auf meinem Macbook damit arbeiten könnte, da ich dieses als Arbeitsgerät verwende. Zu Arduinos gibt es zu genüge Tutorials. Leider sind diese jedoch eher für den Hobbybedarf und lassen sich deutlich leichter programmieren. liebe Grüße und Danke Martin
:
Gesperrt durch Moderator
Du kannst auch "Arduino" Board ohne Arduino Ide nutzen. Unter anderem solltest du selber wissen, welcher Mikrocontroller deine Anforderungen erfüllt.
Ja ich weiß, dass ein AtMega8 meinen Anforderungen gerecht werden sollte, um hier einzusteigen. Ich danke Dir für deine freundliche Antwort und bin um Informationen reicher.
:
Bearbeitet durch User
Martin K. schrieb: > Ich möchte mich beruflich im Bereich mikrocontroller orientieren Dann lasse am Besten die Finger von Arduino & Co, und fange direkt "richtig" an, denn im professionellen Umfeld wird gewiss oft etwas mehr erwartet als Hobby-Bastler-Arduino-Kenntnisse! Zudem ist zu befürchten, dass kommerziell ARM's viel mehr als AVR's genutzt werden, weswegen es vermutlich zukunftsträchtiger ist, sich damit zu beschäftigen. Hardwaremäßig gibt es hier sehr viel Auswahl. Eine Möglichkeit wären z.B. die STM32 Discovery Boards, da hast du alles dabei was du brauchst. Siehe dazu auch STM32. Bücher gibt es in der Software-Entwicklung ja nur für die einfachen Sachen die nur Hobby-Entwicklern ausreichen. Für ernsthafte Anwendungen wirst du dich mit Datenblättern und Online Tutorials beschäftigen müssen. Es gibt allerdings "The Definitive Guide to ARM® Cortex®-M3 and Cortex®-M4 Processors".
Martin K. schrieb: > Ich möchte mich beruflich im Bereich mikrocontroller orientieren, da ich > meine Ausbildung zum Softwareentwickler abgeschlossen habe Der/die Mikrocontroller und die Programmierung sind im Sinne der Entwicklung eines Produktes nur ein kleiner Teilbereich. Bevor es zur Auswahl eines Controllers kommt, sind in der Regel andere technische Aufgaben zu lösen, auch Hardware-Aufgaben, die auch Einfluß auf die Controllerwahl und die Hardware haben können. Irgendeine (Verzeihung für diesen Ausdruck:) Hilfskraft, die das dann programmiert, wird man schon finden. So zumindest in kleinen Firmen und Abteilungen. In großen Firmen und Abteilungen, die sowas täglich machen, unterscheidet sich die Programmierung nicht wesentlich von der einer "Software-Fabrik". Es ist gut, wenn man neben der "normalen" Programmierung auch weiß, wie man einen Mikrocontroller programmiert, aber eine Stelle als "Mikrocontroller-Programmierer" wird man wohl schwerlich finden. Martin K. schrieb: > Wichtig wäre mir noch, dass ich auch auf meinem Macbook damit arbeiten > könnte, da ich dieses als Arbeitsgerät verwende. Dies ist schon eine Such-Option und bezahlbare Hardware (inclusive Programmer und evtl. Debugger), sowie frei verfügbare Entwicklungswerkzeuge. Die Architektur ist erst mal Nebensache. Blackbird
Danke für deine Infos! Damit kann ich was anfangen :) Ich werde mich diesbezüglich mal einlesen. Auch über die Buchempfehlung
Die Architektur ist egal. Wenn Du den Arduino kennst, dann kannst Du ruhig dabei bleiben. Woran es aber oft hapert, ist die grundlegende Herangehensweise an eine Programmieraufgabe. Wer sofort den Editor anschmeißt und eintippt: int main(), der hat schon komplett verloren. Man muß erstmal eine Aufgabe in einzelne Module unterteilen, zu diesen einen PAP erstellen, bis man ihre Funktion verstanden hat, den PAP auf logische Funktion und Fehler überprüfen und erst dann kann man Code eintippen. Das Aufteilen einer Aufgabe ist eigentlich der mit Abstand wichtigste Programmierschritt. Gut geteilt ist schon fast beherrscht. Beim Aufteilen merkt man auch oft, Mensch, das ist ne schöne Funktion, die packe ich in ne Lib und nutze sie in späteren Projekten nach. Das spart dann mächtig Arbeit. Leider sieht man oft das Gegenteil, also völlig undurchsichtige Copy&Paste-Monster, d.h. den zu recht gefürchteten Spaghetticode.
Hey, ich würde mir tatsächlich gerne das STM32F4 bestellen wollen und dazu auf ein Buch über den Cortex M4 zurück greifen. Mehr bräuchte ich ja erst mal nicht oder? Ich fang vermutlich erst mal klein an und taste mich vorsichtig an den Spaß ran. Danke jedenfalls Euch allen!
Als Buchempfehlung: Weniger schlecht programmieren https://www.amazon.de/Weniger-schlecht-programmieren-Kathrin-Passig/dp/3897215675
Martin K. schrieb: > ... und in der Zeit schon viel mit einem Arduino gearbeitet habe. Da > ich noch relativ unberührt bin, was AVR/ARM angeht wollte ich mir hier > input holen. In den meisten Arduinos werkelt ein AVR µC und im Arduino Due ein ARM. Was für Arduinos hast du denn bisher benutzt, dass du in Bezug auf AVR/ARM noch relativ unberührt bist?
Moin, ich hab ein Arduino Uno. Dort ist ein AtMega8 verbaut. Ich meinte auch eher, dass das programmieren von Arduinos sehr einfach von der Hand geht. Was nicht schlecht ist aber was ich bisher gehört habe ist, dass ein "nicht Arduino" doch noch etwas anders funktioniert bzw. programmiert wird.
Martin KI (mrnew) schrieb: > Ich danke Dir für deine freundliche > Antwort und bin um Informationen reicher Ist das hier ein K.I. Bot Test oder menschliche Ironie :-)
Großer Vorteil bei ARM (z.B. STM32): SWD. D.h. Programmieren und ordentlich Debuggen über 4 Leitungen und das Gerät (ST-Link v2) kostet original um die 30 und als Clone um die 5 Euro. Bei AVR hingegen: Zwar günstige Programmer aber Wildwuchs und Fuses, dann 6 Leitungen für ISP und fürs Debuggen wieder Wildwuchs mit Debuwire und JTAG. AVR Dragon ist ne nackte Platine und Zumutung in einem, AVR ICE Profiding kostet ein Vermögen und selbst das neue Atmel ICE Billigheimerteil kostet immer noch um die 100 Euro.
:
Bearbeitet durch User
Martin K. schrieb: > aber was ich bisher gehört habe ist, dass ein "nicht Arduino" doch noch > etwas anders funktioniert bzw. programmiert wird. All das kannst du mit deinem Arduino aber genauso tun. Lass einfach die Arduino-IDE weg, und nimm dir einen Assembler oder Compiler deiner Wahl, dann hast du den "nackten" ATmega8 zu deinen Füßen.
Cyblord -. schrieb: > Gerät (ST-Link v2) kostet > original um die 30 Deswegen wurd' ja oben auch schon das STM32 Discovery (oder auch Nucleo) vorgeschlagen. Da ist der "original" ST-Link schon drin und nach Abbrechen sogar standalone nutzbar. Ich bin vor 2 Jahren angefangen von AVR auf STM32 umzusteigen und mittlerweile soweit, alles was ich benötige umsetzen zu können - hätte sofort auf ARM einsteigen sollen. Was mir besonders beim Einstieg Probleme machte, waren die Libraries (StdPeriph und HAL), die immer mal anders funktionierten als erwartet. Und HAL heisst nicht, dass man zwischen F030 und F103 ohne Source-Änderungen wechseln kann. Einige Dinge habe ich erst zum Laufen bekommen, nachdem ich mir den HAL Source und die Datenblätter angesehen habe und dann kapierte, wie es eigentlich funktionieren soll. Source im Netz zu finden und wiederzuverwenden ist manchmal schwierig, da manchmal die StdPeriph, dann die HAL oder mbed verwendet wird. Und dann noch eine handvoll üblicher Kompiler zur Verfügung stehen. clive1 kennt wohl jeder, der mit STM arbeitet, oder? ;)
Martin K. schrieb: > da ich > meine Ausbildung zum Softwareentwickler abgeschlossen habe und in der > Zeit schon viel mit einem Arduino gearbeitet habe. hmm.. Was lernt man denn so, in der Ausbildung zum Softwareentwicker? Ich hab nen Begriff davon, was man im Mathe-Studium lernt oder was man als E-Technik-Student lernt, aber Softwareentwickler? Selbst Informatik klingt eher nach Bibliothekswesen. Der Grund für meine Frage ist eigrntlich, daß keiner so recht weiß, was du eigentlich gelernt hast, auf welchen Wissensstand du zurückgreifen kannst, was deine eigentlichen Berufs-Vorstellungen sind und womit man dir am ehesten helfen kann, eine für dich passable Richtung vorzuschlagen. Viele Antworten hier laufen auf "nimm dieses" oder "nimm jenes" hinaus, aber das führt lediglich zu einem Persönlichkeitsbild, was man am ehesten als "Markenaffe" bezeichnen kann, also "Ingenieur für STM32F407 mit ST-Lib" und der unterscheidet sich dann grundlegend vom "Ingenieur für STM32F407 mit Cube". Klingt überspitzt, ist aber der Kern der Sache. Nochwas: Peter hatte den Ansatz mit dem Aufteilen der Aufgabenstellung schon richtig begonnen. Wichtiger ist allerdings immer noch, die Aufgabenstellung als solche erstmal richtig auf die Beine zu kriegen. Ich würde das am ehesten mit dem Architekten auf'm Bau vergleichen. Wie man hingegen irgend eine blöde Programmiersprache benutzt oder welches Eval-Board man zum Spielen sich besorgt, ist was ganz anderes. Hat mit dem Berufsweg nichts zu tun. also, schreib mal was über deinen Stand und deine Ziele. Damit wird's konkreter. W.S.
Alexander B. schrieb: > Deswegen wurd' ja oben auch schon das STM32 Discovery (oder auch Nucleo) > vorgeschlagen. Da ist der "original" ST-Link schon drin und nach > Abbrechen sogar standalone nutzbar. Muss gar nicht abgebrochen werden. Da ist ein jumper drauf, denn man setzen kann, wenn man das board als ST-Link verwenden möchte.
W.S. schrieb: > Viele Antworten hier laufen auf "nimm dieses" oder "nimm jenes" hinaus, > aber das führt lediglich zu einem Persönlichkeitsbild, was man am > ehesten als "Markenaffe" bezeichnen kann, also "Ingenieur für STM32F407 > mit ST-Lib" und der unterscheidet sich dann grundlegend vom "Ingenieur > für STM32F407 mit Cube". Klingt überspitzt, ist aber der Kern der Sache. > > Nochwas: Peter hatte den Ansatz mit dem Aufteilen der Aufgabenstellung > schon richtig begonnen. Wichtiger ist allerdings immer noch, die > Aufgabenstellung als solche erstmal richtig auf die Beine zu kriegen. > Ich würde das am ehesten mit dem Architekten auf'm Bau vergleichen. Wie > man hingegen irgend eine blöde Programmiersprache benutzt oder welches > Eval-Board man zum Spielen sich besorgt, ist was ganz anderes. Hat mit > dem Berufsweg nichts zu tun. Ich denke, hier geht es nicht um eine konkrete Aufgabenstellung, sondern um die Orientierung in der Technik. Er sucht also ein Eval-Board und keine Berufsberatung ;-) Peter D. schrieb: > Man muß erstmal eine Aufgabe in einzelne Module unterteilen, zu diesen > einen PAP erstellen, bis man ihre Funktion verstanden hat, den PAP auf > logische Funktion und Fehler überprüfen und erst dann kann man Code > eintippen. PAP ist nett fürs Hobby und schnell hingekritzelt, aber so was von "letztes Jahrtausend" ;-) Zum Einstieg und für kleiner Aufgabe reicht meist trial and error. Eine vertiefende Buchempfehlung: Elecia White: "Making Embedded Systems: Design Patterns for Great Software" https://www.amazon.de/gp/product/1449302149/
Die Aufgabe bestimmt den uC und nicht umgekehrt! Über die Aufgabe an sich hast du jedoch kein Wort verloren, von daher wirst du alles von AVR über ARM bis FPGA zu hören bekommen. Hinterher bist du genau so schlau wie vorher! Aber wenns dir hilft....
Martin K. schrieb: > Wichtig wäre mir noch, dass ich auch auf meinem Macbook damit arbeiten > könnte, da ich dieses als Arbeitsgerät verwende. Dann hast du eigentlich schon geloosed. In der Industrie gibt es nur einen Standard. Und der heisst nunmal leider: Windows. Naja, für die Software von ARM-basierten Gadgets ist auch noch Linux als Entwicklungssystem verbreitet. Apple ist aber definitv raus. Das nutzen nur Doofe und sog. "Kreative". Was auch nur Doofe sind, bloß dass sie zusätzlich irgendeine Macke haben, die sie als Künstler qualifiziert. Jedenfalls ihrer eigenen Meinung nach. Wenn man sich vor Augen hält, dass ein gut Teil der "Werbewirtschaft" unter diese Kategorie fällt, dann wird das aber allein durch diese Tatsache arg zweifelhaft. Das hat ja, für jeden offensichtlich, nun mit Kreativität eher selten und mit Kunst garnichts zu tun...
Hallo Martin, Martin K. schrieb: > Ich möchte mich beruflich im Bereich mikrocontroller orientieren, ... > Wichtig wäre mir noch, dass ich auch auf meinem Macbook damit arbeiten > könnte, da ich dieses als Arbeitsgerät verwende. ich arbeite viel mit GCC, CMake und ARM-Controllern. Das funktioniert prima unter OS/X. An Deiner Stelle würde ich mir einfach mal ein nicht zu kleines STM32 Eval board besorgen und versuchen, die erste LED blinken zu lassen. mfg Torsten
Torsten R. schrieb: > Ich möchte mich beruflich im Bereich mikrocontroller orientieren, ... Also, allgemein kann man sagen, das AVR eigentlich einen ziemlich schlechten Ruf in der Industrie hat. Zum lernen und eintauchen in die µC-Welt sind die Dinger ganz gut, hab ich auch mit angefangen, aber möchte man professionell arbeiten, kommt man an den ARM-Controllern nicht vorbei. Zudem ist der Preis-Leistungsverhältnis zwischen einem AVR 8 Bitter und ARM 32 Bitter einfach unschlagbar. Da können sich die AVR-Leute drehen und wenden, wie sie wollen. Beide haben allerdings ihre Daseinsberechtigung. Industriestandard ist nun mal Windows, Keil und ARM. Torsten R. schrieb: > Wichtig wäre mir noch, dass ich auch auf meinem Macbook damit arbeiten > könnte, da ich dieses als Arbeitsgerät verwende. Du willst in die Hard- und Softwareentwicklung dich weiter orientieren und kommst mit einem Macbook an? Ahh ja... Gruß Daniel
lächler schrieb: > Zum Einstieg und für kleiner Aufgabe reicht meist trial and error. Ja, wenn du damit HelloWorld und LedBlink meinst. Nur bleiben bei trial und error Anfängen die meisten Programmierer auch später bei diesem approach, was entweder in Spaghetticode endet oder in einem Code der nur unter bestimmten Bedingungen funktioniert. > PAP ist nett fürs Hobby und schnell hingekritzelt, aber so was von > "letztes Jahrtausend" ;-) Wie man es auch nennt und was man letzten Endes da hinkritzelt ist absolut unwichtig, aber ein PAP ist oberstes Gebot. Irgendetwas ernsthaftes ohne PAP anzufangen ist absoluter Blödsinn. Und wie du in diesem Zusammenhang auf Hobby kommst ist mir schleierhaft. P.S. Ich kritzel PAP zuerst aufs Papier, danach geht es mit Excel und ein paar Macros weiter, Timeline wenn nötig und schon spuckt mir Excel ein recht brauchbares Gerüst aus.
Hallo Daniel, Daniel V. schrieb: > Torsten R. schrieb: >> Ich möchte mich beruflich im Bereich mikrocontroller orientieren, ... wenn Du mich schon zitierst, dann nimm bitte auch von mir geschriebenen Text (nicht Text, den ich zitiert habe ;-). Daniel V. schrieb: > Du willst in die Hard- und Softwareentwicklung dich weiter orientieren > und kommst mit einem Macbook an? Ahh ja... Der OP schrieb nur von Software-Entwicklung. Die Hardware-Entwicklung legst Du Ihm gerade in den Mund. Ich entwickle seit 20 Jahren Software und kann gerade nicht erkennen, warum ein Macbook dazu ungeeignet sein sollte. Sicher, ich habe auch noch eine VM mit Windows, um Tools, die nur unter Windows laufen, benutzen zu können. Aber die meisten Kollegen, die Windows als Ihr Werkzeug nutzen werden sicher auch MinGW oder ähnliches installiert haben, um Unix-Werkzeuge nutzen zu können. Geht alles, wenn man will. mfg Torsten
Torsten R. schrieb: > Der OP schrieb nur von Software-Entwicklung. Die Hardware-Entwicklung > legst Du Ihm gerade in den Mund. Ja, aber wer ernsthaft sich mit µC beschäftigt, muss man sich schon mit der Hardware beschäftigen und da kann es vom Vorteil sein, zumindest HW-Kenntnisse zu besitzen d.h. mit dem Oszi die Ports kontrollieren und vllt. den ein oder anderen Widerstand oder Kondensator zu tauschen usw... Meiner Meinung sind die SW- und HW-Entwicklung eng verzahnt und sollte als Einheit betrachtet werden. Gruß Daniel
Martin K. schrieb: > Wichtig wäre mir noch, dass ich auch auf meinem Macbook damit arbeiten > könnte, da ich dieses als Arbeitsgerät verwende. Zu Arduinos gibt es zu > genüge Tutorials. Leider sind diese jedoch eher für den Hobbybedarf und > lassen sich deutlich leichter programmieren. Ist doch ideal. Günstig in der Anschaffung und es gibt schnelle Erfolgserlebnisse. Entgegen aller Unkenrufe kann man Arduino auch bei kleineren Aufgaben im semiprofessionellen Bereich und bei kleineren Serien einsetzen. Mit dem ESP8266 wird wird es am Ende sogar Netzwerkfähig. Wenns man damit nicht mehr weiter kommt, kann man immer noch auf ARM umsteigen. Daniel V. schrieb: > Also, allgemein kann man sagen, das AVR eigentlich einen ziemlich > schlechten Ruf in der Industrie hat. Zum lernen und eintauchen in die > µC-Welt sind die Dinger ganz gut, hab ich auch mit angefangen, aber > möchte man professionell arbeiten, kommt man an den ARM-Controllern > nicht vorbei. Die AVR sind leider relativ teuer und nicht sehr schnell. Dazu kommt noch der knappe Speicher, worunter, die vom Vertrieb gewünschte, schöne, GUI leidet. Ein 2*40 Textdisplay ist zwar meist ausreichend, aber eben nicht modern. Heute muss alles bunt und mit vielen, schönen, Logos sein. Am besten noch mit Touchscreen... Hinsichtlich zuverlässigkeit gibt es bei AVRs keine Probleme.
c-hater schrieb im Beitrag #4698024: > Ergo: Du bist ein Blinder Wichser ohne jede Ahnung von der Realität. > Oder schlimmer: Du lügst einfach wider besseren Wissens. Benimm dich und lese nochmal ganz genau durch was ich geschrieben habe. Ich arbeite in der Industrie und weiss daher worauf Wert gelegen wird. Schreiber schrieb: > Die AVR sind leider relativ teuer und nicht sehr schnell. Dazu kommt > noch der knappe Speicher, worunter, die vom Vertrieb gewünschte, schöne, > GUI leidet. Genau das ist der Knackpunkt. Für viel weniger Geld hat Du viel mehr Möglichkeiten. Alleine das Timersystem z.B. von STM kannste ganze Unibibliotheken füllen. Gruß Daniel
Daniel V. schrieb: > Ich arbeite in der Industrie und weiss daher worauf Wert gelegen wird. Aha. Und wie erklärst du dann mit deiner ultimativen Weisheit die Atmel-Verkaufszahlen? Jetzt komm, Butter bei die Fische...
c-hater schrieb: > Aha. Und wie erklärst du dann mit deiner ultimativen Weisheit die > Atmel-Verkaufszahlen? > > Jetzt komm, Butter bei die Fische... Leg mal die Verkaufszahlen von AVR und allen ARM nebeneinander. Nochmal, ich sage nicht das AVR schlecht ist, die Dinger haben ihre Daseinsberechtigung z.B. im Lowcost-Bereich. Aber der TO will in die Zukunft investieren und da ist m.E. das ARM-Pferd am sinnvollsten. Gruß Daniel
:
Bearbeitet durch User
Daniel V. schrieb: > Nochmal, ich sage nicht das AVR schlecht ist, die Dinger haben ihre > Daseinsberechtigung z.B. im Lowcost-Bereich AVR sind mittlerweile deutlich teurer als direkt vergleichbare 8051 oder PIC und werden bei großen Stückzahlen schon lange nicht mehr eingesetzt. Außerdem hat Microchip kürzlich die Preise für AVR und SAM deutlich erhöht, das macht man meist wenn man die Kunden von einem bestimmten Produkt abbringen möchte. Gleichzeitig wurden die PIC32 Minis extrem billig. c-hater schrieb: > Aha. Und wie erklärst du dann mit deiner ultimativen Weisheit die > Atmel-Verkaufszahlen? Welche Atmel-Verkaufszahlen? Du brauchst Dir doch nur mal die letzten Jahresberichte von Atmel auf der einen und Microchip oder Silabs auf der anderen Seite anzusehen.
Daniel V. schrieb: > Leg mal die Verkaufszahlen von AVR und allen ARM nebeneinander. Das ist sinnlos. Genau das begreifst du scheinbar nicht. Natürlich kann ein AVR8 z.B. kein Smartphone heutigen Kalibers antreiben. Das aber ist nicht der Punkt. Der Punkt ist: ein AVR8 kann sehr viel antreiben, was in seinen Anforderungen leistungsmäßig deutlich darunter liegt. Und er kann das mit wesentlich geringerem Energieverbrauch als selbst als ein M0. Das ist der Punkt. Und das ist, warum es die AVR8 nicht nur heute massenhaft im Einsatz ist, sondern auch der Punkt, warum er auch zumindest in der näheren Zukunft massenhaft im Einsatz sein wird. Mindestens jedenfalls so lange, bis irgendein ARM-Lizenznehmer was vergleichbar effizientes liefern kann. Derzeit kann das aber keiner. Nichtmal angesichts des (allerdings sowieso völlig schwachsinnigen und vermutlich auch schnell wieder ersterbenden) IoT-Hypes...
c-hater schrieb: >> Leg mal die Verkaufszahlen von AVR und allen ARM nebeneinander. > > Das ist sinnlos. Genau das begreifst du scheinbar nicht Und warum stellst Du dann die Frage? Hast Dich gerade selbst entlarvt. Bleib doch bei Deinen AVRs, ist doch alles gut. Jetzt wo Microchip Atmel übernommen hat, wirst Du eine goldene Zukunft haben. Fakt ist, das Preis/Leistungsverhältnis ist bei ARM-Controllern wesentlich besser und es macht in der Industrie Sinn, weil es Standard ist.
:
Bearbeitet durch User
Schreiber schrieb: > Die AVR sind leider relativ teuer und nicht sehr schnell. Teuer ist relativ, es gibt Nano Clones für 1,75 mit USB. Billiger als das geht es wohl kaum. Und niemand wird gezwungen, Arduino IDE zu verwenden. Was Schnelligkeit betrifft, so sind AVRs mit Sicherheit in oberen 10% der 8-bit uC. Und 90% der Befehle sind 1-Takt Befehle. IMHO sind die AVRs gar nicht mal so schlecht. Daniel V. schrieb: > Fakt ist, das Preis/Leistungsverhältnis ist bei ARM-Controllern > wesentlich besser. Ja, sicher. Nur kommt es auch auf die Anwendung an. War auch bei PC so. Die ersten fingen gerade mal mit 4,7MHz an, waren aber mit DOS schnell genug. Dann kam Windows und weil es so ein Mist war (und ist) müssten die Prozessoren immer schneller werden, um überhaupt im Laufe eines Tages irgendetwas zu Ende zu bringen. Also, wird mit immer mehr GHz und zusätzlichen Kernen das miserable OS kaschiert - siehe Windows und Android. Wenn man programmieren kann, ist ein AVR nicht selten schneller als ein ARM - effizienter auf jeden Fall.
c-hater schrieb: > Apple ist aber definitv raus. Ungefähr genauso, wie du mit der Programmiersprache C „definitiv raus” bist da. Nur, weil irgendwas in deine Birne nicht reingeht, heißt das nicht, dass es nicht funktioniert. Daniel V. schrieb: > Also, allgemein kann man sagen, das AVR eigentlich einen ziemlich > schlechten Ruf in der Industrie hat. Soso. Bist du „die Industrie“?
Marc V. schrieb: > Schreiber schrieb: >> Die AVR sind leider relativ teuer und nicht sehr schnell. > > Teuer ist relativ, es gibt Nano Clones für 1,75 mit USB. Billiger > als das geht es wohl kaum. Und niemand wird gezwungen, Arduino IDE > zu verwenden. Teuer nicht als absoluter Betrag, sondern teuer verglichen mit einem ARM gleicher Leistung. Wenn der AVR 2€ kostet und ein vergleichbarer ARM nur 1€ (oder noch weniger), dann ist der AVR eben einfach teuer. Je größer die Serie, desto höher der Kostendruck. Bei einer 10k-Serie gibts den höflichen Hinweis auf den Preis zu achten, bei einer 100k-Serie sitzt ein Kostendämpfungsbeauftragter im Team. Bei Hobbyprojekten gibts bei mir nur den Tiny2313, den Mega128 und den ESP8266. Probleme die ich damit nicht lösen kann, werden mit einem richtigen Computer (alles ab Raspberry aufwärts) gelöst. Nicht zwingend die eleganteste Lösung, aber dafür definitiv Zeitsparend und Nervenschonend. Ob man jetzt die Arduino-IDE, Bascom oder GCC nutzt ist Geschmackssache, meist führen alle Wege ans Ziel.
Marc V. schrieb: > War auch bei PC so. Die ersten fingen gerade mal mit 4,7MHz an, waren > aber mit DOS schnell genug. > Dann kam Windows und weil es so ein Mist war (und ist) müssten die > Prozessoren immer schneller werden, um überhaupt im Laufe eines > Tages irgendetwas zu Ende zu bringen. > Also, wird mit immer mehr GHz und zusätzlichen Kernen das miserable > OS kaschiert - siehe Windows und Android. Das Problem ist der Benutzer, der heute eben viele bunte Bilder, schöne 3D-Effekte, neue Schriftarten, einen XXL-Touchscreen... haben will. Wenn das eigene Produkt ein 2*40Textdisplay und das der Konkurenz einen XXL-Touchscreen, und am besten noch eine Cloud-Anbindung per Wlan und eine passende App, hat, dann kann der Vertrieb noch so gut sein, er wird nichts verkaufen! Beim PC das gleiche, bei einigen Programmen waren die alten Versionen für DOS oder Win3.11 benutzerfreundlicher wie die neuste Version für Win10. Am ende werden 50% der Rechenleistung für schöne Bildeffekte, 49% für aufgeblasene Bibliotheken, nutzlose Funktionen und Objektorientierung verbraten und das letzte 1% sorgt für den eigentlichen Nutzen.
Daniel V. schrieb: > Fakt ist, das Preis/Leistungsverhältnis ist bei ARM-Controllern > wesentlich besser und es macht in der Industrie Sinn, weil es Standard > ist. Genau, und mit einem ARM kann man natürlich eine LED zum blinken bringen. Kein Grund dafür einen AVR8 einzusetzen.
Martin K. schrieb: > ich würde mir tatsächlich gerne das STM32F4 bestellen wollen und dazu > auf ein Buch über den Cortex M4 zurück greifen. Mehr bräuchte ich ja > erst mal nicht oder? Das komplette Datenblatt des Prozessors. Jörg W. schrieb: > Bist du „die Industrie“? Wer ist die Industrie? Bei VW war es zumindest mal so, dass Sie einen alternativen Chip eines anderen Herstellers genannt haben wollten. Da fallen AVRs einfach raus. Gruß Jobst
Der passende Freitagsbeitrag. Alle holen die Keulen raus und prügeln sich bis zum nächsten Freitag.
Jobst M. schrieb: > Da fallen AVRs einfach raus. Danach würde so ziemlich alles außer einem 8051 rausfallen, und selbst die sind mittlerweile massiv herstellerinkompatibel. All die ARMs verschiedener Hersteller sind doch nicht untereinander austauschbar. Für solche 2nd-Source-Sachen lassen die Hersteller sich notfalls auf vertragliche Konstruktionen ein, mit denen ein anderer Hersteller das gleiche Bauteil produzieren kann, auch wenn er es normal sonst nicht im Handel anbietet.
Moby A. schrieb im Beitrag #4698521: > bekommt man gehäusetechnisch kleiner Ein ATtiny im SOT-23 ist 3x3 mm und ein LPC11A im WLCSP ist 2.5x2.5 mm trotzdem gebe ich Dir hier mal recht :-) Ein ATtiny im SOT-23 ist aber doppelt so teuer wie ein PIC10 im SOT-23 Und ein NE555 kostet davon nochmal die Hälfte ...
Lothar schrieb: > Und ein NE555 kostet davon nochmal die Hälfte ... Braucht aber deutlich mehr Außenbeschaltung.
Mittlerweile wurde es hier gefühlte 100 000 Male durchgekaut. Die Kriterien für die Wahl eines Controllers kann ganz vielfältig oder auch ganz banal sein. In jedem Fall muss er die gestellte Aufgabe erfüllen. Bei langlebigen Maschinen und Fahrzeugen muss eine langfristige Verfügbarkeit gesichert sein. Letztlich spielt der Preis auch eine wichtige Rolle. Aber auch Vorlieben von Chefentwicklern können ausschlaggebend sein. Das man jetzt sagt ich fange lieber damit oder mit dem an, weil der Controller eine hohe Verbreitung hat, ist für einen Berufsanfänger vielleicht von Vorteil, der schon in der ersten Firma völlig unerheblich sein kann, weil die schon immer irgendeinen Exoten benutzt haben und den weiter nehmen, weil sie sich damit schon so lange und gut auskennen.
F. F. schrieb: > In jedem Fall muss er die gestellte Aufgabe erfüllen. Da es dem TE nur um die pure (Selbst-)Beschäftigung mit Controllern geht, kann er einfach nehmen, was er schon hat. Wenn er dann wirklich mal im Arbeitsleben was mit Controllern zu tun bekommt, ist es ohnehin mehr als wahrscheinlich, dass es ein anderer Typ sein wird. Wichtig ist ja nur, dass man die grundlegende Art und Weise der Softwareentwicklung für Controller dann schon mal kennt, und dass man gelernt hat, wie man irgendeine Funktionalität aus den Beschreibungen im Datenblatt dann in realen Code umsetzt.
Daniel V. schrieb: > Industriestandard ist nun mal Windows, Keil und ARM. ...und wie viel kostet Keil?
Moby A. schrieb im Beitrag #4698584: > Dann langt ja der vorhandene AVR Übrigens Dein gelobter XMEGA kann nicht mal auf dem Xplained Board einfach mal so zum Laufen gebracht werden. Gib doch dort mal Support. Auf jedem LPC Board würde das hier sofort gehen :-) Beitrag "XMEGA verliert Pin Status"
Richard B. schrieb: > und wie viel kostet Keil Für Silabs uC z.B. gar nichts weil die eine Lizenz gekauft haben, die jeder einfach so nutzen kann. Für STM32 M0 ebenso (für M3 aufwärts allerdings leider nicht): http://www2.keil.com/stmicroelectronics-stm32
Richard B. schrieb: > ...und wie viel kostet Keil? Lothar schrieb: > Für STM32 M0 ebenso (für M3 aufwärts allerdings leider nicht): Bis 32kB Code ist dieser ebenso "frei". Reicht also um die ARMs kennenzulernen. http://www2.keil.com/mdk5/editions/lite Der Programmer Ulink2 hingegen kostet richtig Geld. Entweder man behilft sich mit einem Chinanachbau (nicht empfehlenswert) oder einen ST/Link V2 der wenige Euros kostet oder einem Nucluoboard, wo dieser schon integriert ist. Auch von Infenion z.B. der XMC1000 o.ä. bietet sowas an. Gruß Daniel
:
Bearbeitet durch User
Daniel V. schrieb: > Der Programmer Ulink2 hingegen kostet richtig Geld. Entweder man behilft > sich mit einem Chinanachbau (nicht empfehlenswert) oder einen ST/Link V2 Inzwischen haben viele Hersteller auf ihren ARM und 8051 Eval Boards für 25 EUR oder weniger einen J-Link Lite drauf der dem ULINK2 kaum nachsteht z.B. http://www.silabs.com/products/mcu/32-bit/Pages/efm32hg-stk3400.aspx https://www.silabs.com/products/mcu/8-bit/efm8-laser-bee/Pages/efm8-laser-bee-starter-kit.aspx http://www.nxp.com/products/software-and-tools/hardware-development-tools/lpcxpresso-boards/lpcxpresso-board-for-lpc1549:OM13056
Jörg W. schrieb: > a es dem TE nur um die pure (Selbst-)Beschäftigung mit Controllern > geht, kann er einfach nehmen, was er schon hat. Stimmt nicht, der TE wollte sich beruflich im Bereich der µC weiterentwickeln. Steht im ersten Post im ersten Satz. Lothar schrieb: > Inzwischen haben viele Hersteller auf ihren ARM und 8051 Eval Boards für > 25 EUR oder weniger einen J-Link Lite drauf der dem ULINK2 kaum > nachsteht z.B. Stimmt, ich hatte die Alternativen von STM und Infineon aufgezeigt. Aber man braucht diesen eigentlich nicht, es sei man entwickelt SW von mehreren verschiedenen µC-Herstellern. Auf der Arbeit habe ich einen zur Verfügung, privat arbeite ich am liebsten mit STM und mit dem ST/Link V2. Gruß Daniel
:
Bearbeitet durch User
Moby A. schrieb im Beitrag #4698721: > Der Xmega muß auch nicht gelobt werden. Dessen Möglichkeiten > sprechen für sich ;-) Man muss aber deutlich betonen, das die XMegas eine Seitenlinie der AVR8 sind, die sich nicht industrieweit durchsetzen wird. Das hat damit angefangen, das die Errata zu den Dingern Seiten gefüllt haben, einfache Dinge wie interner EEPROM nur mit Klimmzügen anzusprechen waren, die ADC nicht wirklich gut waren und z.B. das Xplained A1 Board zum Kennenlernen der Familie einen netten kleinen Hardware Bug hatte, der die PDI Programmierung behinderte. Atmel hat probiert, das in der Evolution der Chips zu verbessern, aber ein solcher Einstieg ist nicht günstig für eine MC Familie. Ich habe die Dinger gerne mal eingesetzt, würde sie aber vermutlich nicht in industriellem Umfeld verbauen.
:
Bearbeitet durch User
Daniel V. schrieb: > Bis 32kB Code ist dieser ebenso "frei". Reicht also um die ARMs > kennenzulernen. Man kann auch GCC nehmen, dann hat man keine Begrenzung. OpenOCD, oder CoIDE/Coflash (dann kostet der Programmer 25 Euronen). GCC kann mit Keil ohne weiteres mithalten, was den eigentlich C-Code angeht. Anders kann's bei den Libs aussehen, und besonders, wenn man unbedingt printf mit floating point haben will. Braucht man aber normalerweise nicht. Siehe hier: http://raisonance.com/tzr/scripts/downloader2.php?filename=T020/media/07/c9/1kmm1akx6gr&mime=application/pdf&originalname=AN0052-ARM-C-Benchmark.pdf
Moby A. schrieb im Beitrag #4698849: >> Dinge wie interner EEPROM > > Ja genau. Solche schönen Dinge fehlen EFM, ARM & Konsorten ;-) Deshalb ist ARM jetzt Mist, oder was? Nun, das ist in der Tat ein Nachteil und man muß ein EEPROM-IC zusätzlich vorsehen und über I²C oder SPI ansprechen, hat man weniger Platz auf der PCB und drei bis vier Pins sind weg. Die Vorteile (z.B. das Timersystem, Flexibilität, Leistung, usw.) überwiegen die Nachteile. Entweder man geht mit der Zeit (ARM) oder man bleibt stehen. Und ich beziehe das nur auf die berufliche Verwendung und das war die Frage des TEs, weil in der Cosumerindustrie überwiegend ARMs eingesetzt werden. Zudem ist ARM ja nur eine Architektur und den Herstellern bleibt es ja frei, wie sie ihre µCs bauen. Auch bin ich gespannt, wie sich die FPGAs entwickeln. Das könnte auch interessant werden. Nop schrieb: > Man kann auch GCC nehmen, dann hat man keine Begrenzung. OpenOCD, oder > CoIDE/Coflash (dann kostet der Programmer 25 Euronen). Stimmt. Aber ich glaube beim Debugging in Keil hat man trotzdem die 32kB-Grenze, bin mir da aber nicht ganz sicher. Gruß Daniel
:
Bearbeitet durch User
Lothar schrieb: > Auf jedem LPC Board würde das hier sofort gehen Haben die denn eine eingebaute Sicherung gegen ungeschickt agierende Benutzer? Dann würde ich wohl in Zukunft auch nur noch mit LPCs arbeiten, aber natürlich nur, wenn diese Sicherung auch gegen meine Ungeschicktheiten hilft. :-) Daniel V. schrieb: >> a es dem TE nur um die pure (Selbst-)Beschäftigung mit Controllern >> geht, kann er einfach nehmen, was er schon hat. > > Stimmt nicht, der TE wollte sich beruflich im Bereich der µC > weiterentwickeln. Und? Solange es dafür keinen konkreten Beruf und keine konkreten Anwendungen gibt, ist es trotzdem erstmal pure Selbstbeschäftigung, mithin völlig egal, auf welcher Hardware das passiert. Auch, wenn wir beruflich mittlerweile vorrangig mit ARMs arbeiten, wäre mir ein Bewerber, der in seinem Lebenslauf stehen hat, dass er schon mal ein paar kleine Experimente mit AVRs gemacht hat, allemal lieber als einer, der diese Erfahrung nicht vorweisen kann – erst recht dann, wenn derjenige im Gespräch dann zeigt, dass er diese Beschäftigung aus eigenem Antrieb heraus (und nicht nur als Pflichtpraktikum oder dergleichen) getan hat.
Jörg W. schrieb: > Auch, wenn wir beruflich mittlerweile vorrangig mit ARMs arbeiten, > wäre mir ein Bewerber, der in seinem Lebenslauf stehen hat, dass er > schon mal ein paar kleine Experimente mit AVRs gemacht hat, allemal > lieber als einer, der diese Erfahrung nicht vorweisen kann – erst > recht dann, wenn derjenige im Gespräch dann zeigt, dass er diese > Beschäftigung aus eigenem Antrieb heraus (und nicht nur als > Pflichtpraktikum oder dergleichen) getan hat. Ich bin doch 100% bei Dir, ich habe doch auch mit AVR angefangen, aus eigenen Antrieb heraus. Wenn aber einer im Lebenslauf Erfahrungen in AVR und ein anderer Erfahrung in ARM stehen hat, dann hat derjenige der ARM vorweisen kann, einen klaren Wettbewerbsvorteil. Moby A. schrieb im Beitrag #4698888: > Das ist ein schlechtes Argument. Dreh-und Angelpunkt sind nicht > irgendwelche Moden sondern welches Produkt einer konkreten App wirklich > angemessen ist. Da kann die Wahl durchaus auch auf ein ältereres= > ausgereifteres Produkt fallen. Während ARM-MCUs recht > herstellerspezifisch ausfallen sind Atmels 8Bitter ja doch eine > weitgehend homogene Familie-mit viel Auswahl: unter mehr als 600 > Derivaten. Nö, der Core ist immer der gleiche. Atmel ist doch auch nur ein Hersteller und ist herstellerspezifisch oder hat der den gleichen Kern wie z.B. ein PIC? Moby A. schrieb im Beitrag #4698888: > Na ja, vielleicht im Hochleistungs-Bereich !? Die Fritzbox und die ganzen Oszis haben die Dinger schon integriert. Kennengelernt habe ich die in der Signalverarbeitungsvorlesung an der Uni. Aber im Cosumerbereich wird es noch ein langer Weg. Gruß Daniel
:
Bearbeitet durch User
Daniel V. schrieb: > Wenn aber einer im Lebenslauf Erfahrungen in AVR und ein anderer > Erfahrung in ARM stehen hat, dann hat derjenige der ARM vorweisen kann, > einen klaren Wettbewerbsvorteil. Nö, so klar wäre der für mich nicht. Die Einarbeitung in einen ARM eines anderen Herstellers ist genauso viel Aufwand wie die Einarbeitung in einen ARM, wenn man bislang AVR gemacht hat. OK, ich lass mal die Variante außen vor, bei der man nur irgendwas mit irgendeiner IDE „zusammengeklickt“ hat, also die Einarbeitung sollte schon ein tatsächliches Kennenlernen des Controllers beinhalten, nicht nur ein ASF-Demoprojekt oder ein bisschen Arduino-IDE, bei denen dann die eigentliche Funktion in diversen Bibliotheken im Hintergrund liegt. Wichtig ist es, dass man wirklich die Funktionalität bestimmter Baugruppen anhand des Datenblatts sich erschließen kann und von da dann in eigenen Code umzusetzen in der Lage ist.
> Nö, so klar wäre der für mich nicht. Die Einarbeitung in einen > ARM eines anderen Herstellers ist genauso viel Aufwand wie die > Einarbeitung in einen ARM, wenn man bislang AVR gemacht hat. Hmm, der Sprung von AVR auf einen ARM ist m.E. größer als der Sprung innerhalb der ARM-Herstellerfamilie. Ist aber meine Erfahrung. >OK, > ich lass mal die Variante außen vor, bei der man nur irgendwas mit > irgendeiner IDE „zusammengeklickt“ hat, also die Einarbeitung sollte > schon ein tatsächliches Kennenlernen des Controllers beinhalten, nicht > nur ein ASF-Demoprojekt oder ein bisschen Arduino-IDE, bei denen dann > die eigentliche Funktion in diversen Bibliotheken im Hintergrund > liegt. Arduino ist glaub ich mehr für Anwender als für richtige Entwickler aufgrund wegen diesem schrecklichen Processing-Dingsbums gedacht. Die wollen nur, das es funktioniert und nicht warum es funktioniert. > Wichtig ist es, dass man wirklich die Funktionalität bestimmter > Baugruppen anhand des Datenblatts sich erschließen kann und von da > dann in eigenen Code umzusetzen in der Lage ist. 100% Zustimmung.
:
Bearbeitet durch User
Moby A. schrieb im Beitrag #4698933: > Natürlich. Aber die Art des peripheren Drumherum unterscheidet sich bei > verschiedenen ARM MCUs wesentlich mehr als innerhalb der AVR Familie. Weil das doch verschiedene Hersteller sind. Du vergleichst die Vielfältigkeit von AVR mit allen ARM-Herstellern. Äpfel und Birnen. Wenn dann musst Du AVR mit STM, Freescale oder Infineon von der Funktionalität vergleichen. Das da Unterschiede sind, ist doch klar, die wollen sich doch vom Mitbewerber abheben. Für ST hab ich mich entschieden weil das ein europäischer Hersteller ist ich diesen auch auf der Arbeit einsetzen kann. Moby A. schrieb im Beitrag #4698933: > Klar doch. Aber eben einer mit einer Riesen-Auswahl an > Ausstattungs-Varianten bei gleichem Core Viel Spass beim Suchen ;-) Moby A. schrieb im Beitrag #4698933: > Das ist das Entscheidende. > ARMes Imponiergehabe gehört dann eher zum Marketing ;-) Du weisst, das dies auf diese schrecklichen Arduino-Dingern bezogen ist?
:
Bearbeitet durch User
Moby A. schrieb im Beitrag #4698970: > Nein Daniel. Du hast doch gehört, die Einarbeitung von ARM zu einem > anderen ist bei gleichem Core mindestens so schwierig wie von AVR zu > ARM Spezifizier das bitte. Ob ich jetzt einen STMF0 oder STMF4 programmiere, ist doch egal. Manche Befehle in der StdLib sind etwas anders, dies kann man mit der CMSIS-Schreibweise (GPIOA->MODER|=0x00000000) auch umgehen. Das Datenblatt ist natürlich das A und O. Klar ist die Schreibweise bei anderen Hersteller etwas anderes aber der Core ist der gleiche. Wenn man aber schon einmal einen ARM programmiert hat, ist der Einstieg einfacher. Moby A. schrieb im Beitrag #4698970: > Das ist mit der parametrischen Suche überhaupt kein Problem. Suchen kostet Geld. AVR ist teurer als ein M0, aber er hat bereits alles an Board, und wenn man die Funktionen nicht braucht, nutzt man diese nicht. Und der Controller kostet weniger. Moby A. schrieb im Beitrag #4698970: > a doch, eben drum! > Was sich schnell mit Arduino lösen lässt spart größeren Aufwand- es sei > denn, die Lösung soll mit fetter ARM MCU imponieren ;-) Schlimm. Tja, dieser Thread ist echt wieder zu einem Kampf gegen AVR vs ARM ausgeartet daher gilt: Man sollte für jede Aufgabe den passenenden Controller auswählen. Für einfache Steuerungsaufgaben ist AVR sehr gut geeignet. Keine Frage. Möchte man z.B. Bildverarbeitung zur Objekterkennung machen ist man mit einem AVR aufgeschmissen. Da lohnt sich eher ein ARM-Controller. Gruß Daniel
:
Bearbeitet durch User
Moby A. schrieb im Beitrag #4698986: > (StdPeriph und HAL) Das ist ein sehr starkes Argument Deinerseits. Ich muss gestehen, das ich die HAL und diesen Cube bisher kaum nutze sondern die StdLib und die CMSIS weil ich zu jeder Zeit wissen will, was mein Code überhaupt macht. Bei dem HAL geschieht viel im vorborgenden (irgendwelche Magic Numbers usw.) und ist ist nicht immer nachvollziebar. (HAL9000 führt auch sein Eigenleben, xD).Was sich STM dabei gedacht hat, das kann ich Dir nicht sagen. Bei ARM (speziell ST) ist auch nicht alles Gold was glänzt, das gebe ich zu und wird Dir jeder objektiver Entwickler genauso sagen) Diesen Thread habe ich sehr lange beobachtet und deckt sich mit meiner bisherigen Erfahrung Beitrag "STM32: To HAL or not to HAL" Gruß Daniel
Daniel V. schrieb: > Moby A. schrieb: >> (StdPeriph und HAL) > > Das ist ein sehr starkes Argument Deinerseits. Ich muss gestehen, das > ich die HAL und diesen Cube bisher kaum nutze sondern die StdLib und die > CMSIS weil ich zu jeder Zeit wissen will, was mein Code überhaupt macht. Mist, falsch zitiert, Sorry, war nicht deine Aussage ;)
Daniel V. schrieb: > Was sich STM dabei gedacht hat, das kann ich Dir nicht > sagen. Das liegt doch auf der Hand - als vendor-lock-in.
Nop schrieb: > Das liegt doch auf der Hand - als vendor-lock-in. Liegt in der Tat nah, ich werde die HAL dennoch erstmal vermeiden so lange es geht. Moby A. schrieb im Beitrag #4699009: > Ist doch easy- und kostet keinen Cent ;-) Die Zeit die Du mit Suchen verbringst kostet schon Geld ;)
Moby A. schrieb im Beitrag #4698849: >> Dinge wie interner EEPROM > > Ja genau. Solche schönen Dinge fehlen EFM, ARM & Konsorten Selbstverständlich gibt es entsprechende kleine ARM Derivate mit EEPROM z.B.: LPC11xx ohne EEPROM LPC11Exx mit EEPROM Wie man am "E" erkennt :-) Die größeren ARM für LCD Displays haben ohnehin EEPROM: LPC178x oder LPC408x
Moby A. schrieb im Beitrag #4699113: > EEPROM bleibt bei ARM aber die Ausnahme. Das ist doch wurscht. Wenn ich einen EEPROM in einem Projekt brauche, egal ob XMega oder STM32, dann pappe ich einen 93C46 oder einen 24C01 für ein paar Cent ran. So habe ich das mit den ersten XMega dann auch gemacht, als mir die Errata der Kiste empfohlen haben, den EEPROM nur während Sleep(!) des MC zu schreiben. Das konnte ich mir bei dem Projekt einfach nicht leisten. Auch meine alten 8051 Projekte bekamen so ihren nichtflüchtigen Speicher.
:
Bearbeitet durch User
Autor: Matthias Sch. (Firma: Matzetronics) (mschoeldgen) >und z.B. das Xplained A1 Board zum Kennenlernen >der Familie einen netten kleinen Hardware Bug hatte, der die PDI >Programmierung behinderte. Ah, das war der Grund ... Ich hatte eine Ganze Zeit lang mit dem XPlained-Board gespielt und einen kleine Synthesizer darauf implementiert. Aber irgendwie hat das Ding eine undefiniertes Verhalten an den Tag gelegt. Meine Vermutung war, dass es ein Hardware-Defekt sein könnte. Ich habe AVRX-XPlained vollständig aufgegeben, weil es sowieso auf der Kippe stand, lieber vollständig auf ARM zu setzen.
Moby A. schrieb im Beitrag #4699181: > Kostet nicht nur Geld, Platz, ein TWI/SPI Modul samt genutzter IO-Pins > und mehr Flashspeicher, der auch noch mit komplexerer Ansteuer- Software > zu füllen ist ;-) Ich weiss nicht, wie komplex deine Routinen für SPI sind, aber ich brauche dafür 4 Pins, kein SPI/TWI Modul und etwa 50 Zeilen Software :-) Gerade die 93C46 sind idiotensicher und simpelst zu nutzen. > Mittlerweile sind die Xmegas (ich hab nur die A- und die neuen E-Typen > in Verwendung) uneingeschränkt einsetzbar. Aber eben erst mittlerweile. Ich wollte den Dingern eine Chance geben trotz des hohen Preises und sie vergleichen mit Mega168 und STM32F1 in genau der gleichen Anwendung - Sinus Ansteuerung einer dicken BLDC Maschine. Der Xmega hat sich dank AWEX da gut geschlagen, aber gewonnen hat der STM32F1 mit Advanced Timer. Ein STM32F4 o.ä. hätte aber alle anderen weit hinter sich gelassen. Markus schrieb: > Aber irgendwie hat das Ding > eine undefiniertes Verhalten an den Tag gelegt. Meine Vermutung war, > dass es ein Hardware-Defekt sein könnte. Das Problem mit dem A1 Board war eigentlich nur, das man einen weichen Pulldown (47k-100k) an den PDI Data Pin legen musste. Dann klappte die Programmierung mit AVRISP MkII gut und unauffällig. Da musst du bloss erstmal drauf kommen :-P
Moby A. schrieb im Beitrag #4699220: > Mittlerweile sind die Xmegas (ich hab nur die A- und die neuen E-Typen > in Verwendung) uneingeschränkt einsetzbar. Die Xmegas hätten damals warscheinlich auch auf meinen Tisch gefunden, wenn nicht diese bescheuerte Schnittstellenarmut wäre. Mit CAN und/oder Ethernet wär der bestimmt brauchbar gewesen. Am besten 2*CAN und 1*Ethernet zusammen in einem Gehäuse.
Moby A. schrieb im Beitrag #4699403: > CAN als drahtgebundenen Bus für die Ferne halte ich sowieso für > veraltet. Heute muß das drahtlos gehen! Langsam machst du dich echt lächerlich ^^ Wie kannst du nur so einen Unsinn behaupten? Und wie passt soetwas zu deinen AVR und ASM Moralpredigten?
Melde dich mal bei ST an, da kannst du dich für ein Eintagesseminar für Umgang mit ST Tools anmelden. Die fangen aber Anfang Oktober an. 12 Oktober in München. Ein Nucleo gibt es gratis dazu. Thema ist Umstellung der Software zwischen M0 und M4, Cube und HAL. Ich habe mich angemeldet aber noch keine Rückmeldung erhalten, also keine Garantie ob das wirklich statt findet. Als Entwicklungsumgebung ist Coocox und GCC sehr brauchbar und gratis. Wenn du Apple verwendest solltest du wirklich schauen welche Software läuft. Habe selbst keinen Apple aber habe gehört das die Verwendung von Freier Software oft mit erheblichen Problemen verbunden ist. Ich empfehle dir wirklich einen Linux Rechner oder Windows, weiß jetzt gar nicht ob die ST Tools unter Linux laufen.
aller Anfang ist schwer schrieb: > Als Entwicklungsumgebung ist Coocox und GCC sehr brauchbar und gratis. Gute Alternative. > Wenn du Apple verwendest solltest du wirklich schauen welche Software > läuft. Habe selbst keinen Apple aber habe gehört das die Verwendung von > Freier Software oft mit erheblichen Problemen verbunden ist. Ich > empfehle dir wirklich einen Linux Rechner oder Windows, weiß jetzt gar > nicht ob die ST Tools unter Linux laufen. Das ist z.B. bei Keil ein riesengroßer Nachteil, dass die IDE nicht unter Linux laufen. Appleprodukte in der Entwicklung? Ahhh ja. Apple hat seine Stärken in der Bild- und Videobearbeitung, in der Musikproduktion und Videoschnitt usw. Hätte ich auch sehr gerne um meine Fotos und Videos zu bearbeiten und schneiden (was aber auch mit Windows gut geht). Aber ernsthafte Elektronikentwicklung? Hmmm. Es scheint zu gehen aber mit Mehraufwand, wie ich hier im Thread gelernt habe. Gruß Daniel
:
Bearbeitet durch User
Moby A. schrieb im Beitrag #4699403: > Ja, mit CAN können die meisten AVRs nicht dienen- und allzuviele MCUs > mit Ethernet-Interface gibt der gesamte MC-Markt nicht her. Nicht allzuviele MCUs mit Ethernet? Nur mal Cortex-M: Atmel: 27 Stk. NXP : ~130 Stk. ST : ~150 Stk. Geht bei 64Pins los und die meisten davon haben mindestens 1x CAN. EEprom ist schon ungewöhnlicher aber zumindest die drei genannten Hersteller haben entsprechende Controller im Programm. Eth + CAN + EEprom in einem dürfte jedoch nicht dabei sein. 8x UART gibt es von ST und Atmel (Atmel Cortex-A5 sogar mit 10). DMA haben ohnehin die meisten ARMs. Noch irgendwelche Sorgen? PS: Nichts gegen deine AVR, habe sie selbst gerne verwendet aber mit irgendwelchen Features gegen die ARM Familie argumentieren zu wollen funktioniert nicht. PPS: Ganz vergessen: ;)
Moby A. schrieb im Beitrag #4699220: > So ist das eben wenn Technik nicht ganz ausgereift auf den Markt kommt. > Beispiele derer gibt es viele. Wer sich erinnert, der Xmega kam eh schon > mit großer Verspätung und Atmel wird da einen Kompromiß eingegangen sein > um die Sache nicht weiter endlos zu verzögern. Blablabla. Sie haben schlicht und einfach Mist gebaut. Und das wird der XMega Familie weiter anhaften. Ich halte eine Wette, das die Dinger mit der Übernahme von Microchip demnächst auslaufen. > So ein frühes Exemplar habe ich auch noch im Einsatz- man muß halt > wissen wofür man die Dinger dann verwendet. Die Errata-Liste sollte > man zuvor zur Kenntnis genommen haben... Nochmal Blabla. Wenn Atmel eine Weiterentwicklung einer bewährten MC Familie vorstellt, dürfen solche grundsätzlichen Sachen wie EEPROM usw. höchstens besser werden und nicht plötzlich kaputt sein. Ich kenne übrigens kein kommerzielles Gerät, welches mit XMega ausgestattet ist - auch weil sich der Preis gewaschen hat. Ein entsprechender STM32 oder LPC wird vermutlich nur ein Drittel kosten und reichlich mehr Rechenleistung bringen.
:
Bearbeitet durch User
Daniel V. schrieb: > Das ist z.B. bei Keil ein riesengroßer Nachteil, dass die IDE nicht > unter Linux laufen Das liegt aber auch daran dass die Linux-Jünger Eclipse überall so toll finden, deswegen gibt es eine Eclipse-Integration für Keil: http://www.keil.com/support/man/docs/ecluv/ecluv_instplugin.htm > Appleprodukte in der Entwicklung? Ahhh ja Hier hat tatsächlich einer einen Mac als Dienstrechner, mit Eclipse/Keil, ist genauso gut/schlecht wie unter Linux.
Daniel V. schrieb: > Appleprodukte in der Entwicklung? Ahhh ja. Wenn man keine Ahnung hat, einfach mal... Da du selbst keine dieser Gerätschaften besitzt, hast du offenbar auch überhaupt keine Ahnung, was alles geht. Software schreiben auf OS X ist tausend mal angenehmer als unter Windows. Bash, Make, GCC, git, svn, CMAKE, Python usw alles super easy über die Kommandozeile verwendbar. Keine Frickelscheiße mit MinGW oder sonstigem Blödsinn. Wer Klickibunti braucht, kann Eclipse nehmen. Und auch in HW-Entwicklung ist OS X nicht schlechter als Linux. Eagle läuft, Kicad läuft, LTSpice läuft usw. Was nicht geht, ist Altium, aber das geht auch unter Linux nicht.
Daniel V. schrieb: > Möchte man z.B. Bildverarbeitung zur Objekterkennung machen ist man mit > einem AVR aufgeschmissen. Da lohnt sich eher ein ARM-Controller. Ja, und das hast du bisher wie offt gebraucht? Daniel V. schrieb: > Apple hat seine Stärken in der Bild- und Videobearbeitung, > in der Musikproduktion und Videoschnitt usw. Sagt wer? Apple war vor ~20 Jahren Marktführer.
:
Bearbeitet durch User
Moby A. schrieb im Beitrag #4699472: > Horst schrieb: >> Langsam machst du... > > Gehört das wieder zu > > Horst schrieb: >> meinen Trollversuchen > > ??? Nein, diesmal nicht. Eher du, wenn du behauptest CAN ist überflüssig und sollte durch Funk ersetzt werden soll. Vielleicht siehst du es aus deiner kleinen Fricklerposition heraus nicht, wo in der Industrie überall CAN verwendet wird. Aber mit dir darüber zu diskutieren ist ohnehin sinnlos...
Horst schrieb: > Was nicht geht, ist Altium, aber das geht auch unter Linux nicht. Geht bei Linux klaglos unter VMware, würde es vermutlich auch auf OSX tun. Ich finde die Apple-Basherei von denjenigen, die so'n Ding noch nie auch nur ansatzweise (in den letzten 10 Jahren) mal in den Fingern hatten auch abartig.
Moby A. schrieb im Beitrag #4699629: > Du glaubst ja gar nicht wo in der Industrie schon Dampfmaschinen zum > Einsatz kamen... Schau nach vorne! CAN wird durch Ethernet abgelöst und > dieses wird drahtlos- so und nicht anders wirds kommen. So ein Bullshit. 'Wer Funk kennt, nimmt Kabel' kommt nicht von ungefähr. Gerade wo es auf Zuverlässigkeit ankommt, wird Kabel auch die nächsten 100 Jahre noch dominieren.
Horst schrieb: > Moby A. schrieb im Beitrag #4699629: >> Du glaubst ja gar nicht wo in der Industrie schon Dampfmaschinen zum >> Einsatz kamen... Schau nach vorne! CAN wird durch Ethernet abgelöst und >> dieses wird drahtlos- so und nicht anders wirds kommen. > > So ein Bullshit. 'Wer Funk kennt, nimmt Kabel' kommt nicht von ungefähr. > Gerade wo es auf Zuverlässigkeit ankommt, wird Kabel auch die nächsten > 100 Jahre noch dominieren. CAN hat ganz andere Eigenschaften als Ethernet oder gar Funk. Wer da Vergleiche der Art "alt vs. neu" aufstellt, hat sich schon disqualifiziert. Aber bald gibt es sichern Ethernetswitche im Motorraum von Autos und WLan-Antennen an der Heckklappe. Alle mit AVR und höchst Sprachlos.
Die Frage ist doch, wann werden Kernreaktoren denn endlich per ZigBee gesteuert!?
Moby A. schrieb im Beitrag #4699644: > Carl D. schrieb: >> CAN hat ganz andere Eigenschaften als Ethernet oder gar Funk. Wer da >> Vergleiche der Art "alt vs. neu" aufstellt, hat sich schon >> disqualifiziert. > > Na logo. Die Daten die über CAN transportiert werden sind ja auch > elementar anderer Natur ;-) > > Seit wann ist die Transport-Architektur für die Nutzdaten von Bedeutung? Also "anderer Natur" und gleichzeitig "egal". Moby A. schrieb: > Du glaubst ja gar nicht wo in der Industrie schon Dampfmaschinen zum > Einsatz kamen... Schau nach vorne! CAN wird durch Ethernet abgelöst und > dieses wird drahtlos- so und nicht anders wirds kommen. Was jetzt? Eigentlich war das ja nur eine Auffrischungsimpfung für meine Regel "nie mehr in Threads antworten, in denen der Fisch mitblubbert". Das muß wieder für einige Monate reichen.
Lothar schrieb: > Das liegt aber auch daran dass die Linux-Jünger Eclipse überall so toll > finden, deswegen gibt es eine Eclipse-Integration für Keil: Cool, das habe ich nicht gewusst, danke! Richard B. schrieb: > Ja, und das hast du bisher wie oft gebraucht? Aktuell arbeite ich an einem solchen Projekt. Objekterkennung und Optical Flow sind z.B. in der Robotik ein großes Thema. > Daniel V. schrieb: >> Apple hat seine Stärken in der Bild- und Videobearbeitung, >> in der Musikproduktion und Videoschnitt usw. > > Sagt wer? Apple war vor ~20 Jahren Marktführer. Erfahrungen. Wenn du Dich mit Video- und Fotografie oder dich mit elektronischer Musik (Traktor, Abelton) auskennst (da gehe ich nämlich nicht von aus) weiß man das Apple die Nase vorn hat. Zum Thema CAN: Wird häufig in Kraftfahrzeugen zur Motorsteuerungen, in Flugzeugen und fast bei jeder Steueranwendung eingesetzt. Selbst die Drohnen von dji kommunizieren über CAN. Gruß Daniel
:
Bearbeitet durch User
Jemand schrieb: > Die Frage ist doch, wann werden Kernreaktoren denn endlich per ZigBee > gesteuert!? Bluetooth, damit man die Steuerung auch mit dem Smartphone machen kann …
Moby A. schrieb im Beitrag #4699629:
> Bitte richtig lesen: Ich halte es für veraltet.
Sorry, das ist Unsinn, siehe mein voriger Post, den nicht nicht mehr
rechtzeitig editieren konnte.
Gruß
Daniel
Moby A. schrieb im Beitrag #4699672:
> 'Was ist' soll jetzt 'Wen' beeindrucken?
So wollte ich schreiben, konnte es nicht mehr editieren:
Sorry, das ist Unsinn, CAN wird häufig in Kraftfahrzeugen zur
Motorsteuerungen, in Flugzeugen und fast bei jeder Steueranwendung
eingesetzt. Selbst die Drohnen von dji kommunizieren über CAN.
:
Bearbeitet durch User
Moby A. schrieb im Beitrag #4699683: > Daniel V. schrieb: >> Sorry, das ist Unsinn, CAN wird häufig in Kraftfahrzeugen zur >> Motorsteuerungen, in Flugzeugen und fast bei jeder Steueranwendung >> eingesetzt. Selbst die Drohnen von dji kommunizieren über CAN. > > Ja Daniel. Du redest vom heutigen Ist-Zustand. > Mag sein, daß 'veraltet' angesichts der gegenwärtigen Einsatzvielfalt im > Augenblick noch übertrieben formuliert ist. Daß die drahtgebundene > Kommunikation aber mehr und mehr entbehrlich wird ist genauso fakt. > Ich sehe für den Einsatz von CAN keine zwingende Logik- das ist alles > höchstens historisch gewachsen. Gerade weil es so vielfältig ist. C ist auch schon 44 Jahre alt und damit viel älter als ich und Assembler ist sogar noch älter. Ist das nach deiner Meinung auch veraltet? CAN hat seine Daseinsberechtigung, und das zurecht. Wieso sträubst Du Dich gegen CAN? Werden die von AVR nicht unterstützt? ;) Gruß Daniel
Matthias S. schrieb: > Aber eben erst mittlerweile. Ich wollte den Dingern eine Chance geben > trotz des hohen Preises und sie vergleichen mit Mega168 und STM32F1 in > genau der gleichen Anwendung - Sinus Ansteuerung einer dicken BLDC > Maschine. Der Xmega hat sich dank AWEX da gut geschlagen, aber gewonnen > hat der STM32F1 mit Advanced Timer. Ein STM32F4 o.ä. hätte aber alle > anderen weit hinter sich gelassen. Rein aus Interesse: Hast du von Beginn an für die gewählte Ansteuerung des BLDC einen DSP von TI (Piccolo, Delfino o.ä.) ausgeschlossen? Gruß,
Daniel V. schrieb: > > Wieso sträubst Du Dich gegen CAN? Werden die von AVR nicht unterstützt? Schwierig in ASM zu nutzen. Ist keine blinkende LED -> Moby mag es nicht, man braucht es nicht und es ist so wieso unnötig kompliziert.
:
Bearbeitet durch User
Moby A. schrieb im Beitrag #4699699: > Im Bereich Smarthome schwört ja mancher auf seinen CAN-Bus Drahtverhau. > Gerade hierbei ist schon schön sichtbar, wie überflüssig der > Kabel-Aufwand ist, weil er viel flexibler durch Funklösungen ersetzt > werden kann. Du kannst doch nicht ein Smarthome mit der Kraftfahrzeugelektronik oder mit der Avionik vergleichen. Ich bitte Dich...
Daniel V. schrieb: > Aktuell arbeite ich an einem solchen Projekt. ...und dafür benutzt du einen µController? Daniel V. schrieb: > Erfahrungen. Als Hobby? Du redest von Consumer. Ich von Production und Finishing.
Moby A. schrieb im Beitrag #4699683: > Daß die drahtgebundene > Kommunikation aber mehr und mehr entbehrlich wird ist genauso fakt. Klar doch, Du würdest Motormanagement bestimmt per Bluetooth machen. Ebenso wie die Übertragung der Schubhebel vom Cockpit an die Engines eines A380. Drahtgebundene Kommunikation hat den großen Vorteil, daß man nicht ohne weiteres von außen dran teilnehmen kann. Wenn Du mal von Deinen LED-Blinkern zu ernsthaften Projekten kommst, fällt Dir vielleicht auch auf, wieso man da nicht möchte, daß sich rein technisch gesehen jeder in die Kommunikation einklinken könnte.
Richard B. schrieb: > ...und dafür benutzt du einen µController? Häh? Richard B. schrieb: > Als Hobby? Du redest von Consumer. > Ich von Production und Finishing. Der Fotograf bearbeitet seine Bilder mit was? Die Filmleute nutzen zum Schneiden was?
Moby A. schrieb im Beitrag #4699712: > Was das KFZ anbetrifft- nun, da wird sich die > gegenwärtige Busvielfalt (LIN, CAN, Flexray usw.) rein aus Kostengründen > auch nicht mehr lange halten Sorry, aber das ist jetzt absoluter Blödsinn. Die verschiedenen Busse werden für verschiedene Baugruppen eingesetzt (Motorsteuerung, Komfortsysteme, Sicherheitssysteme usw). Für den Fensterheber, der am LIN-Bis sitzt wird sicherlich kein Ethernet eingesetzt. Viel zu teuer.
:
Bearbeitet durch User
Alex schrieb: > Hast du von Beginn an für die gewählte Ansteuerung des BLDC einen DSP > von TI (Piccolo, Delfino o.ä.) ausgeschlossen? Von TI hatte ich ein TMS320 Derivat im Rennen, allerdings war es für ein Proof of Concept eine Frage der Zeit und ich hatte einfach nicht genug, um mich in Code Composer, Pure Path und den dahinterstehenden Unterbau einzuarbeiten. Von Freescale hatte ich einen 56F8013 dabei, der allerdings so mit Processor Expert abstrahiert war, das es mir in der kurzen zur Verfügung stehenden Zeit nicht möglich war, neue Codeblöcke zu generieren, die sich in PE eingefügt hätten. Mit Blockkommutierung allerdings spielte der Freescale schon ganz gut. Da ich auch ein fertiges Projekt für AVR8 da hatte, bot es sich einfach an, den Code auf XMega und STM32 mit SPL/CMSIS zu portieren und die jeweilige Peripherie dabei voll auszunutzen. Der Motorcode war dabei auch nur ein kliener Teil - da es sich um Antriebe für E-Mobilität handelte, war die Plausibilitäts- und Sicherheitssoftware wesentlich umfangreicher als der eigentliche Wirkcode für die Maschine. Ich wage zu behaupten, das dafür ein DSP nicht besser da steht als ein 'normaler' MC.
:
Bearbeitet durch User
Moby A. schrieb im Beitrag #4699629: > Das liegt ohnehin schon oberhalb typischer XMega-Anwendungen. Moby A. schrieb im Beitrag #4699723: >> daß sich rein technisch gesehen jeder in >> die Kommunikation einklinken könnte > > Ab einem gewissen Verschlüsselungsaufwand wird das praktisch unmöglich. Schöner Unsinn. Selbst wenn es nicht möglich wäre, sich in die Kommunikation einzuklinken, dann ist es trotzdem mit einfachsten Mitteln möglich, sie zu stören. Nur weil irgendwelche Nerds auf Kickstarter eine Handy App für Jalousien mit WLAN entwickelt haben, heisst das noch lange nicht, das z.B. die Industrie oder auch normale User da mitmachen. Und das ist schon gar nicht der Fall, wenn es um sicherheitsrelevante Dinge geht.
Moby A. schrieb im Beitrag #4699723: >> Ebenso wie die Übertragung der Schubhebel vom Cockpit an die Engines >> eines A380. > > Das ist zukünftig nicht ausgeschlossen. Das meinst du jetzt nicht Ernst, oder?
Daniel V. schrieb: > Moby A. schrieb im Beitrag #4699723: >>> Ebenso wie die Übertragung der Schubhebel vom Cockpit an die Engines >>> eines A380. >> >> Das ist zukünftig nicht ausgeschlossen. > > Das meinst du jetzt nicht Ernst, oder? Selber Schuld, du diskutierst mit Moby. Die meisten haben das vor langer Zeit aufgegeben.
Warum nicht beides? AVR und ARM? Dann kennt man beide Welten. Der Anschaffungspreis ist ja heutzutage auch kein Thema mehr. Bei AVR nimmt man irgendein Arduino und bei ARM irgendein Evalboard von LPC, ST, etc.. Am besten einsteigen mit AVR und dann ARM, ist definitiv einfacher. Ich glaub ich spinne, unser AVR LED Blinky ATtiny Moby will uns ernsthaft glaubend machen, drahtloses Ethernet wäre die Zukunft in Sachen Steuerungskommunikation. Na viel Spaß, das zuverlässig wie einen CAN Bus hinzubekommen. Nicht nur dass man sich damit ein Haufen neue Probleme einhandelt um das Ganze zu verkomplizieren (Vorteil?), nein man lädt sich auch noch viel mehr Aufwand auf. Und dann noch alles verschlüsseln, na klar, soll dann jede Baugruppe einen individuellen Schlüssel im Werk bekommen oder was? Nicht zu vergessen, dass man drahtlose Kommunikation leicht stören kann. Ein Störsignal auf das fahrende Auto richten und schon funktionieren die Bremsen nicht mehr? So ein Pech aber auch!
Daniel V. schrieb: > Der Fotograf bearbeitet seine Bilder mit was? Software: Photoshop und Co. Hardware: Egal Daniel V. schrieb: > Die Filmleute nutzen zum Schneiden was? Die "Filmleute" nutzen: Unix/Linux, Windows und OS X. Kein Filmstudio wird ausschließlich OS X einsetzen. Diese Zeiten sind seit 20 Jahren vorbei. Müsste ich jetzt alles alleine machen, würde ich für Video auch zwei, drei Mac's kaufen.
Moby A. schrieb im Beitrag #4699723:
> Das ist zukünftig nicht ausgeschlossen.
Laß mich mal raten - Du hattest nie irgendwie mit LBA, FAA & co zu tun?
Du weißt wahrscheinlich ohne Google-Hilfe nichtmal, was diese
Abkürzungen bedeuten, gelle. :-)
Moby A. schrieb im Beitrag #4699754: > TriHexagon schrieb: >> Ich glaub ich spinne, unser AVR LED Blinky ATtiny Moby will uns >> ernsthaft glaubend machen, drahtloses Ethernet wäre die Zukunft in >> Sachen Steuerungskommunikation. > > Nun, auch drahtloses Ethernet wird sich noch weiter entwickeln und > 'Drahtlos' ganz sicher zum Kommunikationsstandard avancieren, ganz egal > wie 'AVR LED Blinky ATtiny' Du Moby nun gerne abwerten willst. Mich > amüsiert, wie engstirnig hier manche 'Experten' am Kabel festhalten- dem > schon heute großen Erfolg drahtloser Kommunikation zum Trotz. Es mag schon sein, dass sich drahtlose Kommunikation immer weiter verbreitet und noch weiteres Potential inne hat. Aber es gibt ein großes, sehr großes Problem mit drahtloser Kommunikation, nämlich Störungssicherheit zu gewährleisten, vor allem in einer nicht labor-ähnlichen Umgebung mit mehreren Teilnehmern. Und das ist bei gewissen Steuerungen lebenswichtig. Dann kommt noch harte Echtzeit dazu, wird der Airbag zu früh ausgelöst, sind die Insassen tot, wird er zu spät ausgelöst sind die Insassen ebenfalls tot. Drahtlose Kommunikation hat richtig schlechte Eigenschaften, beschäftige dich mal damit. Vergleiche mal WLAN mit Ethernet, WLAN ist im Vergleich zu Ethernet einfach nur Scheiße (schlechte Bandbreite, schlechte Latenzen, schlechter Empfang)! Einziger Vorteil, man muss kein Kabel legen. Dieses "One size fits all" funktioniert nicht!
Moby A. schrieb im Beitrag #4699766: > Laß mich mal raten: Du weißt natürlich ganz genau, was in Zukunft > ausgeschlossen ist, gelle :-) "Alles geht" ist üblicherweise ein Symptom des Dunning-Kruger-Effektes. Du bist auf der Stufe, wo Du nichtmal die Probleme begreifst.
Moby A. schrieb in vielen Beiträgen:
> [extrem viel Scheiße]
Junge, Junge, es bleibt nur zu hoffen, dass du für immer bei deinen
Bastelprojekten bleibst und NIEMALS an irgendeinem Produkt mitwirkst,
was verkauft wird...
Horst schrieb: > Junge, Junge, es bleibt nur zu hoffen, dass du für immer bei deinen > Bastelprojekten bleibst und NIEMALS an irgendeinem Produkt mitwirkst, > was verkauft wird... Da Moby ohnehin nur auf AVR (was industriell geflopt ist) ein paar LED-Blinksachen (die sich nicht verkaufen lassen) beherrscht, muß man sich da wohl keine Sorgen machen. Im Grunde muß man ja AVR schon dankbar sein, daß sie auf die Industrie als Trollfilter wirken und Leute wie Moby von ARM fernhalten.
lächler schrieb: > Peter D. schrieb: >> Man muß erstmal eine Aufgabe in einzelne Module unterteilen, zu diesen >> einen PAP erstellen, bis man ihre Funktion verstanden hat, den PAP auf >> logische Funktion und Fehler überprüfen und erst dann kann man Code >> eintippen. > > PAP ist nett fürs Hobby und schnell hingekritzelt, aber so was von > "letztes Jahrtausend" ;-) > Zum Einstieg und für kleiner Aufgabe reicht meist trial and error. Erfahrene Entwickler haben im Laufe der Zeit ein Gefühl dafür entwickelt, wann sie ordentlich planen müssen, und wann sie einfach 'drauflos hacken können. Diese Erfahrung muß ein Einsteiger aber erstmal machen, und dazu gehört eben auch, mal verhunzten Spaghetticode-Projekt zu schreiben und ihn auch wieder aufräumen zu müssen. Es nutzt daher IMHO wenig bis nichts, einen Einsteiger mit Literatur zu Softwaredesign und -architektur zu bewerfen; das meiste wird er ohnehin nicht verstehen oder nicht richtig einordnen können. Das führt nur zu Leuten wie meinem ehemaligen Kollegen I., der zwar immer den Balzert auf dem Schreibtisch liegen hatte, aber trotzdem regelmäßig enorm schlechten, unles- und unwartbaren Code produziert hat. > Eine vertiefende Buchempfehlung: > > Elecia White: "Making Embedded Systems: Design Patterns for Great > Software" > https://www.amazon.de/gp/product/1449302149/ Eine Spitzenlektüre für Leute, die ihr erstes Dutzend Embedded-Projekte abgeschlossen haben und wissen wollen, was sie besser machen können. Vorher schadet so etwas eher als es nutzt, fürchte ich -- premature optimization is the root of all evil. :-)
Marc V. schrieb: > P.S. > Ich kritzel PAP zuerst aufs Papier, danach geht es mit Excel und > ein paar Macros weiter, Timeline wenn nötig und schon spuckt mir > Excel ein recht brauchbares Gerüst aus. Es gibt da für Windows, Linux und IIRC auch OS/X ein kleines Tool namens "dia", mit dem man nicht nur PAPs, sondern auch UML-Diagramme, Netzwerke und allerlei andere Dinge visualisieren kann. Vielleicht ist das ja auch was für Dich?
TriHexagon schrieb: > Vergleiche mal WLAN mit Ethernet, WLAN ist im Vergleich zu Ethernet > einfach nur Scheiße (schlechte Bandbreite, schlechte Latenzen, > schlechter Empfang)! Einziger Vorteil, man muss kein Kabel legen. Offensichtlich hat unser AVR Fan noch nie in einer Hochhausgegend mit dutzenden von WLAN Netzen probiert, ein Signal durchzubringen, wo jeder Kanal schon mit 8 Routern besetzt ist, die sich alle um die Zeitschlitze prügeln. Jaja, jetzt kommt Moby mit 'dann gehe ich eben auf 5,8Ghz'. So schlau sind die anderen aber auch und spätestens dann ist da genauso so ein Chaos. Auch weiss der Kandidat anscheinend nicht, das alles, was übers Internet passiert, dem Wesen nach unvorhersehbare Transportzeiten hat. Das die Betreiber jetzt auch noch mit aller Macht probieren, Streaming Services und VoIP da reinzuquetschen und deren Priorität dafür hochdrehen müssen, macht die Sache für andere Dienste auch nicht besser. Moby A. schrieb im Beitrag #4699745: >> Schöner Unsinn. Selbst wenn es nicht möglich wäre, sich in die >> Kommunikation einzuklinken, > > Ja was jetzt? > Unsinn oder doch unmöglich? Tja, wenn man nur die Hälfte zitiert, ist man verwirrt, was? >> dann ist es trotzdem mit einfachsten Mitteln >> möglich, sie zu stören > > Auch den dazu nötigen Aufwand kann man hoch treiben. Kann man, muss man aber nicht. Als Bösewicht kann ich mit simpelsten Mitteln auf fussballplatzgrossen Parkplätzen die Funkschlüssel aller Autos lahmlegen. Das gilt auch für alle Kommunikation auf 2,4GHz. > Unbemerkt muß die Störung ja nicht bleiben. Kann sie aber. Und wenn der Airbus Pilot nicht mitkriegt, das ein Spassvogel in der Kabine die Funkkopplung zwischen Höhenruder und Joystick lahmlegt, siehts ganz schlecht aus. Die Funkstrecke kann dann zwar rumjammern, das keine Verbindung da ist, das hilft dem Pilot aber nix. Schon 'Fly-by-Wire' war ein schwieriges Kapitel bei der Zulassung der ersten Airbusse - bei 'Fly-by-WLAN' würde bei der FAA (und sicher auch bei der NTSB, der EASA und dem LBA) der Vorhang fallen.
:
Bearbeitet durch User
Nop schrieb: > Moby A. schrieb: >> Das ist zukünftig nicht ausgeschlossen. > > Laß mich mal raten - Du hattest nie irgendwie mit LBA, FAA & co zu tun? > Du weißt wahrscheinlich ohne Google-Hilfe nichtmal, was diese > Abkürzungen bedeuten, gelle. :-) Lieber Moby, Beschäftige Dich mal mit der DO-178 B/C. Das sind Richtlinien für Softwareentwicklung im Luftfahrzeugbereich an der sich jeder halten muss. Die Hardwareäquivalenz ist die DO254 wo unterschieden wird, was zum z.B. komplex (Diskrete Schaltung meistens nicht komplex, µC mit DMA komplex, d.h. mehr Dokumentation, es darf nie, wirklich nie einen undefinierten Zustand auftreten, daher wird Ada in der Avionik als Programmiersprache eingesetzt, weil diese der Norm ANSI/MIL-STD 1815 entspricht, es kann und wird aber auch C eingesetzt, und bei wirklich zeitkritischen Sachen Assembler, was aber ganz selten vorkommt). Hier haben die 8Bitter sogar Vorteile, da sie meistens als nicht komplex eingestuft werden. Auch ist die Technologie wichtig. Auf Grund der kosmischen Strahlung dürfen keine zu kleine Technologieknoten eingesetzt werden. Insgesamt gibt es fünf DAL-Stufen (Design Assurance Level), welche die Sicherheitsanforderungen beschreiben. Es wird bewertet von A (Ausfall ist katastrophal) bis E (nicht relevant) Jetzt kannst Du mal überlegen, zur welcher Stufe die Steuerung der Engines gehören und niemals drahtlos angesteuert werden.
:
Bearbeitet durch User
Daniel V. schrieb: > Beschäftige Dich mal mit der DO-178 B/C. Das sind Richtlinien für > Softwareentwicklung im Luftfahrzeugbereich an der sich jeder halten > muss. Die Hardwareäquivalenz ist die DO254 wo unterschieden wird, was > zum z.B. komplex (Diskrete Schaltung meistens nicht komplex, µC mit DMA > komplex... Dies führt dazu, dass die Entwicklungskosten enorm in die Höhe getrieben werden. Als Ergebniss werden dann hoffnungslos veraltete und schlechtere Lösungen verwendet, worunter die Zuverlässigkeit und Sicherheit leidet. Berüchtigete Beispiele sind die altertümlichen und wartungsintensiven Magnetzündungen, Autopiloten die mit mechanischen Kontakten die Fluglage an einem vakuumbetriebenen Kreisel abgreifen, absolut unzumutbare Triebwerksüberwachungssysteme... Schon toll, wenn die Temperaturüberwachung des Motors aus einem Thermoelement und einem Drehspulinstrument besteht. Ermöglicht überaus genaue Temperaturmessugnen und Probleme bemerkt man damit erst, wenn man schon einen Kolbenfresser hat. Aber das merkt man auch ohne Messgeräte... Für manche Flugzeuge kann man ein genaueres Thermometer mit Datalogger und einem Sensor pro Zylinder nachrüsten, kostet nur 3000€ (für eine Cessna 152!!!) Die Kombination aus mechanischem Kreisel, Kolbenmotor und Graslandepladeplätzen sorgt auch für eine garantiert hohe Zuverlässigkeit, besonders wenn das Vakuum von einer ölfreien Vakuumpumpe erzeugt wird. Da ist der künstiliche Horizont öfter kaputt wie funktionsfähig... Zu Magnetzündungen werde ich mich jetzt nicht weiter auslassen. Die Nachrüstung von zigtausendfach bewährten Kollisionswarnsystemen ist bei Ultraleichtflugzeugen problemlos, bei Segelflugzeugen und Motorselglern erfordert sie etwas Papierkram, bei Sportflugzeugen viel teuren Papierkram und bei Hubschraubern ist sie praktisch unmöglich (halblegale/halbillegale Abhilfe: batteriebetriebenes Kollisionswarngerät mit Klettband aufs Amaturenbrett basteln). Besonders toll, wenn man weiß, dass Hubschrauber, Segelflugzeuge und Ultraleichtflugzeuge meist in einer ähnlichen Flughöhe betrieben werden.
Sheeva P. schrieb: > Diese Erfahrung muß ein Einsteiger aber erstmal > machen, und dazu gehört eben auch, mal verhunzten Spaghetticode-Projekt > zu schreiben und ihn auch wieder aufräumen zu müssen. Ich denke schon, daß es deutlich effizienter ist, wenn man die Erfahrungen anderer beherzigt und nicht alle Fehler selber wiederholen muß. Spaghetticode kann man nicht aufräumen, sondern nur wegschmeißen und nochmal neu anfangen. Sehr schön finde ich die Flowcharts im DS18B20 Datenblatt. Danach kann man wunderbar programmieren.
:
Bearbeitet durch User
Schreiber schrieb: > Dies führt dazu, dass die Entwicklungskosten enorm in die Höhe getrieben > werden. Als Ergebniss werden dann hoffnungslos veraltete und schlechtere > Lösungen verwendet, worunter die Zuverlässigkeit und Sicherheit leidet. Über gut oder schlecht ist gar nicht das Thema, wobei Du auf jeden Fall Recht hast. Es geht viel Zeit in die Doku herein und das macht die Entwicklung halt in der Luftfahrt sehr teuer. Was ich eigentlich mit dem Post sagen wollte (Hauptaugenmerk auf das Verkehrsflugzeug) ist, dass es fast unmöglich ist, im Flugzeug welche der Ausfall mit A, B oder mit Einschränkungen C nach DO-254 spezifiziert ist mit fast 100%iger Wahrscheinlichkeit drahtlos anzusteuern. Allein erst die technische Herausforderung der drahtlosen Kommunikation (Latenz, Störfestigkeit, Herausforderungen in der Signalverarbeitung, EMV etc.), dann die Verifizierung und die Zulassung + die Doku kostet ein Haufen Geld. Und dann ist immer noch die Gefahr durch das Eindringen von außen. Warum auch? Es gibt billigere Alternativen die auch sehr sicher sind. Und das wollte ich Moby nur klarmachen, das gerade im Luftfahrzeugbereich und auch im Automobilbereich nicht ohne weiteres alles drahtlos wird und der Vergleich mit Smarthome absolut fehl am Platz ist. Gruß Daniel
:
Bearbeitet durch User
Schreiber schrieb: > Berüchtigete Beispiele sind die altertümlichen und wartungsintensiven > Magnetzündungen, Autopiloten die mit mechanischen Kontakten die Fluglage > an einem vakuumbetriebenen Kreisel abgreifen, absolut unzumutbare > Triebwerksüberwachungssysteme... Sorry, aber das ist Quatsch. Die Cessna (15x) ist ~60 Jahre alt. Schon mal was von FADEC gehört? Schau dir bitte die Elektronik und Steuerung eine Mustang oder Phenom an.
Schreiber schrieb: > Die Nachrüstung von zigtausendfach bewährten Kollisionswarnsystemen ist > bei Ultraleichtflugzeugen problemlos, bei Segelflugzeugen und > Motorselglern erfordert sie etwas Papierkram, bei Sportflugzeugen viel > teuren Papierkram und bei Hubschraubern ist sie praktisch unmöglich > (halblegale/halbillegale Abhilfe: batteriebetriebenes > Kollisionswarngerät mit Klettband aufs Amaturenbrett basteln). Mir fällt gerade ein: Macht es eigentlich Sinn, bei einer Cessna ein TCAS einzubauen? Die Flugfläche ist doch eine ganz andere als bei einem Verkehrsflugzeug. Will man z.B. in den Dortmunder Luftraum eindringen, muss man sich am dortigen Flughafen anmelden d.h. eine Kollision mit einem großen A320 kann doch durch den Größenunterschied vermieden werden. Oder gibt es dadurch gravierende Vorteile?
:
Bearbeitet durch User
Daniel V. schrieb: > Mir fällt gerade ein: Macht es eigentlich Sinn, bei einer Cessna ein > TCAS einzubauen? Natürlich in den meisten Fällen nicht. Da wird sowieso auf Sicht geflogen und der meiste Verkehr dem man begegnet hat so was auch nicht, und dann bringt auch das eigene TCAS wenig. Man kann sich also sowieso nicht drauf verlassen. Und bei (Motor)Seglern? Also wirklich. Meistens kollidieren die mit einer Baumkrone, da hilft auch kein TCAS.
Cyblord -. schrieb: >> Mir fällt gerade ein: Macht es eigentlich Sinn, bei einer Cessna ein >> TCAS einzubauen? > Natürlich in den meisten Fällen nicht. Da wird sowieso auf Sicht > geflogen und der meiste Verkehr dem man begegnet hat so was auch nicht, > und dann bringt auch das eigene TCAS wenig. Man kann sich also sowieso > nicht drauf verlassen. Macht es eben doch, nur dass man hier kein TCAS sondern FLARM verwendet. Versuchen sie doch mal ein anderes Flugzeug in der Luft zu erkennen, etwa einen Tiefdecker der über ihnen fliegt (wenn sie selber in einem Hochdecker sitzen) Segelflugzeuge, Gleitschirme und Rettungshubschrauber sind auch fast nicht zu erkennen, wenn man selber in einem davon sitzt und entweder unter einer Wolke oder am Hang kurbelt (Segelflugzeug+Gleitschirm) oder (Hubschrauber) gerade 5 Hände und mindestens 10 Augen brauchen könnte. Damit es nicht so einfach wird: Das ganze im Hochgebirge. Segelflugzeuge sind weiß, die Gletscher im Hintergrund auch! Das FLARM kann dann noch mit einem ADS-B-Empfänger aufgerüstet werden und schon sieht man auch fast alle größeren Flugzeuge. Ein Transponder im Segelflugzeug ist auch nicht unüblich, damit man von diesen (und der Flugsicherung bei Wellen- oder Wolkenflug) gesehen wird. Wer schonmal an einem Flugplatz mit allem möglichem vom Learjet über Segelflugzeuge, Hubschrauber, Deppenwerfer(=Fallschirmspringerabsetzflugzeug) und normalen Sportflugzeugen gesehen hat, der lernt das sehr schnell zu schätzen. Richard B. schrieb: > Sorry, aber das ist Quatsch. > Die Cessna (15x) ist ~60 Jahre alt. Ok, die 152 war ein schlechtes Beispiel. Die 172 wäre ein besseres: Mit einigen Verbesserungen und Weiterentwicklungen wird die seit 1956 produziert. Das ist wie wenn VW den Käfer noch heute bauen würde, nur halt mit Klimaanlage, elektronischem Tacho und CD-Radio modernisiert... Dafür darf man dann verbleites Benzin (Mogas-STC gibts nicht für alle Triebwerke) tanken, Zündkontakte nachstellen und sich über undichte Heizungswärmetauscher (sehr gesund, Abgas mit Blei und Kohlenmonoxid in der Kabinenluft) ärgern. Wegen defekten Katalysatoren (gibts nicht) oder Lambdasonden (Gemischeinstellung macht der Pilot am roten Hebel nach Gefühl&Erfahrung) oder Problemen mit dem ABS (gibts auch nicht) bei rutschiger Landebahn muss man sich aber keine Sorgen machen. Hier hat sich seit 1956 nichts geändert... Richard B. schrieb: > Schon mal was von FADEC gehört? Ja. Allerdings gibt es auch heute noch mechanische, hydraulische und pneumatische Triebwerksregler bei Turbinen, entweder bei bewährten Konstruktionen oder wenn Elektronik (wegen der aufwändigen Zertifizierung) zu teuer ist.
Schreiber schrieb: > Macht es eben doch, nur dass man hier kein TCAS sondern FLARM verwendet. Cool, das wusste ich nicht. Danke Dir!
@TO High da hast Du aber wieder eine Diskussion los getreten. Auch wenn hier einige meinen, daß Arduino unter dem "Niveau" ist, bin ich der Meinung, daß man auch mit diesen Bretteln was lernen kann. Wenn man das ganze mal als Evalboard betrachtet, auf dem auch nur Arm oder Cortex verbaut ist, dann kann man damit sehr wohl in die µC Programmierung einsteigen. Man muß ja nicht die Arduino IDE zum Programmieren nehmen. Eclipse oder die GNU Tools gehen da genau so, man muß halt nur mehr Hirn einschalten. Letztendlich mußt Du dann für jeden µC die Dokumentation studieren, wenn was vernünftiges heraus kommen soll. Aber die Basis bzw. die Grundherangehensweise ist für jeden µC gleich - auch wenn dieser Arduino heißt. Sehr hilfreich zum Lernen ist das LernBetty Projekt von W.S.. Suche mal im Forum danach. Er zeigt wie man es machen kann und die Quelltexte sind auch ausreichend dokumentiert, so das man versteht was er da macht. Ein Manual als PDF gibt es auch zu dem Projekt. Die Betty Fernbedienung gab's mal bei Pollin. Ist jetzt aber aus - vielleicht mal bei eBay suchen. Gruß Zeno
Boah Moby was redest du für einen Scheiss! Damit ruinierst du echt den Ruf von uns AVR XMEGA Fanboys! Von wegen "Weiterentwickeln". Die Technik entwickelt sich sicher weiter, aber nicht die Physik, die ist seit ein paar Mrd Jahren so ziemlich stabil und für uns kleine Menschen sowieso und zwar absolut! Da entwickelt sich nichts weiter! Wer Funkt kennt, nimmt Kabel ist zwar ein absolut nichtssagendes Argument und wirkt einfach nur klugscheisserisch, aber trifft es auf den Punkt. Vergleich doch mal Funk mit Kabel. Funk: Bei Standardleitern omnidirektionale Ausstrahlung (ja, stark vereinfacht!) Kabel: Idealer Richtfunk! Ich kann ohne Probleme 10000000000001 Kabel nebeneinander legen und mit vernünftigen Design ohne Crosstalk nutzen. Mach das mal mit Funk! GEHT NICHT! Und wenn da mal ne Ecke kommt? Dann legst du das Kabel halt um die Ecke. MACH DAS MAL MIT FUNK!!! Um die Ecke funken hrhrhr das wärs mal!
Funk ist nichts anderes als mutwillig herbeigeführter Hyper-Crosstalk!
Peter D. schrieb: > Sheeva P. schrieb: >> Diese Erfahrung muß ein Einsteiger aber erstmal >> machen, und dazu gehört eben auch, mal verhunzten Spaghetticode-Projekt >> zu schreiben und ihn auch wieder aufräumen zu müssen. > > Ich denke schon, daß es deutlich effizienter ist, wenn man die > Erfahrungen anderer beherzigt und nicht alle Fehler selber wiederholen > muß. Das ist natürlich richtig; allerdings muß man die Erfahrungen anderer erst einmal verstehen können, um sie dann beherzigen zu können. Ansonsten ist das nur eine Übung in "premature optimization" des Entwicklers, der sich dann oft sklavisch an Rezepte und Lehrsätze hält, ohne sie verstanden zu haben und ohne zu wissen zu haben, wann und wie man sie anwendet und in welchen Fällen man davon Abstand halten darf, soll, oder sogar muß. > Spaghetticode kann man nicht aufräumen, sondern nur wegschmeißen und > nochmal neu anfangen. Das Problem bei Spaghetticode ist doch nicht der Code, sondern dessen strukturelle Mängel. Meist sind darin trotzdem ein paar Codeschnipsel enthalten, die man -- dann in sauber strukturiertem Code -- weiterhin verwenden kann. Das hängt immer davon ab, wie schlimm die Sache ist.
Dennis S. schrieb im Beitrag #4701623: > Fakt ist: Über Funk ist sichere Kommunikation möglich- der geht nämlich > in beide Richtungen und ist deshalb durchaus auch zur Rückbestätigung > aller Daten + Kommandos samt Fehlererkennung fähig. "Yes we CAN" ist > bald von gestern ;-) Offenbar versagt er aber bereits bei der Zuordnung der verschiedenen Accounts hier in µC.net ;-) Also bitte hier einfach bei "Moby AVR" bleiben und "Dennis S." in anderen Threads verwenden. Die Regel dürfte einem langjährigen Nutzer bekannt sein. Irgendwann verraten sie sich eben doch alle ;-) P.S.: Eine Antwort auf die Frage, warum einige hier überhaupt unter verschiedenen Nicks schreiben, habe ich die ganzen Jahre über auch als Moderator nicht finden können.
:
Bearbeitet durch Moderator
Moby A. schrieb im Beitrag #4700945:
> akuten Argumente-Notstand ;-(
Hahaha, du bist ja so viel besser mit deinen Argumenten, dass du schon
von mehreren Accounts aus postest, um nicht so allein mit der Meinung da
zu stehen. ^^
Danke an Chris für Aufdecken, ich habe herzlich gelacht und grinse
immernoch ;)
Chris D. schrieb: > Irgendwann verraten sie sich eben doch alle ;-) > > P.S.: Eine Antwort auf die Frage, warum einige hier überhaupt unter > verschiedenen Nicks schreiben, habe ich die ganzen Jahre über auch als > Moderator nicht finden können. Wie geil! Eigentlich sollten alle hier öffentlich sofort an den Pranger gestellt werden, wenn sie im gleichen Thread unter verschiedene Namen posten. So was ist Leuteverarscherei und das kann ich auf den Tod nicht ab.
Wer wäre nicht gerne mal ein ganz Anderer! (Doch der Zopf, der hängt ihm hinten)
Moby A. schrieb im Beitrag #4701774:
> Um dieses, und nur um dieses gehts mir letztendlich.
Um das Thema des Threads?
Glaub' ich nicht, darüber diskutierst du schon lange nicht mehr.
Aber der TE hat sicherlich genug Meinungen zu seiner Frage bekommen,
und irgendeine „definitive Antwort“ kann es auf so eine allgemein
daher kommende Frage sowieso nicht geben.
Über deine Meinung zur Funkkommunikation brauchen wir nicht weiter zu
diskutieren: du bist sowieso nicht davon abzubringen, wie du uns nun
wiederholt demonstriert hast.
Jörg W. schrieb: > Aber der TE hat sicherlich genug Meinungen zu seiner Frage bekommen, > und irgendeine „definitive Antwort“ kann es auf so eine allgemein > daher kommende Frage sowieso nicht geben. Der TE hat nach dem Start nichts mehr von sich hören lassen und ich hatte schon ganz oben mal angemerkt: Lothar schrieb: > Martin KI (mrnew) schrieb: >> Ich danke Dir für deine freundliche >> Antwort und bin um Informationen reicher > > Ist das hier ein K.I. Bot Test oder menschliche Ironie :-)
Wurden die komplizierte Konfiguration der ARMs bzw. scheinbar einige Bugs mit DMA und so erwähnt ? Ich meine auch von kompliziertem Bus-System gelesen zu haben.
H-G S. schrieb: > Ich meine auch von kompliziertem Bus-System gelesen zu haben. Interessiert aber den normalen Anwender erstmal nicht großartig. Das wird erst interessant, wenn man wirklich massiv Datendurchsatz braucht und drüber nachdenken muss, wer da wann auf dem Bus Priorität bekommt. Moby A. schrieb im Beitrag #4702280: > Bislang habe ich noch nichts Ernsthaftes vernommen, was der weiter > steigenden Bedeutung von Funk in der Kurzstrecken-Kommunikation im Wege > stehen würde. In vielen Fällen leider schon mal die Physik. Aber zwischen „steigender Bedeutung“ und „ist prinzipell in der Lage, alle drahtgebundene Kommunikation in diesem Bereich zu ersetzen“ ist ein himmelweiter Unterschied.
Jörg W. schrieb: > Moby A. schrieb: >> Bislang habe ich noch nichts Ernsthaftes vernommen, was der weiter >> steigenden Bedeutung von Funk in der Kurzstrecken-Kommunikation im Wege >> stehen würde. > > In vielen Fällen leider schon mal die Physik Und die Regulierung: http://www.heise.de/netze/meldung/Funkregulierung-Angriff-auf-alternative-Software-2803189.html
Moby A. schrieb im Beitrag #4702317:
> Welche ist denn Deiner Meinung nach nicht ersetzbar?
Hatten wir alles schon durchgekaut. Du willst es nur nicht akzeptieren.
Aber nochmal: alles, bei dem es 1.) auf definierte Reaktionszeiten
ankommt (dann fallen nämlich schon mal retry-basierte Protokolle
aus) und 2.) bei denen es eine garantierte Verbindung geben muss.
Funk ist immer anfällig für DoS. Selbst wenn du eine explizite
Frequenzzuteilung hast, kannst du DoS nicht verhindern, nur dass du
dann ein Anrecht auf Störungsbeseitigung hast. Bei einer allgemein
zugeteilten Frequenz teilst du dir diese aber immer erstmal mit
anderen, im Zweifelsfalle mit dem Mikrowellenofen, neben dem dein
Gerät steht. Der kann es sich durchaus leisten, 1 Watt durch die
Gegend zu pusten, denn sein einziger Grenzwert (außer den Bandgrenzen)
ist, dass es demjenigen, der davor steht, nicht gefährlich werden darf.
Eine explizite Frequenzzuteilung wirst du dir übrigens nicht leisten
wollen, für deren Kosten könntest du kilometerweise Kabel kaufen. :)
Physik: in einen Faradayschen Käfig funkt keiner rein, ein Kabel
bekommst du trotzdem dahin.
Was du natürlich völlig untern Tisch fallen lässt: keep it simple.
Um auf einer UART (kann ja auch RS-485 sein) ein Byte zu übertragen,
musst du ein IO-Register lesen (um zu sehen, ob der Sender frei ist)
und ein zweites schreiben (das eigentliche Zeichen). Eine
Funkkommunikation, gar noch mit Kryptographie (Verschlüsselung oder
[noch wichtiger] sichere Authentisierung) braucht einige 10 bis 100
Kilobyte an Code. CAN ist zwar ein bisschen aufwändiger als eine
UART, aber trotzdem noch weit von der Komplexität üblicher
Funkprotokolle entfernt.
Moby A. schrieb im Beitrag #4702364: > Das Management der Funkkonnektivität gehört zu den Dingen, die vor > dem Anwender verborgen sein sollten Das ist bald nicht nur vor dem Anwender verborgen sondern auch vor dem Programmierer. Heute gibt es noch ISM-Band SoC mit für die Programmierung voll zugänglichem uC Core z.B. CC1100 mit 8051. Bald wird es aber nur noch geschlossene SoC geben d.h. Dein dann externen uC gibt die Daten per UART oder SPI API an das Funk SoC und was dort damit passiert weisst Du nicht mehr. Vielleicht ist das Funk SoC abhörbar oder sogar hackbar, ohne dass Du es mitbekommst: http://www.heise.de/newsticker/meldung/Sicherheit-implantierbarer-Medizintechnik-Herzschrittmacher-von-St-Jude-Medical-sollen-hackbar-sein-3307510.html
Also der Moby AVR ist schon sehr beratungsresistent. Also ich kann die Argumente von Jörg schon gut nachvollziehen. Es gibt halt Sachen die mit Funkt problematisch sind z.B. schon eine simple Notauskette. Wir durften für unsere Großgeräte genau aus diesem Grund bis vor kurzem keine Funkbedienung benutzen. Wenn bei diesen Geräten der Notaus nicht funktioniert ist Moby einfach nur breit, es sei denn er bekommt es rechtzeitig mit und kann schnell rennen. Ich bin gerade dabei mir eine Wetterstation zu bauen und die ist kabelgebunden, weil die Vorhandene mit Funksensoren immer wieder mal Aussetzer hat, was sicherlich auch daran liegt das derzeit viel zu viel rum gefunkt wird und Netze sich gegenseitig stören. Im besten FAll wir ja die Verbindung nur langsam. Ganz üble Störer sind LAN-Dingens die übers Stromnetz funktionieren. Man muß auch nicht alles über Funk machen, obwohl ich auch zugeben muß daß WLAN schon eine feine Sache ist. Zeno
Moby, was machst du eigentlich beruflich, so oft und zu welchen Zeiten du hier rumhängst kannst du eigentlich nur Student sein? Wenn ja, sag bitte nicht, dass du Etechnik studierst...
Zeno schrieb: > Es gibt halt Sachen die mit Funkt problematisch sind z.B. schon eine > simple Notauskette. Not-Aus könnte man noch mit Funk hinbekommen, aber nur, wenn es nicht stört, dass im DoS-Fall halt lieber (safe state) alles ausgeht. Dann müssten sich die Geräte einfach periodisch unterhalten und bei Ausfall der Verbindung auf „Not-Aus“ gehen. Hat den zusätzlichen Nachteil, dass die Kommunikation dann permanent Energie verplempert, ist aber andererseits nicht viel anders als bei einer Stromschleife, die bei ihrer Unterbrechung einen Alarm auslöst. Failsafe eben. Moby A. schrieb im Beitrag #4702364: >> Funk ist immer anfällig für DoS. > > Funk mag in dieser Hinsicht schwieriger kalkulierbar sein, bewegt sich > deshalb aber trotzdem in naturgesetzlichem Rahmen, sprich: kommt > unabgeschirmt definitiv an. Die Störungs-Beherrschung ist allein eine > Frage technischen Entwicklungsstands. Daran merkt man, dass du von der dahinter liegenden Physik einfach keinen blassen Schimmer hast. Es hilft dir eben gar nichts, wenn dein Nutzsignal zwar „definitiv ankommt“, aber ein Störer 40 dB stärker ist. Genau diesen Fall kannst du jedoch nicht technisch verhindern bei Funkkommunikation. >> im Zweifelsfalle mit dem Mikrowellenofen, neben dem dein Gerät steht. > > Der gehört da eben dann nicht hin. Doch, der gehört genau da hin, denn für ihn ist das ISM-Band mal erfunden worden. Dass man das dann später noch missbraucht hat, um preiswert (ohne Einzel-Frequenzzuteilung) auch Kommunikation dort zuzulassen (zuerst mal war es CB im 11-m-ISM-Band, später dann Kurzstreckenfunk in den anderen ISM-Bändern), heißt natürlich nicht, dass man nun deshalb den echten ISM-Geräten dort den Betrieb untersagen könnte. Aber wie schon geschrieben, selbst auf einer einzeln (also nur einem bestimmten Anwender in einem Bereich) zugeteilten Frequenz kannst du DoS technisch nicht verhindern. Der Zustand, dass das Nutzsignal aufgrund eines Störers nicht aufnehmbar ist, kann bei Funk immer eintreten. Moby A. schrieb im Beitrag #4702390: > Wie wärs wenn Du mal mit Argumenten zum Thema kommst? Die willst du ja die ganze Zeit lang einfach nur nicht akzeptieren. Moby, falls es dich beruhigt: ich habe 10 Jahre lang in einer Entwicklungsabteilung gearbeitet, die Funk-ICs gebaut hat. Außerdem bin ich Funkamateur. Du darfst mir daher zutrauen, zumindest eine Idee von dem zu haben, was ich hier schreibe …
Es gibt ja nicht nur Konsumerelektronik. Z.B. im CERN wird bestimmt nichts über Funk gehen. Da werden CAN und Ethernet dominieren. Wir benutzen CAN für die in Geräte Kommunikation. Das macht die Verdrahtung sehr bequem (+24V, GND, CANH, CANL). Aber auch zwischen den einzelnen Geräten wird CAN einfach durchgeschleift. Bei kleiner Leistung brauchen die dann nichtmal eine eigene Stromversorgung, sondern speisen sich mit aus den 24V. Zunehmend wird auch Ethernet eingesetzt. Aber an Funk ist nicht zu denken, wie soll der in so ein 19 Zoll Rack eindringen?
Peter D. schrieb: > Aber an Funk ist nicht zu denken, wie soll der in so ein 19 Zoll Rack > eindringen? Vielleicht ja mit nem Hammer oder nen Schweißbrenner, den man dem Funk mitgibt :D Ne, mal Spass beiseite: Ich hab die Diskussion nur überflogen, kann aber beide Standpunkte verstehen/nachvollziehen. Von daher kann ich Moby AVR auch verstehen. Aber wie wäre es wenn man diese Diskussion (Kabel oder Funk) in einen eigenen Thread verlegt? Mit dem eigentlichen Thema hat das ja nix mehr zu tun.
Daniel V. schrieb: >> Wenn du Apple verwendest solltest du wirklich schauen welche Software >> läuft. Habe selbst keinen Apple aber habe gehört das die Verwendung von >> Freier Software oft mit erheblichen Problemen verbunden ist. Ich >> empfehle dir wirklich einen Linux Rechner oder Windows, weiß jetzt gar >> nicht ob die ST Tools unter Linux laufen. > > Das ist z.B. bei Keil ein riesengroßer Nachteil, dass die IDE nicht > unter Linux laufen. Appleprodukte in der Entwicklung? Ahhh ja. Zumindest AVR Entwicklung geht Problemlos. Ich muss oft zwischen C für AVR und Swift für die IOS App hin und her wechseln. Das sind einfach 2 Fenster im selben Programm. Freie Software installieren, z.B. Doxygen, ist allerdings ein Aufwand. Dazu muss ich im Terminal "sudo port install doxygen" eingeben.
:
Bearbeitet durch User
Moby A. schrieb im Beitrag #4702364: >> im Zweifelsfalle mit dem Mikrowellenofen, neben dem dein Gerät steht. > > Der gehört da eben dann nicht hin. Aua. Du weisst schon, warum ein Mikrowellenofen auf der Frequenz sendet, auf der er sendet? Oh, das hat was mit Physik zu tun - ist anscheinend nicht so dein Ding.
Fritz G. schrieb: > Zumindest AVR Entwicklung geht Problemlos. Ich muss oft zwischen C für > AVR und Swift für die IOS App hin und her wechseln. Das sind einfach 2 > Fenster im selben Programm. > Freie Software installieren, z.B. Doxygen, ist allerdings ein Aufwand. > Dazu muss ich im Terminal "sudo port install doxygen" eingeben. Ja genau das wollte ich sagen. Das sollte auch kein albernes Applebashing sein. Das kommt je nach Anwendung drauf an wozu Apple einfach besser geeignet ist. Moby A. schrieb im Beitrag #4702385: > Nö. Ich möchte Fakten auf dem Tisch und keine Weltanschauung. Sorry Moby, aber wenn Fakten auf den Tisch legen, willst Du es dennoch immer besser wissen. Es ist dann sehr schwer und anstrengend immer zu verschiedenen Sachverhalten sich zu äußern (siehe die Beispiele aus der Luftfahrt). Ich gehe davon aus, das hier im Forum gestandene und erfahrende Entwickler (ich selber zähle mich noch zu den Jungspunden und maße mir nicht an der allwissende superduper-Entwickler zu sein, ganz im Gegenteil, ich bin in meinem bisher kurzen Entwicklerleben schon heftigst aufs Maul geflogen) unterwegs sind. Die trittst Du ständig auf die Füße. Cyblord -. schrieb: > Selber Schuld, du diskutierst mit Moby. Die meisten haben das vor langer > Zeit aufgegeben. Leider bin ich selber erst seit einer Woche aktives Mitglied, aber die Erfahrung habe ich jetzt sehr schnell machen müssen. Gruß Daniel P.S. Für Sozialwissenschaftler und Psychologen muss dieser Thread eine wahrer Schatz sein ;)
:
Bearbeitet durch User
Moby A. schrieb im Beitrag #4703630: > M. K. schrieb: >> Von daher kann ich Moby AVR >> auch verstehen. Aber wie wäre es wenn man diese Diskussion (Kabel oder >> Funk) in einen eigenen Thread verlegt? Mit dem eigentlichen Thema hat >> das ja nix mehr zu tun. > > Gute Idee. Besten Dank für Dein Verständnis ;-) Klasse: M.K. schlägt einen neuen Thread vor, Moby bestätigt das mit "Gute Idee" und schreibt trotzdem hier noch einen Roman zu Funk & Kabel.... Warum verschmutzt Du diesen Thread noch mit Deinem Sermon zu Funk und Kabel? Du bist hier offtopic. Mach endlich einen neuen Thread auf, in welchem Du Dich und Deine Meinung dazu präsentieren kannst.
Moby, hast Du schonmal Pfefferminztee oder Baldrian probiert? ;-)
Daniel V. schrieb: >> Freie Software installieren, z.B. Doxygen, ist allerdings ein Aufwand. >> Dazu muss ich im Terminal "sudo port install doxygen" eingeben. > > Ja genau das wollte ich sagen. Das sollte auch kein albernes > Applebashing sein. Das kommt je nach Anwendung drauf an wozu Apple > einfach besser geeignet ist. Ich weiß jetzt nicht ob das ironisch von Fritz gemeint war ;)
Christopher J. schrieb: > Ich weiß jetzt nicht ob das ironisch von Fritz gemeint war ;) Nach nochmaligen Durchlesen war mir das auch klar ;)
Moby A. schrieb im Beitrag #4703630: > Den Eindruck habe ich nicht. Wenn, dann mangels Argumenten :-) Mit mangelnden Argumenten hat das, glaube ich, nur noch wenig zu tun. Ich finde dein Enthusiasmus für ASM und AVR grundsätzlich ja gut, aber egal wie weit du dich vom eigentlichen Thema entfernst, du kriegst einfach kein Ende. Ich denke deshalb geben die meisten dann irgendwann auf. Jeder hier weiß doch mittlerweile deinen Standpunkt, besser Standpunkte und dann bleib doch einfach bei deinen Empfehlungen, die du hier neuen Usern gibst, begründe sie gut und lass die Bekehrungsversuche sein. Ich bin auch vom ATtiny10 begeistert und für sehr viele Sachen reicht der völlig, aber wenn jemand die Kaffeemaschine mit einem uC der 100 Beine und 240Mhz hat, morgens pünktlich schalten will, dann lass ihn doch und versuche ihn nicht zu bekehren.
>> Leute, haltet Euch ans Thema. Ja, mach das... Them ist Einstieg Mikrocontroller AVR vs ARM? jedenfalls ist das der Titel des Threads.
Moby A. schrieb im Beitrag #4703924: > Leute, haltet Euch ans Thema. > Das wird hier genauestens kontrolliert ;-)) Hauptsache ist, dass du kontrolliert wirst.
Moby A. schrieb im Beitrag #4703924: > Leute, haltet Euch ans Thema. > Das wird hier genauestens kontrolliert ;-)) Die Mods haben ja schon recht, mittlerweile ist der Thread schon lange OT...
Moby, habe ich mich eigentlich irgendwie unklar ausgedrückt, als ich darauf hinwies, dass in einem Thread nur ein Nick verwendet werden darf? Da Du mit Deinen vielen Accounts offenbar nicht zurechtkommst, bleib doch einfach bei einem. Es besteht auch kein Grund, dann mit dem neuen "anonymen" Nick "Fallingborstel" plötzlich die Smileys wegzulassen und komplett ausfällig zu werden. Dies ist der letzte Hinweis.
Thread beobachten
Seitenaufteilung abschalten