Hallo, die Frage, welcher der BESTE uC ist, hängt natürlich vom Anwendungsfall ab. Konkret geht es hier aber nicht um die Anwendung, sondern um die Möglichkeit der Programmierung in Assembler. Programmiert man einen uC in C, bekommt man ja eh nicht mehr mit, was im Hintergrund für Befehle ausgeführt werden. Das ist ja alles transparent. Wenn man allerdings gerne in ASM programmiert, spielt es eine sehr wichtige Rolle, wie intuitiv (und damit einfach) sich die Programmierung gestaltet. An erster Stelle kommt der Befehlssatz. Je mächtiger die Kernbefehle sind, desto weniger Befehle braucht man und desto einfacher ist das Programm dann auch lesbar. An zweiter Stelle kommt die Anzahl der Register. Je mehr Arbeitsregister man hat, desto einfacher lässt sich programmieren. Man kann länger mit den Registern arbeiten, bevor man mit dem RAM rumfrickeln muss. Mal eben eine globale Variable in ein Register ablegen tut weniger weh, wenn man viele davon hat. Derzeit programmiere ich ausschliesslich AVRs. Mit 32 Arbeitsregistern wirklich sehr angenehm. Allerdings sieht es so aus, als ob der Trend zu ARM geht. Mittlerweile gibt es ARMs für 30 Cent und die 8-Bitter werden immer teurer. Jetzt habe ich mir den ARM mal angeschaut und die Programmierung in ASM scheint wirklich eine Quälerei zu sein. Viel weniger Register, viel mehr zu beachten und deshalb natürlich auch viel dickere Handbücher. Es sieht fast so aus, als ob die Designer sich dachten, dass 99% der Welt die Teile eh in C programmiert und die deshalb nicht mehr angenehm von Menschen programmiert werden können. Was meint ihr? Und gibt es sinnvolle Alternativen?
:
Verschoben durch User
Arm, c, asm wenn es sein muss für startup - den kann man auf cortex aber auch in c schreiben. Welchen Hersteller? Egal, such nach dem was du brauchst, sortiere nach preis, sortiere das aus, was du nicht löten kannst - den lpc1769 gibts z.b. auch in wafer bga... Dann nimmst du entweder einen RPI - gibts ab 5$ als jtag/swd dongle mit openocd. Ziehe dir gnuarm eclipse, da gibts board/cpu packs mit register files - oder du nimmst dir das svd file vom hersteller und lässt das register file generieren. Oder du nutzt die IDE des Hersteller - lpcexpresso geht bis 256k, das reicht meistens, wenn nicht nimm die open source Lösung, wie gerade beschrieben - ist auch universell und Hersteller unabhängig. Dann nimmst du gcc oder clang als cross compiler. Und es ist dir ziemlich egal woher die CPU kommt. Achte vielleicht noch dass es eine Familie ist, wo man mehr oder weniger Speicher bekommen kann und Fange mit einem eval board mit maximalem Speicher an. Wenn das Projekt mit eval board geht, kannst du auch das ganze zurecht schneiden. Wenn du den sevice von seeedstudio nutzten willst, Dir auch das board zu bestückeb, nehme eine CPU, die in er open parts library ist. Lpc1769 ist da ein heisser Kandidat... Es gibt aber auch einen kleineren von st... Wenn du was exotisches haben willst, nimm esp8266, leicht zu programmieren und hat wifi in chip. Wenn du was fürs steckbret willst, bleib beim atmega328 - preislich/Leistung ist jeder arm oder esp8266 aber besser. Ich würde meine Zeit auf keinen Fall mehr mit Assembler verschwenden. Also fallen alle controller weg, für die es kein GCC Backend gibt ;-)
Christian S. schrieb: > die Frage, welcher der BESTE uC ist, hängt natürlich vom Anwendungsfall > ab. Konkret geht es hier aber nicht um die Anwendung, sondern um die > Möglichkeit der Programmierung in Assembler. Wenn du lustig bist kannst du auch den Skylake in Assembler programmieren, daher kann man ohne konkrete Anwendung schlicht gar nicht sagen welcher Mikrocontroller der Beste ist.
Christian S. schrieb: > Wenn man allerdings gerne in ASM programmiert ... was heutzutage halt praktisch keiner mehr macht. Ob gerne oder nicht. > Es sieht fast so aus, als ob die Designer sich dachten, dass 99% der > Welt die Teile eh in C programmiert ARM stand mal für "Acorn RISC Machine". Wie bei anderen RISC-Designs ist die Architektur bewusst für Compiler optimiert. (Und 99% ist zu niedrig geschätzt.) > gibt es sinnvolle Alternativen? Ich mag den MSP430. Das ist aber auch nur eine persönliche Meinung.
Christian S. schrieb: > Und gibt es sinnvolle Alternativen? Ja. Nimm als Alternative zum Assembler einfach C...
:
Bearbeitet durch Moderator
Oliver S. schrieb: > 6809 > > Dem traure ich heute noch nach ;) Die Freescale (HC)S12(X) könnten als Nachfolger durchgehen. Zum Ausgleich für ein paar fehlende Feinheiten gibt es die mit aktuellen I/O-Modulen und 1MB Flash auf dem Chip. http://www.nxp.com/products/microcontrollers-and-processors/more-processors/8-16-bit-mcus:8-16-BIT-MICROCONTROLLERS Bei 6809 fällt einem natürlich der 68000 ein; auch der hat Nachwuchs bekommen: http://www.nxp.com/products/microcontrollers-and-processors/more-processors/coldfire-plus-coldfire-mcus-mpus:PC68KCF Die beiden lassen sich schon sehr angenehm in Assembler programmieren. Aber es geht noch deutlich besser. Mit dem VAX-Macro-Assembler und -Linker und den Maschinenbefehlen braucht man kein C. http://www2.hmc.edu/www_common/OVMS072-OLD/72final/4515/4515pro.html Und von wegen "das ist doch kein uP": die MicroVAX gab's auch in Bastler-freundlichen Gehäusen http://www.vaxination.ca/vms/microvax/mv_ii.html
Wie wäre es mit dem GA144 von Greenarrays? Damit hat man kein C oder ASM Problem.
Christian S. schrieb: > Jetzt habe ich mir den ARM mal angeschaut und die Programmierung in ASM > scheint wirklich eine Quälerei zu sein ARM ASM ist für den Anfänger sehr einfach und klar strukturiert. Das erste ARM Betriebssystem von 1989 ist komplett in ASM geschrieben, hier mal für den Raspberry Pi: https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/HAL/BCM2835/s/ Christian S. schrieb: > Derzeit programmiere ich ausschliesslich AVRs. Mit 32 Arbeitsregistern > wirklich sehr angenehm. Wer so viele Register braucht sollte den 8051 gut finden 4x 8 Register + 80 als Register nutzbare Speicherstellen gibt 112 :-) Christian S. schrieb: > Mittlerweile gibt es ARMs für 30 Cent und die 8-Bitter werden immer teurer Welche denn? Und die 8051 kosten bei gleicher Ausstattung immer noch die Häfte z.B. kleinster ARM mit USB ab 2.50 EUR und gleicher 8051 mit USB 1.50 EUR Das der kleinste AVR mit USB viel teurer ist sagt eher was über Atmel aus. http://www.mouser.de/ProductDetail/NXP-Semiconductors/LPC11U14FBD48-201/?qs=sGAEpiMZZMtXqW1IUNX6MKATeJoK9A5C http://www.mouser.de/ProductDetail/Silicon-Labs/EFM8UB20F32G-A-QFP48/?qs=sGAEpiMZZMu6TJb8E8CjrwwHrm3kwS2LYoXxmeLYWso%3d
Christian S. schrieb: > die Frage, welcher der BESTE uC ist, hängt natürlich vom Anwendungsfall > ab. Konkret geht es hier aber nicht um die Anwendung, sondern um die > Möglichkeit der Programmierung in Assembler. Der BESTE µC ist wohl derjenige, mit dem man vernünftig umgehen kann. Was nützen die tollsten Fähigkeiten, wenn man in Assembler rum stümpert.
Lothar schrieb: > Wer so viele Register braucht sollte den 8051 gut finden 4x 8 Register + > 80 als Register nutzbare Speicherstellen gibt 112 :-) Kommt darauf an, was man unter "Register" versteht und ob man einen Akku noch für zeitgemäß hält. :-)
Lothar schrieb: Und die 8051 kosten bei gleicher Ausstattung immer noch die > Häfte z.B. kleinster ARM mit USB ab 2.50 EUR und gleicher 8051 mit USB > 1.50 EUR Das der kleinste AVR mit USB viel teurer ist sagt eher was über > Atmel aus. Nö. ARM MCUs mit USB gibts ab 1,51 € auch bei Mouser: http://www.mouser.de/search/ProductDetail.aspx?R=0virtualkey0virtualkeyEFM32HG110F64G-A-QFN24 Die sind nicht mehr teurer als 8051ger.
Jim M. schrieb: > ARM MCUs mit USB gibts ab 1,51 € auch bei Mouser > Die sind nicht mehr teurer als 8051ger Das 8051 Beispiel war ein EFM8 von Silabs und Dein ARM Beispiel ist ein EFM32 von Silabs. Soweit ich das sehe hat kein anderer Hersteller so billige ARM. Trotzdem hat der EFM32 noch zwei technische Nachteile gegenüber dem EFM8 bei USB: - der EFM8 schafft Full Speed USB mit dem internen Oszillator der EFM32 braucht einen externen Quarz - der EFM8 unterstützt High Memory so dass der USB Bootloader direkt ein "normales" Binary mit Startadresse 0 laden kann beim EFM32 ist der Bootloader ab Startadresse 0 so dass das Binary Relocatable neu kompiliert werden muss für ab Adresse &4000
Christian S. schrieb: > Allerdings sieht es so aus, als ob der Trend zu ARM geht. Mittlerweile > gibt es ARMs für 30 Cent und die 8-Bitter werden immer teurer. Jetzt > habe ich mir den ARM mal angeschaut und die Programmierung in ASM > scheint wirklich eine Quälerei zu sein. Viel weniger Register, viel mehr > zu beachten und deshalb natürlich auch viel dickere Handbücher. Es sieht > fast so aus, als ob die Designer sich dachten, dass 99% der Welt die > Teile eh in C programmiert und die deshalb nicht mehr angenehm von > Menschen programmiert werden können. Dieser Absatz zeigt mir, dass Du die Konzepte und Ideen dahinter nicht verstanden hast. ARM ist so schlecht nicht, auch wenn sie damals beispielsweise das Interrupt-Konzept vergurkt hatten - den Fehler haben sie mit Cortex wieder ausgebügelt. Die YouTube-Videos mit Steve Furber (einem der ursprünglichen Entwickler bei ACORN) sind schon ganz nett. Manche Leute brauchen Papier zum Lesen. Denen sei das hier angeraten: http://www.amazon.de/Definitive-Guide-Cortex-M3-Cortex-M4-Processors/dp/0124080820 fchk
Christian S. schrieb: > fast so aus, als ob die Designer sich dachten, dass 99% der Welt die > Teile eh in C programmiert und die deshalb nicht mehr angenehm von > Menschen programmiert werden können. Nicht "fast". Genau das ist der Ursprung der RISC Philosophie. In den 70ern stellte man anhand von Analysen bestehender Programme fest, dass Compiler nur einen Bruchteil der Befehle häufig nutzen. Eine CPU mit schnellen einfachen Befehlen erwies sich als billiger und schneller als die damaligen komplexen CPUs. https://de.wikipedia.org/wiki/IBM_801
:
Bearbeitet durch User
Frank K. schrieb: > ARM ist so schlecht nicht, auch wenn sie damals > beispielsweise das Interrupt-Konzept vergurkt hatten - den Fehler haben > sie mit Cortex wieder ausgebügelt Das ist doch wohl eine Legende. Die Cortex A und die Cortex R für harte Echtzeit in Automotive und Industriesteuerungen haben genau das Interrupt-Konzept der ursprünglichen ARM. Für die Cortex M wurde ein neues Interrupt-Konzept eingeführt, weil sich die uC Programmierer nicht in der Lage sahen, für die ISR Assembler Wrapper zu machen, es musste alles direkt in C gehen. Das führt aber zu neuen Problemen: keine re-entranten ISR, ISR Einsprung bei korruptem Stack führt zu Hardfault weil keine FIQ Registerbank mehr usw. Nebenbei für den dann erforderlichen Hardfault Handler braucht es dann doch wieder einen Assembler Wrapper, der auch noch viel komplizierter ist :-)
ACHTUNG!!!! Schwanzvergleich!!!! schon allein die frage disqualifiziert ihn....
Lothar schrieb: > Das ist doch wohl eine Legende. Die Cortex A und die Cortex R für harte > Echtzeit in Automotive und Industriesteuerungen haben genau das > Interrupt-Konzept der ursprünglichen ARM. Das Interrupt-Verfahren der ursprünglichen ARM Architektur ist wirklich vergeigt worden. Interessanterweise gleich zweimal. Es ist dennoch verwendbar. Es wurde anfangs nicht an verschachtelte Interrupts einer Klasse gedacht (IRQ/FIQ). Die waren im jeweiligen Interrupt-Kontext nicht machbar, weil das kombinierte PC/Status-Register im Linkregister vom Interrupt-Kontext gesichert wurde. Man musste daher im Handler immer erst einmal auf einen anderen Kontext umschalten bevor die Interrupts wieder freigegeben wurden. Mit der Abkehr vom 26-Bit Programmadressraum und der Trennung von PC und Statusregister in ARMv3 war das so nicht mehr machbar und ein separates Sicherungsregister für den Status wurde eingeführt. Hätte man zu diesem Zeitpunkt ein analoges Sicherungsregister für den PC definiert, dann wäre der Overhead eines Handlers deutlich geringer und der IRQ-Stack voll verwendbar geworden. Da man dies unterliess blieb das Problem unverändert erhalten. Wesentlich später (ARMv6T2, ARMv7-A/R) wurden mit den neuen Befehlen SRS,RFE,CPS Nested-Interrupt-Handler deutlich vereinfacht und beschleunigt.
:
Bearbeitet durch User
Die besten Mikrocontroller kommen aus dem Hause Microchip ;-)
Автомат К. schrieb: > Die besten Mikrocontroller kommen aus dem Hause Microchip ;-) Nö, das war der PIC1650 aus dem Hause General Instrument. ;-)
Viel interessanter wäre doch eigentlich die Frage, welcher der schlechteste Microcontroller ist ;)
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.