mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Einstieg Mikrocontroller AVR vs ARM?


Autor: Martin KI (mrnew)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst auch "Arduino" Board ohne Arduino Ide nutzen. Unter anderem 
solltest du selber wissen, welcher Mikrocontroller deine Anforderungen 
erfüllt.

Autor: Martin KI (mrnew)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Blackbird (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin KI (mrnew)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für deine Infos! Damit kann ich was anfangen :) Ich werde mich 
diesbezüglich mal einlesen. Auch über die Buchempfehlung

Autor: Peter Dannegger (peda)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Martin KI (mrnew)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Als Buchempfehlung:

Weniger schlecht programmieren

https://www.amazon.de/Weniger-schlecht-programmier...

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Martin KI (mrnew)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Cyblord ---- (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alexander Brickwedde (Firma: floodping.org) (alexbrickwedde)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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? 
;)

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Torsten Robitzki (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: lächler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: ASM Superprofi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: c-hater (Gast)
Datum:

Bewertung
-10 lesenswert
nicht lesenswert
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...

Autor: Torsten Robitzki (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Torsten Robitzki (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Schreiber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Deepdiver99 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ARM !

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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“?

Autor: Schreiber (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Schreiber (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Forist (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: F. Fo (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der passende Freitagsbeitrag.
Alle holen die Keulen raus und prügeln sich bis zum nächsten Freitag.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Und ein NE555 kostet davon nochmal die Hälfte ...

Braucht aber deutlich mehr Außenbeschaltung.

Autor: F. Fo (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Richard B. (r71)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel V. schrieb:
> Industriestandard ist nun mal Windows, Keil und ARM.

...und wie viel kostet Keil?

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/ef...
https://www.silabs.com/products/mcu/8-bit/efm8-las...
http://www.nxp.com/products/software-and-tools/har...

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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
Autor: F. Fo (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias S. schrieb:
> Man muss aber deutlich betonen,

Danke für diesen interessanten Beitrag!

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?...

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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
Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Lothar (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Horst (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: aller Anfang ist schwer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Stefan (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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:  ;)

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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
Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_i...

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

Autor: Horst (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Richard B. (r71)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Horst (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Horst (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Carl Drexler (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist doch, wann werden Kernreaktoren denn endlich per ZigBee 
gesteuert!?

Autor: Carl Drexler (jcw2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 …

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß,

Autor: Cyblord ---- (cyblord)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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
Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: Richard B. (r71)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nop (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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
Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Cyblord ---- (cyblord)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: TriHexagon (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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!

Autor: Richard B. (r71)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nop (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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. :-)

Autor: TriHexagon (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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!

Autor: Nop (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Horst (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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...

Autor: Nop (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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. :-)

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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
Autor: Schreiber (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Richard B. (r71)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Cyblord ---- (cyblord)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Schreiber (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schreiber schrieb:
> Macht es eben doch, nur dass man hier kein TCAS sondern FLARM verwendet.

Cool, das wusste ich nicht. Danke Dir!

Autor: Carl Drexler (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moby du hast den "." vergessen.

Autor: Zeno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: ASM Superprofi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: ASM Superprofi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Funk ist nichts anderes als mutwillig herbeigeführter Hyper-Crosstalk!

Autor: Sheeva Plug (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
7 lesenswert
nicht lesenswert
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
Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: F. Fo (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. Landolt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer wäre nicht gerne mal ein ganz Anderer! (Doch der Zopf, der hängt ihm 
hinten)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: H-G Sch (haenschen)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Lothar (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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-...

Autor: Zeno (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Horst (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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 …

Autor: Peter Dannegger (peda)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: M. Köhler (sylaina)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Fritz Ganter (fritzg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Chris F. (chfreund) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Moby, hast Du schonmal Pfefferminztee oder Baldrian probiert? ;-)

Autor: Christopher Johnson (christopher_j23)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 ;)

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Ich weiß jetzt nicht ob das ironisch von Fritz gemeint war ;)

Nach nochmaligen Durchlesen war mir das auch klar ;)

Autor: F. Fo (foldi)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Bernd N (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
>> Leute, haltet Euch ans Thema.

Ja, mach das... Them ist Einstieg Mikrocontroller AVR vs ARM? jedenfalls 
ist das der Titel des Threads.

Autor: Kardan (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Moby A. schrieb im Beitrag #4703924:

> Leute, haltet Euch ans Thema.
> Das wird hier genauestens kontrolliert ;-))

Hauptsache ist, dass du kontrolliert wirst.

Autor: Daniel V. (voda) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
6 lesenswert
nicht lesenswert
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.

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.