Hallo liebe Gemeinde, ich hab mal wieder eine Frage zur Prozessorwahl. In der Vergangenheit hab ich am liebsten mit den AVR Megas gearbeitet. Nach einer längeren Pause möchte ich nun wieder einsteigen. Leider hab ich bei den AVRs etwas den Überblick verloren. Vor allem ist mir wichtig das der Controller den ich auswähle nicht in Kürze abgekündigt wird. Es sollte also eine moderne Generation sein. Welche Serie würdet Ihr wählen wenn es um Nachhaltigkeit geht? Das Projekt: Mal wieder ein Hausbus. Das Raspberri Pi bildet den zentralen host. Satelliten sind dann in den verschiedenen Unterverteilungen aktiv und werden per RS485 angesprochen. Es geht hier also um den Satellitencontroller. Der ist eigentlich nicht ziemlich intelligent sondern kommuniziert nur mit dem Host. Ca 14 Ausgänge, 16 Eingänge, 1 wire für Temp Sensoren und die RS485. Mehr brauchts nicht. Die Ausgänge können gerne per Relaistreiber (z.B. TPL9202) geschaltet werden, dann brauchts eine SPI. Danke für die Antworten.
Die Anzahl der Pins (16+14+1+3=34) legt einen 40/44 Pinner nahe. Wenns ein AVR sein soll, dann wäre das ein Mega164P/324P/644P/1284P oder ...PA. Gegenüber den alten Mega16/32 sind die stromsparender, schneller, und haben zusätzliche Fähigkeiten. Außer Altersstarrsinn gibt es keinen Grund, noch die alten Teile zu verwenden. fchk
RS485 ist für Hausbus nicht so gut geeignet. Nehme besser CAN. Als Prozessor nutze ich in meinem Hausbus STM32F103. Lese mal hier im Artikel STM32
Der grosse Vorteil bei den STM32 ist die Existenz extrem preisgünstiger Eval-Boards, den VL Discovery gibts so ab ca. 12 Euro und den F4 nur ein paar Euro teurer. Die kann man auf ein selbstgebautes Board stecken und fertisch. Die IDE muss man sich atwas zusammenbasteln, aber Coocox sollte schon recht gut und nahezu auf Anhieb klappen. http://www.coocox.org Programmiergerät brauchst du nicht, die Pins sind 5 Volt tolerant und die Chips sauschnell. Alles in allem können sie einen 8-pin ATTiny nicht ersetzen, aber alles was grösser ist, schon. Ich würde mir heute nicht mehr das Discovery VL zulegen (habe hier 2 Stück) sondern das STM32F4Discovery mit dem F4 - einfach weils viel mehr Rechenleistung bringt. http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1199/PF252419 Das STM32L Discovery hat ein kleines LCD und Sensorbuttons: http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1199/PF250990 und Das VL ist das billigste: http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1199/PF250863
... schrieb: > Verwendung eines AVR ist bereits Altersstarrsinn. Ja ne, is klar. Zum Relais schalten braucht es natürlich einen 64Bit 3GHz Quad-Core.
Markus Müller schrieb: > RS485 ist für Hausbus nicht so gut geeignet. Nehme besser CAN. Würde ich auch sagen. CAN macht die Software extrem einfach und ist sehr zuverlässig. Ich benutze den AT90CAN128.
Warum soll RS485 nicht geeignet sein? Das wird bsp. für Profibus mit Leitungen mit mehreren hundert Meter verwendet. Man kann ja die Übertragungsrate hinreichend niedrig wählen.
Bastler schrieb: > Warum soll RS485 nicht geeignet sein? Hat keiner behauptet. "nicht so gut" != "nicht". Ist eher mehr Arbeit als CAN, ganz besonders bei Multimaster-Betrieb, also z.B. bei Signalisierung von Ereignissen. CAN wurde als Hausbus erst interessant, als billige Interfaces verfügbar wurden, insbesondere auch in µCs integrierte. Für RS485 brauchts nur eine übliche UART.
:
Bearbeitet durch User
So, erst mal danke für die Antworten. Die Antwort von Frank K. (fchk) war genau das was ich gesucht habe bzw wonach ich gefragt habe. Es wird wohl ein 644P oder 1284P werden. Zu den anderen Antworten: Ob ich nun RS485 oder CAN verwende stand nicht zur Debatte. Die Entscheidung ist bereits gefallen. Das mit dem Altersstarrsinn hab ich als Dummenjungenkommentar eingestuft. Ich werde definitiv beim AVR bleiben. Ich hab keine Zeit mich mit einer neuen IDE+Programmer... auseinanderzusetzen.
Ich Habbichauch schrieb: > ... > Das mit dem Altersstarrsinn hab ich als Dummenjungenkommentar > eingestuft. > ... Nein, am AVR festzuhalten nachdem man etliche Zeit nichts mehr damit gemacht hat ist tatsächlich eine erste Form von Altersstarrsinn. Es gibt inzwischen jede Menge bessere (besser erhältlich, besser dokumentiert, preiswerter, einfacher handhabbare, debuggbare) Controller als AVR. Für ganz kleines Geld auch als fertige Boards mit allem drum und dran. Der genannte Cortex-Mx war nur der offensichtlichste. Neben den UARTs bietet der auch (mindestens) eine echte CAN-Schnittstelle. Die wird in spätestens 1 Jahr interessant, wenn es dir zum Hals raushängt, dass auf dem RS485 jeder Dreck einstört und du zu Fuss die Übertragung sichern musst. PS: Und da ARM von etlichen angeboten wird, ist eine Abkündigung (auch wenn sehr unwarscheinlich) kein Beinbruch. Solange man sauber programmiert hat, läuft das Programm vom ST 1:1 auch auf einem NXP.
:
Bearbeitet durch User
Roland Ertelt schrieb: > Solange man sauber > programmiert hat, läuft das Programm vom ST 1:1 auch auf einem NXP. Na das ist ja toll. Dann kann ich ein Programm vom ST32F407 auf einem LPC4350 laufen lassen? Ein guter Witz! Ich Habbichauch schrieb: > Ich werde definitiv beim AVR bleiben. Ich hab keine Zeit mich mit einer > neuen IDE+Programmer... auseinanderzusetzen. Gute Entscheidung!
Wird hier inzwischen ernsthaft empfohlen einen ARM zu benutzen um Relais über RS485/CAN anzusteuern? Meine etwa 15 Jahre alten Treiber mit AT90S2313 kann ich problemlos mit Tiny2313 reparieren, dank Sockel ohne Werkzeug. Das schwierigste daran war die neuen Registerbezeichnungen zu finden. ARMs gibt es fast monatlich neue, die Vorgänger werden natürlich sofort abgekündigt. Aktuelle Entwicklungen können nach 2 Jahren nicht mehr repariert werden weil die Bauteile nicht mehr verfügbar sind, grad erst erlebt. Warum soll man also keine AVRs nehmen wenn sie den Zweck erfüllen?
Hallo Roland, > wenn es dir zum Hals raushängt, dass auf > dem RS485 jeder Dreck einstört welch harsche Aussage, ich glaube ich leide auch schon an diesem Altersproblem - stützt mich. RS485 ist doch ein differenzieller Bus. Jede Störung hebt beide Signale um das gleiche Potential an, nur der Unterschied der beiden Leitungen ergibt die Information, daher stört die Störung nicht. Ich dachte, deswegen setzen wir in der Industrie RS485 (Profibus, etc.) ein. Teile Dein Wissen mit uns ... Dein Geist zu meinem Geist, Deine Gedanken zu meinen Gedanken...
> > welch harsche Aussage, ich glaube ich leide auch schon an diesem > Altersproblem - stützt mich. RS485 ist doch ein differenzieller Bus. > Jede Störung hebt beide Signale um das gleiche Potential an, nur der > Unterschied der beiden Leitungen ergibt die Information, daher stört die > Störung nicht. Ich dachte, deswegen setzen wir in der Industrie RS485 > (Profibus, etc.) ein. > > Teile Dein Wissen mit uns ... Dein Geist zu meinem Geist, Deine Gedanken > zu meinen Gedanken... Genau, auch jedes Ethernet funktioniert mit differenziellen Schnittstellen im gbit Bereich über > 100 Meter. Sicher und robust.
Peter Dannegger schrieb: > > Ja ne, is klar. > Zum Relais schalten braucht es natürlich einen 64Bit 3GHz Quad-Core. AVR Fan was, Wenn du später aber mal ein TFT anschließt dann wars das mit den AVR . Zum zweiten sind die AVR's teuerer als zB. ein STM32 . Aber jder hat seine eigene Meinung.
A. K. schrieb: > Endlich mal ein Controllerkrieg, in dem kein PIC vorkommt. ;-) Sei doch nicht so ungeduldig, Das Wort PIC ist ja schon gefallen ;-)
Oliver R. schrieb: > Wird hier inzwischen ernsthaft empfohlen einen ARM zu benutzen um Relais > über RS485/CAN anzusteuern? Ja. Ich schließe mich dem an. Um in einem Hausbus die Nodes ans Netz zu kriegen ist sowas wie LPC11C24 nicht von den AVRs zu schlagen. Inclusive CAN-Transceiver in einem noch gut handelbaren TQFP 48 für 2,26€. Da ist der Softwaretreiber und der CAN-Bootloader auch schon im ROM. Einfacher gehts kaum. CAN ist als Hausbus deutlich besser geeignet als ein selbst erfundenes RS485 Protokoll. Die Industriebusse auf RS 485 Basis sind halt historisch gewachsen und werden oft überwiegend von nur einem Master gesteuert. Es macht die Sache sehr einfach im CAN Treiber einen Filter auf die interessanten MSGs zu setzen und nur auf das zu reagieren was wichtig ist. Wenn die Node ein Taster ist, versendet sie einfach eine Msg bei Betätigung. Es ist ein riesiger Vorteil sich nicht um das Protokoll und die Kollisionen auf dem Bus kümmern zu müssen. Ich würde aber auch keinen STM32 an dieser Stelle verbauen. Schon allein wegen dem dort nicht vorhandenen CAN-Bootloader. Ausserdem sind sie incl. Transceiver knapp doppelt so teuer.
Erst: Ich Habbichauch schrieb: > Vor allem ist > mir wichtig das der Controller den ich auswähle nicht in Kürze > abgekündigt wird. > Es sollte also eine moderne Generation sein. aber dann : Ich Habbichauch schrieb: > Ich werde definitiv beim AVR bleiben. Ich hab keine Zeit mich mit einer > neuen IDE+Programmer... auseinanderzusetzen. Klassischer Troll-Thread.
m.n. schrieb: > Na das ist ja toll. Dann kann ich ein Programm vom ST32F407 auf einem > LPC4350 laufen lassen? > Ein guter Witz! Ah ja.. so treffen wir uns wieder. Nee, das worüber du dich lustig gemacht hast ist eben KEIN Witz. Eine ganze Reihe con Peripherie-Cores sind in gleicher Form sowohl bei ST als auch bei NXP anzutreffen, beispielsweise SDIO. Da kann man - wenn man in den #define's SDIOxxx gegen MCIxxx austauscht - exakt den gleichen HW-Treiber benutzen. Nebenbei gesagt, scheinen mir die Core-Unterschiede innerhalb von NXP größer zu sein als zwischen NXP und ST. Und was die Firmware-Teile betrifft, die oberhalb der HAL werkeln, da ist es in ganz vielen Fällen wirklich 1:1 austauschbar. Ich sehe hier mal von Spezereien ab, die einen ganz bestimmten Cortex erfordern wie beispielsweise DSP-Routinen in Assembler usw. oder Peripherie, die es beim jeweils anderen überhaupt nicht gibt (32 Bit externer Bus, SDRAM, TFT-Interface...) W.S.
Henning schrieb: > Zum zweiten sind die AVR's teuerer als zB. ein STM32 . achja? Dann zeig doch mal ein Beispiel im < 1€ Bereich. Und EEprom sollte er auch haben.
W.S. schrieb: > Da kann man - wenn > man in den #define's SDIOxxx gegen MCIxxx austauscht - exakt den > gleichen HW-Treiber benutzen. Ist letztlich auch egal, aber unter Programm verstehe ich den .obj-Code und nicht die Quelldatei. So, wie ich Dich bislang verstanden habe, programmiert man die ARMen Kerne doch am besten in Assembler. War das nicht so? ;-) Mit der gleichen Quelldatei für unterschiedliche µCs kann man sich die übelsten Programmfehler einhandeln. Ein scheinbar funktionierendes Programm bleibt unerwartet irgendwo hängen, weil dort ein 'Kompatibilitätsloch' im Code vorhanden ist. Ja ich weiß, sollte man schon vorher alles testen. Aber wer entwickelt und erprobt denn ein Programm für unterschiedliche ARMe zur gleichen Zeit? Schließlich will man mit dem vorhandenen Controller fertig werden. W.S. schrieb: > oder Peripherie, die es > beim jeweils anderen überhaupt nicht gibt Gutes Argument für mich :-) Vergleich mal die jeweilige Anzahl und Art der Timer. Wieviele Quadratursignale können ein STM32F407 und ein LPC4350 per Hardware verarbeiten? Das sind doch die Kriterien, nach denen man sich den Typen und den Hersteller aussucht. Es paßt eben vorne und hinten nicht.
Für nur einen Client sehe ich auch eher nicht die Notwendigkeit für so viel Speicher und viele Ein/Ausgänge - mit Relais über SPI braucht man auch dann die vielen Pins nicht mehr. Da reicht sogar schon eine kleinerer AVR, also etwa MEGA164 oder auch ein Mega164 mit weniger Pins. Beim Speicher kann man unabhängig von den IO's wählen - das Programm kann fast unverändert (z.B. gleicher C Sourcecode) vom Mega 164 bis 1284 laufen. Von der Programmierung hat sich bei den AVRs nicht viel verändert. Da macht die Pause nicht viel aus. Wenn man wirklich in den Bereich eines Mega1284 kommt, also so viel Speicher braucht, dann ist wirklich ein ARM als Alternative zu überlegen. Bei mehr Speicher (vor allem über 128K Falsh) kommt die 8 Bit Architektur einfach an eine Grenze und gegenüber eines AVRs mit viel Speicher ist auch der Preis der ARMs Attraktiv - nur ist halt die Bauform nur als SMD mit recht engen Pins, also nichts mehr fürs Steckbrett oder Lochraster.
>Eine ganze Reihe con Peripherie-Cores sind in gleicher Form sowohl bei ...
Also, dass Peripherieteile selbst bei unterschiedl. Herstellern zu 100%
gleich sein sollen, kann -sofern das überhaupt irgentwo vorhanden ist-
nur eine absolute Ausnahme sein, auf die man niemals setzen sollte!!!
Zumal sich unterschiedl. Controller-typen ja gerade auch durch
unterschiedl. Periferie unterscheiden.
(Manche Perif-Teile sind sogar innerhalb gleichen Hersteller anders.)
MCUA schrieb: > Also, dass Peripherieteile selbst bei unterschiedl. Herstellern zu 100% > gleich sein sollen, kann -sofern das überhaupt irgentwo vorhanden ist- > nur eine absolute Ausnahme sein Das ist dann bei ARMs der Fall, wenn dafür das gleiche Modul von ARM mit eingekauft wurde. Zumindest die ersten Luminary Micros bestanden weitgehend daraus, aber sonst scheint das bei den I/O-zentrierten µCs heute eher selten zu sein - diese Module sind nicht grad der Knüller.
:
Bearbeitet durch User
m.n. schrieb: > aber unter Programm verstehe ich den .obj-Code und nicht die Quelldatei. Im Kontext von Windows-PCs ja, bei Linux und bei µCs nicht.
W.S. schrieb: > Eine ganze Reihe con Peripherie-Cores sind in gleicher Form sowohl bei > ST als auch bei NXP anzutreffen, beispielsweise SDIO. Und sonst, ausser SDIO? Z.B. UART, Timer, GPIO, CAN, ADC, Suchesdiraus, alle völlig verschieden.
:
Bearbeitet durch User
Wenn man Code schreibt und schon zu Beginn die HW-Ansteuerung und die Programmierung sauber trennt, dann würde man bei Wechsel ST <> NXP <> andere nur den Code der HW-Ansteuerung anpassen müssen, jedoch das eigentliche Programm muss wenig bis nicht angepasst werden. Ich habe auf diese Weise die UART Ansteuerung vom AVR zum PIC und ARM portiert, ohne dass die die eigentliche Intelligenz (Buffer, Auswertung usw.) anpassen musste. "Ich Habbichauch" will keinen neuen Prozessor, mit den neuen Features in den Peripherieeinheiten, also braucht man ihn auch nicht weiter überzeugen versuchen. Wer nicht lernen will, muss sich eben mit der "Zurückgebliebenen" Peripherie Funktionalität eines AVR zufrieden geben/herum ärgern. Alleine schon die GPIO Möglichkeiten eines STM32F4xx sind genial.
Markus Müller schrieb: > Wenn man Code schreibt und schon zu Beginn die HW-Ansteuerung und die > Programmierung sauber trennt, dann würde man bei Wechsel ST <> NXP <> > andere nur den Code der HW-Ansteuerung anpassen müssen, jedoch das > eigentliche Programm muss wenig bis nicht angepasst werden. Eben. Wobei es aber schon mal vorkommen kann, dass völlig andersartig arbeitende komplexe I/O-Module Einfluss auf die Gesamtstruktur eines Programms nehmen. > Ich habe auf diese Weise die UART Ansteuerung vom AVR zum PIC und ARM > portiert, ohne dass die die eigentliche Intelligenz (Buffer, Auswertung > usw.) anpassen musste. Weshalb der Prozessorkern selbst keine entscheidende Rolle spielt, zumindest so lange man sich nicht nachträglich Klimmzüge zur Adressraumtrennung antun muss (so etwa bei ARM => AVR). Der spielt eher eine monetäre Rolle, in Form des evtl. teueren Entwicklungssystems.
> Wenn man Code schreibt und schon zu Beginn die HW-Ansteuerung und die > Programmierung sauber trennt, Ich nehme mal an, das ist eine Verallgemeinerung über das Programmieren an sich (embedded, PC, abstrakt etc. halt alles was unter Programmieren fällt), dann mag das so richtig sein - in Thread-kontext ist es aber nicht. Wenn es kleine Satelliten sind, dann besteht kaum ein Grund, die 20 Zeilen Code für die Hal von den 20 Zeilen Code für die Logik streng zu trennen. Mehr noch, es kann den Unterschied zwischen kleineren und größeren yC bedeuten. Da mehrere yC vom TO geplant sind die mit hoher Wahrscheinlichkeit 24/7 laufen, wird er versuchen, sowenig Energie wie möglich für die Satelliten zu verbrauchen. Und unter diesem Aspekt sind eigentlich die STMs gegenüber den 'OldSchool'-AVRs im Nachteil ( Bei oben gegebener Aufgabe). > Wenn du später aber mal ein TFT anschließt dann wars das mit den AVR . Welcher Entwickler käme auf die Idee, sämtliche mögliche Features in das Pflichtenheft eines einfaches Projekt zu stecken und danach die Hardware zu wählen? Selbst Adobe hat mindestens Zehn Versionen gebraucht, um den Reader bis zur Lächerlichkeit aufzublasen. Vermutlich ist es einfacher, in diesem Fall einen eigenen erweiterten Satelliten zu bauen. > Klassischer Troll-Thread. .. ist ein sehr merkwürdiger Schluß, aber nachvollziehbar wenn man nicht genau liest: OT sucht nicht nach Rat zur Wahl der Prozessorfamilie, sondern um Rat zur Wahl des Modells innerhalb der 8bit-AVR. Dass es viele gibt, die ihm zum "Blick über den Tellerrand" ermutigen, ist löblich aber eher akademisch. Mich würde eher interessieren, welches Bussystem es denn geworden ist.
Finds schon irgenwie nervend, immer wieder diese ständige Missionierung zum ARM, wie die Zeugen Jehovas. Wenn man schon den AVR kennt, was spricht dagegen, ihn weiter einzusetzen. Man kommt dann viel schneller vorwärts, als erstmal was neues lernen zu müssen. Einfach nur AVR-Studio installieren und los gehts. Auch ist die Unübersichtlichkeit der ARM-Typen und Hersteller nicht gerade hilfreich, für welchen soll man sich denn nun entscheiden? Umständlich ist auch die Unterteilung in Usermanual und Datasheet, warum kann nicht alles wichtige in einem Dokument stehen? Gibt es überhaupt für ARM eine ähnlich einfach zu handhabende freie Programmierumgebung, wie das AVR-Studio? Wenn ich manchmal lese, man muß sich den Compiler erstmal selber compilieren, patchen oder spezielle Linkerscripte erstellen, na vielen Dank auch, ich wüßte Besseres mit meiner Zeit anzufangen. Bezüglich CAN vs. RS-485, war ja nur ein Vorschlag, um sich die Programmierarbeit drastisch zu erleichtern. Wenn man sich mal RS-485 Protokollstacks anschaut, die das gleiche leisten, wie die CAN-Hardware, sind die meistens schon mehrere 10kB groß. Für CAN würde ich um die 0,1 .. 1kB ansetzen.
Gästlein schrieb: >>... > > Genau, auch jedes Ethernet funktioniert mit differenziellen > Schnittstellen im gbit Bereich über > 100 Meter. > > Sicher und robust. Wenn du dir die Mühe machen würdest, mal auf Hardwareebene Ethernet mitzulauschen, würdest du maßlos erschrecken. Da ist nix "sicher und robust". Das sieht nur auf Anwendungsebene so aus, weil man nicht sieht dass die Rahmen zigmal übertragen werden. > RS485 ist doch ein differenzieller Bus. > Jede Störung hebt beide Signale um das gleiche Potential an, nur der > Unterschied der beiden Leitungen ergibt die Information, daher stört die > Störung nicht. Typischer Theoretikerfehler. Für RS485 gilt: sobald die Störung mehr als 5V in den Bus indiziert ist die Information Schrott. Und da ist es völlig Latte, ob die Störung Gleich- oder Gegentakt ist. Da reichen 2kV über die Koppelzange aus, um das zu sehen. > Ich dachte, deswegen setzen wir in der Industrie RS485 (Profibus, etc.) > ein. Nein. Der Transceiver ist billiger als RS232 und braucht keine 4 Kondensatoren für die Ladungspumpe.
Roland Ertelt schrieb: > Da ist nix "sicher und robust". Das sieht nur auf Anwendungsebene so > aus, weil man nicht sieht dass die Rahmen zigmal übertragen werden. Ethernet-Karten und intelligente Switches haben Fehlerzähler. Ein Netz mit solchen Daten ist kein normaler Betrieb, sondern übelst. In einem normalen Netz sind Fehler die Ausnahme. Sollte andererseits tatsächlich ein korrektes Netz vorliegen, dass aufgrund von massiven Störungen solche Fehler liefert, dann wärs Zeit mal die Quelle zu beseitigen oder auf Glas zu gehen.
:
Bearbeitet durch User
Die ganze Einarbeitung in die komplexe ARM-Welt lohnt für den Hobbyisten dann und nur dann, wenn man tatsächlich diese Leistungsklasse benötigt. Ansonsten kommt man mit AVRs deutlich schneller, oft auch sehr viel kompakter und stromsparender ans Ziel. Das übersieht der industrielle ARM Profi sehr gerne, wenn er geringschätzig auf die kleinen 8-bittigen AVRler herabschaut.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.