Hallo zusammen! Ich bin auf der Suche nach einem mc zum Anfangen. Ich habe vorher eine berufsbildende Schule mit dem Schwerpunkt Elektrotechnik gemacht. Mitlerweile studiere ich Elektronik an einer FH. Hab mir in den letzten Jahren C++ und Qt angeeignet und möchte mich nun ein bisschen mit embbeded systems beschäftigen. Des weiteren verwende ich auch Linux als Betriebssystem und möchte, das natürlich auch mal am mc ausprobieren. Ich weis, dass ist alles recht viel fürs Anfangen, aber ich hab mir mal gedacht ich schreib alles rein, was ich so in den nächsten Jahren vor habe. ich hoffe auf eine spannende Diskussion! Danke im voraus!
Als Student solltest Du es schaffen, mit der Suchfunktion die vielen Diskussionen zum Thema zu finden...
Für den absoluten Anfang in die Mikroelektronikwelt kann ich nur immer wieder den 8-bit AVR empfehlen, allerdings ist die Programmierung dort sehr hardware-nah, so dass du mit C wesentlich besser bedient bist als mit C++. Es gibt für die AVRs auch ein sehr gutes Tutorial hier http://www.mikrocontroller.net/articles/AVR Linux kann man dort natürlich nicht drauf laufen lassen. Es ist eben die Frage, was du alles erlernen möchtest... Ob es dir "nur" darum geht einen High-Performance Mikrocontroller zu programmieren, oder ob du auch die komplette Hard-ware drum herum selber entwerfen möchtest. Wenn letzteres der Fall ist sollte man mit "kleinen" und "langsamen" 8-bit MCUs anfangen. Schöne Grüße, Alex
Jeder Controller ist für den Anfänger gedacht... sofern man Datenblätter lesen kann und ein bisschen was in der Birne hat. Also ich habe mit PICs angefangen und arbeite heute noch relativ gerne damit. Da ich jedoch größtenteils C# programmiere und nicht ASM wäre ein Umsteig auf jeden anderen Controller ein reiner Formalakt. Seit etwa einem Jahr beschäftige ich mich auch mit ARM7 und ARM9 Controllern. Wenn du Linux verwenden möchtest (nicht µCLinux), dann kann ich ARM9 nur empfehlen. Vielleicht ist die Einarbeitungszeit in einen ARM9 etwas schwieriger als in einen PIC oder AVR, dafür hast einen Controller der reichlich Performance liefert. Schlussendlich entscheidet aber deine Applikationen welchen Controller du nehmen sollst... Um eine LED anzusteuern brauch ich weder Linux noch ARM, dafür braucht man noch nicht mal einen Controller ;-) Ich persönlich würde dir raten mit einem Controller anzufangen der auch von entsprechenden Tools unterstützt wird. Es bringt nichts wenn du einen "simplen" Controller besitzt, der grade mal ein paar Cent kostet, wenn du dann deine Firmware nur im Schneckentempo entwickeln und debuggen kannst... Deswegen ist mein Vorschlag für dich mit einem SAM7 von Atmel durchzustarten. Zum Entwickeln würd ich IAR (Compiler) und einen Wiggler Clone (Debugger) besorgen. Die Hardware kostet dir in etwa 100€. Wennst dich in den SAM7 eingelebt hast, ist ein Umstieg auf einen Linux fähigen ARM9 recht einfach. Hardwarekosten etwa 170€.
Hallo, wie wäre es mit dem MSP430? http://msp430.com Mit dem eZ430F2013 wird Dir sogar ein komplettes Entwicklungspaket als USB-Stick geboten. Reichelt/Conrad > 40 € oder bei TI 20$. http://focus.ti.com/mcu/docs/mcuprodmsptoolsw.tsp?sectionId=95&tabId=1203&familyId=342&toolTypeId=1 Gruss Klaus.
erstmals danke für die vielen Antworten. Es wird wohl ein arm werden hab in eurem shop den arm mit display gefunden, ist das anfängertauglich? im internet hab ich dann noch ein anderes ARM Borad gefunden: AT91EB40 Kennt das jemand? Ist das anfängertauglich?
Ich würd zum Anfangen das Olimex Board SAM7-P256 kaufen. Dafür gibts bereits Beispielprogramme.
Olimex hätte ich jetzt auch empfohlen... Das ist auf jeden Fall gute Ware!
> Es wird wohl ein arm werden hab in eurem shop den arm mit display > gefunden, ist das anfängertauglich? Was möchtest du dir zuerst aneignen, die hardwarenahe Programmierung auf µCs oder die Programmierung auf Embedded-Linux? Das sind zwei ziemlich unterschiedliche Dinge: Die hardwarenahe Programmierung lernst du am besten mit einem einfachen 8-Bit-Controller. Das schnellste Erfolgserlebnis hast du sicher mit einem AVR (typischerweise einem ATmega8). Dessen "Support" hier im Forum ist optimal, da wahrscheinlich über 80% aller µC-Bastler Erfahrungen damit hat. Es gibt viele preisgünstige Einsteigerboards. Wenn du dich mit Embedded-Linux beschäftigen möchtest, würde ich dir für den Anfang zu einem Board raten, auf dem Linux bereits installiert ist. Bei der Arbeit mit einem vorinstalliertem Linux kommst du mit der hardwarenahen Programmierung nicht so sehr in Berührung, da das Handling von Schnittstellen, Timern u.ä. größtenteils bereits durch die Linux-Treiber erledigt wird. Du lernst aber, mit Cross-Entwick- lungsumgebungen umzugehen und den Aufbau eines Linux-Systems besser zu verstehen. Linux-Boards sind eine ganze Ecke teurer als einfache 8-Bit-Controller-Boards. Kennst du dich dann irgendwann sowohl mit µC-Interna als auch mit Embedded-Linux gut aus, kannst du versuchen, Linux auf einem nackten µC-Board selbst zu installieren. Dazu gehört aber schon recht viel Erfahrung. Das Olimex SAM7-P256 scheidet übrigens für so ein Unterfangen komplett aus, da es viel zu wenig Speicher hat, um Linux auszuführen.
mich reizt einfach die arm-architektur. natürlich will ich auch hardwarenahe programmieren. Ich möchte in ein paar jahren, mein eigenes Arm board bauen und linux zum laufen bringen. deswegen hab ich mir gedacht, dass ich gleich mit einem arm anfangen soll. zum Preis: ich wäre schon bereit um die 100€ fürs board auszugeben. Interessant an dem SAM7 board ist halt, dass CAN und Ethernet dabei ist. zum thema Dokumentation: Das hab ich auch schon bemerkt, dass die Doku zu AVRs ideal ist. Spricht natürlich für einen AVR. Wenn ich mich aber nicht unbedingt mit AVRs beschäftigen möchte, ist es dann trotzdem ratsam mit einem zu beginnen? Ich denke mir, dass dann die umstellung auf einen ARM sehr schwer wird. Ich kann mir vorstellen, dass ich dann wieder von 0 anfangen muss. Ist ja eine ganz andere Prozessorarchitektur. laut Rooney: der Umstieg von einem SAM7 auf einen ARM9 ist dann nicht mehr so is problem
... Meine Befürchtung ist, dass ich zu wenig Dokumentation bzw. Support zum SAM7 finde, und dann bald mal überfordert bin
Georg Pfusterschmied wrote: > Hab mir in den letzten Jahren C++ und Qt angeeignet und möchte mich nun > ein bisschen mit embbeded systems beschäftigen. Des weiteren verwende > ich auch Linux als Betriebssystem und möchte, das natürlich auch mal am > mc ausprobieren. Du solltest besser die Auswahl von der Anwendungsseite her vornehmen. Was für Applikationen willst Du denn mit dem MC machen? Nur so für sich ein Linux draufspielen ist so ziemlich witzlos, wenn es niemand braucht. Eine Toastersteuerung, eine Heizungssteuerung, eine Modellbahnsteuerung, ein Timer usw. kann mit Linux rein garnichts anfangen. Ich würde generell nicht mit super-duper Monster 32-Bittern anfangen. Geht ja schon los, wenn man Geräte selber bauen will. So nen BGA-Flatschen lötet man nicht so einfach und in der Stromversorgung sind die auch ganz schön anspruchsvoll (mehrere Spannungsregler nötig). So ein 8Bitter kann dagegen direkt an ner unstabilisierten 1,8..5,5V Batteriespannung betrieben werden und braucht auch nicht soviel Strom. Wenn Du auch ein bischen in die Hardwareprogrammierung reinschnuppern willst, dann ist ein 32Bit-Bolide vollkommen ungeeignet, das geht sehr viel besser mit nem 8Bitter. Statt Betriebssystemcalls aufzurufen, kannst Du einfach direkt auf die IO-Register schreiben, das sind quasi ganz normale Memoryadressen. Und Du wirst auch nicht so sehr von den vielen Optionen erschlagen. Außerdem haben 8Bitter eine viel einfachere Interruptlogik, da ist Interrupthandler programmieren fast so einfach, wie ne normale Funktion. Und die mit einem 8Bitter gewonnenen Erfahrungen nützen sehr wohl beim späteren Lernen eines 32Bitter. Sie können äußert nützlich sein beim effizienteren Programmieren gegenüber einem, der nicht weiß, wie etwas in einem MC wirklich abläuft und immer nur durch die Betriebssystemsbrille beschränkt auf die Hardware schaut. Peter
Ich muss jetzt gleich mal allen widersprechen... Hardwarenahe programmieren kannst mit einem ARM7 genauso einfach wie mit einem AVR. Wenn du IAR Compiler verwendest, gibt es von Olimex für das SAM7-P256 Board zwei Beispielprogramme. Die musst nur noch öffnen, kompilieren und auf das Board spielen. Eines wird verwendet um LEDs anzusteuern, dass zweite hat die selbe Funktionalität nur über Interrupts gelöst. Ich habe diese Beispielprogramme als Ausgangsbasis benutzt. Code reinschauen, Datenblatt zur Hand und innerhalb von einem Tag kannst schon deine eigenen Anwendungen schreiben. Es sei denn du hast mit Mikrocontroller noch gar nix zu tun gehabt, dann dauerts sicher etwas länger. Wenn du ARM programmieren willst würd ich definitiv nicht mit AVR anfangen. Wieso auch? Ein ARM7 ist nicht komplizierter als ein AVR. Kann mehr, ist stromsparender und geht ab wie die Post :-) Wieso einen Käfer kaufen, wenn man einen Porsche fürs gleiche Geld bekommt. Nix gegen AVR, die sind nicht schlecht, aber wenn du gleich mit ARM starten willst spricht absolut nix dagegen. ARM ist eben eine kleine Herausforderung, weil er doch sehr viel Peripherie und Register besitzt, die alle mal konfiguriert werden müssen... Wenn du ein Betriebssystem brauchst kannst FreeRTOS oder µCLinux verwenden. Hab FreeRTOS innerhalb von 6 Stund auf meinem System zum Laufen bekommen, also keine Hexerei.
re Peter: Danke erstmal für die Antwort. Ich möchte dem MC mit Qt eine grafische Benutzerobefläche verpassen, und somit stand alone geräte entwerfen, die daten erfassen, bearbeiten, und ausgeben, und das ganze halt in einem etwas größerem rahmen als mit einem zwei zeiligen lcd display. Ist klar, dass es sehr schwer mit einem 32 bitter anzufangen. es ist mir auch klar, dass die fortschritte mit einem 8 bitter sicher zahlreicher sind. ich will mich nur nicht mit einem AVR beschäftigen, wenn ich ihn nicht als vorraussetzung für einen ARM brauche. Mir ist klar, dass es immer besser ist mit einem 8 bitter zu beginnen, aber ist es schaffbar, und was noch wichtiger ist, zielführend, wenn ich gleich mit einem 32 bit ARM anfange?
ich möcht mich einfach so gut es geht, und so effizient wies geht auf einen ARM9 mit embbeded linux vorbereiten.
Rooney Bob wrote: > Es sei denn du hast mit > Mikrocontroller noch gar nix zu tun gehabt, dann dauerts sicher etwas > länger. Nicht nur etwas, sondern viel länger. Deshalb für die ersten Erfolgerlebnisse besser 8Bit. > ist stromsparender Das erklär mir mal genauer. Wenn Du nen ARM im Stromsparmodus an 1,8...5,5V mit einigen µA betreiben willst, brauchst Du schon ne ziemlich tricky und teure Spannungsreglerschaltung. > Wieso einen Käfer > kaufen, wenn man einen Porsche fürs gleiche Geld bekommt. Also ein ATtiny13 kostet bei Reichelt 1,15€ Der Tausenderpreis liegt vieleicht bei 0,20€. So und was kostet der Porsche (ARM)? > Nix gegen AVR, die sind nicht schlecht, aber wenn du gleich mit ARM > starten willst spricht absolut nix dagegen. Doch. Kommt drauf an, ob er schnell Erfolgserlebnisse haben will oder erstmal viele Schwierigkeiten und dann vielleicht alles frustriert in die Ecke haut. Ich hab mir kürzlich auch ein Luminary Cortex M3 Board gekauft. Ich bin in 8051, AVR topp fit und habe trotzdem ganz schön zu knabbern, den 32Bit Boliden zu beherrschen. Peter
Fraglich. Denn die Aufgabenstellung ist eine andere. Waehrend man mit einem AVR lernen kann einen 2x16 LCD in Betrieb zu nehmen, was auch mit ASM gut machbar ist, so ist eine Ethernet schnittstelle enorm viel komplexer wie eine Serielle. Ja, irgendwann sendet auch die ethernet Schnittstelle, beim PC kommt noch nichts an. Was macht man dann ? Dann sollte man die Tools zum einen haben und kennen. Ich denke 32bitter sind Profis vorbehalten, die zum einen taeglich damit arbeiten, die Tools haben und auch abschreiben koennen. Ein Mixed signal scope sollte man haben. Sonst macht's wenig Sinn.
peter wrote: > Doch. > Kommt drauf an, ob er schnell Erfolgserlebnisse haben will oder erstmal > viele Schwierigkeiten und dann vielleicht alles frustriert in die Ecke > haut. genau vor dem hab ich angst. bin jetzt ein wennig verwirrt. einerseits, spricht nix dagegen gleich mit einem ARM zu beginnen, anderer Seits werden mir hier nicht sehr großer Erfolgschancen gegeben.
Ich sach mal so, mit nem AVR anzufangen, ist kein großer Kostenfaktor und keine vergeudete Zeit. Es hilft Dir definitiv, dann mit dem ARM zurechtzukommen und nicht zu leicht aufzugeben. Peter
> Wenn ich mich aber nicht unbedingt mit AVRs beschäftigen möchte, ist > es dann trotzdem ratsam mit einem zu beginnen? > > Ich denke mir, dass dann die umstellung auf einen ARM sehr schwer > wird. Ich kann mir vorstellen, dass ich dann wieder von 0 anfangen > muss. Ist ja eine ganz andere Prozessorarchitektur. Bei 0 keinesfalls. Ich wage mal zu behaupten, dass bei einiger Erfahrung mit AVRs (oder einem beliebigen anderen Controller) die Einarbeitung in die ARMs in der halben Zeit möglich ist, so dass du in Summe u.U. sogar etwas Zeit, auf jeden Fall aber Frust sparst. Und als angenehmen Nebeneffekt beherrschst du anschließend gleich zwei Controllertypen. Es gibt einige grundlegende Dinge, die bei allen Controllern gleich sind, wie bspw. das Bitgepopel bei I/O-Zugriffen und das konfliktfreie Interrupthandling. Andere Dinge sind sehr ähnlich, bspw. die Bedienung eines UARTs, ADCs oder eines Timers. Natürlich sind Namen und Aufbau der jeweiligen I/O-Register unterschiedlich, aber solche Dinge muss man sowieso immer wieder im Datenblatt nachschlagen. Und Begriffe wie RX-Interrupt-Enable, Busy-Flag, Prescaler oder CTC wirst du in den Datenblättern von fast allen µCs wiederfinden. Gut ist, wenn man sie beim Lesen eines Datenblatts mit 500+ Seiten schon kennt, sonst wird man damit nie fertig. Etwas anders sieht es aus, wenn man sich mit Assemblerprogrammierung beschäftigen will. Die einzelnen Befehlssätze unterscheiden sich bisweilen schon deutlich in ihrem Grundkonzept. Aber auch hier gibt es sehr viele Gemeinsamkeiten, so dass man die zweite Assemblersprache deutlich schneller lernt als die erste. Aber ich habe den Eindruck, dass du vorerst sowieso eher bei C bleiben wirst. > Meine Befürchtung ist, dass ich zu wenig Dokumentation bzw. Support > zum SAM7 finde, und dann bald mal überfordert bin Dokumentation gibt es zur Genüge, aber vieles davon ist nicht für Einsteiger aufbereitet. Die typischen Einstiegsarchitekturen sind nun einmal AVR, PIC und 8051, nicht zuletzt deswegen, weil man damit mit geringem finaziellem und zeitlichem Aufwand eigene Schaltungen zusammenpappen kann. > laut Rooney: der Umstieg von einem SAM7 auf einen ARM9 ist dann > nicht mehr so is problem Ist es auch nicht. Aber auch hier gibt es Unterschiede: Neben der CPU (worum es sich bei ARM7 und ARM9 letztendlich handelt) ändert sich auch die On-Chip-Peripherie (Timer, Schnittstelle usw.), insbesondere dann, wenn die ARM-Controller von unterschiedlichen Herstellern stammen. Natürlich kannst du gleich mit einem ARM beginnen, du wirst bei entsprechender Motivation auch damit sicher zum Ziel kommen. Aber mit AVR und Co wirst du anfänglich bestimmt mehr Spaß haben. > Ich möchte dem MC mit Qt eine grafische Benutzerobefläche verpassen, > und somit stand alone geräte entwerfen, die daten erfassen, > bearbeiten, und ausgeben, und das ganze halt in einem etwas größerem > rahmen als mit einem zwei zeiligen lcd display. Das würde ich mal ganz weit hinten anstellen. Bis du so weit bist, dass du auf einem selbst gebauten Board mit einem selbst installierten Linux und Qt ein Grafikdisplay ansprechen kannst, ist so viel Zeit vergangen, dass die AVR-Einarbeitung einfach nur Erdnüsse ist ;-)
> Fraglich. Denn die Aufgabenstellung ist eine andere. Waehrend man mit > einem AVR lernen kann einen 2x16 LCD in Betrieb zu nehmen, was auch mit > ASM gut machbar ist, so ist eine Ethernet schnittstelle enorm viel > komplexer wie eine Serielle. Ja, irgendwann sendet auch die ethernet > Schnittstelle, beim PC kommt noch nichts an. Was macht man dann ? Dann > sollte man die Tools zum einen haben und kennen. Ich denke 32bitter sind > Profis vorbehalten, die zum einen taeglich damit arbeiten, die Tools > haben und auch abschreiben koennen. Ein Mixed signal scope sollte man > haben. Sonst macht's wenig Sinn. Ist klar, dass ich nicht gleich mit der Aktivierung der Ethernet - Schnittstelle anfangen kann. Aber es wird mir sowieso nichts anderes übrig bleiben als mit einem 2x16 LCD und ein paar Ausgaben anzufangen. Auch wenn ich jetzt einen 32 Bitter verwende
re:yalu natürlich kann ich erst in 2-3 jahren daran denken, mit embbeded linux und TFT und Qt und ..., zu arbeiten. also deiner Meinung nach sollte ich mir einen AVR zulegen. Ein STK500 oder was wäre deine Wahl?
> also deiner Meinung nach sollte ich mir einen AVR zulegen. Ein > STK500 oder was wäre deine Wahl? Ich kenne mich mit den käuflichen AVR-Boards nicht aus, da ich keins besitze. Aber wenn man die Forenbeiträge verfolgt, gewinnt man den Eindruck, dass das STK500 mit die wenigsten Probleme aufwirft. Wenn dir das Geld dafür nicht zuviel ist, ist das sicher eine sehr gute Wahl. Billigere Lösungen verwenden meist so genannte Bitbang-Programmier- adapter, bei denen die Zuverlässigkeit der Kommunikation zwischen PC und Controller nicht immer gegeben ist.
Man kann sich auch ohne Probleme ein Testboard auf Lochraster selber bauen. Benötigst nur einen Spannungsregler, den Controller, einen seriellen Programmieradapter (besteht aus einem IC - Pegelwandler) und bissl Hühnerfutter (Kondensatoren, Widerstände). Und dann eben paar LEDs oder ein Display dazu, je nach dem mit was man spielen möchte. Ich selber hab auch so angefangen, weil ich nicht so viel für das STK ausgeben wollte. Hatte dabei auch keine größeren Startschwierigkeiten. Anleitungen dazu findest du hier auf der Seite, die Hardware hab ich aus dem Assembler-Tutorial nachgebaut.
Ich würde auf jeden Fall ARM empfehlen - ich hab damit angefangen, und mir hat's auch nicht geschadet ;) Das typische Pin-Gewackel, für das ein AVR sicher besser geeignet ist als ein ARM, verliert doch immer mehr an Bedeutung. Spätestens wenn dann mal wieder einer USB low-speed Geräte (Maus oder so, "nur" 1.5 MHz) an seinem 8-bitter anschliessen will, merkt er, dass das in Software eben nicht geht, oder zumindest Null Sinn macht - für sowas gibt's uCs mit integriertem USB Host, oder meintetwegen externe USB Host Adapter, evtl. wie Vinculum, die dann auch gleich den Stack mitbringen. Wenn man nen AVR einsetzt, weil der ein bestimmtes Hardware-Protokoll in Software besser umsetzen kann als ein ARM, dann hat man einfach den uC noch nicht gefunden, der das gleiche in Hardware macht. Auch das "Selber-bauen" wird einfach aufgrund steigender Integrationsdichte und Taktraten immer mehr an Bedeutung verlieren. Klar gibt es einige, wenige, die auch ein System mit 100+MHz externem Bus auf ner 2-Layer Platine gerouted bekommen, und dann auch noch die nötigen BGA Teile im Pizzaofen löten, aber sofern das "Selber-baue" nicht Selbstzweck ist macht's irgendwann keinen Sinn mehr, weil ein Hersteller wie Olimex das deutlich billiger, schneller und besser kann. Bleibt das "von Grund auf verstehen" - und das kann man nun bei nem ARM7 oder ARM9 auch wunderbar nachvollziehen. Das Teil startet an Adresse 0x0, und ab dann lässt sich jeder einzelne Takt im Debugger ansehen (mal abgesehen von den in der Hinsicht bescheidenen LPC2000). Wenn man die GNU Toolchain benutzt muss man sogar verstanden haben, was alles zum Startup dazugehört, da einem dort eben niemand die Arbeit abnimmt. Die serielle Schnittstelle eines ARM9 wird wohl kaum deutlich komplizierter zu bedienen sein als die eines AVRs. Einzelne PINs für ne LED ein- und auszuschalten ist sicherlich komplizierter, aber da geht's doch eher um Stunden oder Tage, in denen man auch das hinbekommt. Ausserdem gibt's für fast jedes Board ein Beispiel, das ne LED blinken laesst... Bleibt zusammenfassend zu sagen, dass ich für AVR & Co. nur in absolut preis-sensitiven Bereichen ne Daseinsberechtigung sehe - wenn ein Gerät 100.000x verkauft wird machen eben auch 1$ oder 2$ Preisunterschied ne ganze Ecke am Gewinn aus, v.a. wenn man die Leistung eigentlich nicht bräuchte. Es gibt auch noch ein paar sicherheitsrelevante Bereiche, in denen es einfach viel leichter ist, 20 PICs zertifiziert zu bekommen, als einen großen uC, der die gleiche Arbeit macht, weil die einzelnen Aufgaben deutlich kleiner und damit leicher zu verifizieren sind. Das ist aber wohl für kaum einen hier von Bedeutung. Gruß, Dominic (der keine 8bitter mag)
@Peter Danninger: Für den AVR brauchst auch eine Stromversorgung… also ist das völlig egal. Der AVR ist für 5V ausgelegt, der AT91SAM7S256 beispielsweise für 3.3V und generiert sich intern die 1.8V. Wo ist jetzt also das Problem? Den AT91SAM7S32 bekommst wennst teuer kaufst für 6€, und 6€ wäre mir ein Porsche auf jeden Fall wert. @yalu: Kann dir nur zustimmen, an ein Betriebssystem sollte man wirklich erst denken, wenn man die Basics von Mikrocontroller-Programmierung verstanden hat. @Dominic R. Danke!!! Ich bin derselben Meinung. Ich hab zwar mit einem PIC angefangen, hab mir sämtliche Tools gekauft und musste dann nach 4 Jahren erkennen, dass es rausgeschmissenes Geld war. Solche 8 Bitter sind für kleine bis mittel komplexe Anwendungen, wenn man mehr braucht muss es einfach ein 32 Bitter werden. Ich kann nur nochmals betonen, dass es vom Prinzip her keinen Unterschied macht ob du AVR oder ARM programmierst, sofern du C# oder eine höhere Programmiersprache verwendest. Portpins zu toggeln geht bei AVR gleich wie bei ARM, lediglich andere Register müssen beschrieben werden. Die UART zu konfigurieren ist ähnlich, dein Erfolg kommt darauf an, ob du die richtigen Register mit dem richtigen Wert beschreibst (solche Informationen findet man im Datenblatt) Das Datenblatt zum AT91SAM7S256 ist sehr gut geschrieben, ATMEL hat eben schon immer gute Datenblätter gemacht. Es gibt für den SAM7 eine Library, die bereits sehr viele Funktion ausprogrammiert hat, d.h. um die UART zu verwenden musst du nix mehr neu schreiben, sondern einfach fertiges Material reusen. Was definitiv für den ARM spricht ist, dass du einen JTAG Debugger verwenden kannst, damit kannst du schneller debuggen als mit irgendwelchen ISPs oder ähnlichem, wie es diese für AVR oder PIC gibt. Damit du nicht vor ARM zurückschreckst, weil du keinen Support bekommst, dann sei dir gewiss, dass ich dir zumindest weiterhelfen kann.
Dominic R. wrote: > Ich würde auf jeden Fall ARM empfehlen - ich hab damit angefangen, und > mir hat's auch nicht geschadet ;) Merkwürdige Aussage, hat denn irgendjemand behauptet, ARM seien schädlich? > Das typische Pin-Gewackel, für das ein AVR sicher besser geeignet ist > als ein ARM, verliert doch immer mehr an Bedeutung. Spätestens wenn dann > mal wieder einer USB low-speed Geräte (Maus oder so, "nur" 1.5 MHz) an > seinem 8-bitter anschliessen will Du scheinst ne sehr eingeschränkte Ansicht von Anwendungsgebieten von MCs zu haben. Eine Zahnbürste, Rasierapparat, Kaffeemaschine, Sensordimmer, Küchentimer usw. mit Maus stelle ich mir äußerst unpraktisch vor. Die Mehrzahl der MC-Anwendungen verrichten ihren programmierten Job, ohne den User mit langen Bootzeiten, komplizierten Eingaben usw. belästigen zu müssen. Ich finde es sehr angenehm, MCs so unkompliziert wie früher einen 7400 einsetzen zu können und damit viele nützliche Geräte aufzubauen. Aber den tausendsten MP3-Player, Datenlogger, Handheld usw. nachzuentwickeln, finde ich einfach nur langweilig. > Auch das "Selber-bauen" wird einfach aufgrund steigender > Integrationsdichte und Taktraten immer mehr an Bedeutung verlieren. Das ist eben das schöne an den kleinen 8Bittern, man kann damit einfach und billig Sachen selber bauen und sich daran täglich im Haushalt erfreuen. > Dominic (der keine 8bitter mag) Dann bleibt Dir eben der weitaus größte Teil von MC-Anwendungen verschlossen, Dein Pech. Aber die 8Bitter, die in Tastatur, Maus usw. werkeln, um sie an Deinen 32Bitter anschließen, magst Du doch? Peter
Rooney Bob wrote: > Für den AVR brauchst auch eine Stromversorgung… also ist das völlig > egal. Aber eben kein stabilisierte. > Der AVR ist für 5V ausgelegt Nein, sondern je nach Typ und Taktfrequenz für 1,8..5,5V. Es ist also direkter Batteriebetrieb möglich. Peter
Step-Down-Converter mit Wirkungsgrad >93% und Problem erledigt.
Rooney Bob wrote:
> Step-Down-Converter mit Wirkungsgrad >93% und Problem erledigt.
Ja, bei Vollast, aber nicht im Powerdown.
Peter
Willst jetzt wetten? Gibts alles voll integriert...
Peter Dannegger wrote: > Dominic R. wrote: >> Ich würde auf jeden Fall ARM empfehlen - ich hab damit angefangen, und >> mir hat's auch nicht geschadet ;) > > Merkwürdige Aussage, hat denn irgendjemand behauptet, ARM seien > schädlich? Mit einem ARM anzufangen hat mir nicht geschadet. Es ging im Thread um den richtigen Controller für den Einstieg, und da schien mir der Tenor zu sein, dass kleinere uCs wie AVR & Co. besser geeignet sind - folglich müsste ARM ja schlechter sein, und wenn ein Einsteiger mit ner schlechten Wahl anfängt wäre das schädlich. >> Das typische Pin-Gewackel, für das ein AVR sicher besser geeignet ist >> als ein ARM, verliert doch immer mehr an Bedeutung. Spätestens wenn dann >> mal wieder einer USB low-speed Geräte (Maus oder so, "nur" 1.5 MHz) an >> seinem 8-bitter anschliessen will > > Du scheinst ne sehr eingeschränkte Ansicht von Anwendungsgebieten von > MCs zu haben. > Eine Zahnbürste, Rasierapparat, Kaffeemaschine, Sensordimmer, > Küchentimer usw. mit Maus stelle ich mir äußerst unpraktisch vor. > Die Mehrzahl der MC-Anwendungen verrichten ihren programmierten Job, > ohne den User mit langen Bootzeiten, komplizierten Eingaben usw. > belästigen zu müssen. Zahnbürste, Rasierapparat, Kaffeemaschine oder Sensordimmer sind doch wohl der von mir erwähnte Massenmarkt mit enorm großen Stückzahlen und geringen Leistungs-Anforderungen. Bei diesen Produkten geht es aber in aller erste Linie um die Mechanik etc., in der der uC zum Einsatz kommt. Meine Kaffeemaschine hat vermutlich nen 8, evtl. 16 bit uC, aber gekauft hab ich sie wegen dem Mahlwerk, der Brühgruppe, und dem Druck, den sie aufbauen kann. > Ich finde es sehr angenehm, MCs so unkompliziert wie früher einen 7400 > einsetzen zu können und damit viele nützliche Geräte aufzubauen. > > Aber den tausendsten MP3-Player, Datenlogger, Handheld usw. > nachzuentwickeln, finde ich einfach nur langweilig. Darauf wird's aber bei vielen hinauslaufen. >> Auch das "Selber-bauen" wird einfach aufgrund steigender >> Integrationsdichte und Taktraten immer mehr an Bedeutung verlieren. > > Das ist eben das schöne an den kleinen 8Bittern, man kann damit einfach > und billig Sachen selber bauen und sich daran täglich im Haushalt > erfreuen. Gut - wenn an vielen Stellen einfachste Steueraufgaben zu erledigen sind, mag ein 8-bit uC der nur geringe Anforderungen an externe Bauteile stellt eine angemessene Wahl sein. Ob es "Spass" macht, bzw. zumindest nicht langweilig ist, den Code für solche Aufgaben zu schreiben, lass ich mal dahingestellt... >> Dominic (der keine 8bitter mag) > > Dann bleibt Dir eben der weitaus größte Teil von MC-Anwendungen > verschlossen, Dein Pech. > > Aber die 8Bitter, die in Tastatur, Maus usw. werkeln, um sie an Deinen > 32Bitter anschließen, magst Du doch? Bisher war mir noch nicht der Sinn nach Pimp-My-Maus/Keyboard, ich war mit denen, die's im Laden gab, sehr zufrieden. Ob der Hersteller hier auf einen 8-bit oder 32-bit uC setzt ist mir herzlich egal - die Regeln des Marktes werden in wohl dazu zwingen, einen 8bitter zu verwenden. > Peter Dominic
Dominic R. wrote: >> Das ist eben das schöne an den kleinen 8Bittern, man kann damit einfach >> und billig Sachen selber bauen und sich daran täglich im Haushalt >> erfreuen. > > Gut - wenn an vielen Stellen einfachste Steueraufgaben zu erledigen > sind, mag ein 8-bit uC der nur geringe Anforderungen an externe Bauteile > stellt eine angemessene Wahl sein. "Einfacheste Steueraufgaben". Hast du eigentlich überhaupt mal etwas mit einem 8-Bit AVR gemacht? (Und bitte nicht PIC)
Dominic R. wrote: > Klar kann ein AVR mehr - deswegen muss man ihn noch lange nicht > verwenden... Wo ist da ein Argument versteckt? Ich finde keins.
Argumente siehe oben - es gibt nur sehr wenig Gründe, einen AVR zu verwenden, auch wenn das vielen der alten 8-bit Haudegen nicht passt. Die meisten/alle Aufgaben lassen sich mit einem 32-bit uC wie ARM7 besser erledigen, warum sollte man dann nicht gleich mit einem solchen beginnen.
@ Dominic R. (dominic) >Klar kann ein AVR mehr - deswegen muss man ihn noch lange nicht >verwenden... Geh mal zum Arzt und lass dir ein Anitallergen verschreiben . . . Mfg Falk
hey, sorry wenn ich da irgendwie Unruhe gestiftet habe. Habe nicht gewusst, dass die Meinungen bei diesem Thema so auseinander gehen.
Dass das kontrovers formuliert ist, ist mir auch klar... und dieses Forum ist wohl ein denkbar schlechter Platz, über 8-bit zu lästern, aber die Welt verändert sich nun mal...
Wenn's dir eher darum geht, komplette Basteleien mit dem Mikrocontroller zu bauen (Roboter, Datenlogger, Steuerung für Whatever, ...) dann nimm einen AVR. Wenn du hingegen anspruchsvolle Software drauf laufen lassen willst (Betriebssystem, MP3-Decoding, Webserver, ...) und dich nicht vor anspruchsvollem Schaltungsdesign scheust, dann nimm einen ARM. Eventuell sollte man sich die AVR32 auch mal näher ansehen...
> hey, sorry wenn ich da irgendwie Unruhe gestiftet habe. Habe nicht > gewusst, dass die Meinungen bei diesem Thema so auseinander gehen. Das ist der ganz normale Alltag hier ;-) Allerdings geht die Diskussion normalerweise um AVR <-> PIC Linux <-> Windows Target <-> Eagle Weller <-> Ersa Das jetzt plötzlich AVR gegen ARM kämpfen muss, obwohl die beiden in völlig unterschiedlichen Klassen spielen, verstehe ich jetzt auch nicht ganz. Wie wär's - um noch eins draufzusetzen - mit Transistor <-> PC :D
Hehe. Sehe ich genauso. Hier werden Birnen mit Äpfeln verglichen. Während ein 32Bit ARM Prozessor eigentlich in Printservern oder Handhels eingesetzt werden, so werden 8-Bit Prozessoren eigentlich viel häufiger verwendet. Peter hat dafür ja auch ein paar Beispiele genannt. Man sieht es nur nicht immer direkt. Bei Waschmaschinen, Mikrowelle, Ofen oder was weiß ich macht es einfach keinen Sinn einen teuren "Porsche" einzusetzen. Punkt!
Dominic R. wrote: > Dass das kontrovers formuliert ist, ist mir auch klar... und dieses > Forum ist wohl ein denkbar schlechter Platz, über 8-bit zu lästern, aber > die Welt verändert sich nun mal... Aber die Zukunft besteht doch nicht nur aus Kühlschränken, die übers Netz ihren Vorrat nachbestellen und Internetfähigen Kochtöpfen. Auch in Zukunft wird es noch Rolladensteuerungen geben, die man mit zwei Knöpfen bedienen kann und Batterieladegeräte ohne RGB-Touchscreen... Wie ja schon mehrfach gesagt wurde ist das wirklich nur eine Frage des Einsatzbereichs. Btw.: Wieso müssen Verkehrspiloten zuerst ihre PPL-A(Privatpilotenlizens) machen, bevor sie sich gemächlich der Jumboklasse nähern dürfen? Vielleicht weil man sobald man mit den leicht zu erlernenden Basics vertraut ist einfacher, schneller und sicherer mit den größeren Geschützen umgehen kann?
Georg Pfusterschmied wrote: > hey, sorry wenn ich da irgendwie Unruhe gestiftet habe. Habe nicht > gewusst, dass die Meinungen bei diesem Thema so auseinander gehen. Das hier manchmal der Staub etwas aufwirbelt, braucht Dich nicht zu kümmern. Lieber so, als gar keine Diskussion. Die Frage ist, willst Du es eher privat oder beruflich lernen? Für privat hab ich immer das Problem der mechanischen Seite, d.h. daß ein Gerät draus wird und es auch nach was aussieht. So ein ARM-Entwicklungsboard kann man ja keinem ins Wohnzimmer stellen. Es wäre außerdem ein teurer Spaß, jede Applikation mit nem Entwicklungsboard aufzubauen. Und ein Gerät mit GLCD, Touchscreen usw. selber zu designen, kann teuer werden. Die ganze fein-SMD Löterei ist, wie ja schon anklang, auch nicht so basteltischtauglich. Ich mags daher lieber, bestehende Geräte mit nem 8Bitter aufzupimpen. Oder irgendwelche Kästchen aufzubauen, die kaum oder nur einfache Bedienelemente haben. Interessant finde ich auch das Thema der Haussteuerungen, d.h. in jeder Steckdosen- und Schalterdose sitzt ein 8Bitter am CAN-Bus. Beruflich gesehen denke ich, daß für 8Bit-Anwendungen immer gute Chancen bestehen, schon aufgrund der großen Vielfalt der Aufgaben. 8Bit-Projekte lassen sich in der Regel als Einmannprojekt bearbeiten, d.h. man hat viele Freiheiten. Bei 32Bit-Anwendungen könnte der Bedarf schon anders aussehen. Für MP3-Player, Handys, Router, DVD-Player und ähnliches dürfte schon eine reichliche Programmiererschar in Lohn und Brot stehen. Auch denke ich, daß da vorrangig im Team entwickelt wird, mit strengen Vorgaben bezüglich der Herangehensweise und Dokumentation. Daher finde ich die 8Bitter viel interessanter, ist aber nur meine rein persönliche Meinung. Peter
dann will ich jetzt auch mal meinen Senf dazugeben :) Ich habe vor einem knappen Jahr mit den 8 Bit AVRs angefangen und schon eine Menge Unfug damit angestellt. Jetzt bin ich gerade an einem Punkt angekommen wo ich mir schon wünschen würde, dass die AVRs ein bisschen schneller getaktet wären. Bisher habe ich Geschwindigkeitsprobleme (zB bei meiner Propellerclock) so gelöst, dass ich entweder mehrere 8 Bitter benutzt habe, oder das Programm so umgeschrieben hab, dass es gerade so hinhaut. Da ich jetzt versuche eine SD Karte im wahrsten Sinne des Wortes "on the fly" auszulesen, reichen mir die 8MHz SPI Frequenz schon nicht mehr. Deshalb bin ich gerade am Überlegen ob ich auf einen SAM7 umsteige. Ich bin trotzdem mehr als froh mit einem AVR 8 Bitter angefangen zu haben, weil man da schneller zum Erfolg kommt und wie oben geschrieben einfach mal eine kleine Kiste bauen kann, die etwas steuert, regelt, timed oder anzeigt :)
Wie wäre es mit einem FPGA, dann könnts mir ARM, AVR, PIC & Co alle sch**** gehen ggg Nein im Ernst, dieses Forum ist hauptsächlich für AVR Freaks. Wenn du dich durch andere Foren wühlst, werden sie dir andere Controller vorschlagen, mag's nun PIC, 80C51, ARM7 oder ARM9 sein. Ich mache Projekte, die gehen weit über irgendwelche steuerbaren Steckdosen hinaus, bin also ARM7 lastig. Lass dir nich irgendwelche Meinungen aufdrängen, sondern stell die beiden gegenüber und entscheide dich dazu was dir DEIN Kopf sagt. Um es noch einmal festzuhalten: # AVR und PIC sind für den Einstieg sicher einfacher als ARM7 oder ARM9. Das sieht man vorallem auch bei der Größe des Datenblatts - obwohl Größe ja nicht alles ist ;-) Einfacher wenn du Assembler programmierst, in C# macht es kaum einen Unterschied. Die Entwicklungsumgebung für AVR, PIC ist einfacher zu handhaben. Mit IAR oder Keil muss man sich doch etwas herumspielen und reichlich Dokumentationen lesen, damit man auch den Compiler so konfiguriert, dass man bestmögliche Ergebnisse erzielt. # Willst du mehr als nur eine Mikrowelle oder Minirobotor ansteuern, dann solltest du zumindest ARM7 in Erwägung ziehen. Von der Leistung her ist dieser 32 Bit Controller natürlich um Hausecken besser - kostet jedoch auch etwas mehr. # AVR und PIC gibt es in DIP Gehäuse, du kannst also deine Schaltungen auf Streckbrett oder Lochrasterplatine aufbauen. ARM7 gibt es bestenfalls nur im TQFP, ARM9 nahezu nur als BGA Versionen. TQFP ist jedoch relativ einfach zu löten, Ersa hat für seine Digital 2000 Hohlkehlen, mit denen bestückst du solche ICs in einigen Sekunden. Für ARM7 wirst du also entweder eine eigene Platine entwerfen müssen, oder du kaufst dir Adapterplatinen bei Conrad, Farnell oder RS, dann kannst du einen ARM7 auch auf einem Lochrasteraufbau verwenden. # Willst du ein Betriebssystem verwenden (z.B. FreeRTOS), dann Hände weg von AVR und PIC. Durch das Betriebssystem wird ohnehin scheinbar alles langsamer, deswegen ARM7. # µCLinux läuft auf einigen ARM7 Controllern, doch dafür wirst du ein externes Speicherinterface benötigen. # Willst du Linux haben, wirst an einem ARM9 nicht vorbeikommen. Olimex hat ein super Board mit einem AT91SAM9620 für 140€. Dort ist das Linux bereits drauf und kannst sofort starten. Würde ich aber definitiv abraten, wenn du noch nie etwas mit Mikrocontrollern gemacht hast. Du kannst zwar deine Programme auf einem Linux-System entwickeln, aber die Hardware initialisiert sich nicht von selbst... # AVR32 ist wohl auch eine gute Wahl, jedoch gibts die meines Wissens nur in BGA Gehäuse und fällt somit durch. # Willst du schnell debuggen, dann geht das nur mit einem JTAG Debugger. ARM7 und ARM9 besitzen JTAG. # ARM7 besitzt einen großen RAM und Flash Speicher. Was du an einem AVR extern dran hängen musst, hat der ARM bereits intern. Im muss mich aber korrigieren, ARM ist nur der Core, sagen wir lieber ein AT91SAM7S256 beispielsweise. Und noch etwas: # Lass dich von keinem Controller abschrecken, nimm die Herausforderung an. Es ist nicht immer der leichte Weg der beste Weg. Frustriert wirst bei jedem Controller mal sein, aber nie das Ziel aus den Augen verlieren. # Support bekommst du für jeden Controller, egal ob AVR, PIC oder ARM. # Lass dir keine Meinung aufdrängen, jeder will "seinen" Controller durchsetzen, auch wenn er für deinen Bedarf gar nicht einsetzbar und das Teil schon seit 10 Jahren abgekündigt. Das liegt in der Natur des Menschen lange zu diskutieren nur um seine Meinung kundzutun, egal wie stupide und eingeschränkt diese ist. Wir könnten auch über die Farbe von Widerständen diskutieren... stundenlang... Hör auf deinen Kopf!!
Eine Contoller-Familie wurde noch gar nicht gennant : Renesas M16C und R8C. Das einzige Problem bei diesen ist, man bekommt sie nicht an jeder Staßenecke. Ein Vorteil dieser Controller ist, man braucht keinen Programmieradapter. Das flashen und debuggen geht über RS232 oder mit einem FT232 auch über USB.
ARM7 kann man auch über USB flashen, mittels SAM-BA. Ich hab mir einen eigenen Bootloader geschrieben, kann also theoretisch über alle erdenklichen Schnittstellen flashen. Angepasst müßte nur der Physical Layer werden.
also... um das ganze zusammen zu fassen: Grundsätzlich muss man sich die Frage stellen was man machen willt. 1.)Will man sich simplen und einfachen Anwendungen(IO, LCD display) beschäftigen genügt ein 8 bit AVR. 2.)Will man sich mit Datenaustausch im größerem Bereich, TFT, Grafische Benutzeroberfläche und einem Linux Kernel beschäftigen kommt man um einen ARM nicht herum. Hat man keine Erfahrung mit MCs, wählt aber trotzdem Variante 2.) ist es trotzdem ratsam mit einem AVR zu beginnen, wenn es auch nicht unbedingt nötig ist. Man wird mit AVRs sehr schnell Fortschritte machen und verliert nicht so leicht die Motivation. so, ich glaub das ist kurz und knapp um was es in den letzten 40 einträgen gegangen ist.
Also echt mal ne nette Diskussion, drum geb ich auch mal n Senf dazu ab. Nun ich mußte aufgrund meiner damaligen Diplomarbeit auf nem ARM7 Programmieren. Meine Programmierkenntnisse waren zu beginn mal echt bescheiden, und ich machte mir anfangs auch viele Gedanken über die "Angst" vieler vor den ARM-Controllern. Natürlich ist das nicht gerade der einfachste Controller, aber sooo viel schwerer ist die ganze Geschichte dann auch wieder nicht. Ehrlich gesagt hab ich mir deswegen am Anfang viel zu viel Gedanken über so Sachen wie Compiler, Startup-File und Programmierschnittstelle gemacht, um am Schluß festzustellen, daß es im Endeffekt doch fast egal ist welchen Controller man vor sich hat. Man initialisiert die einzelnen Module wie im Users angegeben und gut. Sicherlich sind das beim einen mal mehr mal weniger Register, aber was ist schon dabei? Mit nem Evaluation-Board und den überall zu findenen Beispielen geht das ganz zügig. Ab und zu wirst immer ein Frusterlebnis haben, egal welchen Controller du hast, aber wenn mal n bischen durchgestiegen bist wirst mit nem ARM doch mehr Freude haben weil da leistungstechnisch einfach doch flexibler bist. Außerdem: Egal was heute für ne Anwendung hast... wer weis was morgen für Ideen hast. Mit nem ARM bist leistungstechnisch immer abwärtskompatibel, aber n 8-Biter ist nicht aufwärtskompatibel... da wirst immer nur bei "Waschmaschinenprogrammen" bleiben^^
Genau wrote: > Ehrlich gesagt hab ich mir deswegen am Anfang viel zu viel Gedanken über so > Sachen wie Compiler, Startup-File und Programmierschnittstelle gemacht, um > am Schluß festzustellen, daß es im Endeffekt doch fast egal ist welchen > Controller man vor sich hat. Genau das sind Sachen wo ich mir überhaupt keinen Kopf drum machen würde, der Mechanische Teil dürfte der weitaus schwierigere sein, es sei denn man werkelt immer nur auf seinem Eval Board/Stick. Zum Thema Abwärtskompatibilität: Bei den 8 Bittern hast Du halt die Möglichkeit mit recht wenig Vogelfutter und noch bequem im PDIP zu basteln. Für jede verdammte Schaltung die ein 8er schafft nen ARM zu nehmen, wäre mir dann auch etwas zu umständlich...
Ich sehe das rein pragmatisch, betrachte zuerst die Aufgabe und wähle danach den MC aus. Ich will mich nicht lange mit Programmieren aufhalten und komplizierte Layouts routen. Ich setze daher MCs ein, wie andere TTL-ICs oder Operationsverstärker, ein Gerät mit 20 MCs ist nichts ungewöhnliches. Nun könnte man denken, ich muß 20 AVRs nehmen, weil sie so schwach sind. Aber nein, genau umgekehrt wird ein Schuh draus, ich kann 20 AVRs nehmen, weil sie so einfach sind. Ich muß nicht hochpolige teure Steckverbinder nehmen, um alle Signale zu nem zentralen ARM zu routen, sondern ich kann die Rechenleistung genau da anbringen wo sie gebraucht wird. Dadurch sinkt der Aufwand zum Routen der Platinen erheblich, die Programmierung vereinfacht sich und obendrein erhöht sich natürlich auch die EMV-Festigkeit drastisch. Wir haben auch ein ARM-Board, was natürlich sehr groß und teuer ist. Teuer ist ja nicht der ARM selber, sondern das ganze nötige Drumherum, inclusive des 4-Layer-Layouts. Und EMV-Probleme hat es auch. So ein AVR braucht kein Drumherum (Flash, SRAM, Takt, Reset, Spannungsregler) und für nen 8 oder 14 Pinner hab ich auch schnell das 1- oder 2-lagen Layout zusammengepappt. Im ganzen bedeutet also der Einsatz von 8Bittern für mich, erhebliche Kosteneinsparung, weniger Entwicklungszeit, bessere Zuverlässigkeit. Ich wollte das nur mal anmerken, da ja hier immer nur die reine CPU-Leistung betrachte wurde, was in nem fertigen Gerät allerdings nur ein Aspekt unter vielen anderen ist und oft nicht mal ein entscheidender. Peter
@Genau >Mit nem ARM bist leistungstechnisch immer abwärtskompatibel, aber Ja, der ARM in der Waschmaschine ist ja auch viiiieeeel sinnvoller... >n 8-Biter ist nicht aufwärtskompatibel... Das spiegelt sich ja auch im Preis wieder. >da wirst immer nur bei "Waschmaschinenprogrammen" bleiben^^ Sehr unqualifizierte Aussage, mein Freund. btw. EIB-Lichtschalter sind nicht so teuer, weil ein 32bitter drin wäre...
Was ich an den AVR mag: Das ich sie ohne viel Aufwand in eine Schaltung einsetzen kann. Im einfachsten Fall ist das: Einen 8-Pinner Tiny in die Schaltung rein, Versorgungsspannnug anschliessen, ev. ein ISP Interface (muss nicht unbedingt sein), die gewünschte I/O Hardware anschliessen und fertig. Ich finde das ehrlich gesagt oft simpler als einen Aufbau als TTL oder CMOS Grab. Selbst für so einfache Dinge wie Zähler, Teiler etc. Natürlich nur solange die Rechenleistung ausreicht. Aber das tut sie bei mir praktisch fast immer. Ansonsten finde ich die Frage bzw. Antwort nach 'dem besten Prozessor' genauso sinnvoll wie die Frage nach 'der besten Programmiersprache' oder 'dem besten Auto'. 'Das beste xxx' ist für jeden was anderes. Je nach seinen Anforderungen. Im Zweifelsfall ist 'das beste yyy' immer dasjenige yyy mit dem man umgehen kann. Sei es Programmiersprache, Auto, Waschmaschine, Handy oder eben auch µC. Ich haben fertig.
Super Aussagen sind hier schon dabei, daß muß man euch lassen. @edson: ">da wirst immer nur bei "Waschmaschinenprogrammen" bleiben^^ Sehr unqualifizierte Aussage, mein Freund. btw. EIB-Lichtschalter sind nicht so teuer, weil ein 32bitter drin wäre..." Und nun? Klingt irgendwie wie:"Nachts ists kälter als Draußen!". Prinzipiell ists doch auch wie das Problem von A nach B zu kommen. Den einen reicht n Mofa und die anderen brauchen n Ferrari. Ich persönlich würde mich da auf den Ferrari spezialisieren, denn dann kann ich sowohl schnell als auch langsm fahren, oder die Sonderausstattung nutzen oder nicht. Mitm Mofa kann ich halt nur langsam fahren. Sicherlich kommt man mit beiden ans Ziel. Nun wenn der Unterschied 2-3 Euro (bei Controllern) macht und nicht für ne Großserie geplant ist warum dann das schlechtere Modell wählen? Oder kauftst du dir bei der Anschaffung eines neuen Pc´s n Modell von vor 5 Jahren nur weils hauptsächlich vor Office-Anwendungen sitzt?
Genau wrote: > Nun wenn der Unterschied 2-3 Euro (bei Controllern) macht und nicht für > ne Großserie geplant ist warum dann das schlechtere Modell wählen? Weil der Unterschied eben eher bei 300,-€ pro Gerät liegt, auf die Gesamtkosten bezogen. Und das "schlechter" sich ausschließlich auf die CPU-Leistung bezieht (nur 90% ungenutzt statt 99% beim ARM). In vielen anderen Punkten sind die kleinen aber besser. Nen ARM setze ich nur dann ein, wenn ich den Vorteil auch wirklich nutzen kann. > Ich persönlich würde mich da auf den Ferrari spezialisieren, denn dann > kann ich sowohl schnell als auch langsm fahren Bitteschön, spann ruhig nen Ferrari vor die Landmaschine, statt nen Traktor. Ich bevorzuge allerdings das für die Aufgabe optimale Verkehrsmittel. Peter
Hi Peter Hab aufgrund deines Beitrags doch noch ein-zwei Fragen: Wie kommst denn auf 300€? Unser Threaderöffner hat hier keine Endgeräte bzw. Großserie geplant, und n ARM muß ja wohl nicht auf ne Diamantbesetzte Platine gebaut werden, oder? Nenn doch mal die vielen objetiven Punkte wo n "kleiner" besser ist? Bis auf Stromverbrauch und event. Größe fallen mir nicht so viele ein, und die interessieren Georg bestimmt nicht. Bist du dann einer der gleich mehrere Rechner im Zimmer stehen hat? Einen 286 für Briefe schreiben, n P1 zum Surfen und P-IV für Spiele?
>Super Aussagen sind hier schon dabei, daß muß man euch lassen. >Und nun? >Klingt irgendwie wie:"Nachts ists kälter als Draußen!". Das selbe kann man über deinen vorletzten Post sagen, mit dem Unterschied dass es da wirklich zutrifft! >... >Sicherlich kommt man mit beiden ans Ziel. Ja, sicher. >Nun wenn der Unterschied 2-3 Euro (bei Controllern) macht und nicht für >ne Großserie geplant ist warum dann das schlechtere Modell wählen? Das ist doch schon wieder so ein "Nachts ist es kälter.."-Unsinn! Erkläre doch mal warum ein Traktor schlechter als ein Ferrari ist... (respektive zur Ackerarbeit) >Oder kauftst du dir bei der Anschaffung eines neuen Pc´s n Modell von >vor 5 Jahren nur weils hauptsächlich vor Office-Anwendungen sitzt? Wenn du Vergleiche anstellen willst, denk bitte vorher mal über deren Aussagekraft nach. Das war dein dritter "Nachts ist es..."-Vergleich. Ist schon albern, mir das vorzuwerfen...
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.